Friday, December 21, 2007

Moving to France (part 1)

I'm moving to France (Nice area) and I think I should publish some pieces of advice here for other people moving there. I'm Pole (citizen of Poland) and unfortunately I'm not allowed to work in France without work permit (that's crazy stupid! we've been in the EU for almost 4 years now!). The amount of things I had to do is huge - french immigration and work bureaucracy is horrible.

You have to prepare at least 15 (make 20 to be sure :) color photos of your face (looking straight in the camera).

You have to arrange 3 original international birth certificate (to be sure arrange one original birth certificate in your mother language).

You have to make copies of:

  • your passport

  • your ID card

  • your wedding contract (if you're married)


You have to scan:

  • 3 last payslips from your current (previous) employer

  • your passport

  • your spouse passport

  • some stuff sent to you by hiring company (that's optional I think)


I also had to pass medical examination and go to the nearest ANAEM (Agence Nationale d'Accueil des Etrangers et des Migrations) office (the only one in Poland is in Warsaw - that sucks!!! 10 hours in a train and 15 mins in the office to get a stamp and a signature).

I'm married and to be sure I translated our wedding certificate - you should do the same if you're married. If your wife/husband wants to study in France you have to arrange 3 original international birth certificate (to be sure arrange one original birth certificate in your mother language). You should also translate your secondary school certificate to French.

Last but not least you have to pack yourself and go :)

One conclusion - it takes a lot of effort and money - I hope it will pay off.

I will continue the story when I arrive to France - that could be an interesting post ;)

Friday, December 07, 2007

UML is useless (not to say sucks ;)?

Take a look at following UML class diagrams generated using Enterprise Architect:

Diagram I:


Diagram II:


I intentionally removed class names because they could disclose design patterns' names in question. But if you are medium intelligent monkey you can see that these diagrams are almost identical, nevertheless the first diagram represents State while second represents Strategy GoF design pattern.

Even if you are experienced developer who knows and uses design patterns everyday you probably don't see any difference in those diagrams, don't differentiate them and most probably don't understand them. But when you see the code everything will be clear and obvious and you'll know what's going on.

I'm asking here why should anybody use class diagrams? Maybe I generalize the problem but I really don't see any value in at UML's class diagrams. If I don't see the code I don't know the real dependencies, associations, implementations and so on, and so forth. More so when I look at class diagrams it makes the project obfuscated and unintelligible - I don't think that was the reason to invent and use class diagrams.

What are your experiences with UML?

Sunday, November 11, 2007

About RSS, Google Reader and feeds in general

Invention of RSS is genius in my opinion. I'm the person who reads many many information every day because I'm engineer and really want to be up-to-date every day. I need it to bring my customers the best solutions available on the market. In order to accomplish that I'm subscribed to many blogs and other technical feeds - and I use Google Reader to read them all :)

Google Reader (GR) sucks but it's the best tool for reading feeds I know (on the other hand I don't know many of them). Comparing for example with Firefox bookmarks GR rocks. If you want to read new items in Firefox you have to press Ctrl+B and your main web view will be smaller which is annoying (I wanted to use other words but I don't like using dirty words in public). In GR I have everything in one place nicely lay outed and the most important it's very clear and readable. I don't want to advertise GR because it sucks anyway (there is also cool add-on for Firefox that notifies you about new items to read from GR).

Unfortunately some websites that interests me does not expose RSS feeds which sucks very very much. It's so simple and powerful - why, oh why you don't implement this feature - I need it :) I see only two remedies for this:

  1. Ask website admin/author to implement it (yeah, good luck ;)

  2. Implement it by yourself (it sucks 10 times more because you will probably have to parse HTML page!!! but you will get what you want and help others :)


I even tried second solution because I've had enough checking the website for news. In place where I live (Gdansk area or Tricity) there is local news website that does not expose RSS feed (it sucks, of course :) I needed it very much so I wrote my own crawler (in Java obviously) and helped the World. The RSS for news from this site is available under this address: http://java.bielu.com/trojmiasto.rss.
Unfortunately there are other interesting sections other than news (culture events, concerts, theater plays, etc.) that still don't have their RSSs. And I don't want to parse HTML anyway...

The point is that not everybody knows RSS and not every website publishes feeds. I wonder how we can advertise or maybe better, impose website authors to do this? Is it possible?

Are IT certificates worth anything?

My post can be found here

Wednesday, August 22, 2007

TIBCO EMS WebAdmin has got new address...

TIBCO EMS Web Admin is now available at http://tibco.bielu.com

Monday, August 06, 2007

TIBCO EMS Web Admin

Bored and tired with console-based TIBCO EMS admin?

Check it out!!!
TIBCO EMS Web Admin (EWA)

This is my system that I developed in few days after struggling with console-based EMS admin. If you like it and would like to use it let me know.

Do you think such system would be useful for TIBCO EMS developers/admins?

Thursday, July 26, 2007

Playing with JFreeChart and AJAX

I played with JFreeChart and AJAX (Struts2) on my web page a bit and here are the results:


Here are some screenshots:





Thursday, May 31, 2007

Few words on SOA

Take a look at these short posts:

Monday, May 28, 2007

What is leadership?

"What was leadership, after all, but the blind choice of one route over another and the confident pretense that the decision was based on reason" (taken from "Pompeii" by Robert Harris).

I don't want to spoil this great motto so I will limit myself to just couple of words. I think that every great manager and leading developer should know the power of motto above not from this excellent book but from his/her own experience.

We will never know whether the choice was right or wrong until we make it. My humble advice is that you have to take the risk - nobody will (or at least should :) punish you if you make the wrong decision because the worst choice is the lack of choice.

Tuesday, May 15, 2007

Sun Certified Web Component Developer's logo

I'm proud and will be loud about it :)

See also: SCJD logo & SCJP logo



NOTE: Logo above belongs to Sun Microsystems and you are not allowed to use it for any purpose. For details refer to: Sun Trademark and Logo Usage Requirements.

Friday, May 04, 2007

java.bielu.com

I started doing and publishing real stuff. See this: http://java.bielu.com (and don't laugh - it's just the beginning)

Thursday, April 12, 2007

Hoooooooray.....!!!

Today I passed SCWCD exam and I'm very happy. I learned a lot during couple of weeks hard learning about JSP, JSTL, EL and Servlets - I hope I will be using this knowledge very often in my professional life.

For all people who wants to take this exam: it is not as hard as books describe it - if you are expert of course ;)

Thursday, February 22, 2007

Silence...

Vacation and sickness is a good reason not to use the computer at all. That's why I was quiet for such a long time...

There's been some changes in my future plans. I resigned from SCEA certificate for the moment - firstly I want to take (and pass, hopefully) Sun Certified Web Component Developer (SCWCD). I learn from this book: Sun Certified Web Component Developer Study Guide and will give it only 3 stars out of 5 because:

  • there is a lot of typeos

  • there are a lot of little mistakes (and everybody knows that the devil sits in the details

  • there are some errors/typeos in the exam questions (which is especially annoying).


Generally this exam lacks in good study guide and I will recommend reading this book, at any rate. I finished the Servlet part and am starting JSP (second half) part.

I already bought the exam voucher, so I have to do it :) Buying the voucher is a really great impulse for learning...

Tuesday, January 30, 2007

Sun Certified Java Programmer's logo

Although I passed SCJD on August 2005 I lost my logo :( I requested it once again and received it couple of days ago (I'm very happy about that fact :)

Regarding my SCEA (Sun Certified Enterprise Architect) exam - I'm stuck and don't know whether I'll manage to sit this exam by June 2007...

See also: SCJD logo



NOTE: Logo above belongs to Sun Microsystems and you are not allowed to use it for any purpose. For details refer to: Sun Trademark and Logo Usage Requirements.

Monday, January 01, 2007

MicroIterations

Problem statement


Our team most often sets two-month iterations in which we commit to implement defined features as well as fix known and new bugs that will appear later on. This time is called iteration (we also call it release) in XP and is fine grained in my opinion. We define set of tasks (we use JIRA but any other issue tracking system is fine), bugs, improvements, etc., assign them to most relevant developer, estimate them and start working on the new release/iteration.

We've encountered big problem recently. If project manager does not track project progress on the regular basis project will delay. How it's possible? There can be many reasons but excluding wrong estimation I will stress problems I see in our project:

  • Developer working on issue can be (and often is) interrupted by other developers who assign him/her new tasks because they cannot cope with some problems.

  • Developer working on single issue can encounter more and more problems, add them to issue tracker and then prolong original issue



As far as the second bullet is concerned it is quite normal that undiscovered and new topics will expand to many small subproblems (issues). However, the first bullet can be really serious. Developer commits to his/her PM that he/she will deliver concrete issues by the end of the week (let's say XX-200 and XX-203). Unfortunately for this developer another developer assigns him/her new critical issue that has to be solved immediately. Developer has to stop working on committed issues and start working on the new critical issue. At the end of the week there is a big surprise because:

  • PM does not know nothing about the new critical issue

  • Developer who committed to finish issues XX-200 and XX-203 did nothing about them but finished new critical task

  • Project plan extends because two issue that has to be completed by the end of this week will be postponed for the next week



I see one reason why that happens: lack of communication. Very often developers and PMs trust too much tools they use. For example if we use JIRA I know that every new issue goes to the PM (by email), but I don't know whether my manager reads these emails and checks how it affects the release plan.
In example above PM received the email but did nothing about that. Also developers (one who created the issue and one who was assigned to the issue) made a mistake because they should communicate this change to the PM (DON'T TRUST TOOLS - COMMUNICATE).

Following Use Case diagram shows the responsibilities and indicates where is the problem and how to solve it:


MicroIteration


I defined iteration earlier and now want to give my proposal how to solve problem presented above. Having one or two-moth iterations we can define MicroIterations that will always last one week. At the ending of the week the whole team meets (30 minutes is max - 15 minutes should be enough) and every developer commits to resolve/work concrete issues. PM has to write it all down (it can be done by the tool or in the individual developer's status report) and track the progress. Every change has to be communicated to the PM e.g.:

  • when developer sees that issue will take more time,

  • when somebody assigned the developer new critical task and working on current issues has to be postponed,

  • etc.


Having such knowledge PM can easily adjust release plan and move some tickets to the next release, assign additional resources, delay release, etc.

To recap my ideas I will write down responsibilities for the PM and the developers:

  • Project Manager is responsible for the project;

  • Developers are responsible for the project and for the communication between other developers and the Project Manager;

  • All team members are responsible for using they brains and well known new global buzzword, namely common sense.


As far as tools are concerned they should be used for generating reports, visualizing progress, as communication hub, whatever else, BUT tools DO NOT:

  • THINK for Project Manager and Developers,

  • COMMUNICATE problems,

  • SOLVE PROBLEMS.


Tools only HELP PM and developers.

Conclusion


Communication in the team is one of the most important success factor. Without good, efficient and effective communication it is highly probable that your project will be crap. MicroIterations concept should help in realizing and establishing some realistic lightweight communication patterns within project team. To recapitulate the most important aspects:

  • MicroIteration should always last one week

  • At the end of each week team members meets (15 - 30 minutes long) and each team member commits to deliver concrete outcome (e.g. solve some issues)

  • Project Manager tracks progress of each developer (not exactly track but check the real outcome next week)

  • Developers has to meet their commitments - if the developer knows that he/she will fail he/she MUST communicate that fact to the PM in order to change plans

  • Project Manager has to adjust release/iteration plan according to changes (e.g. new issues, prolonged tasks, etc.)

  • Developers has to communicate their progress (especially lack of progress) and every problem that can impact issue delivery date

  • If there is no tool available that can track developers' commitments PM cannot say that it is impossible to comply to these rules - if PM does not have relevant tool for that he/she should use Excel or just piece of paper and a pencil - it's really simple and every dummy can do that (and PM's are not dummies :)

  • Developers can and should assign other issues to other developers but they should communicate that fact to the PM - PM can then change assignee or adjust other issues - developers should not blame other developers for not having time for their issues (commitment is important and can be changed only if PM knows about it)



Yet another process?


What I tried to present is a way of working in a team I used to work. Our team was really successful and we were very flexible. We communicated every problem to the Project Manager and had no problems in delivering even complicated and experimental features on time. It was not only because we were great engineers, we estimated our effort precisely, etc... No - the reason why we were so successful was the COMMUNICATION. It is not any kind of process or methodology (even lightweight ;) - it's just piece of tips how communication within project team can boost productivity and make team successful.

PS. Happy New Year 2007