Freitag, 29. März 2013

Things every developer should do at least once

There are things ever man/woman should do at least once. Here is a list of things I think (mind you, it's just my point of view) every developer should do:
  • Contribute to an OS project: I could write a whole page why I think every developer should contribute to opn source and just going on and on about that it is the only responsible thing to do. Instead I want to focus on the positiv: It makes you a better developer. Looking into other people code, diving into the whole concept of this project, then trying to fix a bug/implement a feature and get feedback on it is very valuable.
  • Learn a functional language: I'm not talking about learning it in depth and every aspect of it. Just choose one, look into it and get used to it. You don't need to use it often, but looking into it you will give you another perspective. You will see another way of doing things. It will make some implementions much nicer, even if you are coding strictly object oriented (Immutable objects for example are a concept worth looking into).
  • Look into shell scripting: There are small things where it's much nicer to get some shell script up and running than integrate it into your application. If you don't know shell, you don't know when this applies. Since I know a bit about shell scripting, I see opportunities.
  • Experience Test Driven Development: Knowing what this exactly is and how to do it may help you. You may not use it every day (even if I would suggest it!), but again you may learn valuable lessons. It's also not about saying the way you are currently developing is bad. It's just about seeing things from another angle.
  • Set up/Maintain a server: Again, I'm not talking about production server, critical systems and in depth knowledge. Just dive into system administration and see what "the guys at IT" are doing all day long. Learn their problems and you may understand why certain things are done in a certain way. The idea of DevOps (bringing together developers and operation guys) is really appealing, as it solves those communication gaps and may lead to a healthier, more supportive environment to work in.
  • Educate yourself: Waiting or your company to push you into a language/framework/tool is something that isn't going to happen. Thinking you know it all is a lie. The only thing you can do is stay on top of the news and just look into new things briefly. For web developers, there is much going on with javascript MVC frameworks right now. There is also much HTML5/CSS3 stuff happening. NoSQL might be something every developer who needs to store data on a server might to want to look into.
This list isn't complete. And I think it's not the point to make a complete list. The point is to acknowledge that you should do something. There are so many ways and opportunities to get better and evolve. You just need to start.

    Dienstag, 19. März 2013

    Using screen(1)

    Sometimes when it comes to sysadmin stuff, I don't have all the tools at hand or don't even know about them properly. I am not a sysadmin but have to do some stuff on our servers and one tool which I use more and more is screen.

    I read about it at webadvent in a post by Remy Sharp and had many situations this could be handy. One where long-running commands. I was using nohup which was ok but had a few drawbacks. I could not do anything else while the command run. I also need to remember to put nohup in front of every command which would maybe run a little longer. Now using screen, I'm inside a "standard" session and if my connection cripples, I can get back where I left of in no time.

    Another use case is a very basic deamon. If you run any command in screen, you can exit the screen session and the command will continue to run if the program is not at the end. I would not recommend running apache inside a screen session in production, but if you have something non-critical, you could use screen. I did it yesterday to run a command which logs i/o data. I wanted to run it for 24h and just startet it inside screen. Nice! I also use it sometimes if I need to run a python or node.js server in my development environment and don't want to block my ssh session (I ssh into a vagrant environment).

    And if you are working remote, sharing a session and being able to work together on a problem is also an awesome feature. It makes working together on a server easy. It is also easy to leave the problem and let another person return, as he can take over, see what was done and has some kind of history other than the bash history which may include commands not related to the problem and often has to little information.

    I think what amazes me most about screen is that it's a tool that does one thing, and it does it good. It does not want to be the only tool you need but is a tiny little thing, always there when you need it. If you want to try it check the blog post mentioned above or one of the many tutorials out there. It's very easy to use because of it's simple nature and brings real benefit.