Making Sense, First Week
We just landed in Entebbe, Uganda. I’m filled with a childish glee as I envision our driver holding a board with our names on it. What I see is a scribbled name on scrap paper, but the DIY sign is endearing. I’m giddy with excitement about traveling far from home — again.
In Kampala city, we enter our lavish apartment to find our investor, Ed, working away at his laptop. The place is immaculate. Better than I ever could have hoped for. Nicer than my apartment in Vancouver. Jamal and I each have our own rooms and bathrooms. There’s air conditioning to fight the sweltering 30-degree weather. The internet is the fastest possible in Uganda (6Mbps/~750KBps), unless you’re inside the actual telecom building.
Friday morning, Ed takes us for breakfast and we cover the important aspects of the project. What to do first? What aspects of the system need the most attention? Are we refactoring old code or rewriting new code from scratch?
We walk 10 minutes to the office, taking in the surroundings.
Our first minutes in the office are all smiles. We get a quick tour and meet the employees. When we’re introduced to the two other developers at Ensibuuko, Roy and Dave, we get straight to work.
The current system is a straight-forward CodeIgniter project. That’s a micro PHP framework, coincidentally maintained by BCIT (the British Columbia Institute of Technology). There have been several devs on the project, and a quick scan through the code shows that the project will benefit from some strict naming conventions and coding guidelines. So I whip up a tailor-made cheat sheet:
We also decide that a rewrite makes the most sense. Nobody is ecstatic about the current code-base, and the local developers admit that regressions are common due to the historic inconsistency of developers. I don’t drill too deep into the architecture of the app, and I anticipate that a re-think should accompany the re-write.
I also recommend the code be rewritten in the Laravel framework. Laravel is PHP’s answer to Ruby on Rails. It’s a mature, robust, full-featured MVC framework, and it features close to a thousand top-notch instructional videos at laracasts.com. The devs here know PHP, so it seems a logical step forward from their CodeIgniter past.
In choosing the tech stack, I had to face a couple complaints that I’ve heard from the students and (sometimes) mentors where I work at Lighthouse Labs:
- “I don’t want to use a framework because there’s too much magic going on”
I understand the sentiment here. Junior developers want the full picture, and `link_to` statements, for example, abstract from the underlying HTML you would otherwise write. I too wrote my own micro MVC frameworks in the early days, due in equal parts to my stubbornness, lack of perspective, and fright at learning something large like Laravel (~500 pages of documentation). But spending significant time writing low-level code is a small regret of mine.
While writing your own micro-framework provides insights and awe at the inner-workings of a legitimate work of art like Laravel, it’s not directly productive. Work smart, not hard.
Stand on the shoulders of the giants who have come before you. Use Taylor Otwell’s incessant work on Laravel to your advantage. Otherwise you will spend ten times as long as the dev next to you, writing buggier, less extensible code. At least for your first 5-10 years, by which point the world will have changed around you.
- “PHP sucks.” — “I’d rather die”
I hear this one a lot. From students and mentors. But this kind of elitist programming vitriol always strikes me as peculiar.
Most gripes against PHP seem to stem from the following:
B) It’s slow. Really it’s Apache that is slow, at least relative to its handsome brother nginx and distant node cousins.
C) WordPress uses it, and WordPress is gross. Huh? This argument is the most confused of all. WordPress may be sluggish with awkward quirks (a topic for another day), but its authoring in PHP says nothing about PHP itself.
There are other arguments and issues, but they either stem from early versions of PHP, or can be overcome with HHVM and self-discipline.
In my humble opinion, a thousand things matter more than the language:
- Core programming: do your developers write modular, DRY code? Do you follow Object Oriented Programming principles (assuming you’re going the OOP route)? Do you architect to interfaces rather than concrete classes? Do you keep your languages separated? Do you follow conventions as a team? Do you leverage the framework or rewrite boiler-plate?
- Database: Do you eager load your database queries or hammer MySQL for every related object in a collection? Are you full-text searching over joined tables on every keyword search? Is there any query involving joins that would benefit from a search index table?
- Are you getting a good night’s sleep? Eating your vegetables? Meditating regularly?
You get the picture.
So we’re writing a Laravel app. In PHP.
It’s been a breeze and things are going great so far, thanks for asking.