I've spent the last couple of months working on an API written using Python, Django, and Django REST Framework (DRF). The latter is a popular, well-established framework for building APIs in Python, so I assumed it would have decent documentation surrounding relational fields, which is a fairly common situation in any model-view-controller (MVC) framework. It turns out that was a faulty assumption.
Move your company to the next level and allow your business to organize, manage and act on the massive amount of data that arrives every second.
Enterprise software often gets a bad rap from a user experience perspective, but it doesn't have to! Here's how we helped increase productivity for one client and their users by improving their system's UX.
What if I told you that technical debt could turn out to be the grim reaper itself, jeopardizing all of your hard-earned growth and success?
The stars have aligned, and you’ve gotten the go-ahead to significantly overhaul some software. Figuring out if you should blow away the existing code and start from scratch, or if you should just rewrite parts of it instead, can sometimes be a challenging and difficult decision.
By now we're sure that you've heard that the Python programming language is undergoing some big changes. It's true the developers who created Python 2 are no longer supporting that version of the language as of January 1st, 2020. Yes, nine months ago! They are encouraging everyone to upgrade to Python 3 but what does this mean for your business?
During a recent Legacy Code Rocks virtual meetup, a community member shared that a senior colleague had recently rejected a request to change a variable name. I used to encounter resistance to refactoring all the time, but since starting Corgibytes, I don’t come across it as often. But I’m curious if there are others out there who have encountered this sentiment, and I’m especially curious about how they’ve dealt with it.
I often encounter software projects that have absolutely no automated tests. This is rarely because the development team feels that authoring tests is a waste of their time. It’s most often the case that the team would love to have automated tests. If you feel like your project or team is stuck when it comes to automated testing, then I’d like to provide some guidance and specific techniques for how to get started.
Software systems can find themselves in a state of "rock bottom." When we encounter projects like these, we need to channel our inner monk. Start where you are. Eliminate the shame that goes with having a messy codebase. Embrace that your system is worth investing in and start making it better from where you are today.
Wouldn't it be great if there were a documentation tool that's directly tied to the source code (so that you can always access information that's relevant to the code you're looking at), that doesn't clutter up the code itself, that's carefully and automatically timestamped (so that you know how current its information is), and that's guaranteed to be updated whenever the code is? Oh, wait. There is.
This wasn't the sexiest project we've ever worked on, but a combination of good tooling, careful preparation, and a fair amount of mind-melting compiler error resolution made this a one of our best remodeling efforts of 2018.
If you want to eliminate your technical debt, communication HAS to be a critical component of your efforts. If you're struggling to break up your monolith and move to a microservices model, the first place to look is how your team is communicating. Command and control silos will result in monoliths. Self-organizing and autonomous teams give rise to microservices.
In many ways the Ship of Theseus paradox is quite similar to software development. Is this app the same one it was five years ago? How about two? What about after the massive refactor we *just* finished? If it still serves the same business users in the same capacity, but we rewrote it, does it matter?
Your software isn't working the way you'd like. What should you do? Scrap everything and start over or slowly transform your application into something more in line with your vision. In this post, we explore the differences, strengths, and risks of each approach.
Software is one big party! The question is: When's the optimal time to pause the partying so that you can restock and clean up? Well, it depends on who you ask.
In my last blog post, I explained why metaphors are so important and how they can help raise our chops (and our hopes) when it comes to influencing the business side of things. The Seat Belt metaphor used in my previous example may have worked great for some, but not for others. Keeping a few different ones at the ready helps you adapt on-the-fly and better connect with whomever you’re speaking with. Another one of my favorite car metaphors to use is inspections.
Over the years, I've heard a lot of different attitudes regarding code that’s going to be thrown away. Let me be clear here. I’m not talking about code that we think might get thrown away. I’m talking about code that we know will get thrown away.
Is your code difficult to work with? Chances are, it’s time to get rid of code you don’t need. That can be a scary prospect, but the rewards can be well worth the effort. Recently, I was inspired by KonMari, a technique for decluttering physical spaces, to help me visualize how to refactor codebases to make them easier to work with.
“How would you rate yourself as a programmer?” They always have to ask THAT question in job interviews. And I hate it. So much. Why do I hate it? Because I know they won’t like my answer. But what am I supposed to do, lie? Nope. I have to be honest. Which is why I take my time before responding. I take a deep breath, look deeply into the eyes of the interviewer, and, finally, I say: “Average.”
My dad is a self-described contrarian and eccentric. I love that about him. He doesn’t ever do something because that’s the way you’re “supposed to.” He’s also incredibly driven and energetic. He’s a fixer. If he sees a problem, watch out. If it aligns with one of his passions, he’ll put all of his energy towards finding a solution.
The process of renaming models in Rails can be very error prone. To just start renaming files and changing class names and search-replace variable names is fraught with peril -- so I figured having the ability to repeat the process, in essence fix my scripting mistakes and “do-over,” was important.
Estimates are useful. They help business owners predict and control their budget, scope, and timelines. Right? Well, not always. Over the years, we’ve learned that there are some projects where estimates work great and others where it’s a disaster.
One of my current projects' Rails application is hosted on AWS OpsWorks. OpsWorks is a lower-cost alternative to Heroku and EngineYard that still provides a full-suite of features, from deployment to scalability and fail-over. As with most Rails applications, this application requires background tasks.
When I was interviewed by Corgibytes for a lead developer position, I was asked who were my role models. I responded David Heinemeier-Hansson (DHH) and Kent Beck. I expounded: DHH because he is a business developer rather than a computer scientist and he has great ideas about achieving excellence while maintaining a work/life balance. And furthermore Kent Beck because, as brilliant as he is, he still sees himself as a coder. Whatever.... The thing is, I lied.
When a JavaScript project comes our way, we’ve found bitHound to be a fantastic tool to help us understand where we can have the most impact on a project. We love them, and not just because their company also has a dog in their name. So what makes bitHound stand out from other static analysis tools out there? We’re glad you asked.
While it's true that there are many software developers who do enjoy starting with a clean slate, there is also a group who loves working on making existing applications better. Rather than starting from scratch and building an 80% solution, these developers are ideal for taking over a project once it's become stable, and nurturing it for a long time. Neither developer is better. Both are needed in the software world. You just need to understand when to use each one.
There's been an interesting case winding it's way through the court system in the United States over the past few years. The outcome of the case is hinging on one small question: Can you copyright an API?