“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