Month: July 2016

Composer magic

Now that everyone is super comfortable with composer, I thought I’d share these two gems which I didn’t know or think about.

composer info

This command lists all of your packages installed with composer.  This is super handy if you want to include a page in your project, listing all the libraries and versions which are currently installed.  It also gives you a description of each library as provided by the package.

composer outdated

This command lists packages which you are using, which have updates available.  With this you can have a better understanding of what will happen if you run composer update (depending on your composer.json of course).

Update (July 21, 2016): Guess what? There is even a way to combine the two with one command: composer info -l .  This will list all the packages, with their versions and descriptions, and with an additional column of the latest version for each package.

10 Favorite Job Interview Questions for Linux System Administrators

As someone who interviews a lot of people (mostly for the web development positions though, not system administration), I’m always looking for more ideas on what to ask the candidates.  Today I came across “10 Favorite Job Interview Questions for Linux System Administrators“, which has a few of bits that I liked.

First of all, this GitHub repository is super awesomeness.  It also links to a few other resources with more questions and ideas.  Not only for sysadmin interviews.

Then, this one is funny, yet somewhat challenging:

2. Name and describe a different Linux/Unix command for each letter of the alphabet. But also, describe how a common flush toilet works.

It also checks that you know the alphabet.

9. Print the content of a file backwards.

“I like broad questions where each person could give a different answer depending on their depth of knowledge. My personal answer is 8 characters not including the filename.” – Marc Merlin, Google.

This one caught me by surprise.  My immediate thought was “tac some_file“, but that’s obviously not enough.  tac only prints the lines in reverse order.  Which is not the same as reversing the file.  Perl to the rescue, but I wonder what’s the most elegant way to do it without the scripting language.

As always, interview questions are not only useful for the interviews.  They are a good measure of your own knowledge gaps and habit pitfalls.  This time was no exception.

The History of the URL

The History of the URL is a brilliant compilation of ideas and resources, explaining how we got to the URLs we use and love (or hate) today.  In fact, the article comes in two parts:

  1. Domain, protocol, and port
  2. Path, fragment, query, and auth

Read them in whatever order you prefer. But I guarantee that you’ll have a number of different responses through out, from “Wow! I never knew that” and “I would have never thought of that!” to “No way! I don’t believe it“.

And here is one of the bits that made me smile:

In 1996 Keith Shafer, and several others proposed a solution to the problem of broken URLs. The link to this solution is now broken. Roy Fielding posted an implementation suggestion in July of 1995. The link is now broken.

After a year of using NodeJS in production

There are days, when I feel jealous of all the young kids playing around with new technologies.  I need a certain level of stability and acceptance of the technology before I can apply it to client projects.  And I need time, which is a very scarce resource lately.

And yet there are days, when I feel good about being somewhat reserved and conservative in my technology stack choices.  Reading this blog post makes me feel just that.  Of course I need to try it out for myself and shape my own opinion, but with my lack of time, this should do.

I spent a year trying to make Javascript and more specifically Node work for our team. Unfortunately during that time we spent more hours chasing docs, coming up with standards, arguing about libraries and debugging trivial code more than anything.

Would I recommend it for large-scale products? Absolutely not. Do people do that anyway? Of course they do. I tried to.

I would however recommend Javascript for front-end development such as Angular or React (like you have another choice).

I would also recommend Node for simple back-end servers mainly used for websockets or API relay.

Now if only somebody wrote a similar post about Docker …

Why Some People Get Promoted (And Others Don’t)

I enjoyed reading the article “Why Some People Get Promoted (And Others Don’t)“.  Unlike many other in this domain, it is simple, direct, and to the point.  TLDR version:

  1. Do great things.
  2. Tell people.

There are quite a few links to external resources, with research and insightful quotes.  Here are a couple of my favorite bits:

‘[S]ent does not mean received’ is a profound thing. Half of your job in this studio is doing your work, the other half of your job is communicating that it’s been done. Because if you do it, and I don’t hear about it, how do I know what’s going on? I’m not trying to control everything, but in an intimate work environment, where we’re really trying to develop something complex, a nod, saying, ‘I got it,’ helps move things along.

And this part, which resonates with my inner blogger:

Asking for help is part of getting better at your job.

3. Work where people can see you.

Gaining visibility might require going outside your office. Maybe you have a side project, or maybe your work culture isn’t a healthy environment to pursue visibility.

Promoting yourself doesn’t have to be on someone else’s terms. Write a book, start a blog, make a side-project, collaborate with new people outside of work, or speak at panels and conferences. Tell people about what you’ve done, what you’re doing, why it’s important, and how you did it. Give talks, teach others, raise your hand for new projects.