Taking the time to understand a problem and design a proper solution is the best first thing you can do. During this process, you are essentially defining your program's logic and requirements. This will help you – and any other developer – a great deal when having to develop or use the software. It serves as a map, illustrating a high level picture of how your software works. Also, by exposing a design document before implementation, you will uncover any errors or mis-conceptions that you would have otherwise found during your implementation.Read More
Filtering by Category: development
I recently came across a blog post on a very popular topic in software development:
Technical Debt 101 by Maiz Lulkin
Most of the developers I know (myself included) would be the first to advise for a re-write of a legacy application. Likewise, most of the managers that I've worked with are always there to advise against it. They would say things along the lines of "This would take too long, we need this new feature yesterday" or "We don't have the funds or resources to support this right now".
While both sides have valid points (and are probably exaggerating their points for their own cause) the truth lies somewhere in the intersection of both circles in a venn diagram. This article - in my opinion - gives a description of what the venn diagram looks like. Maiz paints a detailed picture of what both sides argue and then goes on to explain what that intersection area contains. After reading his post, my doubts or uncertainness about re-writes have been silenced. A required reading for developers and managers alike.
Test-driven development (TDD) is a software development process that relies on the repetition of a very short development cycle: first the developer writes an (initially failing) automated test case that defines a desired improvement or new function, then produces the minimum amount of code to pass that test, and finally refactors the new code to acceptable standards.
Why I started doing TDD
There are two reasons why I started doing TDD:
Firstly – like everyone else – I've been noticing the buzz around it and how people rave that "everyone should be doing it". So I figured I'd like to find out what all the fuss was about.
Secondly, I recently started a new job where my team wants to start doing TDD on all new project. Fully supportive of this notion, I was assigned a new project and started my TDD adventure. What better way to start TDD then on a clean slate, right!
The part that attracted me the most to TDD is that it forces the developer to work around unit tests. In my honest opinion, unit tests are a critical part of software development. It gives the developer a sense of security that the code they just added didn't break existing functionality. When working on large projects with other contributors, stepping on people's toes is imminent. In situations like this, unit tests - along with continuous integration – can be like guide rails to help keep you in bounds and prevent you from releasing a new feature that might have inadvertently broken a existing features.
One thing is for sure, getting into the discipline of writing tests before writing any logical code takes some time. Especially for me, as I'm one of those devs that likes to start writing some code as soon as possible. But, once you get the hang of it, it's actually really helpful. It forces you to put some thought into the design of your code before you start writing any. The workflow that I'm currently using is:
- Start off by drawing a quick high-level data flow diagram.
- Class design with functions needed (just the stubs).
- Write my unit tests for each of the functions.
- Start implementing the functions.
- Commit on the completion of a passing unit test.
I also started using Grunt for running some general tasks.
These tasks consist of
- Running unit tests
- Checking for syntax errors
- Code sniffing for PSR2 code style validation
Coupled with a pre-commit hook, I am now sure that each commit is clean and free of careless errors. Code sniffing also allows for the codebase to follow a standard and prevents the project from turning into some scary mishmash of all the developer's preferred coding styles. For those interested, I created a initial Laravel 4 framework with my grunt setup on my GitHub. Feel free to fork it.
I really feel good about working with my new workflow. Knowing that my code is automatically being tested, sniffed and linted before each commit is comforting. Also,TDD keeps me on track with which functions I have to implement and what they should do.
If you're a developer thinking of whether or not you want to jump on the TDD wagon, I suggest you wait for the opportune moment and give it a shot. It might be frustrating in the beginning, but once you get used to it, it's really effective. I find myself becoming more productive as I have become better at writing tests, implementing and re-factoring my code and thinking before coding. It really is an efficient way of writing code.
After my post about Microsoft – and how much I enjoy using their products – I began to wonder: why are so many people still using their products?
I recently read this article by Mike Elgan and am now a firm believer that it's only a matter of time before Apple and Google become the dominant parties in the industry - even though they practically are already. I think Mike's prediction of how Microsoft will eventually lose all of it's strength in the business and enterprise markets is spot-on.
As of now, only newer companies are adopting the "BYOD" concept, as the legacy companies are still depending on Microsoft products to run their companies. The bottom line is, those old-fashioned companies will eventually be forced to make the switch if Microsoft continues going down it's current path. This is due to the fact that the majority of the population uses Apple,Google or Linux based devices. And if people are no longer using Microsoft based devices for their personal use, well then why would they want to use it in their work place?
The only way for Microsoft to survive is to adapt and learn from what Apple and Google are offering their customers. Because clearly, that's what people want.
Finally got around to setting up all the repositories on Github for Party Stream. There are several parts to the system and I'm really happy to say I have already received volunteers to work on some of them.
Here is a list of projects that are open for collaboration:
- Web App
- iOS App
- Phonegap App
GuidelinesIf you are working on any of these projects, there are some guidelines that I would like to follow:
ForkFirst thing's first, please work off your forked copy of the repository. Do no work directly on the repository on my account. If you are new to Github, here is a introduction to Forking.
Git FlowIf you haven't been using a good workflow with git, may I introduce: Git flow, the only workflow you'll ever need to know about! I use this religiously as it helps keep source control simple and easy - especially for collaborations. I will be using this on each of the projects and I suggest you use it on your forks as well. It will keep it simple when it comes time to create your pull requests. If you use Source Tree it actually incorporates git flow – which is really helpful. They have both windows and mac versions.
Pull RequestsWhen you're done working on a feature and are ready to bring it to the main repository, please make your pull requests to the Develop branch. Nothing should ever be merged into the master branch as it is reserver for stable releases (see git flow).
That's it for now, I will add more as the project progresses. Thanks ahead of time for all those interested in the collaborations.
Happy Hacking :)
UpdateOnce you're setup and ready to start contributing, we need to let everyone else know what you're working on. For this, we will use GitHub Issues.
If you see an issue that you'd like to work on, assign it to yourself. Otherwise, simply create an issue specifying what you are implementing and assign it to yourself.