When your business needs help with IT, it can be difficult to find the right fix. Technology talent is tough to find, and the best people always seem to be taken. Consider hiring a software development consultancy rather than going through an expensive, time-consuming hiring process that doesn’t guarantee you the candidate you want. Weigh the benefits against the potential drawbacks to decide what’s right for your company.
Doing soft deletes is a very common requirement or preference used in software development and it has many benefits including the main one of not accidentally losing data since it is never actually deleted from the database. The main approach to doing this is to add an IsDeleted flag to the database table and setting that to true instead of doing a hard delete. Simple enough and it works pretty well. The annoying part of using this approach comes when you have to add !IsDeleted to every single query you run against each table where you have implemented soft-deletes. Casey, a fellow Fairway-er (or Fairway-ian, Fairway-ite, ???) pointed this out as we started working on a new project. So we decided to treat this as a cross-cutting concern and implement it as an attribute that we can apply to the entities that we want to be soft-deleted. While we are still early on in using this new approach, so far so good.
A little while back I noticed that a GitHub user had forked SharpRepository and added some simple hooks into it in order to automatically index entities into Lucene when they are added, updated or deleted through SharpRepository. This was such a good idea that I knew we needed to get some proper hooks into the library itself. We decided to use an Aspect Oriented Programming approach and allow developers to decorate their entities with attributes that would hook into the proper part of SharpRepository to give them the controls they need.
I'm at a point in my project where I need to look up stuff. No doubt you're saying something like "Duh - programs need to look up stuff all the time, dummy! THAT'S NOT SPECIAL! TELL ME SOMETHING INTERESTING!"
Two developers. One Backbone tutorial. One of us is an avid hockey fan. The other is a bit of a sci-fi/fantasy nerd. Therefore, it only makes sense that the app we'll be building is a fantasy hockey league website during this tutorial series. Because seriously - who doesn't want to see Darth Vader vs. Sauron on the ice? An epic seven game series of elves of Lothlorien vs. stormtroopers of the Death Star? Yes, please. I'm sure there's a "one puck to rule them all" joke in here somewhere. I'll leave that exercise to you, dear reader.
A while back, I worked on a project that required persisting data to multiple databases. The requirement was to save some data to a Microsoft SQL Server (which hosted the billing application data) and save a different set of data to an Oracle database (which housed the database for the flagship Online Transaction Processing [OLTP] system). Both of the database servers were protected by the almighty firewall, valiantly protecting the valuable database servers from a variety of virulent violations.
Ailing attempts at alliteration aside, here’s a high-level diagram describing the application I’m talking about:
I’m sure you’ve heard of the 20% doctrine implemented by companies like Google.
In a nutshell, they encourage their developers to spend 20% of their time working on anything they want. The purpose is to inspire innovation and help keep developers engaged at the company.
I ran across this article in which the author makes an argument against using this development incentive. He argues that “100% of work time should be used for work and side projects should be done on your own time.” I’m sure I could write pages arguing both sides of this statement, but don’t worry, I won’t. I will however, examine one specific comment he made: “… it's better to find the right fit in a company that gives us work we're interested in 100 percent of the time.”
In the series opener, I wrote about “optional” software development practices like Test-Driven Development (TDD), Continuous Integration (CI), data migrations, one-click deployment and code review which are fundamental to how we build software at Fairway, but are often touted as optional and embraced by a small percentage of development shops.
In this post, let’s dig into one of the “optional” heavy-hitters, code review.
There is any number of reasons why code isn’t reviewed at all shops – every reason from the presumed time/cost commitment being too high, to just not understanding the true benefit or how to get started, to a general aversion to change. My two favorite reasons include protecting developer morale (i.e. developers can’t handle having their work critiqued) and naively thinking there’s no need/value since developers are producing a good product already. Oh brother. Perhaps worse than avoidance, though, are the truly unfortunate cases where the fears of the skeptics are the reality, where teams preform code reviews poorly. Here, a lively roomful of peers nitpick and bash away on Johnny’s code or, quite the opposite, the review becomes a total snooze session. In either case, the review is probably scheduled too late in the project lifecycle so there’s no time for anything constructive to be done in response. There’s absolutely no value – just wasted time.