Wednesday, September 16, 2009

The wisdom of "Döner Kebab" consumers

I was pretty hungry yesterday in the evening so I decided to go to the city center to get me a "Döner". The plan was good, the only problem I had was that I didn't know which place to choose. The city of Munich has hundreds (or rather thousands) of them! Each place offers very similar product for the similar price. How do I choose the one offering a good quality and won't cause me stomach aches at night?

So what did I do? Well... I just relied on the instinct :-) Sounds easy, but as soon as I got what I wanted (a nice, fresh and tasty "Döner") I realized how complex and logical my decision making process was. (Tip: It has something to do with groups.)

Once I got to the city center I walked along the street for a while passing "Döner" bars. I didn't go to the first one, not even to the second one or third one. The one I've chosen was somewhere in the middle of the street. Just a typical "Döner" place (small and a bit dirty looking). There was however one significant difference if you compared this place to the other ones. In this bar there were people, many people. What's more, people who were waiting in a queue for their food to get prepared. Why did my brain told me to go there and wait with those guys? Illogical, isn't it?

No, it's not. It's rather really cool! This group actually "told" me which place to choose by simply being there and my instinct convinced me that I should rely on their wisdom.

The choice was perfect. I got myself a "Döner" having a very good "price/quality" ratio... just because I was relying on my instinct.



Interestingly, in my city I do not rely on the instinct anymore. I simply know where to go. I guess I learned which bars are the best from some other groups ;-)

Tuesday, September 15, 2009

Better controlling the Cloud

This is what I found on the web. Check it out:

http://link.brightcove.com/services/player/bcpid1753162278?bctid=17374112001

Seems to be an interesting idea. Waiting for some opensource product going this way.

Monday, September 14, 2009

I hate Mondays!

Last week I've booked my hotel and tickets to Munchen. I originally planed to stay there for three days (read two nights) and then come back to Erlangen and work remotely. Everything was great until today when I realized that I've made appointment for Thursday with a guy who substitutes my boss and comes to get some feedback info about me and my work. This fu... totally sucks! Booking another hotel just for one night in Munchen (it won't be cheap), re-booking the ticket (those guys at DB really know how to piss somebody off), etc. My girlfriend will be pissed of too (I promised to give her a ride to Nuernberg to the dentist on Thursday.) Why didn't I look at the calendar last week? It was all written there!! I don't get it! Oh.. I am such a... oh... no... I just hate these fu... Mondays!!!

Wednesday, August 26, 2009

Monkey see, monkey do

For the next two months I am going to work on a software project in Munich, Germany. Moving to a big city is quite a change for a guy like me. I am a person used to quiet, small and clean places the population of which does not exceed the size of 100.000 people. There are naturally many disadvantages of living in a small town but I personally think that the pros overtake the cons dramatically if you value the quality of your life the most.

I have been researching (reading about) the subject of "Groups" and "Behavior of individuals being a part of Groups" for a few weeks now. The last few days in Munich proved the theory I was familiar with and allowed me to experience some of those "wise statements" I've learned in practice.

The amount of people who unconsciously base their decision making on decision making of the group is extremely large. One of my observations (in the Munich subway) proves that when in a rush, many of our decisions are based on instincts. These instincts fire some behaviors which are proven to be "ok" or sometimes even "safe" or "normal". Consider this: What would you do if a group of people (let’s assume 10 people) surrounding you would suddenly start running in the opposite direction? Would you run with them? Would you at least think about it? Would you be scared? Or maybe you would decide to analyze the situation and make you decision based on "strict facts" concerning you?



I was on my way to get the train to my office. There was no rush. One of the digital displays showed that next train will arrive in approximately 5 minutes. I decided to slowly go to my destination. I've chosen the escalator because I am very, very lazy guy in the morning. There were about 6-7 people on the way in front of me too. Unexpectedly, two of the guys rushed of the escalator as if there was a train coming in a few seconds. There would be nothing special about it if not the fact that the rest of people who were standing in front of me rushed after them. (Interestingly, those behind me didn't.) When I reached the station, I saw the confused faces of those people. They were moving chaotically as if filled with some sort of energy generated by sudden jump of adrenaline level. Why did they react that way? Why did I feel like reacting the way the others did? That's crazy!

Being part of the completely different environment on day-to-day basis allowed me to "save my independence". I know however that if I was to stay in that city for a longer while I would become part of that "system/crowd" and my decisions would no longer be based on rational facts. They would be rather based on instincts taking over the decision making process for the boring part of my life.

Anyway, do not ever forget this:

Life moves pretty fast. If you don't stop to look
around once in a while you'll miss it.
-- Faris Beulers day off.

Monday, August 3, 2009

Why big hardware corporations can not write software?

I think one could write an entire Ph.D. thesis on this subject. Master's thesis could be to short and not cover all the aspects/problems the large corporations are dealing with.

I experience this sort of problems everyday since this is the kind of corporation I currently work for. It is extremely interesting to observe the behavior of people working here and it would be such a waste if I didn’t share some of my experience with you.

Why do they build software if they are hardware experts?


Well, the thing is that modern hardware has to go together with some sort of software. It needs it to function properly or/and to interact with the user. The devices the company produces are therefore useless without appropriate software package. Since the company builds the device itself, they are also the ones who understand it best. They simply know how the software should interact with their product. This knowledge is very seductive and makes them think: "Well, we've build the hardware, building software is just the formality then".

Since there is no way to go around this and some kind of software has to be build in the end, many companies choose to build it by themselves (and keep the implementation details "secret").

Why build it yourself, why not?


This is actually a very good question. If you have no experience with building software, then what do you do? Yes, you outsource it to someone who does! This idea is not that bad but only under one condition; you outsource the project entirely to the professionals who really know what they are doing! The problem of most hardware companies is that they want to go cheap. They simply outsource their projects to places where the so called "programmers" do not cost a lot. ("You know, the software is just this virtual piece of functionality that we need but is naturally of lower importance for the hardware itself, which our main product!"). This is the place where they are totally wrong and the "numbers" that management has seen at the beginning of the project turned out to grow up exponentially after delivery of the first working version of the new so called "software package".



So what do they do when they see the problem?


First of all they want the code back to their development centre. However, as soon as it’s there they realize there is no one who understands it. (I think that even the best software developers would have problem with it.) So what do they do next? Yes, they look for people who do (or at least say that they do). This is actually the place of their second failure. When they hire their new software developers they actually don’t know what kind of people they want. This problem may be well explained by the company’s lack of knowledge and experience related with building software. The group of their current hardware (or old software) engineers is simply not able to recruit good software developers since they themselves don’t know what the difference between "good" and "bad" is. So after asking the questions like: "How much experience with C++/ Java do you have?" or "Do you know what Ajax is?" they tend to recruit trashy people who have just a little idea about the art of software development.

But that's not all...


Hardware companies usually do not use, understand (or want to understand) the agile development methods. They stick with their waterfall models (or waterfall-like models) and think that something which was suitable for hardware can be also suitable for software. Well, it is not.

The typical problems they face:

  • Lack or badly defined requirements

  • Lack or bad architectural design. No "design for change". ("who needs architecture after all? We need to deliver soon so please start coding now!")

  • Lack of good software developers

  • Lack of unit, integration and system tests (no comments...)

  • [ ...write some yourself... ]


I was recently on a job interview at the typical, medium size "software company" in Berlin. These guys really impressed me with both, their professionalism and their recruitment process. I have spoken with the project manager and one of the lead developers. They knew absolutely everything about their product, developers, development methods they used and project management tools. They were even able to draw a simplified version of the architectural design of their application to explain me how it works and where they see me in that project. I didn't accept that job because of personal reasons and partially because they could not offer me the same or better financial conditions as I have at the moment. Now I kind of feel it was a bad decision.

Yesterday I was on a job interview for the other department at my current company (see, I am a "software engineer to rent"). The interviewers were totally different. They didn't know what they wanted from me, asked inappropriate questions, tried to convince me about how .NET is superior to Java technology without any reasonable arguments. They made me angry and in the end offered a JavaScript coding position for some sort of user interface they don't have requirements for. Can you imagine this? This was simply a waste of my (precious :-)) time. The funny part is that even though I don’t fit that position at all, they will probably accept me.

In the end I have one short message to all hardware developers. Guys, wake up! Software is a real deal! Be careful who you hire and don't forget to get rid of all that bad, useless and incompetent, so called architects, developers and most of all project (or product) managers!!! I want to be able relax when I am using my new digital TV receiver or get X-Rayed at the hospital, so please, get educated and do it right!

Tuesday, July 28, 2009

Tapestry 5.1 on JBoss 5.1

Well, today I tried this configuration and guess what... it didn't work! We all know who to blame (and this is not the Tapestry guys)! Now, what can we do about it?

The information on Tapestry wiki states that there is a workaround required for Tapestry to work on JBoss 5.0.x. The wiki says also that the workaround wouldn't work with JBoss 5.1. Hmmm... to bad, but why wouldn't it work?

I've decided to debug the code I got from the wiki and take a look at the behavior differences on both versions of JBoss. After an hour of debugging I found out that the URLs to the resources are build differently for jars which are packed inside of wars. There is however easy way to make them look the same.

Here's my patch for the original workaround at Tapestry Wiki.


...
public URL convert(URL url) {
if (url != null && url.getProtocol().startsWith("vfs")) {
// supports virtual filesystem used by JBoss 5.x
try {
URLConnection connection = url.openConnection();
Object virtualFile = invokerGetter(connection, "getContent");
Object zipEntryHandler = invokerGetter(virtualFile, "getHandler");
Object realUrl = invokerGetter(zipEntryHandler, "getRealURL");

// start of the patch (small fix for JBoss 5.1)
if (realUrl.toString().endsWith("jar")) {
Object localPath = invokerGetter(zipEntryHandler, "getLocalPathName");
Object context = invokerGetter(zipEntryHandler, "getZipEntryContext");
Object tempUrl = invokerGetter(context, "getRealURL");
realUrl = new URL(tempUrl + "" + localPath);
}
// end of the patch
return (URL) realUrl;
} catch (Exception e) {
log.info(e.getCause());
}
}
return url;
}
...


Now, you may enjoy having Tapestry on your favorite application server... and wait for a more professional workaround from Apache guys.

Twitter - isn't it just an observer pattern

It just occurred to me how great and powerful design patterns really are. Well, I must admit that I always thought about them as if there were just a tool that I can use to build great, exciting, flexible and maintainable applications. Well, after all that's totally true! However, it never occurred to me that I could take a design pattern and make an entire application out of it. Yes, I mean it! The pattern may be a great business idea! The business idea where the pattern implementation itself is all the software has to offer to its users. Sounds simple, doesn't it?

The concrete pattern that I am "secretly" thinking about is commonly known as an "Observer pattern". This "recipe" is extremely important to every good software developer who would like to build a flexible system which needs to deal with some sort of event handling… but you already know that. Now, take this pattern and map it to the real world. This is actually where it originally came from. What do you see?

I see e.g.:

  • newspaper companies and their subscribers

  • church and all the people who "subscribed" to it. They (typically) receive recent information about some sort of catholic events... etc. whatever...

  • the company which employs you and yourself. Well, you subscribed to get the money every month from them. The bad part is that you have to work to keep yourself on the list of subscribers.


As you can see our live is surrounded with observer pattern. It is natural that people love patterns. They make our lives easier. We don't have to think so much about that many things around us. Just this simple fact proves that a pattern itself can be a great business idea! How can we use it then to build our own business on the web using this common "routine"?

In my opinion, the best example is the Twitter. In Twitter you are acting as a Subject and Observer at the same time. The network of observers and subjects is therefore huge! Every time you post a message, all people who are your observers get informed about it. Every time the subject you subscribed to is posting an update you get informed about it too. Isn't it great!? Take a pattern and use it directly to make a lot of money. This is of course pure theory. The internal implementation of Twitter is probably not that simple, but this is not the point of this post.

So, when thinking about your next genius, innovative business idea, just make sure to take a closer look at the design patterns. Try to map them to the real world problems and use to build solutions nobody thought about yet.

I think that this approach will always lead you to a success. Here's why:

  1. This new thing of yours (whatever it is) will work for sure. Design patterns were tested by millions and proved to work correctly and efficiently.

  2. It will also be simple... and since people like it to be simple it makes a perfect match.

  3. We all probably will know this routine by our hearts. We just didn't suppose that you could use it this way. This means that the users will know how to use your software right away!

  4. There is more... and more... and more... but I am too lazy and too dumb to put them here.


Anyway, I will re-read my patterns book and look for some clues there.