“Probatura” (Spanish word): Test, trial, experiment.
If you’re a web developer, chances are that you’ve come across Emmet before. If you haven’t, chances are that you’re wasting time whenever you get to write some html in your favorite code editor or IDE. You should really check it out and see the options on the project page, but let me show you a quick example of how Emmet can help you. Let’s say you’re prototyping a simple page and know the markup you need. It would look like this:
Easy, right? Because you’re a cool front-ender with great and fancy text editors like Sublime or Atom, and fancy features like tag autocompletion, attribute suggestions, etc… surely just a few seconds to write. For you too, phpstorm guy, because nobody beats your all-terrain IDE, capable of even preparing pop-corn for you while you’re churning out the most beautiful PHP lines ever written with, you know… a real programming tool. Not to mention the vim players out there. You really are on another level of the game. HTML ain’t nothing for you, is it? Well, whatever built-in support you have for writing html, Emmet’s going to be better. Continue reading
One of the major disadvantages of entities in Drupal 7, is the lack of support for built-in comments. This is due to the model of the core comments module, which is heavily tied to nodes -node comments are essentially settings of each content type-, and not available for other entity types. In Drupal 8 this has changed already, and comments are considered fields that can be attached to any entity type.
For Drupal 7, in the meantime, there’s been a similar solution for a while, which is the reply module. The reply module leverages the Entity API to define a “reply” entity type, and offers a UI to create “reply” bundles. Then, via the Field API, you can add a “Reply” field to any entity type, choosing the reply bundle that should be used by that particular field. The flexibility that gives is huge, since it means that you’re not restricted to just a comment type for your application. Continue reading
I’ve been recently involved in a Symfony project where the login process had to support 2-factor authentication with Yubikeys for certain users of the application. This post describes the steps that I followed to implement this feature in Symfony.
Before diving into the details and code snippets, I’ll describe the two main requirements of the task:
- Not every user in the system has a Yubikey, so 2-factor authentication (2FA) is not enforced sitewide.
- The fact that a user has a Yubikey and is required to authenticate with it, is private information, which means a partial authentication has to be performed before asking the user to perform the Yubikey authentication.
- Basic authentication is already implemented in the application against an LDAP instance, via the IMAG LdapBundle.
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
Not an actual representation of myself
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.
Life before Code Generators
I love automation.
It’s something that lives deep inside me, and I always seem to seek it as hard as I can, even when dealing with the most trivial things. Yes, even those things for which automation might not even give huge benefits at all. That is, perhaps, because I just fit in the prototype of lazy developer who wants to reduce the work to do as much as possible, or simply because I like the challenge of grabbing a problem that requires some hours and several steps to get solved, and turn it into a trivial matter that can be done in less time, by anyone.
And that’s what I did a year and some months ago, when I wrote the Field Type Generator module for Drupal 7, which I’m releasing today. Depending on your background, and the processes and tools that you use for Drupal development, this might or might not be as great a tool as it is for me, but I can tell you that in my case, it’s a little gem that has saved me a lot of time over the last year.
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.