When I have been employed as a programmer, I have many times been allowed to enter an open course x times per year, invest x hours per year in self studying etc. However, usually, the subjects needed to be related to my work.
For me, it did actually mean that I connected learning with work. And I didn't want to work on my free time...
Then came a time when I realised that I had forgotten that I love learning IT stuff. I have always loved that - how could I just forget? But somehow I forgot it.
When I remembered - I started learning again, for my own sake, as my hobby and just to have fun - and on my free time. And it is so fun! When I learn on my free time I relate IT as my hobby - not as work.
I have now been into a period where I started to look more into Tapestry 5, Spring, Hibernate.
When looking into new techniques, it usually opens doors to so many other things as well. In my case, for example, openejb, Maven, HSQLDB etc.
Sometimes learning is like trying to plough through a really thick snow wall.
You feel like you never get through. And more and more snow is just falling off the sides of the tunnel around the plough.
Then when you finally are through, you have to reverse and collect the snow that fell down as well.
Ok - so here it comes....my metaphor. (I truly hate everyone else’s metaphors, always think they are silly, so let me therefore be equal silly and make my own....)
I see the small snow chunks that fell around me, as new leanings that I get on the way of pursuing my studies.
And many times they can be as giving as the subjects I intended to study.
When studying on my free time, I can just pursue any road I wish. If I find openejb interesting, I can just invest some days in that, and then when I am ready, continue with Tapestry.
I guess what makes it so fun is that there is no time pressure or pressure for effective study.
My experience is that no matter what I study, either if I study something I already know or if I study something totally new,
I always learn something.
Learning things we already know
Many times we learn techniques at work. We learn by practice.
For example, I guess a lot of people are familiar using Ant or Maven, but not all have actually studied the techniques in detail.
Sometimes it is not needed to directly study a technique in order to use it. And when needed, we may just study the part we need to use.
However, it can be fun, fairly easy and comfortable to read about something you already are quite familiar with.
Sometimes one can just sit in the sofa and read the code, and still get aha's.. That's convenient! No need to code yourself, because you get the picture any way.
Learning more in depth - gives me self confidence.
Learning things we have forgot
Some techniques needs a full understanding when setting up or creating - but may after an initial phase, not be altered so much.
For example, creating EJBs, webservices, project setups, database schemas etc. These tasks are very seldom performed, compared to just coding business logic etc.
So certain things we forget because we seldom use it. And when we need to use it, we need to refresh our knowledge.
It can be quite fun as well to refresh old knowledge. And usually it goes quick. Like driving a manual geared car after long time having driven automatic gears.
Quite fun! (Oooops - one more metaphor!)
Refreshing old knowledge also gives me self confidence.
Since there are so much happening and so many techniques, one may feel overwhelmed. Where to start?
A couple of years ago I was frustrated by all new web framework that had emerged. No one could tell which to use.
Wicket, Tapestry, JSF, Struts, Rails etc
But once we just dive into it - it's not THAT bad.
When no one can tell which to use - we need to believe that we have the power to judge ourselves.
We can get a good overview ourselves. Actually it's like learning languages.
Once you know French - then Italian, Spanish and Portuguese is not that far away.
Same with web framework - you start to see the similarities. And can also appreciate the differences.
So what do I want to say with this post?
Learning new stuff and old stuff can be fun.
And it gives self confidence.
I at least like to be self confident and I always like to have fun.
So if you are looking for either of the above, maybe some learning can do the trick?
:-)
söndag 15 november 2009
Technology stressed? Cool down. Relax.
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.
I am thinking about telephony. In India the infrastructure for landline telephony was never good. Most people never had any telephone and used telephone boots for calling. This was a great problem.
And then the cell phones arrived. And all of a sudden, telephony was not a problem any more! A great deal of the population could just skip the landline phase and go directly to cell phones. And it works great!
So sometimes when I get stressed about technologies I think the same way.
Some technologies come and then they disappear.
If I don't have time to learn them now - maybe it's not a problem. They may be replaced by something better or at least less buggy.
The longer I wait, the more experiences other have had from it, which I can learn from.
One thing most of us probably have experienced is how hard and frustrating it can be to be on bleeding edge. Since - you really bleed. The products to use are still not mature and you discover lots of bugs. Sometimes it can truly be effective to be one step behind!
As programmer, I love to learn new technologies. But soon vacation time is arriving - and I don't intend to be technology stressed then!
Don't be you either! :-)
After vacation - there may be a new release out there. Main bugs solved...and if you wait little more, the new introduced bugs will also be solved....
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.
I am thinking about telephony. In India the infrastructure for landline telephony was never good. Most people never had any telephone and used telephone boots for calling. This was a great problem.
And then the cell phones arrived. And all of a sudden, telephony was not a problem any more! A great deal of the population could just skip the landline phase and go directly to cell phones. And it works great!
So sometimes when I get stressed about technologies I think the same way.
Some technologies come and then they disappear.
If I don't have time to learn them now - maybe it's not a problem. They may be replaced by something better or at least less buggy.
The longer I wait, the more experiences other have had from it, which I can learn from.
One thing most of us probably have experienced is how hard and frustrating it can be to be on bleeding edge. Since - you really bleed. The products to use are still not mature and you discover lots of bugs. Sometimes it can truly be effective to be one step behind!
As programmer, I love to learn new technologies. But soon vacation time is arriving - and I don't intend to be technology stressed then!
Don't be you either! :-)
After vacation - there may be a new release out there. Main bugs solved...and if you wait little more, the new introduced bugs will also be solved....
Ruby on Rails - my roadtrip so far
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.
My roadtrip so far:
I started out with the Eclipse IDE using plugins from Aptana and using SqlLite3 as database.
Then I moved over to Netbeans and started using MySql as database.
Ruby on Rails have/is moving to Github, a distributed source repository, and most of the rails plugins are also moving to Git. So I also needed to install and understand Git.
The main concepts of Rails builds on having a well thought through datamodel and using ActiveRecords for storing the objects. So it is indeed a VERY object oriented framework. I've learned how to use ActiveRecords for setting up the datamodel using belongs_to and has_many... etc.
One reason, I think, that makes Rails so flourishing, is that there are so many plugins out there.
However - I would say this is for both good and bad.
I guess the reason why there are so many plugins - is that the framework encourages own development of plugins.
However, some days ago, I got a wake-up call - of the vulnerability of the abundance of plugins and free opensource.
I was to use a plugin, named Streamlined, that there was so much buzz over.
A plugin that gives a administrative GUI interface to the datamodels.
A quite handy thing to have - and unnesseassary to build yourself.
As late as in october 2008 there was a lot of buzz about this plugin - but I realised I hardly saw andy post that was dated after that...
And while looking for a solution to a problem I found in the said plugin - I found a google group where one of the contributors told, what I deep inside had suspected...the plugin should be considered as dead!
"We've put out calls for others to step up and take over the project, but so far noone has responded. "
Ofcourse these things happens often - new techniques take over. But I was struck by how fast it can go.
And I guess that the faster the pace within an area, in this case Rails and all its gems and plugins, the faster techniques can also die.
Anyway - since another eqvivalent plugin exist, ActiveScaffold- with equal amount of buzz, I could continue to roll with Rails...
I am also using Restful_Authentication plugin - which is also very conveneient - since all authentication, including setting up of tables etc, is taken care of, I can roll even faster...
But I have philosophical reflections:
I assume the following:
On the other hand - this is nothing new either. This is frequent in all languages and framework.
But I find it extra evident in Rails.
To end - I am still hooked to Ruby on Rails. And now I can say I know quite a bit of it!
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.
My roadtrip so far:
I started out with the Eclipse IDE using plugins from Aptana and using SqlLite3 as database.
Then I moved over to Netbeans and started using MySql as database.
Ruby on Rails have/is moving to Github, a distributed source repository, and most of the rails plugins are also moving to Git. So I also needed to install and understand Git.
The main concepts of Rails builds on having a well thought through datamodel and using ActiveRecords for storing the objects. So it is indeed a VERY object oriented framework. I've learned how to use ActiveRecords for setting up the datamodel using belongs_to and has_many... etc.
One reason, I think, that makes Rails so flourishing, is that there are so many plugins out there.
However - I would say this is for both good and bad.
I guess the reason why there are so many plugins - is that the framework encourages own development of plugins.
However, some days ago, I got a wake-up call - of the vulnerability of the abundance of plugins and free opensource.
I was to use a plugin, named Streamlined, that there was so much buzz over.
A plugin that gives a administrative GUI interface to the datamodels.
A quite handy thing to have - and unnesseassary to build yourself.
As late as in october 2008 there was a lot of buzz about this plugin - but I realised I hardly saw andy post that was dated after that...
And while looking for a solution to a problem I found in the said plugin - I found a google group where one of the contributors told, what I deep inside had suspected...the plugin should be considered as dead!
"We've put out calls for others to step up and take over the project, but so far noone has responded. "
Ofcourse these things happens often - new techniques take over. But I was struck by how fast it can go.
And I guess that the faster the pace within an area, in this case Rails and all its gems and plugins, the faster techniques can also die.
Anyway - since another eqvivalent plugin exist, ActiveScaffold- with equal amount of buzz, I could continue to roll with Rails...
I am also using Restful_Authentication plugin - which is also very conveneient - since all authentication, including setting up of tables etc, is taken care of, I can roll even faster...
But I have philosophical reflections:
I assume the following:
- Most plugins are contributions by individuals who have created them for free. In other words - charity work.
- Most programmers like more to develop and less to maintain.
- Plugins are developed isolated but may rely on version of rails and other plugins.
- So when rails upgrade or change or other plugins change - the existing plugins may need to change as well.
On the other hand - this is nothing new either. This is frequent in all languages and framework.
But I find it extra evident in Rails.
To end - I am still hooked to Ruby on Rails. And now I can say I know quite a bit of it!
Make your voice heard
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
Ruby on Rails - den spännande fortsättningen...
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.
:-)
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.
:-)
Äntligen har jag också sett ljuset - Ruby och Rails!
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!!!!
Jag utvecklade i Eclipse och använde en befintlig plugin.
Det måste medges - att det enda som varit krångligt i det hela, var att få till miljön. Mitt långsamma hemnätverk bidrog till den frustrationen, så det ska absolut inte ligga någon plugin till last.
Det jag främst fick erfara - var Aptana. Wow - en helt ny värld öppnar upp sig.
Vad är Aptana?
Ja inte vet jag riktigt - men det är hur mycket som helst! Sen alla "gems" - som om det var ett vedertaget uttryck!
Look it up yourself! Jag orkar inte förklara här. Hursomhelst, det är från Aptana man får nödvändiga plugin och gems till Eclipse miljön.
Sedan när det är på plats, så vill man antagligen fixa så att man kan köra med en egen liten databas.
Det finns bra inbyggda varianter - jag testade med SQLLite3 som var ett bra alternativ att börja med.
OBS - jag har ännu inte kommit till det roliga!
När väl miljön är på plats - då bara smäller det!
Man högerklickar och skapar ett Rails projekt.
Sedan använder man inbyggda funktioner för att skapa ett färdigt flöde som innehåller allt från websida med GUI funktioner för att uppdatera data till att de facto spara ned och hämta upp datat från tabell.
Det enda man behöver göra är att på en rad skriva objekt med kolumnnamn. Sedan ett knapptryck.
Då skapas klasser, websidor, databas scheman och rubbet.
Sedan ett till knapptryck där man skapar tabellerna utifrån detta.
Alltså - totalt 2 knapptryck och en rads specning - och en hel websajt är på plats. Unbelievable!
Visserligen - detta är ju då rätt fyrkantigt, såtillvida att det tex bygger på engelska.
Jag skapade en bilbytarsajt där jag hade objektet bil med fälten biltyp, arsmodell.
Självklart skapas ju då automatiskt objektet bils som kan innehålla flera bil.
Så i detta fall inser man att det som vanligt är bättre att köra med engelska. Då blir car och cars mera logiskt än bil och bils....
Men det är ju ändå inte menat att man ska använda det genererade rätt av. Däremot, ger det en enormt bra hjälp för att komma vidare och tänka själv.
Man är väl inte mindre programmerare än att man kan ändra på saker - när man väl har ett facit nära till hands!
Så Rails är bara så kul! Så enkelt!
Men - det är inte lämpad för större komplexa system - men perfekt för mindre grejer. Och kul!
Oj - jag kanske redan hade sagt att det var kul...
:-)
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äsentliga inom Ruby på 15 minuter.
Prova! Jag tyckte denna turorial var jätte kul!
http://tryruby.hobix.com/
Så därja. Nu har jag nog inget mer att säga.
En del säger att diamonds is a womans best friends....jag vet inte jag....kanske är det ruby....
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!!!!
Jag utvecklade i Eclipse och använde en befintlig plugin.
Det måste medges - att det enda som varit krångligt i det hela, var att få till miljön. Mitt långsamma hemnätverk bidrog till den frustrationen, så det ska absolut inte ligga någon plugin till last.
Det jag främst fick erfara - var Aptana. Wow - en helt ny värld öppnar upp sig.
Vad är Aptana?
Ja inte vet jag riktigt - men det är hur mycket som helst! Sen alla "gems" - som om det var ett vedertaget uttryck!
Look it up yourself! Jag orkar inte förklara här. Hursomhelst, det är från Aptana man får nödvändiga plugin och gems till Eclipse miljön.
Sedan när det är på plats, så vill man antagligen fixa så att man kan köra med en egen liten databas.
Det finns bra inbyggda varianter - jag testade med SQLLite3 som var ett bra alternativ att börja med.
OBS - jag har ännu inte kommit till det roliga!
När väl miljön är på plats - då bara smäller det!
Man högerklickar och skapar ett Rails projekt.
Sedan använder man inbyggda funktioner för att skapa ett färdigt flöde som innehåller allt från websida med GUI funktioner för att uppdatera data till att de facto spara ned och hämta upp datat från tabell.
Det enda man behöver göra är att på en rad skriva objekt med kolumnnamn. Sedan ett knapptryck.
Då skapas klasser, websidor, databas scheman och rubbet.
Sedan ett till knapptryck där man skapar tabellerna utifrån detta.
Alltså - totalt 2 knapptryck och en rads specning - och en hel websajt är på plats. Unbelievable!
Visserligen - detta är ju då rätt fyrkantigt, såtillvida att det tex bygger på engelska.
Jag skapade en bilbytarsajt där jag hade objektet bil med fälten biltyp, arsmodell.
Självklart skapas ju då automatiskt objektet bils som kan innehålla flera bil.
Så i detta fall inser man att det som vanligt är bättre att köra med engelska. Då blir car och cars mera logiskt än bil och bils....
Men det är ju ändå inte menat att man ska använda det genererade rätt av. Däremot, ger det en enormt bra hjälp för att komma vidare och tänka själv.
Man är väl inte mindre programmerare än att man kan ändra på saker - när man väl har ett facit nära till hands!
Så Rails är bara så kul! Så enkelt!
Men - det är inte lämpad för större komplexa system - men perfekt för mindre grejer. Och kul!
Oj - jag kanske redan hade sagt att det var kul...
:-)
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äsentliga inom Ruby på 15 minuter.
Prova! Jag tyckte denna turorial var jätte kul!
http://tryruby.hobix.com/
Så därja. Nu har jag nog inget mer att säga.
En del säger att diamonds is a womans best friends....jag vet inte jag....kanske är det ruby....
Javakonsult och Google är en bra kombination!
Många gånger hamnar jag som javakonsult i en mentor roll för nyutexaminerade javaprogrammerare.
De vill då se och lära av mig hur jag gör för att attackera javaproblem. Och ibland blir jag lite ställd av situationen,eftersom jag själv inte alltid har ett strukturerat sätt att angripa alla problem på.
Det är svårt att visa hur man gör när man brainstormar med sig själv eller när man bara testar hej vilt och går på känn.
Å andra sidan - oftast när man går på känn, så avänder man ju sin intuition.
Och intuition i sig bygger ju på iaktaggelser och erfarenheter som man faktiskt under åren som javakonsult lagrat i huvudet nånstans.
Så därför kan man ju faktiskt försöka sätta ord på hur man tänker, varför man valde att tänka just så och vad det är man tänker testa för att se ifall man är rätt ute.
För det finns ju en rationell tanke till varför man gör som man gör, även om man själv inte är helt medveten om den.
Man lär sig ana när problem kan vara data-relaterade, java-relaterade eller konfigurerings-relaterade.
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.
De vill då se och lära av mig hur jag gör för att attackera javaproblem. Och ibland blir jag lite ställd av situationen,eftersom jag själv inte alltid har ett strukturerat sätt att angripa alla problem på.
Det är svårt att visa hur man gör när man brainstormar med sig själv eller när man bara testar hej vilt och går på känn.
Å andra sidan - oftast när man går på känn, så avänder man ju sin intuition.
Och intuition i sig bygger ju på iaktaggelser och erfarenheter som man faktiskt under åren som javakonsult lagrat i huvudet nånstans.
Så därför kan man ju faktiskt försöka sätta ord på hur man tänker, varför man valde att tänka just så och vad det är man tänker testa för att se ifall man är rätt ute.
För det finns ju en rationell tanke till varför man gör som man gör, även om man själv inte är helt medveten om den.
Man lär sig ana när problem kan vara data-relaterade, java-relaterade eller konfigurerings-relaterade.
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.
A java programmers thoughts - if you just wait long enough, the problems disappear...
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.
I believe most systems now and then suffer from bugs/problems which no one seems to find a solution to.
Sometime these problems exist for years. If you go for a year long leave, that bug may be the last thing you saw and also the first one that welcomes you back, one year later.
That feels really annoying.
However, if one just waits long enough - such problems can actually disappear.
-The system itself may get replaced.
-New functionality may get implemented that somehow removes the problem.
-The client might have got so tired of the problem that they learn how to live with it and let you live without it.
Many times we don’t even need to wait long! Sometimes a bug is fixed by itself during the night. The next day everything works fine.
Well one thing is for sure. There must be a reason for the problem. But do we always need to find out the reason? Hmmm I don't know.
Sometime we may put so much effort and time in tracing impossible problems - one may wonder if it is worth it. But on the other hand, we can't neglect problems.
Well - I don't have any solution to how to solve these impossible problems. If I had, I would probably be lying on a beach on a paradise island, instead of blogging....
So I just want to say - it feels really good to know...that problems may just disappear by themselves....
One only needs to wait....sometimes really really long...
Ps For all my clients that may read this - this doesn't apply to Your problems. I always fix them yesterday! Ds
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.
I believe most systems now and then suffer from bugs/problems which no one seems to find a solution to.
Sometime these problems exist for years. If you go for a year long leave, that bug may be the last thing you saw and also the first one that welcomes you back, one year later.
That feels really annoying.
However, if one just waits long enough - such problems can actually disappear.
-The system itself may get replaced.
-New functionality may get implemented that somehow removes the problem.
-The client might have got so tired of the problem that they learn how to live with it and let you live without it.
Many times we don’t even need to wait long! Sometimes a bug is fixed by itself during the night. The next day everything works fine.
Well one thing is for sure. There must be a reason for the problem. But do we always need to find out the reason? Hmmm I don't know.
Sometime we may put so much effort and time in tracing impossible problems - one may wonder if it is worth it. But on the other hand, we can't neglect problems.
Well - I don't have any solution to how to solve these impossible problems. If I had, I would probably be lying on a beach on a paradise island, instead of blogging....
So I just want to say - it feels really good to know...that problems may just disappear by themselves....
One only needs to wait....sometimes really really long...
Ps For all my clients that may read this - this doesn't apply to Your problems. I always fix them yesterday! Ds
Java konsulter eller javakonsulter
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.
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.
Avoid laziness by recalling the basics of the basic
A person who has been driving for 20 years may not be as particular in watching all the mirrors before turning, holding the steering wheel at ten to two or only make legal u-turns. That person is still probably a better driver than he/she was in the beginning.
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 common laziness is to make all access modifiers of the java methods public.
New java developers may do it by mistake, but senior developers do it by laziness.
And maybe most of all – maybe we get reminded about some good finesse in the java language that we can use!
At least I do! I know there are so many good things in java that I should use more often. And by saying it here – I force myself to also take action and do so.
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…”
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 common laziness is to make all access modifiers of the java methods public.
New java developers may do it by mistake, but senior developers do it by laziness.
And maybe most of all – maybe we get reminded about some good finesse in the java language that we can use!
At least I do! I know there are so many good things in java that I should use more often. And by saying it here – I force myself to also take action and do so.
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…”
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, knyckl
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å.
Vid vissa programmeringsuppgifter kan man ju hamna i en situation där man inte vet hur man ska börja eller vad man skall göra. En frustration börjar växa.
Då kan det vara skönt att bara tokprogrammera. Dvs programmera hur som helst som en vettvilling. Ofta tills att koden går sönder - dvs verkligen inte går att köra,
men förhoppningsvis hinner man att se, precis innan man sabbat allt , ljuset!
Då är man redo. Då kan man backa. Reverta all programmering som man precis gjort. Och så börjar man om.
Men nu är man lugn och sansad. Skriver kommentarer, använder schysst namnsättning i koden, bryter ut/ner delar - ja, tänker lite längre. Och nu kan man verkligen styra mot ljuset.
Det bästa med tokprogrammering är att man förutom att bli av med frustrationen verkligen får bra insikter i hur koden bör göras och hur saker fungerar.
Framförallt vilka andra fällor, i form av klasser och beroenden, som lurar runt hörnet som man också måste ta höjd för.
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å.
Vid vissa programmeringsuppgifter kan man ju hamna i en situation där man inte vet hur man ska börja eller vad man skall göra. En frustration börjar växa.
Då kan det vara skönt att bara tokprogrammera. Dvs programmera hur som helst som en vettvilling. Ofta tills att koden går sönder - dvs verkligen inte går att köra,
men förhoppningsvis hinner man att se, precis innan man sabbat allt , ljuset!
Då är man redo. Då kan man backa. Reverta all programmering som man precis gjort. Och så börjar man om.
Men nu är man lugn och sansad. Skriver kommentarer, använder schysst namnsättning i koden, bryter ut/ner delar - ja, tänker lite längre. Och nu kan man verkligen styra mot ljuset.
Det bästa med tokprogrammering är att man förutom att bli av med frustrationen verkligen får bra insikter i hur koden bör göras och hur saker fungerar.
Framförallt vilka andra fällor, i form av klasser och beroenden, som lurar runt hörnet som man också måste ta höjd för.
The pure joy and rush of programming
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?
I believe that in professional working situations, it is essential to have passionate programmers. In the same way as I believe that it is essential that leaders are passionate about leading. Wrong person in wrong place is disastrous.
A passionate person does more than the minimum requirements…which is good!
So what is so great about programming? Usually I feel that the more impossible the task feels, the more the rush.
My first programmer job ever was actually as a Cobol programmer, even though I was educated in C++.
So when I got the first clean compile in my Cobol program, I just screamed hurrah loud in pure joy. Some senior programmers thought it was fun and energizing to see that a clean compile actually could create such a joy.
However, once you are used with a syntax and basics of a language, it usually takes more to get that rush.
Nowadays the rush is triggered by other things.
When I look in messy legacy code and finally figure out how it is supposed to work and maybe how to make it better – I get a rush. Legacy code can give a rush! Hurrah.
However, nowadays, I most of all get a rush when I learn new things.
When I realise how I can programme better or cleaner.
But also when I learn new techniques. Languages, tools and frameworks – to be more precise.
If I try a new technique or script language, then a working Hello World can make me happy enough to take a coffe break and at least a little say Hurrah. And it is good to take a break, because it is after the working Hello World, that the real struggle begins. And more rush! Hurrah.
So how can I make something useful out of this passion? Well, as long as it makes me happy, its useful enough! And I can learn more. Maybe teach others? Maybe get the old knitting ladies to also see the greatness of programming…?
The main thing for me now is to figure out how to make it ever lasting. How to make programming so exciting that it will always make so happy. I think the best is:
- Make applications that I can be proud of.
- Always strive to be a better programmer, find new better ways.
- Experience new techniques. Upgrade and be in touch with cutting edge technology. Feel the future.
- Make some own applications in my spare time that will make me economical independent – in short a millionaire…
In any case – my last word must be – if an organisation turns a programmer from being passionate to be inpassionate – it is very tragic. And it is unnecessary! And what a waste of good talent. Don’t ever let it happen.
Find out if the passion is disappearing and do something about it. It’s worth it. A million times.
Programmers do actually have a brain...and so does others
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. How is a programmers test and what may the programmer not test? What is the meaning of a build or deploy? What is a server? How may branches and releases be connected? What is a merge?
A list of some benefits that I think is achevable by recognicing peoples intelligence:
*Programmers have a brain - let programmers atleast once meet the end consumers of the system and really understand WHY certain requirements exist.
-This will surely help minimising misunderstanding.
-This will probably help in achieving a consistent vocabulary, i.e. so that the naming in code are the same words as the words used by users.
-This will hopefully help programmers be pro-active in finding weaknesses in system and find better design solutions.
*Non-programmers have a brain - let non-programmers at least get a fair chance to get explanations to what is happening in the technical area.
-What is acually a jar file?
-What are servers?
-What does a build mean?
They will understand! Once basics are cleared out - process and planning can be smoother.
Explain and understand once - benefit for ever!
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. How is a programmers test and what may the programmer not test? What is the meaning of a build or deploy? What is a server? How may branches and releases be connected? What is a merge?
A list of some benefits that I think is achevable by recognicing peoples intelligence:
*Programmers have a brain - let programmers atleast once meet the end consumers of the system and really understand WHY certain requirements exist.
-This will surely help minimising misunderstanding.
-This will probably help in achieving a consistent vocabulary, i.e. so that the naming in code are the same words as the words used by users.
-This will hopefully help programmers be pro-active in finding weaknesses in system and find better design solutions.
*Non-programmers have a brain - let non-programmers at least get a fair chance to get explanations to what is happening in the technical area.
-What is acually a jar file?
-What are servers?
-What does a build mean?
They will understand! Once basics are cleared out - process and planning can be smoother.
Explain and understand once - benefit for ever!
There are big differences between system development in a maintenance system compared to working with new development. The 3 major differences, I wou
There are big differences between system development in a maintenance system compared to working with new development.
The 3 major differences, I would say, is time, system knowledge, and version handling.
In this article I aim to discuss these differences a bit.
But to start with... I think it is crucial to aknowledge that there are great differences.
And also crucial to always think about the maintenance of the system when developing it.
For example, the choice of technique to use in the system should be synced so it matches the people who most likely will maintain the system.
One need to ask - who may maintain this system 1 year ahead and who after 5-10 years ahead? How will this system be running then?
What are the technical competencies of the people who 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.
This developer may not keep up to date with all the latest teqniques for understandable reasons.
We don't want stagnation - we need to move forward with techniques and be in the future.
But we should be aware not to use too many new and small techniques - especially if maintenance will be by just 1-2 persons.
When designing the code - we should also think about maintenance. Develop for maintenance.
Are we creating a system that easy can be debugged? Easy can be regression tested?
Are we making the system 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!
So now - my reflections around the issues "Time", "System knowledge" and "Version handling":
Time:
In new development teams - you have deadlines to look after. Nemas problemas.
In maintenance systems, you have to make severe problem fixes in modules you have never heard about in a couple of hours. That is problemas.
The question is - How to secure good and fast fixes for severe production problems?
One option is making a a quick temporary fix - that allows some time to breethe and figure out a more well designed programmatic fix to the problem.
In any case you need to know about the systems full functionality and design in order to figure out where any fix best should be placed.
You also need to understand the implication of the fix.This leads me to the second difference...
System knowledge. Or rather how to get access to system knowledge, in a quick way.
When new systems are built, system knowledge is found all around you. The architect or programmer of a certain module, may sit next to you.
New systems are usually built by a large team of a bunch of clever intelligent programmers. They use all their smartness. They prefer to use new improved technology that will be flexible and suit the future. Some of the team may stay a while - but then as the system goes into production and stabilises, they diminish. Left is maybe just 1 or 2 persons. 1-2 people will now support a complex system, maybe built by 10 people over 1 years time. Not an easy task!
Even if the people working with maintenace hopefully have been part of the development, they will probably not know about all the clever smart things implemented.
Many times it is the most smart programmatic solutions that are most difficult to maintain, i.e. to understand and make changes within.
Usually, all further development of the system, now made by the maintenance team - are just focused around certain bits of the system.
So what is needed to quick get access to knowledge about the rest of the system, when it start to fail?
Solution is mainly.... Documenatation! Yes, documentation.
Since our head can't have everything, and we may die - and then somebody else needs to take over... The best is to have a single point of start where we quick can find links to all documents we need.
For example, its perfect with a wiki that links us right.
From the top of my head I would say the following piece of documentation/information to be stored, is definetely needed.
- Location of things - list of server names, log locations, applications and batch jobs locations - for all various levels of environments.
- Roles documentation. Who is responsible for what, Who can I call to quick get answers of functionality etc. Needs to be accessible by all and updated always.
(Ofcourse, the people having a role, must know that they have that role, this is not always the case.). - Architectural descisions doc - will answer "what are the reasons for why this was built like this". Should only be used when a descision actually is made.
A reason can be like: "we decided to keep module A and B separate since there are discussions of maybe in the future replacing module B with XXX".
If we know the reason - then we can evaluate if that reason still seems valid.
This may have a huge impact on how the fix may be implemented.
So - some kind of "architectural descisions" document is very valuable.
We may remember that regarding module C it was something important to remember but not wat it was.
With this kind of document, we will remmeber what to remember. . - A plain old fashioned System documentation. That we need! I don't agree with those who argue for no documentation.
If the only thing we have in a maintenance team are some java docs and maybe some initial specs...then we need to rethink!
However, from all really heavy system documents I've read during my years, I would say it is usually just the first two pages that has been of most use.
So it may as well be enough just to have these 2 pages in a System documentation. But then they need to be real good!
So what do I like in a System doc...? Pictures are good!
-An absolute updated graphical picture of the system and its interactions to other systems, servers and databases.
That gives, as a start, a very good overview of the full system and its external interactions.
- A management summary of the system.
- Lists of all modules and what there main functions are.
Hmmm and so much more... can't take it here...
In any case - documentation outside the system ensures that also non programmers can help in finding the best solution to a fix that needs to be done.
Javadoc is good - but doesn't allow lengthy explanations of a full module. And the question ...which class in the module should have that overview explanation...
- the "Everything" log. My own name for it. Keep a log of all that happens within the system. Mail konversation with client of new requests, complaints from operations regarding time out problems etc.
Just a very long simple text document where you can cut and paste all from
a bug report to a mail conversation. In stable systems not much happens. But when it happens it is usually connected with something that you will find in the log.
A fix was done 9 months ago in module X - and now System B is complaining over data delivered from module X...aha...
It doesn't get that long - and regurlarly it can be deleted. A log can easy keep 2-3 years of work. It sound a lot, but its not.
Remember I am talking about stable systems. - Step by step instructions, are also great to drop here and there! So convenient.
For example How to build or install module X. Some modules are updated so seldom that there is no knowledge in how to build and deploy them. - Runtime generated System logs. When production problems, use the generated logs. Make sure you have easy access and full understanding of the generated system logs, in al environments!
The last main difference between new development and maintenance, in this article, is Version handling:
Version handling is seldom of any major importance for new development. You just version handle it in a simple way.
For systems in production, version handling becomes one of the major concerns. And it is also this that annoyingly starts to consume most of the working time.
I.e. this becomes one of the major focuses for all - how to implement new functionality and at the same time maintain old functionality.
How to be able to back. You start to need several paralell versions and you merge branches and codes at appropriate times. You feel like you are more of an administrator than a programmer.
Many times there are also confusions to what release actually is running in production.
With manual installations, human mistakes can be done. Old or wrong releases can be deployed to production.
It is very valuable to ensure an easy way to detect what version of certain code that actually is running.
Can easily be done by logging or other ways of display.
Bla bla...this was my second blog entry ever...are they really supposed to be this long?
....must do something about this...
:-)
Effective communication - Distributed teams can absolutely be effective
I believe I am very good at system development and to make development a success. I aim therefore to fill this blog with my thoughts, best practices and experience that are related to System development.
A blog is very much about communication - and communication, I belive, is a necessity for success.
For long I thought it is not possible to work in distributed teams. I had a lot of experience of working with collegues split between countries, mainly split between Copenhagen in Denmark and Stockholm in Sweden.
Then I realised, the problem was not the distance. It was the communication!Everybody insisted that the communication should be in Scandinavian - even though no such language exist. Once we started to listen to our instincts and communicated the way we understood - english - work started to get smooth!
But the main thing with communication, I believe, is to communicate effective!
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.
I call all. Managers, collegues, clients and sometimes very rare, even friends...The trick is to make short calls. Just a minute or two. But my oh my, how much faster and effective things go. Especially detecting misunderstandings and finding solutions.But keep the calls short. Better more and short. According to me.
To meet live or atleast on the phone - is a to z for building a relation.If I have a relation to my client, my client will not scold me when I've misunderstood or done wrong. Instead we will work together and do right.
Especially for distributed teams, it is a necessity not to feel any hinder in picking up a phone. In todays IT world where more and more teams are distributed between continents and the collegues we work with may have strange sounding name, different culture, climate and believes - we tend to be even more reluctant to pick up the phone. Nowadays, nobody can blame this reluctant behaviour to have to do with telephone costs, since no such hardly exist any more. We have to face it, we are afraid of the different. We like to hide behind a chat or mail.
But by just picking up the phone - phoning the partner, client, collegue in that distant location, we break that barrier. Once broken - communication start to flow!And this is according to me the true road for success. This is the true way of eliminating the "them" and "us".
And equally important, I believe, is to break down the hindrance to calling the client. We need to have a direct communication in order to check, double check and triple check that we are on the right track. No misunderstandings. And it is of our clients interests. And they like it. The've told me!
Thankfully, ofcourse there are a lot of process theories that helps and encourage us in communication and doing right. But with ineffective communication, you might as well go to bed!
Communicate effective.
Maybe that should be my new parol? No - I'll stick to my initial one...
"If you see someone without a smile, give him one of yours..."
Prenumerera på:
Inlägg (Atom)