Before looking at the book itself, it’s interesting to see that the author is a serial-oneliner-author, if I can say: Perl One-Liners is his third book on the topic, after Awk One-Liners Explained and Sed One-Liners Explained. I think Peteris bash history must look a bit scary to unprepared eyes!
So, as you can guess the book is about oneliners, those magic-and-cryptic commands some bearded sysadmins use everyday to tell their servers what to do (Wait? This last sentence is a cliché? No way!).
The book’s cover looks nice and fresh, I must say the first impression is good, it’s nice to see new Perl books published with nice and eye-candy artworks. Speaking of the artwork, it’s funny to see that a one-liner is here associated to a telegram machine, as if this was the antic way of communicating with a computer. Or maybe that’s more about the compact size of the instruction sent. Anyway, let’s look more at the content!
A quick glance at the table of contents tells everything: this book is a cookbook for the sysadmin. The title tells no lies, it’s not a guide to enlightened modern Perl programming, but more something like: How to use Perl as a swiss-army knife, on the command line. Which is indeed another interesting angle to look at Perl.
The table of contents gives the full overview of what you can find: one-liners grouped by topics (Spacing, Numbering, Calculations, Array and Strings, Text Conversions, Printing and Deleting Lines, Regular Expressions).
I won’t comment on all the one-liners (130 of them in the book!) but I can say that this book can be a good companion to learn how to use Perl on the command line.
By reading this book and trying the recipes, you’ll master shortly all the command-line options that can turn the Perl interpreter into a sed-awk-grep-toolboox-on-steroids. Indeed, here is the real lesson you’ll find in that book: beyond the 130 examples, you’ll get to understand how and when to use flags like -p, -l, -i or -n, which will let you write your own one-liners in no time when needed.
If you want to control the LED of your Android phone, you definitely want to give a try to Light Manager.
It’s as simple as it sounds: you can pick whatever color you want for quite every kind of possible notifications. I like also the fact that you can pick a color for the state of your battery: in charge, critical or completely charged, that’s nice.
Simple design, does just what it claims to, and free!
Every day at work the same routine takes place: you take off your coat, grab a coffee, sit down at your desk and log into your workstation. First things first, you start looking at your inbox. It’s full of unread emails, as always, the bold “291” is like a stressful reminder that you failed at processing that inbox, you’ve long gave up on the idea of reading them. Without really noticing, you’re only focusing on the latest emails you’ve received, trying to find clues about things to do in that mess.
An email got your attention, it’s a bug to fix, soon enough, a terminal pops up to your screen and you start hacking into the code, trying to find out where that bug is hidden. It takes you a moment to get into the code, to load the context into your brain, reminding yourself all the details about that program. But as soon as you feel you can touch a lead, your email client sends a notification to the upper-right corner of the screen: “New Email”. It’s your boss, he wants a summary of the meeting you had yesterday with the database admin guys. You forgot to send it right after the meeting. No more hacking, you need to do that report now, the fear of forgetting again is stronger than the priority of that bug. All that time you just spent fitting the code into your brain? Pure loss of time. But wait, what was that meeting about by the way?
It’s likely that this little slice of office life rings a bell to many. Even though I’ve read Getting Things Done and many blog posts about it, tried many todo-list tools, used Evernote, experimented with zero-inbox or even tried to use principles of The Secret Weapon, I never found a good, not-overkill and working implementation of GTD that fits with my daily routine.
The challenge is there: GTD is a very clever strategy, but it’s more about a design pattern than an algorithm, it needs to be implemented by yourself, adapted to your environment and crafted with the appropriate tools.
I think I’ve finally found the right implementation for me, and as it’s 90% thanks to a very well designed tool, I guess many of the people that read that blog post could do the same.
Before going into the details, it’s important to have the GTD principles in mind, I strongly suggest to read David Allen’s book but we could summarize the core of the strategy as follows.
We constantly get input of things to do: emails, phone calls, meeting notes, colleagues interruptions, even coffee-break discussions can lead to new items to process. The main idea of GTD is to acknowledge that this is normal and constant, and should be controlled instead of being controlled by it. We need to collect items to add to the list, on purpose, organize them and process them. And loop that way all day long.
Once we have collected all the possible items, we need to filter them with a simple question: “Does the item needs an action?” If not, archive it. If yes, another question is asked: “Does the action needs more than 2 minutes?”. If not, do the action and archive the item. Once you’ve filtered all the collected items this way, you end up with a list of items that needs an action that needs more than 2 minutes. Another filter can be applied: “Do I depend on someone before I can address that item?”. If yes, organize it under the waiting label, with the name of the person who you depend on. Another question: “Can I do the action now?”. If not, organize it under the Later label. At this point, all the remaining items are things to do, today.
You start then doing them, and flag the items as “done” when they are. When all the items are done, start collecting again, organizing and processing. This is the virtuous circle of GTD.
The implementation: InboxZero and NirvanaHQ
NirvanaHQ is a software-as-a-service that provides a GTD-oriented application for managing things to do. Combining it with your email client is the implementation I’m going to describe here.
Your email client is the main tool through which things to do gets in. The idea is to combine the “Inbox Zero” idea with GTD: when you open your email client, the rule is to archive all the emails: if you can reply to them, do it and archive, if you can’t, bounce the email as an item in your NirvanaHQ account. Soon, you won’t have any email left in the inbox. Close the email client and switch the the “Organize” phase in NirvanaHQ.
Process all items and classify them: actions that depends on someone are dragged onto “Waiting”, things that’s can’t be addressed now are sent to “Later”, things that can be done today are sent to “Next”. That’s it. Now you have all the newly collected items organized, just pick the “Next” list, that’s your todo list.
Once all the items in the Next section are done, you’re good to loop back to the collect phase, and start over. Once a day, probably in the morning before tackling your Next items, you can go over the Waiting, Later and Scheduled lists, and reorganize them if needed.
Basically it’s as simple as that, the power of NirvanaHQ is its elegant and lightweight design. It just does GTD and nothing more. Very handy and easy to adopt, fits perfectly with an InboxZero routine.
I received an email from a recruiter which really made my day. I was going to reply in a somehow sarcastic way but realized it would be better to do it on my blog.
Indeed that email is so wrong it makes a perfect example of recruiters mistakes when it comes to hackers hunting. He won’t get a reply from me, but I’ll have a funny post to share with you, I hope!
First things first, let’s have a look at the email I received, the French version and its translation.
Je me permets de te contacter après avoir vu ton profil github.
Je suis recruteur pour le compte d’une start-up parisienne dans le domaine des réseaux sociaux.
Je recherche actuellement un profil de développeur ruby expérimenté.
Pourrais-tu être intéressé par un nouveau poste de ce type aujourd’hui?
Voici quelques éléments sur l’environnement technique lié au poste (ce ne sont pas forcément des pré-requis), sachant qu’on cherche à la base un profil avec un bon socle Ruby / RoR:
Elastic Search, HAL, Angular.js, Backbone, MySQL/PostGreSQL, API réseaux sociaux
N’hésites pas à me contacter si tu es potentiellement intéressé.
It could be translated to English as follows, but the strongest mistake here is not something we can keep in the English version: he uses the casual way of speaking to me, the tutoiement. It’s really not common for a first professional email.
I’d like to get in touch with you because I’ve seen your github profile.
I’m a recruiter for a parisian startup that works in the social network field.
I’m currently looking for an experienced Ruby developer.
Would you be interested in such a job position?
Here are some technical details related to the job position (it’s not prerequisites), given that we’re looking for someone with a strong background in Ruby / RoR: Elastic Search, HAL, Angular.js, Backbone, MySQL/PostGreSQL, social network APIs.
Feel free to contact me if you’re interested.
As I said, the first huge mistake here is the tutoiement, this emails sounds like we know each other, a minimum, but we don’t. First bad impression: it makes me feel like a 14-years-old teenager who is asked by a teacher to do some kind of homework.
Let’s look at the content now, first sentence: second mistake. GitHub is not LinkedIn, obviously, the recruiter didn’t read that blog post. Even though my GitHub profile could be a lead, it’s not sufficient to know if I’m a good match for a job position. My GitHub shows part of the code I’ve wrote and doesn’t give enough background to understand, where, why and how I wrote it. In no way can it be enough material. But we’re not even there, he didn’t even read the GitHub profile.
Here comes the third mistake: “experienced Ruby developer”… Well, a quick look at my repositories shows very few Ruby-related material. Worse, it’s almost only Perl-related stuff!
At that point, it comes to mind that the assumption that I could be an experienced Ruby developer is very hazardous.
The last mistake is for me the fact that obviously the guy didn’t Googled me or looked for my LinkedIn profile. He obviously has no idea that I’m currently managing the R&D team at Weborama and probably not interested into leaving that position for writing Ruby code for a startup.
At least the email made me write a blog post, so it wasn’t entirely a bad email!
I’ll be giving a Perl Dancer training at the Portuguese Perl Workshop. It will take place on October 25th at Portugal Telecom. If you happen to be around, feel free to come! More details on the website.
During the training we’ll build a complete web application, from scratch, iteratively and will discover each of the main features of Dancer doing so. I won’t spoil here more about the topics!
This will probably end up as a new GitHub repo, who knows!
I’m glad to be part of that event and will do my best to prepare an interesting training!
I’ll post a report on the blog afterwards, stay tuned!