Misc. Misc.
If I had to summarize this book with a single word it would have to be "disappointing". I had quite high hopes for it as I read some of the “beautiful” book series before and they were really good. Unfortunately beautiful teams is not that great at all. I am not sure who would I recommend it to anyone.
The art of lean software is a very short book. I was really surprised when I got it delivered home. It is not a bad book though. Even that most of the practices are common sense nowadays I still people should spare few hours to read it.
I have seen too may people not following these common sense rules to discourage anyone from reading the book. Don't expect breakthrough, just a list of useful advice.
I have not read a book about computer algorithms for a long time now. I liked parts of the programming pearls and I disliked parts as well. I think it is worth going through the book if you are a software engineer. Especially if you want to get better at designing efficient software or if you want to practice on some non-trivial programming puzzles.
In general I think it is a a solid book.
That is a really exceptional book! You would expect googler's books to be good, but this one is really great. Don't waste time, just order a copy you wont regret it.
Team Geek is a great source of knowledge not just for leaders but for all the people who work with software engineers (or who are engineers themselves).
I have been in quite a few technical job interviews in recent years and I think I can see some patterns of why people fail. You can find a lot of guides on how to get the dream job or how to behave in the engineering interview but there are few tips on what not to do. I thought it may help some people in getting their dream jobs or maybe even becoming better engineers. Here are three simple things to avoid during the software engineer interview.
Whenever I conduct job interviews for a while or go to interviews myself I realise how much is there to learn and how often we forget to stay sharp. Over the years I developed a personal regime that lets me stay reasonably up to date. As they say in China “sweat during peace so that you would not bleed during war”.
It would take a longer discussion to analyse my beliefs and explain better how was my career shaped but I think there are a few core advices that have worked for me so far.
Last week we had a Yahoo! winter hack day. It was my third hack day in Yahoo! and it was the best one so far! The hack party started at 5pm on Thursday. We hacked all night with some people working throughout the weekend as well.
2012 "winter hack day" was an amazing event. We got so much love from management teams and office folks. We produced over 20 super cool hacks with prototypes of mobile apps, internal tools and all sorts of freakn cool code. It was AWESOME! YO SYDNEY, YAHOO!7 IS IN DA HOUSE!
While working with legacy applications and inherently dirty code you have to find creative ways to make things better. Rewriting / major re-factoring are usually not an option as team does not get enough time to do even basic housekeeping, what do you do then?
I have seen sphagetti code way too many times in my life not to call it an anti pattern. One of the main reasons for sphagetti code is allowing any object in the codebase to talk to any other object. In addition it comes hand in hand with usage of global/static scope and leaking information between application layers.
I recently realised that i have been applying the same pattern for a while now. The pattern i propose is an effort to cluster ugliness and relief rest of the code-base from exploding dependencies.
That is just a very quick tip how to get git branch name into the prompt. Friend of mine pointed me to this neat little trick just last week and i thought its pretty neat so i am sharing it.
From time to time I see bugs in the code and I start thinking "really? is it possible that no one noticed that bug before? am i the first person to see this code?". I thought it might be worth writing a little post on what helps me to deal with bugs and software quality in general and what are the common pitfalls in developer's thought process. Although it is not a very extensive post i hope it may inspire some developers to try new approaches :-)
In general it is extremely rare for me to commit bugs that would make it into production (maybe less than one a year? hard to say as it is really rare). To be honest I can't remember a serious issue with my code for last 5 years.

To make it short and clear, I liked the book a lot. From a very begining it is clear that author has a vast experience in software design and development.
There are a few bits that really stand out.
First of all I loved the chapter showin pair programming and minimal effort principles. It is really fun to read and shows some very interesting observations.

Well, i am not sure what to think of this book. It is a bit uneven as it is a composition of many separate articles written by different authors.
First chapter was really poor. A lot of talk but no real value. How many times do we have to hear that architecture and design are important? Entire chapter is a very vague and buzzword filled blob.
Second chapter was actually very entertaining but again also bringing little value. Author describes two systems he used to work on. He brings a list of factors that made them fail / succeed. I like the chapter as it seemed a bit funny and had some good points.
After many years of reading references to it, i finally read Design Patterns by the famous Gang Of Four (GOF). Book is probably one of the most quoted and refereed IT books ever :-). Many of the articles I have read, that referred to the book, were really badly written. In most cases I had a feeling that authors did not understand design patterns at all. As a result my impression was that book has to be poor as well and does not do good job explaining patterns. This made me think that book has to be horrible if so many people write these vague and confusing articles referring to the GOF book itself.

This post is my final look at the total of nearly 1200 pages long CISSP book.
In the end i think it was not a total waste of time as i really liked the physical security chapter and also chapter about cryptography was not that bad. Maybe it was not that bad of a refresh. But was it really worth it?
I would definetly not recommend it as i cant see who can really benefit from that book, its not senior and not junior, does not explain things well nor provide deep insights. Its just a too long poorly written book in my opinion.
Wordpress is a very nice blogging solution but does not really allow to create and publish multilingual blogs out of the box. The good news is that it allows you to set the language for frontend so that users see localized messages.
Writing wordpress posts in your chosen language is one thing but then you make sure buttons, error messages and other labels are translated. This is where gettext and translation files step in.
Main Blog Categories
About the author

Hi, my name is Artur Ejsmont,
welcome to my blog.
I am a passionate software engineer living in Sydney and working for Yahoo! Drop me a line or leave a comment.
Follow @artur_ejsmont