When we put empathy at the center of our technology, human connection becomes stronger. Infusing empathy throughout your organization and development strategy can have profound positive impacts on customer loyalty, employee retention, and vendor service.
Integration tests? Unit tests? Acceptance tests? How do all these tests work together and what should you focus on first? We like to think of testing as a pyramid. The goal is to build an entire pyramid and keep it growing at scale.
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?