Keksrolle.de

Heute mal ein Blogpost in ganz eigener Sache.
Und zwar macht mein Neffe Steve gerade seinen Zivildienst / freiwilliges Jahr auf den Philippinen. Er ist dort im Rahmen einer Organisationen mit dem Namen PREDA und dem Tatort Straßen der Welt e.V, und betreut dort Kinder, welche von der Organisation aus Gefaengnissen geholt werden. Genaueres kann man auf seinem Blog nachlesen, wo er heute schon einen ersten Beitrag kurz nach seiner Ankunft geschrieben hat und erste Bilder hochgeladen hat.

Doch auf eine wichtige Sache moechte ich noch hinweisen:
Steve, seine Mitstreiter und die Organisation sind in diesem Projekt auf Spenden angewiesen. D.h. wenn ihr gut findet, was Steve dort macht, dann koennt ihr dies mit einer Spende unterstuetzen. Steve moechte auf seiner Website dann dokumentieren, wofuer die Spenden eingesetzt werden. Die Organisation kann ab 50 EUR auch Spendenquittungen austellen.

Details zum Spenden findet ihr hier.

I found a really nice video by Dan Meyer who gives a presentation basically about what is wrong with the usual way we get taught math in school these days. And better than that he also gives advices on how to do it better.

Here are the 5 most important bullet points to me from his video:

1. Use Multimedia
2. Encourage Students intuition
3. Ask the shortest question you can
4. Let students build the problem
5. Be less helpful.

To me this is the “less is more” philosophy applied to teaching in general.

After years of using Serendipity as my blog engine I switched to WordPress today because I just wanted to try it and get used to it.

Here is a page which helped me a lot with the migration. Pay attention to the “dummy entries” which are mentioned there:
https://wiki.nodomain.cc/projekte/blog-migration

One outstanding thing is to migrate the Serendipity permalinks 100% to wordpress.

In Serendipity I had the following structure:

http://www.keksrolle.de/index.php?/archives/139-Freemarker-Templates-Layout-Decorators-with-Shared-Variables-in-Data-Model.html

The problem is the “index.php?” –> the question mark spoils the links. I got it working with just /index.php/archives/… but my pages are indexed with the index.php?/archives. Shouldn’t be a huge problem as people just get to the homepage.

We all know it: We have a complex problem which we need to solve but we need to explain the problem first to a group of people to look for a solution or give sign-off.
That means we first need to get the attention of those people, make them understand the problem. If the problem you need to explain becomes complex it can be quite hard to do so.
Here are a few tips I try to stick to when I write my emails:

1. Purpose and Goal

Make the recipients understand purpose and goal. You are writing the email for a reason and not for the sake of writing a mail. Make that as short as possible.
Just as you do for your meetings: Give each email an AGENDA. People should know what your email is about before they read it.

2. Structure is key!

Structure your email into sections:
- Introduction & problem description: Why are you writing this mail and what do you expect.
- Symptoms: Say what you did, what you see and believe is wrong and what you would have expected to see instead. Never say: “Software XYZ is not working!“, because nobody knows what and how you expect it to work.
- Solution proposal: If you believe you have an idea what could be the reason for the problem and how it can be solved, then say that. But outline that this is only a guess. If you are wrong, then no problem.
- Conclusion: This is most important. After you have written and explained a lot, people are usually more confused than before. Summarize your mail in a few short notes.

3. Be polite

Never think your problem is the most important problem. Better always expect that everybody couldn’t care less about your stupid problem. If you think like that, you spent more thoughts into writing the mail and making a point. Do this in polite words. Remember you are dealing with human beings just like you who all have their own little problems, maybe a bad day and at the end of the day have to do their jobs – just like you. So just behave like you would expect it from everybody else too. If your colleagues are all assholes, then stand out of the crowd and do NOT be one!

4. Use screenshots, screenshots and screenshots!

In the IT and Software Development industry, problems are usually about software which happens on your screen. Instead of writing 10 long sentences about a problem you see on e.g. a Web page, just take a screenshot, add some red arrows and some circles to it and send it. If one screenshot isn’t enough, send another one.
Don’t even think of the larger size of your email. That doesn’t matter. Hard disk space is for free these days and productivity and information is more important!. Time is money.
I use SnagIt! for Windows or Skitch on my Mac for taking screenshots and adding annotations and stuff. Some of my mails consist only of screenshots because that might explain the problem without any words and the recipient sees exactly what I see. Make sure you use short keys to make screenshots. I just press the “Print” button which brings up SnagIt. It is possible to write a mail with a screenshot within 5 seconds.

Example:
It makes clear that I want to point out that specific part of the text.

5. Do NOT use abbreviations

Instead of don’t, write do NOT.
Instead of can’t write cannot
Always write the word not in capital letters and maybe bold, if you want to highlight that this is important. When reading emails too fast that small word can be missed and maybe it turns the sense of your mail upside down.

6. Favor notes or bullet points over full sentences

If you are listing a couple of related thoughts, then just put it into bullet points or a numbered list instead of writing it into full sentences. That has the following advantages:
- people can refer to each bullet point / numbered item which is very exact. You immediately know what they are referring to.
- easier to see what belongs together. In long sentences it can get hard to distinguish between the different things
- they are shorter and people can read it faster. If something needs more explanation, people will ask you.

7. Summarize your mail

Always add a conclusion or summary to your mail. After you have written a lot of text, people are usually more confused because of information overload.
Thus summarize your mail at the end in 3-4 bullet points. It helps to get back to the main purpose and goal of your mail.

1. The Internal Design of Force.com’s Multi-Tenant Architecture (Video)

2. Dan Pritchett on Architecture at eBay (Video)

3. Orbitz.com Architecture with Brian Zimmer (Video)

4. Scalability Principles

5. An Unorthodox Approach to Database Design : The Coming of the Shard

6. Domain Driven Design and Development In Practice

7. The Challenges of Latency

8. LinkedIn – A Professional Network built with Java Technologies and Agile Practices

9. LinkedIn Communication Architecture

10. JAX TV: Java-Programmierung im Multicore-Zeitalter (Java Programming in the age of multicore processors) by Angelika Langer

Collection of links on my way to get Hibernate to work in my first OSGI application based on Equinox.

Hibernate and OSGi: An elaborate solution

OSGI Bundle Repository

SpringSource Bundle Repository

This article is just a central place where I want to collect all the steps and links which I found useful while learning Maven2 and migrate and existing project from Ant to Maven2.
The reason I have picked Maven2 is that the new application I am developing uses Spring and OSGI and the Spring guys are also using Maven. As I am still learning I want to avoid opening to many fronts and possibilities for errors.

•Nice tutorial for Spring / OSGI and Maven2
•Maven Getting started guided
•How can Maven benefit my development process
•The pain of switching from Ant to Maven (very good post, funny too read, thoughts of developer migrating I am sure I will suffer the same)
•Maven2 Eclipse Plugin
•Better builds with Maven (Free E-Book)

•Screencast about PAX-Running + Spring OSGI
•

I am working since a couple of years in client-facing software projects in the e-commerce area.
Most of them were german clients of varying sizes which outsourced development of their e-commerce projects.
One thing I realized was that many those projects had issues after going live.
that is nothing new, but those issues were in my opinion mainly because of one fact:

The client wanted to do too much at a time.

I am under the impression that in many german projects i have worked, the clients never go live with version 0.9 which has less features and is not perfect.
instead they want to to have version 1.0 but actually expect it to be version 2.0….of course in time and in budget!

Experience told me that this doesn’t work. Instead you should try to start small with the most simple setup possible to achieve the business goal.
That is my personal opinion of course.

I have tried to come up with a set of questions which should help Software projects to go live successfully:

Q: What is the most important functionality which is needed for launch?
A: E.g. for an online store it is products, the possibility for customers to have a shopping cart and a successful and short checkout and payment process.
that’s it: nothing more! people should buy your stuff. Don’t stop them from doing that with all kinds of features!

Q: Which features are used the most?
A: if something you want to implement is most likely not used by at least 90% of the users….leave it out in version 1.0
After going live monitor your site and analyse which areas could improve with your new feature ideas.

Q: “But all of our competitors have those features…”
A: “Do you actually know if users need those features?” Try to stick out of the crowd and do less,
but do this better than your competitor.

Q: why don’t we just put more people on the project to get all of our crazy ideas done?
A: Do you actually know that you can get fired for this question? More people are like more features: they makes things more complex.
And complexity is not easy anymore. Avoid complexity in phase one. You still can make things more complex
when you once have understood even the simple setup.

Maybe it’s those project budgets who are responsible for this mess. Bugdets are agreed for a certain
period of time and it is expected that the budget is used only for this time. So the stakeholders try
to get as much as possible out of that budget in that time. I think people should start to think different:
Split projects into phases/stages right from the beginning and stick to the magic number 3.

Phase 1:
- the most simple setup, to go live. No “nice to have” features, only the most used stuff.

Phase 2:
- Add most important “nice to haves” which are based on analysis of Phase 1.

Phase 3:
- Here you can get experimental. Your business is running and stable. There is room to try out something new.

It would be nice to get some feedback about experiences from other people.
Maybe that is a german thing…mentality..you know all the stereotypes have a bit of truth in it
I would be interested in experience from other countries…are people more brave there and try to risk to do actually less ?

live und unplugged gaben wir unseren Song “Make you heal” zum besten.

Unser naechstes Konzert ist am Samstag d. 8.3. im JC HUGO in Jena zusammen mit Mastoles + Rhythmsphere

A collegue and I just found out that the FTP fuction listFiles() has a problem exactly today on Feb . 29th as we have leap year.

We just guest this, but as we have found this blog entry we were pretty confident.
http://blogs.lodgon.com/johan/Leap_year_issues_in_apache_commonsnet

Unfortunatelly also still an unassigned issue for the guys 
https://issues.apache.org/jira/browse/NET-188

If you have strange problems today with tools that rely on this framework you should have some more coffee and wait for tomorrow

Christoph