Kezdésnek betennék egy klippet a youtube-rol, azt tessék szíves lenni meghallgatni, addig úgyse megyünk tovább:

Ha megvan, na akkor:


(This post is partly a response for the Webisztan post for iPad owners)

So, yes, I bought an iPad recently.


For some reasons, I cannot bring too much pack with me, and I had a half-vacation trip to Amsterdam. Four days, which means, you shouldn’t really bring your laptop with you (nearly 3 kilograms, how I regret that I switched to 15 cols, I don’t need the large display…), yet it’s definitely good to bring some computing power.

I looked at the Androids, and after holding an Android phone for 2 hours in my hand, I decided that this platform is underperforming for me.

I knew that webOSes are also slow, an I would have to wait for them until christmas shopping season at least anyway.

Average netbooks? I used one with linux (moblin, perhaps?), and brought one with me to Paris with windows (thanks again, Balazs), they’re awfully slow, and the reason we brought it with us - namely: calling parents on skypeout - didn’t work: you could skype-skype, but somehow, no skypeout on Atom…

So, why are they slow? Answer is: they have traditional multitasking.

So, this left me with the Apple option. I’m a mac user since 5 and a half years, and it took me just some googling to get an iPad a few days before the trip (they weren’t introduced then in the Netherlands). For the technically curious, it’s a 64-3G, just to make sure I don’t regret buying a smaller one - although 32GB would be also fine.

The thing is, I bought it for work, which it half-failed.

Especially in Amsterdam, when I had to create a homepage, and I couldn’t switch easily between the SSH terminal (vim - editor… ) and the safari browser. I planned to use VNC, but somehow, unusually my home computer was frozen (thanks for Kelt for checking that it wasn’t stolen), so I had to rely on the machine.

But guy, what an immersive platform it is!

The difference between a device with such form factor and a full-blown computer is simple: a computer is a computer; an iPad becomes the thing you’re running on it.

If you use it as a notetaker, it becomes your notepad. If you use it as a piano, it becomes a piano (although it’s easy to miss the keys). If you use it as a drawing board, it becomes your drawing board.

And it’s that easy. The window is the iPad.

Now, let’s get back on why on Earth people need multitasking?

Because they need to switch between things!

In fact, I don’t find it that hard: I can easily switch between mail, safari, and BeejiveIM (an MSN/Gtalk client), press the button, click. The reason of this is that every application stores its last state on flash, and opening it just reloads (we call this serialization, or using the name from the 90s: permanent computing).

So when you close an application, it doesn’t ask for saving the document you’re working on. The next time you open it, it will stay the same, so it will feel just like multitasking.

So, ‘perceived’ multitasking works, and things are blazingly fast - since the computer does only the one thing it became.

There are two things which cannot be handled this way.

The first obvious thing is an alarm clock: you cannot have a good alarm clock on iPad in the background. Also, you can’t play music, especially not youtube music videos in the background, not that it would be feasible for an ARM processor I believe, since streaming video needs the most power from such devices.

The second thing is about network connections (sockets) - although few things need it (my only example is SSH) it makes your life really hard if you can’t keep them.

Maybe it would be good if chats could be open like in GMail, but we’ll have to see how this works on the ChromeOS tablets, and it’s easy to see the limits of such an interface.

So, the iPad is a suitable device for on-the-go. I know it’s a bit heavy, but still I bring it with me to a lot of places. It’s more convenient to use than a phone, and you can solve a lot of things with it.

The most used apps so far:

  • Safari, of course (check timetables, or anything on-the-go)
  • BeejiveIM (talk with your friends in unusual places and situations)
  • iBooks (yes, you can read books on it - it has a brightness setting. Also, it eats .epub and PDFs)
  • OmniGraffle (it’s really immersive to draw on a drawing board, instead of a computer)
  • Virtuoso (a piano app - it’s much more fun creating music than to listening on it)


First, the sound quality of iPad is below my expectations, so I still prefer to listen to music on computer, but for those who can’t hear the difference between the different qualities of bitrates, it could be fine.

Second, the Mobile Safari programming is harder then expected: For example, there’s no focus() function, so you can’t lead the user through a form easily; or there’s no contentEditable, which basically kills any WYSIWYG HTML-Editor support.

Also, the built-in apps are rather primitive: I’d laugh my ass off at anybody saying that iPad mail is full-featured; at least it could load pictures of people from the addressbook… Or maybe could I type bold text? (BTW, rich text editing is basically missing on the whole platform - except for the Pages app)

Oh, and you can’t attach a photo to a mail, but you can mail a photo. Cute, isn’t it?:)

Even the calendar app is strange: you cannot add new events by clicking (tapping) on their place: you have to press the plus button in the corner, set the date and time from a dropdown, and save it.

So, it does feel like I’m holding a prototype now; but hey, I haven’t seem too much prototypes this fast and usable.

Let’s see what the new OS brings. I hope they won’t ruin the speed of the device.

I have told this multiple times, maybe it’s worth a blogpost on its own. It’s mainly a reaction to recent posts of Dave West from InfoQ, and the discussions formed beneath them. Although I can feel it through what makes someone to think this way, yet I have different opinions which I would like to tell.

I have been hearing a lot of times about wether what programmers do is engineering, is science, art, or what. When I was about 18, even I had some thoughts that building software is not about engineering, but now, perhaps just because I became a master of software engineering officially (ok, it’s called engineer-informatitian in hungarian), I do think it is.

Why does the question arise? Because our daily job - at least, for a lot of us - is not based on science, but rather is about some chaotic finding-your-way thing. It rarely involves drawings and science - not gut - based calculations if you don’t explicitly insist on them, especially not in the enterprise world.

Some say 60 years ought to be enough for an engineering discipline to form, and therefore this isn’t one; I think it otherwise. I think it will take us a lot more time to find out what this thing is, even if we reached this far, and even if our profession has roots in the ancient Egyptian civilization (have you ever thought of that the basis of Egyptian tax administration is a series of calculatiosn based on water sensors and other aggregated data?).

Let’s start with two questions: what is engineering? What is software engineering?

Let me answer the first question with a personal point of view, and a second with an official one.


Szeretem érezni az énekes hangján az utolsó, felvétel előtt elszívott cigaretta torokfüstjét, a hangot, ahogy a mikrofon védőhártyájára valami rárepül, ahogy a pengető elcsúszik picit a gitáron, a keverő hibáit, ahogy összeollózta a számot. A hangszerek csendülését, ahogy a háttérben újabb-s-újabb komplex formákat fedezek fel, a tízezredik visszahallgatáskor.

Technics / Panasonic RP HTF 880 Digital Monitor


… And especially about Darjeeling first flush maharani 2010

The following text was originally a letter to my friend, Massimiliano Mirra, along with a pack of the aforementioned tea, reproduced here as it was written, in the public library of Amsterdam, as he said it’s a text which shouldn’t be enclosed into a single letter. This story was told before to a few tea-loving friends already, but this is the first written version. In case you spread it, please drop me a mail, and at least also mention my name. Creative commons nc-sa…

Darjeeling tea is known as the Queen of black teas and not without a reason.

Darjeeling is in the Indian part of Himalaya, with a breathtaking view of the tschomolungma, and an also a breathtaking height of 6000 meters. Mount Everest seems like a small bump from there. Its slopes makes it ideal for tea, as they get so much sunshine, just like the slopes of Tokaj are ideal for wine. 

Darjeeling tea is harvested three times a year, called first flush, second flush, and autumn flush. Since they are queens, let’s look at them as women, and be sure we won’t miss a point.

First flush is like a sixteen years old girl. She’s really fresh, but also don’t have too much experience of the intercourse with hot water. Therefore, you have to brew it carefully: don’t use too hot water with it, as it would make her closed, and you can’t really enjoy your meeting with her. 70 degree celsius or a little more is about enough. Also make sure you always use clear water with her: mostly we recommend spring water, but having a usual bottled water without gas is enough.

The advantage of her, that if you are careful enough, she has the curiosity and strength to be with you multiple times in a day;that is, if you don’t pour too much water on her - just about one deciliter per 2 teaspoons - you can enjoy her 3-4 times without getting another portion. 

The problem with such a 16 years old that she will spend only her summer vacation with you: after that, girls go back to school, and either become more serious, or unenjoyable at all.

First flush is harvested in late march, and usually gets into the stores early may. Be sure to drink it before september.

Second flush is harvested in mid-may: she’s about 26 years old. already has some experience with hot rains of the himalaya, you don’t have to teach her everything. Also she is more serious and more colorful: knows more of the world, and has more to tell you. However, she isn’t that interested in you: maybe you can go two rounds with her, but after that she won’t be really part of your experience. Yet you can enjoy her year-round. 

Autumn flush is 36 years old: full of experience, full of shades and secrets which shine through her personality. You can only experience her once per session, but what an experience it will be! Also, she has the dark colour you would expect from most of the black teas. Be careful with her too, however: pour water just below the 100 degrees, 95 should do fine.

The tea I gave you is a first flush maharani from this year. I have an autumn flush maharani at home, she’s my celebration tea, along with a 30 years old pu-erh. Maharanis are a bit sad, sour like a lemon: you will feel it. She’s an emo kind of girl: this will grow into the experience of the autumn Diva later. I hope she can grow up at you - some first flushes turn into older by themselves - but I’m not sure, so enjoy her through the rest of the summer.   

Ez a poszt angolul van most, bocsi. Igaziból egy kommentem egy InfoQ-s cikkel kapcsolatban, de önmagában is megállja a helyét, így gondoltam, kirakom

Recently, a whole module of a legacy web application written in PHP4 around 10 years ago (and constantly “maintained” since) was needed to have new features.

We’re talking about 1000s of lines of code within one function, or even case of a switch case.

Most of the time, people don’t refactor maintained legacy applications, as somebody told me “the first rule of support development is: don’t change anything other than requested, just add your stuff.”

I haven’t been able to track the application back to its beginnings but its imminent to me that if-else branches don’t grow to 600 lines by themselves, without human intervention. Somebody has to mess these up, and someone has to have such kind of thinking. This is pretty general in enterprise programmng:

  • most of the tasks are about legacy applications
  • people fear to clean things up
  • it’s not about development, but adding requested features and fixing bugs.

Also, PHP is a dynamic language, and therefore formal refactoring tools are usually unavailable. For example, PHP refactoring support in netbeans is basically non-existing.

So, what would you do here?

I decided that a system’s answer is dependent only from its input and its context. This seems pretty straightforward:

System ( input, context ) -> output

OK, what is the input of a web application? Of course, its HTTP request! In PHP, it’s hard to think about any other input.

What’s the context? Context is given by two components basically: the underlying platform, whatever it is (no matter you have a framework or just common libraries, we call these platform together), and the persistent data layer. So:

Web app (request, persistent data) -> answer

(I know, I forgot platform to add, but in refactoring scenarios, platform should stay the same anyway. In case you change platforms too, there are other complications which we won’t talk about this time.)

What’s the answer? First, it’s an HTML (or XML, JSON, etc) output. We didn’t have to care about it in this particular case. The other output is: changes to the persistence layer. It’s unusual for web applications to change anything other than their database and cache layers.So:

Web app(request, persistent data) -> (written-out response, persistent data' )

OK, what to do? We have an old system and we want to refactor it to a new system, and the question was: are they equal in functionality?

Question is: Web app == Web app' ?

Let’s see what I did:

  • Ask a manual tester to go through every possible combination on the user interface
  • Recorded these into files (serialize($_REQUEST)), or, even better, (serialize($GLOBALS))
  • Ask the DB layer to NOT write anything to the DB (ugly global variable hack, if it is present, only select queries are executed), this way, we ensure that we keep a consistet state
  • Record every writing operation (so, instead of executing them, take note of them)
  • An algorhythm:
    1. load the serialized request,
    2. start recording db,
    3. run the original controller,
    4. collect db recordings,
    5. re-load request (in case it was modified by the original controller - we could never know)
    6. run the new controller
    7. collect db recordings
    8. see if the two are equal

This way, I could be sure, that in all of the scenarios a manual tester could come up with, both of the controllers behave the same way.

After the original recordings, I did a few additional points:

  1. re-load the request again
  2. enable db writing
  3. run the new controller
  4. display result.

This way I could create an - albeit slower - but seemingly normally functioning version of the software, which did everything it did previously, and it was verified that functionality haven’t changed with the new controller.

I called this blackbox-harness test.

What do you think?

Kértétek, itt van. Alapvetően itt a modultervezésről lesz szó, a komplett rendszerek tervezése egyrészről picit más tészta, másrészt ebből a szempontból meglepően sokszor van megkötve a kezünk. Érdemes elolvasni a cikket is, de a kapcsolódó két esettanulmány a legértékesebb talán.

Ha a specifikáció megvan, hányszor adjuk oda tetszőleges, az implementációs környezetet valamelyest ismerő kollegának azt, már implementált (és titokban: tesztelt) terméket várva vissza cserébe? Mi sem természetesebb ennél, nem igaz? Az alkotói szabadság, a modulok amúgyis függetlenek, a srác amúgyis megbántódna, ha beleszólnának a dolgába… ugye?

Hát egy lúf.szt.

Alapvetően a kód azon részei, amit senki nem menedzsel (nem látja senki a készítőjén kívül), fekete dobozok. A fekete doboz pedig nem elhanyagolható valószinűséggel lehet rossz, hibás. Azt, hogy megvalósítja-e egyáltalán a specifkációt, csak akkor tudjuk, ha ténylegesen leteszteltük (amit általában szintén a programozóra bízunk..). A specifikáció gyakorlatilag mindig interfészspecifikáció: azt mondja meg, adott interfésze(ke)n keresztül milyennek tűnjön a program. Lehet ez UI, lehet ez adatbázis, de lehet épp másik programrész.

A tervezés elsődleges feladata, hogy részekre válassza a megoldandó feladatot, a részek közti összefüggéseket (interfészeket) pedig rögzítse. Tehát eme fázis nem más, mint részekre bontás, és részspecifikálás.


Avagy, lusta vagyok leveleket írni

A kedvenc karácsonyi dallamom a Carol of The Bells, másnéven Ukrainan Carol, abbol is Ray Conniff 1962-es feldolgozása:

Ugyanis olyasmit mond el, amit kevés karácsonyi dalban látok viszont.

Ez nem a meleg szobák éneke: ez a vidéké, a hideg télé, a bizonytalanságé, a félve kimondott reményé, a csakazértis Jézusé, amikor már csak kapaszkodóként is ezt énekled, mert bár Tudod, de bizonyos sose lehetsz benne teljes valójában földi léted során, mégha naponta tapasztalod is.

Ez az értékrendeddel ellentétes világban énekelt dallam, aminek része vagy, de mégse úgy jó itt amit jónak hívnak, ahogy szeretnéd, hogy jó legyen, a huszonegyedik századi mindennapok tapasztalata - és a huszadik századi Ukrajnáé is minden bizonnyal. De mégis, bár picit félve, kiállsz, és Jézusért kiáltasz.

Az eredetileg kora tavaszi szerencsekívánó versikét már abban az időben írta át Leontovics kórusművé, amikor Ukrajnában az újévet nem tavasszal, hanem január közepén ünnepelték, megmagyarázva ezzel az eredeti szöveg- és dallamvilág különbözőségét. Keresztény kontextusra és angol szövegre csak a 30-as években ültette át Peter Wilhousky.

Ezt a hangulatot adja vissza olyan jól a Connif-feldolgozás.

Az ukrán eredetit meg lehet hallgatni itt (Oleg Bulaschenko professzor oldaláról).

Ebben a playlistben pedig 3 kiváló feldolgozás szerepel egymás alatt, köztük egy cseh amatőr kvintett zseniális videója.

Mindenkinek Boldog Karácsonyt és - bár addig tervek szerint jelentkezünk - sikeres új évet!

Objektívan nézve a szavazásban ez nyert, így ez az első, de következőnek követi majd a tervezési folyamat. Kevésbé objektíven nézve a szavazószoftver az adblockereseknek jó eséllyel nem működött megfelelően (legalábbis kaptam erre utaló visszajelzéseket), de valami alapján dönteni kellett…

A requirement analysisnek (magyarul: megtudni, mit is kéne csinálni) a gyakorlatban két módja van:

  • az egyiket már félig-meddig bemutattam, ez a use-case analízis. Ez egy lassú, de biztos módszer.
  • A másik egy sajátos európai módszer: a klónozás. Ez általában nem is a programozókat érinti leginkább, hanem a megrendelőket: “egy olyat akarok, mint ez”.

(Hívják ezt kreatív másolásnak is…)

Ez utóbbi módszer megrendelői oldaláról egyszer elmondtam az őszinte véleményemet. Azóta több ember nem hajlandó velem szóbaállni; olyan se, aki részt se vett benne, csak klónozott terméket felügyel. Így most csak azzal foglalkozunk, a fejlesztés műszaki vezetőjeként mit tehetsz a szituációval.

A klónozás ugyanis egy dolgot nem mond meg: hogy mi miért van ott. Pont a legfontosabbat hagyja ki, azt, hogy mikre van szükség. Nem jó általában dolgozni olyan ügyféllel, akit nem lehet túllendíteni ezen.

De mégis, mit lehet tenni?

Ha előre nem megy, kénytelenek vagyunk visszafele.


Az architect dolgok sorozatra több megoldásom is lett volna a héten, de sajnos időközben ideiglenesen lekorlátozódtak az energiáim.

Szeretnék azonban némi interakciót is, nem kell komment, kéne egyet szavazni. Remélem, jövő héten már jobban leszek, és akkor tudok tartalmat is mögérakni…


  • Architect dolgok - mindless cloning, avagy, hogyan kell mérnöki módon kezelni azt, ha a specifikáció annyi “ugyanilyet szeretnék mint ez?”
  • Architect dolgok - Közösségi webalkalmazás építése PHP alapokon, szépen - van elfekvőben egy jó minőségű kis symfonys kódom, közösségi (twitter,facebook, iwiw) appnak, nem túl sok, de sokmindent be lehet rajta mutatni, és senki felé nem licencköteles
  • Architect dolgok - tervezési folyamatok - tovább folytatva az általános részt, rendszertervezési gyakorlat
  • Egyéb - akkor kommentelj :)

A tarsolyban van még egy félkész játék JS-ben, opensocial okosságok, webes modultervezés (ami nem azonos a rendszertervvel), de ezek azok, amik előránthatóak könnyedén.

Nos, mit gondoltok?

(Alant egy poll-r szavazás, ha nem jelenne meg rss-ben)

Eddig megjelent architect cikkek:

Next Page »