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.
The main screen of Time Keeper
A few weeks ago I published the first version of Time Keeper for OSX, a time tracking desktop application written in Vanilla JavaScript. Yes, a desktop application written in Vanilla JavaScript is actually possible these days!
I chose to write it in JavaScript because building a desktop application was not the goal. The goal was to build an actual JavaScript application that I could make use of, on a daily basis. The fact that I wrote it as a desktop application was purely incidental to the fact that I had discovered NW.js (previously known as node-webkit) a few months before I started to write it. Without getting into any details about NW.js, let’s say that it allows you to write create desktop applications written in JavaScript, making use of Node.js modules, and calling them from the DOM of your application, just like in a web browser.
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.
In a recent project built in Drupal 7, I came across a bit of an uncommon scenario, by which some users needed to have access to certain features that were normally restricted to them, when viewing, editing or creating groups content (ie: whenever they are visiting a part of the site that is considered part of a group).
For example, while normal users didn’t have access to use certain text formats in the wysiwyg editor, those that were considered group leaders needed to make use of that particular text format. In this scenario, a group leader was an existing role within Organic Groups.
Image taken from https://drupalize.me
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.
In the last blog post, I started to talk about the process of upgrading the Viewport module from Drupal 7 to Drupal 8. While the module is now fully ported and has a stable version for Drupal 8, I didn’t cover all the steps and new things that I came across while working on it.
This time I’ll go through the notes I took while working on the settings page, the creation of a proper schema for configuration management, and the conversion of procedural code into PHP classes. Let’s get into it:
Image taken from Phase2 website
Viewport is one of the modules I maintain for Drupal 7. It’s a very small and simple module that does a very specific thing: it allows site admins to specify the values they want for the HTML meta tag that specifies the viewport settings for browsers. It also allows admins to choose the pages in which they want this custom viewport applied.
Back in the day a client required this functionality to embed some browser games that required very specific settings. Nowadays it’s not really common for a site admin to set those values, and developers don’t really require any UI to set them.
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
A few weeks ago I wrote a blog post about Yeoman and the existing Yeoman generators for Drupal. As someone who loves and rants a lot about code generation, it was a tool that I had been wanting to try out for quite some time, and the experience after having spent a couple of hours with the tool, figuring out which generators could be useful for me, was rather satisfactory.
Now, beyond having some generators that I can benefit from, my interest in Yeoman was mostly in the APIish side of it. In other words, I wanted to see how easy it is to create my own generators for whatever tasks I find myself repeating a lot. The best way to find that out is, of course, to try and write a generator plugin for it, facing the usual challenges of being a total newcomer to a language or a framework. One of the most common pieces of code I have to write in my projects, are ctools plugins, in particular, Content Type plugins, so I decided to write a generator for just those type of plugins. This post will explain the basics of the tool and how to create a basic generator. If you want to get the most out of it, I’d recommend you to open your IDE or text editor of choice, and follow along, so that you can experiment with Yeoman at the same time.
One more year, DrupalCamp Spain is getting closer and closer. This year, it’ll take place in Jerez de la Frontera, and it’ll be during the second half of May (22nd, 23rd and 24th of May, to be precise). Last year’s camp in Valencia was a bit of a miss for me, as I had some troubles with the schedule, and could only attend to a couple of sessions, so I’m more excited this time, given that it’s been a while (2 years, I could say!) since my last DrupalCamp. And it’s always a great pleasure to meet and talk to friend made on previous camps, as well as new people of the Spanish community. Continue reading
