Guest Post by Eugene Mutai
There’s a famous quote around the internet allegedly extracted from one of Bill Gates’ interviews, “I choose a lazy person to do a hard job. Because a lazy person will find an easy way to do it.”
Before you break it down, I’d like to state that this quote is taken for granted by tonnes of people. Please remember he stated “lazy” but nothing about that person being smart, intelligent and hard working, which, metaphorically relate to his “lazy” meaning.
Let me then move on to add one more piece of advice that was passed to me when I once told my soft skills tutor, Ashton Coghlan, “I plan to be one of the best in the current industry,” after which he stated “You could be the best, but one person alone cannot change the world, let alone in time. He/she needs a whole team backing him/her up.”
If you think about this and try to fuse both of these statements, you’d conclude, you need a “lazy” team to get things done, or change the world, if you, like me, see yourself as a superhero and not just a developer.
So then, let’s narrow down the topic to building great applications that change the world. How would a “lazy” team go by easily building really great and superlative applications such as Uber, AI, Rhino Tracking systems, Ushahidi, BRCK, Github, superhero costume online shop and so forth which are really hard to do.
There’s a lot that is required besides building the application itself, but as developers one of the things that would pop up, being biased technically, is having a great pool of tools that we are fools for to build a product that the world would drool about (hope that rhyming didn't suck).
For example, we’ve always wanted to build a superhero registration tool since we need these heroes to come out of hiding, coz it’s about time. I’m tired of watching their movies (On a side note avengers was dope!).
We’d want to build this tool really fast. In 2 weeks, to be precise. We’d have to use a framework, it would have to be one that the whole team knows. A full-fledged framework would come with a templating engine, ORM driver, database migration, seeding, a HTTP routing system and an elegant way to modularise our application’s logic using controllers or middleware. Oh yes! Security built in thus taken care for us. Sadly superheroes are pretty powerless when it comes to the internet.
Hold on to your seat or screen. I feel you’re about to get lost.
Having 2 weeks, we’d opt for a HTML5/CSS bootstrap library to come up with a UI real quick. We’d also require a front-end library to do form validation, a little animation, a slide show, and voice recording section to get the catch phrases of these heroes eg. “I’ll be back” by Terminator, not so sure he is a hero, but oh well, it’d be so cool!!
At this point, you’re definitely lost. If not let me try harder.
Are you lost? Honestly, I believe you should be. If not, we’re almost close to the end. If you are, I stopped fooling around in the last 2 and a half paragraphs.
There’s something very important I’ve left out. When working in a team, we’d use the SCRUM/Agile methodology. In simple terms, this means splitting up the goal tasks, into lists of micro-tasks that should be done to accomplish the ultimate tasks.
So how would the team work on one major task and still be in sync with each other in every step. One word, Git flow. This is using a VCS(version control system), git in this case, to track every progress/changes made, and to be able to fix the differences in a file that were made by each member of the team. Simply known as merging or fixing conflicts. How did we end up having conflicts within some files? Each developer in the team, worked on a feature branch and neither bothered to look at what the other member was doing. This sounds ignorant, but it actually isn’t.
Why? Because each of functions, as many as they are, of a feature created, comes with a set of tests written by the developer to ascertain his features work well and every function does what it supposed to do. This is known as Test-driven development (TDD). We’d also love to add end-to-end testing (E2E) close to the end of the project, to automate the testing of a feature fully. For example the sign-up feature is expected to capture the superhero’s information, store or process, and a response sent back to the hero to assure him/her that will call them, mostly scream for help, when we require them.
Ok. Let me stop right here. I’d love to talk about continuous integration and deployment, being the final route our application travels to get exposed to the superheroes in the internet but I believe I may have lost you a long time ago. Sadly, I can only explain all this to you when you come on Thursday, October 8th for the iHub Craftsmanship Training, where we’ll start with tools, mentioning really awesome ones, and explain why, how and when to use them.
If you do come, I promise to show you how far we are. I know you don’t want to know this, but Clark Kent is our beta tester(Oh! we got him google glasses; dorky spectacles are sooo ancient).