After 5 years and 8 months of hard work and joy alongside the wonderful team at Code Enigma, last March I decided it was time for me to move on to something new, stretch myself a little bit, and discover some new grounds in the Drupal world.
Last week I finished Robert C.Martin’s The Clean Coder: A Code of Conduct for Professional Programmers. It had been on my shelf for a year and a half, and last year I even started it and got halfway through it, but ended up forgetting it for some time. Until last month, when I decided to start it again, but this time, going cover to cover.
Chances are that you’ve come across it before, at least once. If you haven’t, then I’m happy you’re reading this post now. If you have, but it didn’t arouse an interest in you, then let this post serve as a reminder to you, software developer, that it is probably one of the few must-read books that you need to read. You might not agree 100% with everything that is said in the book, although you’ll probably agree with a big chunk of it, and if you’re like me, you’ll realise about things that you never thought of before, and you’ll find some other aspects of your job where you can still improve. One way or the other, I can’t recommend it enough.
With most books (technical ones, at least), I like to do a quick recap of the things that I liked most, or that caught my eye for some reason. I won’t do a review of this book, but I wanted to list here some of the quotes that I found more interesting. Not because they looked very poetic but because of the principles and attitudes they show towards the software development profession. So, let’s get straight into it.
Excerpt from the preface. On political pressure and experts’ advice:
Despite all the protest and memos, and urgings of the engineers, the managers believed they knew better. They thought the engineers were overreacting. They didn’t trust the engineers’ data or their conclusions. They launched because they were under immense financial and political pressure. They hoped everything would be just fine.
With parts one and two of the series covered, this 3rd (and final!) part will cover some other important aspects of Drupal development that I wanted to pay attention to while working on the Drupal 8 version of the viewport module.
Essentially, the kind of aspects that are easy to forget (or ignore on purpose) when a developer comes up with a working version or something “good enough” to be released, and thinks there’s no need to write tests for the existing codebase (we’ve all done it at some point).
This post will be a mix of links to documentation and resources that were either useful or new to me, and tips about some of the utilities and classes available when writing unit or functoinal tests.
A few weeks ago, I wrote a blog post about what the first quarter of 2015 had been like. That was, in a way, to track my progress on the different projects and objectives I had set out to complete during the year. It was also a way to remind myself that I should keep working on them, and structure a bit better the time spent on each one. However, I wasn’t completely honest when writing up that list. And when I say completely honest, I’d like to stress the first part of it.
Yes, that’s right: completely. Of course there wasn’t a single dishonest bit on that blog post, but it’s fair to say that the list of objectives wasn’t 100% complete. I deliberately left out an important one: I wanted to speak at a conference, too. But that list was meant to cover the second quarter of 2015, and I wasn’t confident enough that with all the other things I wanted to do, I could also prepare a presentation for a software conference. I chose the easy thing: leaving it out the list wouldn’t require that I took action on it. Everyone knows that if you don’t write something down, you’re not commiting to it! Continue reading
2014 wasn’t a bad year. I could say it was a reasonably ok year for me in some aspects, althought I didn’t make, by any means, as much progress as I wanted in many of my side projects. To say that I got a bit stagnated would be in fact to say too much, though, because while I didn’t progress as much as wanted in some things, I did progress on other things not initially planned.
That raised for me an obvious thing (or two) to address as soon as possible: planning and focus. Planning, so that I have a clear path to follow in order to achieve what I want to achieve, and by the time I want to get it done. Focus, so that I can successfully push out of my plate anything that is not related to the things I want to do or the things I want to learn. Or, seeing it from a different perspective, so that I can avoid one of the endemic ills most software developers out there suffer: (not) finishing things. While I don’t consider myself a non-finisher, I truly believe I can become a much better finisher. Continue reading
Yes, the title is right, and no, I’m not embarassed of saying that I’m finally making use of this blog, and that it all has happened, in part, thanks to a free 3-week blogging course from John Sonmez that I recently signed up for.
So who’s that John Sonmez guy? Well, I came across his website a few months ago, when reading one of Derick Bailey’s newsletters in which John’s site (Simple Programmer) was linked, or mentioned in some way. The first thought that struck my mind was that the site was probably some kind of developer community, given the visual design and the topics of some of the posts, but I was totally wrong. It was “just” his personal blog, and I have to say a rather good one, because all the materials and professional advice one can find in there have an incredible value.
I’ve been recently trying to get back to blogging. In fact, I’ve beeen recently trying to do what I set out to do more than one year ago, when I created and launched this blog. For a number of reasons, which I may or may not cover in a future post, that intent has been replaced or delayed for quite some time, but it seems that I’m finally taking action to solve that.
One of the reasons that made me become a bit lazy on the matter, was the “hassle” to maintain the platform that I chose for blogging: wordpress. I’m not complaining about wordpress itself, which is a great blogging tool. However, having been a drupal developer for a few years now, I’m rather used to Drush. In the unlikely event you, the reader, don’t know what Drush is, I suggest you go and read the first paragraph of its readme, but to keep it quick, let’s just say that drush is “a command-line utility for drupal that let’s you tackle all maintenance and deployment aspects of a drupal project during its entire lifecycle.”. That’s the simplest definition I’ve come up with in a few seconds. If you don’t like it, I have others, too.
This was meant to be an entry in the past. In fact, it was an entry in the past, but it’s not that anymore… I know what I mean.
The fact is that since that October 20th, in 2013, I’ve learned plenty of things. Just to list a few:
- Despite what you might think, leaving your server unattended for several months, is not a good idea.
- Forget to sort out the misconfiguration bits you know left behind after installing new software in it, which you promised yourself to fix the day after, is not a good idea, either.
- The sysadmin of your company won’t fix your badly broken MySQL server with a severely corrupted ib_logfile0, no matter how much he likes you or you like him.
- If you have bothered to write a silly script to take nightly backups of stuff, push them to a different server, and rotate them keeping the last X backups taken, *do* activate it. Your future you will feel less miserable. 100% ego back guaranteed if things go wrong.
And many more, but you get a rough idea with that. I’ll try to put that knowledge in practice more often. Or not, who knows. In any case, purpose of the blog remains the same. I’ll probably write some more stuff than I used to, though.