Jag tycker inte om att bli överraskad. Även om det är så att någon trevlig person bokat en hemlig resa till mig eller anordnat en surprise fest. Det låter kanske tråkigt - men jag är bara ärlig - jag tycker inte om överraskningar. Självklart kan jag alltid spela glad. Man är ju trots allt artig. :-) Jag tycker inte heller om att överraska andra. Jag tycker om kontroll. Jag tycker om transparens. Man kan visserligen inte alltid ha full kontroll. Men man kan ha stor kontroll. Oftast genom att ha öppna ögon och öron, vara kommunikativ och hänga med.

Det här med överraskningar gäller även i arbetslivet. Och särskilt vid systemutveckling.
Genom att hänga med, vara kommunikativ och ha diverse tentakler ute, kan man få bra koll på vad som är i görningen. Man ska inte behöva bli överraskad av att ett delsystem inte fungerar. Det bör istället upplevas som att ett nytt problem uppstått. Men inte behöva vara en överraskning. Har man inte beräknat att sådant kan hända, då blir man överraskad. Inte annars.

Om kraven förändras, eller om det tillkommer nya krav som problematiserar den design/implemenation som redan gjorts, då är det ingen överraskning. Det är helt enkelt nya förutsättningar. Och har man haft tentakler ute, god kommunikation - så har man antagligen kunnat ana att något sådant eventuellt skulle komma.

Man ska inte bli överraskad av att det är lågkonjunktur. Att den skulle komma visste man faktiskt INNAN Lehmans Brothers föll!
Man ska inte bli överraskad av att det snart kommer vara stor brist på it-utvecklare.
Under lång tid är det färre som utbildar sig inom det området men samhället blir mer och mer beroende av IT.
Man ska inte bli överraskad av effekterna som kan komma av att energi och datorer just nu hör ihop - och att energi är en bristvara.
Det är mycket man inte borde bli överraskad av. Ändå blir många alltid så överraskade.
Kanske beror det på att så många tycker om överaskningar...som 5-åringar också gör...

Läs mer...

This post is about how fun I find learning and how it gives me better self confidence.

If you want to know more  - please click the link and read the full post.
:-)

Läs mer...

Sometime I get technology stressed out. There are so many technologies coming all the time which I feel I must learn.
But then I think about India - where I am originated from - and I get relaxed. Because it's actually possible to just skip one or more phases. And you may still be a winner.

Click the link if you want to know why...

Läs mer...

On my Ruby and Rails roadtrip I am getting new insights and understandings...

In summary - with a very few lines of code - you can accomplish so much with Rails.
However, the main bit is to understand how to use the existing puzzle bits.
Once one learns how to use the framework and plugins - it is just rolling...as they say.
I.e. not much coding to do.

There is an abundance of existing plugins that enthusiasts around the world creates and gives you access to - the main thing is to decide which to use, which will live and not die, which are the best for your needs.

Use below link to read more about my insights and reflections.

Läs mer...

So what do we actually need to ensure robust systems and effective system development?

We need a lot of courage. So we can stand for what is right.  Each and every programmer or involved person, needs to feel the right to speak up.

Make the voice heard - when things are going wrong. But it's not always easy. We are all humans. And humans may be shy, scared or even worse...uninterested.

Musicians are bold people. They sing about the worries and bad things in the world.

Can we save some systems out there if we sing about them....? A song about releases and bugs, IDEs and memory leaks...

I tried. I'm bold. I think... I thought - there can't be any woman out there who sings about effective systemdevelopment....so let me be the first one! I made a rap song.

Beware: I'm not a musician so if your ears are damaged for ever...don't sue me. Sue the enervating systems out there....

Enjoy:   triginta.net/JavaRap.wav

Läs mer...

I förra veckan skrev jag om hur jag också sett ljuset - Ruby och Rails.
Nu är det dags att lära sig på riktigt.
För så pass mycket har jag insett - att detta är något jag verkligen tänker mästra!

Det gäller ju inte bara att skriva applikationer, man vill ju även att de ska bli skrivna elegant, följa rätt praxis och utnyttja styrkan i ramverket och språket på bästa sätt.
Helt enkelt - man vill skriva lite "by the book".

Så nu har jag köpt en riktigt bra bok om Ruby on Rails - som jag läser i soffan.
Varför jag skriver om det just nu och här?
För att alla ni som läser detta ska veta mitt mål - och genom det tvingas jag att uppfylla det - med råge.

:-)

Läs mer...

Jag måste medge, det var så mycket snack om Ruby och Ruby on Rails att jag inte visste om jag bara skulle vara nyfiken eller även unna mig att bli lite anti - just för sakens skull.
Så fort man läste om det, så var det ju bara superlativ och folk som jublade.
Nästan så det kändes för mycket.
Jag tänkte - ja men så himla bra kan det ju ändå inte vara.
Det som definitivt slog mig var att alla som skrev om Ruby on Rails beskrev det i termer som att det var så roligt och kul.
Ja - som att det fanns ren glädje i det hela.  Självklart kan man ju bli extra skeptisk av sådant - särkilt när man tänker - men varför kan inte jag detta!

Så jag provade! Och det är bara så kul! Så kul!!!!

.... för alla detaljer måste du välja "Läs mer" länken nedan.... :-) - dessa är bortklippta här

Men då har jag inte berätta om det som är riktigt kul! Det är scriptspåket Ruby.
Jag hittade en kul sajt i helgen - där lär man sig syntaxen och det väsenliga inom Ruby på 15 minuter.!
Prova! Jag tyckte denna turorial var jätte kul!
http://tryruby.hobix.com/

Läs mer...

Många gånger hamnar jag som javakonsult i en mentor roll för nyutexaminerade javaprogrammerare.
...

Men lika mycket som det är svårt att sätta ord på vissa angreppssätt, så är det enkelt för mig att dela med mig av mitt bästa knep för effektiv och robust javaprogrammering och felsökning.

Mitt nummer-ett-tips till alla javaprogrammerare som kör fast är: Använd Google.
Jag använder Google till allt ifrån att kolla upp vad diverse felkoder i krasher är till att kolla upp vad diverse klasser egentligen gör.
Jag har då aldrig använt en javadoc till att få reda på det (undrar just om någon gör det), däremot är ju tutorials, exempel och forum på nätet, suveräna för att få vägledning i hur man bör göra.
Men de är framförallt bäst för att veta varför man INTE ska göra på vissa sätt. Utmärkt sätt att hitta fallgropar på!
De svåraste fallen med de mest intetsägande felmeddelanden kan många gånger lösas blixtsnabbt genom att bara klistra in felmeddelandet i browsern.
Man är ju oftast inte ensam om att råka ut för händelser, vare sig det rör sig om minnesproblem, versionsproblem eller rena programmeringsfel.

En javakonsult behöver faktiskt inte kunna allt. Det viktiga är att en javakonsult vet hur man hittar information och kan applicera den på effektivt sätt.
När jag kör fast hjälper Google mig oftast ur träsket.

Läs mer...

Certain system errors feel impossible to solve. Multiple programmers have over time looked in to the same problem, analysing, using their full capacity of experience and knowledge but finally having to resign.
They don't know how to solve the problem. The errors can't be reproduced. No clues in logs or in code.
In worst cases it doesn't even occur in your environment, only in the client’s environment and, of course, very rare and for different users.

Ps For all my clients that may read this - this doesn't apply to Your problems. I always fix them yesterday! Ds

Läs mer...

Många människor blir trygga av att kategorisera in folk i grupper.
Men att kategorisera in människor i gruppen java konsulter är inte helt enkelt.
För vad är egentligen en javakonsult. (Och ska det särskrivas eller ej?)

En java-konsults arbete kan ju skilja sig avsevärt beroendes på vad man sysslar med. Så vissa har försökt med att använda uttrycket front-end för tekniker som
applets, scripts, webapplikationer (Struts, JSF, Wicket, GWT etc) och uttrycket back-end om man arbetar med  tekniker som EJBs, databaser osv.
Sen finns det ju självklart alla java konsulter som arbetar med både front-end och back-end och mittemellan och över och under.
För att inte tala om alla andra javatekniker som inte heller kan kategoriseras in i back-end eller front-end.

En java konsult arbetar dessutom med så mycket mer än just språket java. Man kanske kontinuerligt även arbetar med SQL, Ant, Maven, XML, diverse scriptspråk som jsp mm.
Så därför kanske uttrycket systemutvecklare passar bättre. Men då har man ju också gjort det ännu mer odefinierbart....
Eller kanske man borde säga systemutvecklings programmerare med fokus på java....och däribland både front-end tekniker och back-end tekniker...

Eller så säger man bara att man är konsult. Och är det otydligt, kan man förtydliga....IT konsult.

Läs mer...

In this article I have some thoughts over laziness when programming and that I believe that recalling the basics of the java language may inspire us to be less lazy...

Some quotations from the article
"However, if you do an illegal u-turn once, you may do it again, all of a sudden you may do it just whenever, by routine, because it works."

"A programmer, who has programmed for over 15 years, is in the same way probably a better programmer than he/she was in the beginning of the carrier. However, also programmers may become lazy in obeying all the programming rules."

"The basic of the java language is not like 'once you know how to cycle you will always know how to cycle'. I think it is more like 'even if you have been fluent in French – when not practicing you don’t speak as fluent anymore…' "

Welcome to read more! It's free!

Läs mer...

Jag tror att Winston Churchill sagt något så här (eventuellt har jag själv modiferat lite):
Om du skriver ett brev i vredesmod, läs igenom det, knyckla sedan sönder det och släng det i brasan.
Skriv sedan ett nytt dagen därpå.

Jag tycker ovan talesätt verkligen kan appliceras på  programmering oxå.

Läs mer...

Programming is a great happiness recipe for me – I need to find ways to keep it lasting for ever!

 

 

I love programming. It gives me a rush. It gives me so much energy. If I’m tired, I will be wide awake as soon as I start programming. So what can it be that is so great? How can I make something useful out of this passion? What kind of person any way gets such a passion?  What should I do if I lose this passion?

 

I believe a programmer is a person who likes to be creative.

But also structured.

 

I believe that all those who like to solve crosswords, sudokus, knit or bake a cake, have the perfect basics for becoming a passionate programmer.

 

Therefore, it is remarkable that there are so few knitting old ladies that consider programming as a hobby. Why is that so? They can do it! They would love it. Instead of knitting parties, why not a Hello World over a cup of tea?

 

Read more about my philosophical thoughts here...

Läs mer...

I believe that by aknowledging that people are intelligent and indeed can understand things outside their own domain, we have a chance to improve our systems and working process.

I say - let the programmers meet the end user! Atleast once!
To allow the programmer to see the end user working live - is a great way of allowing the programmers brain to be used in a broader way!

I also want to encourage programmers to actually take time and  explain technical stuff to non-programmers that are dependent on their work. They will understand - if just someone took the time and tried to explain.

Explain and understand once  - benefit for ever!  Read more...

Läs mer...

There are big differences between system development in a maintenance system compared to working with new development.

Therefore, I  believe , it's crucial to have the maintenance of the system in mind already when developing it. For example, the choice of technique to use in the system must be chosen having in mind  the people who most likely will maintain the system..

Many times a system developer in a maintenance team is a mix of a programmer and functional expert.  Probably that person maintain not just one system but several ones. And several big ones. We should be careful not to use too many new and small techniques - especially if maintenance will be by just 1-2 persons.

Also when designing the code, we need to have maintenance as a prime focus.  Are we creating a system that easy can be debugged? Easy can be regression tested? Are we making the system's architecture intuitive, so it will be easy to find which functionality is implemented by which class/classes. Do we really need so many modules? Do we really need so many interfaces? Do we need recursive loops or can we write it longer but easier to debug and understand? Do we need all these innerclasses? They may be smooth and fit well into the object thinking - but maybe they are more difficult to find/debug?

Ofcourse, with Behavour Driven Development and Test Driven Development - we are  very close to the goal of getting system that are easy to maintain and develop further!

Read the article for  more reflections around  the main differences between maintenance and new development regarding "Time", "System knowledge" and "Version handling" :

Läs mer...

Since nobody questions the good of chat and mail - I would like to give a tribute to the phone! The phone, I would say, is the number one tool for effective communication! It is the phone that make us feel near. The human voice. We work with computers - but so far, we are still not computers. The human voice, when not screaming and scolding, make us feel allied. When we are allied, we start to work more effective. Because we dare to ask when we don't understand and we dare to double check when we are in doubt.

...

Läs mer...