So, yes, I bought an iPad recently.

Why?

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)

Disatvantages

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.

Engineering is art and science

Engineering is a set of disciplines between art and science; that is, there’s no engineering without science; yet it has the elements of art. Most of the time, I will use build-engineering, so, architecture as an example.

I don’t believe that architects always knew how to build monumental buildings; I believe that only our later generation thinks that people were sure what to do back then. Of course, a lot of buildings didn’t stand out the winds of time. But even those who stand, may be a fortunate result of trial and error, rather than a final product of a well thought-out process.

I also believe that the ratio between art and science changes over time and over discipline: modernist buildings, in which a lot of us are living today - at least in Hungary - were more about science. Perhaps bridges are more about science too: it is not really a question how a bridge should look like if it does not stand the tides of the river it is built over.

But software engineering has a bit more of an art: it has merely much more soft parts, hence the name. How rigid are these parts is depending on the given software: however, our whole profession believes that softwares have to be as soft as possible in order to be able to adapt these soft ecosystems they are perceived to be employed in.

Code is the formalization itself

We should also note, that we prefer to hide the hard parts behind libraries. Code is nothing else but formalization.

Some may argue that even data is formalization of the information; it may be true.

We see a lot of formal methods turned into code: connecting to a server on the internet is a quite complex task, yet we should rarely think about it; after a few lines, the copy of a textual file from another server becomes a memory block.

One thing that is hard to formalize such way is the creational process itself: of course, we have build scripts and IDEs and GUI designer programs and so on, we may even have program-generators; yet the creational involves a lot of human factors, a lot of uniqueness for the given situation, that even if we have formal methods for that, we should decide on a per situation basis what to apply.

Engineers work for communities of human beings

I also believe, that engineering is about creating things which are a part of a human system: that is, there’s no real building without human use; waterpipes are built for humans, buildings, bridges are mostly for humans.

It is interesting to note, that engineering is nearly always about supporting communities: building houses is rarely about a single person, but a community of people living, using the building over a long period of time. You also wouldn’t create a waterpipe system for just one person except for the really luxorious ones: they mostly support a neighborhood.

Software engineering, in a good sense, is also about supporting the needs of a group: the group of your end-users. People involved in the process are rarely part of this group: the customer for, let’s say, a webshop is not the customer who will use that webshop, but rather the head of the company which attempts to sell goods in it; in some cicumstances, those won’t be even its administrators.

So what is software engineering?

Let me quote the SWEBOK

The IEEE Computer Society defines software engineering as: “(1) The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approaches as in (1).”

It does not say software is a science: what it does say, that:

• Software has patterns, therefore systematic solutions can be used for common situations
• Software can have methods to build, that means, there could be a discipline to build software
• Software has numbers associated with it (like: resource used, speed), therefore it can be measured, and optimized for it.

Let us say that while these may be argued in general, in specific cases they would be hard to argue: I honestly think, for example, that most webpages have a notion of menu, and I start most of my homepage desings systematically with a logo and a menu, even if that logo is textual.; also, over the years, I have developed systematic solutions for solving certain web development needs; for some, I have automatic tools, for others, not yet. And I believe any of us could measure the loading time of our favourite social network, and a lot of us could argue about its acceptabilty

Also let us put software engineering back in context: traditionally, software engineering is traced back to the 1968 NATO conference.

What they realized in 1968, is not only that our - back then - current way of creating software is a chaotic mess; they realized, that it is expected that we will need to write a whoole lot of software, not just necessarily for military purposes.

And we do write a lot of software: every day, dozens of facebook apps, iphone apps, homepages surface, not to talk about embedded softwares from cars to microwaves and beyond.

Software engineering is not about building exceptional software: doing something exceptional is always more an art than a science. It is about building good enough software in general.

May we failed in a large scale, as some say, we are mostly succesful in the middle scale: any of us could create a blog in the order of minutes; of course, we would use pre-built software for that - like, wordpress - but that would be less about creating new software but reusing something existing.

Also, we didn’t really fail in the large scale: we successfully applied some theories and metaphors which we use in our everyday lifes: any of us could build a list-based component in their favourite system of choice, for example. Every programming language in mainstream use is a succesful generalization of concepts in itself.

On small scale, it’s still questionable whether we will be able to win. As Boochs, one of the authors of the UML and the pioneer of using classes and “inheritance” as a basis of our analysis said:

Software is inherently complex.

As an example, today I had to analyse an account locking mechanism: at first, it seemed simple: accounts should be locked if wrong password is tried more than five times a row; but we realized, that they should be locked even if the last password set is more than half a year old; then we realized that we need different behaviour in case the account is locked for different reasons.

What seemed simple in the beginning became complex in a few minutes just by talking about the requirements; the simple drawing started to explode.

We still don’t understand these enough and, until then, software projects are subjects of being late or being broken.

Conclusion

So, we are part of a young discipline. What we should understand is not only the world surrounding us; we should understand to take the right directions. This is our responsibility, as part of the early generation.

Nem tud sokat a Technics / Panasonic RP HTF 880: nem üt a basszusa, picit hiányoznak belőle a magasok. A Sennheiserek műanyag világa után megváltás mégis úgy érezni, a gitár csendülése igazán természetes volt. Persze a dinamikája sem rossz, mégha nem is tudom, mintha mélabús lenne, lassúcska. Nehéz megmondani dinamikáról, nincs rá jó szó: nem lapos, pusztán lassú.

Az a baj az audiofilizmussal - bár talán szerénytelenség lenne ezt ennek nevezni, hívjuk talán úgy, ahogy: HiFinek - hogy a hangszer, eszközpark meghatározza a zenei ízlést is: így tudom, a Buddha Bar remekül szól, de nem tudnék élvezni benne egy Sonata Arctica számot, mint basszuskiemelős párjaival. Mégis jó, kellemes érzés.

Napokat töltöttem el albumokat hallgatva, Flacban beszerezve, CD-n előkeresve, mikor megvettem. Lassan másfél-két hónapja használom, s a vételt nem bántam meg; kár, hogy jól (ill.: jobban) csak gépről szól, hordozható eszközeim hangkimenete nem olyan jó, hogy látványos romlást ne okozzon a rosszabb minőségű hangvezérlő. De ha valaki úgy gondolja még, van értelme a zenehallgatást nem pusztán melléknek, holmi háttérzajnak, hanem egyenesen főtevékenységnek, mindent kizáró dolognak, olyan hobbinak, ami teljes embert kíván, egész, önmagába merülő figyelmet, muszáj beszerezni egyszer az életben valami hasonlót.

Mert nem sok jó élmény marad, amire drogként vágysz utána, ez viszont olyan lesz.

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.   

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:

9. re-load the request again
10. enable db writing
11. run the new controller
12. 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?

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.

Ezért van, hogy a legtöbb kezdő programozótól egy masszát kapunk vissza, ahol a felelősségeket hibásan veszik széjjel, ha egyáltalán. Hiába az MVC, template-jeik általában tartalmaznak logikát, controllereik az adatbázisokat szinte közvetlenül kezelik, az absztrakciók rendszerint gyengék (hányszor láttam natív SQL hívásokat kezdő programozóktól ORM modellek függvényeiként…)

Minél több komponens menedzselt (nem .net értelemben), annál kevesebb a hibalehetőség, annál kisebb része van potenciálisan elrontva a kódnak, igaz, exponenciálisan nő a tesztesetek száma is.

Mégvalamit vesz el a tervezés: a felfedezés örömét. Bár én már megtanultam örömemet lelni a mérnöki hozzáállásban, az UML-ábrák és tervezési, szervezési folyamatok közt érzem jól magam, nem pedig a kódolásban, ez azonban egyfajta egyensúlytalanságot is erdményez: a nagy szívások a kód elírásaiban, az alsóbb rétegek félreértésében vannak. (Persze kiveszem a részem a debuggolásban, de mégis más nézőpont.) Dijsktra viszont ezzel magyarázza gyakran tökéletes hiányát, hogy az örömöt veszi el a programozásból (na, nem neki).

Az általános tervezési folyamat

A tervezés mindig az adott rendszertől függ: a frameworkök jó keretet nyújtanak, de nem ebből kell kiindulni, elvégre nem a frameworköt modellezed, hanem a valós folyamatot. Persze, ha a valós folyamatod jól leképezhető ezekre (végülis a Rational Analysis Classes se véletlenül jött létre), akkor hajrá: ettől még igyekezz a két világban - az ügyfélében és a platforméban - párhuzamosan járni.

(Ehhez persze érteni kell, az ügyfél mit akar és miért.)

A tervezési folyamatod a csapatodtól és a rendszeredtől is függ: jó, ha 1-2 projektet azonos csapattal tudsz csinálni, így nem kell minden alkalommal az új körülményekkel együtt új embereket is megismerni, így felhasználható a tapasztalat.

Egy picit ez olyan, mint a javascript-fordítók: általánosítani csak az ismétlődések felismerésének árán lehet. Persze ezt a tapasztalatot megszerezheted sok projekten keresztül is, de ezeknek adott területre kell fókuszálniuk (és épp ezért nem vállalok pl. beágyazott rendszereket).

A SOLID szabályok közül (ha a SOLID kifejezés, így, nagybetűkkel nem ismerős, akkor azonnal kattints ide) én leginkább a felelősség-problémát tartom irányadónak, megoldja a decoupling jó részét: legtöbb problémád ugyanis a különböző rejtett függőségekből és feltételezésekből lesz. Ha egy osztály pontosan egy feladatot lát el, azt viszont jól, kevesebb az esélyed arra, hogy spagettiként tapadjanak össze a moduljaid (mégha a kód kinézete nem is spagetti, a tapadásuk jól hasonlít rá.)

(Persze, a többi szabály jól jön ha nagy rendszereket tervezel, meg iszonyatos modularitasra van szükség, bár a megvalósítás módjáról vitáznék sokszor.)

És akkor itt most álljunk meg egy pillanatra.

Ha arra kérnélek, rajzold le azt a munkafolyamatot, amit naponta csinálsz, le tudnád?

Ha arra kérnélek sorold fel a tipikusan ismétlődő dolgokat, fel tudnád?

Az informatika dolga kettős:

• az egyik a folyamatok felismerése, és azok formalizálása.
  Ha a napodnak ritmusa van, sok az egymást követő robotikus taszk egy projekten, pláne programozó vagy szoftvermérnök vagy, akkor valamit elrontasz. A robotikus taszkokra a számítógépek valók, meg a buta programozók. Szinte mindig létezik kiút, a generátorok, a windows makrók végső megoldásként mindig ott vannak.
• A másik az ismétlődések kiváltása: általánosítással, ciklusokkal, újraszervezéssel, DE: semmiképp sem kopipasztával.

A legtöbb programozó, akivel eddig beszéltem, vagy dolgoztam, külső kényszerítő erő híján a specifikáción túl nem tervezett semmit: ha igen, az is leginkább adatbázis modell volt, meg levadászott a netről az adott feladat megoldására jónak tűnő csomagokat. Nem értek vele egyet. Ennek több oka van, részint az adatstruktúrák érzékenysége a rosszul definiált folyamatokra, részint az az egyszerű meglátás, hogy itt egy valós világot feleltetünk meg egy virtuálisnak, ez pedig nem írható le pusztán taxonómiai ( ~hierarchikus) alapon. A tervezés ennél több.

Annak eldöntése, hogy az informatika, mint mérnökszakma, megállja-e a helyét, nem pusztán az én tisztem. Szerintem igen, naponta eszerint a paradigma szerint dolgozom, ezt veszem alapul. Viszont azt is gondolom, ha valaki úgy gondolja, igen, az, akkor úgy is kell hozzáállnia munkájához, hogy ez megfeleljen ennek.

Tervezés MVC (desktop és web) rendszerekben

Általában az MVC-sorrend az UI tervekkel indul, mert ez az,amit az ügyfélnek meg lehet mutatni, illetve ez alapján lehet tőle kérdezni dolgokat. Ezekről majd lesz szó egy másik cikkben.

Valamelyest párhuzamosan készülhetnek a folyamattervek (algoritmustervek), amik az egyes akciókat írják le. Félreértés ne essék: a klasszikus információs rendszerek világában az akciók elég vékonykák.

Én csak ezek után szoktam adattervezéssel foglalkozni, a legvégén. Ennek két oka van, adattervezni egyrészt mindenki tud, gyakorlatilag ez az egyetlen tervábra amit viszontlátok a legtöbb kezdőtől, másrészt viszont ha rossz gondolatmeneted van a UI-ban, vagy a folyamatokban, sokkal könnyebben javítható, mint ha elnéztél egy use case-t és elrontottad az egész adatbázis-sémádat.

Case study: A prototípus-alapú tervezés

Az egyik projektben két dolog állt rendelkezésünkre: a grafikus felületek prototípusai (mock-upok), és néhány user story. Ezeket az ügyfél adta, az ő emberei készítették, ezért módosításuk nehézkes volt. Mint az én esetemben szinte mindig, weboldalról volt szó, az adatok egy része egy - szintén általunk fejlesztett - webservice szolgáltatásból, más része adatbázisból jött, és HTML-CSS-JS felületen kötött ki a végén, természetesen.

A prototípusok widgeteket írtak le, tehát egységes blokkokat, nem feltétlenül teljes oldalakat.

Elég sok fejlesztői szerepet készítettem, jóval többet, mint ahány fejlesztő adott volt rá, ezekre emlékszem:

• Volt a layout engineer (én), ez a prototípus képek alapján meghatározta az osztályneveket, az interakciós pontokat, a felépítés alapjait, ezeket bejelölte a prototípuson
• A template engineer ennek megfelelően készített egy HTML template-et, amely fals adatokkal is tudott dolgozni, viszont csak felépítményt tartalmazott
• A CSS engineer készítette el a megfelelő CSS-eket a már meglévő sablonhoz a jelölt prototípus alapján, viszont nem nyúlt bele az interakciókba. Az ő problémája volt jórészt az IE (amely az oldal más részei miatt eleve quirks-módba került sajnos)
• A JS engineer az AJAX - és mozgásinterakciókért volt felelős az interakciós pontok alapján
• A service engineer a megfelelő webszolgáltatásokat készítette elő
• A PHP engineer pedig az MVC-modellben a puszta PHP-t készítette el, adott GET/POST bemenetekre template-es vagy épp JSON-választ adva, a modellrétegekben megfelelően modellezett szolgáltatásokat használva.

Prototípus alapú tervezés, légbőlkapott, gyors ábra, bár már itt is látszik, az adatstruktúra nem lesz jó

A szép az volt, hogy ezzel 2-3 embernek rögtön lehetett adni szöszmötölnivalót, mihelyst rászántam azt a 2-3 órát, amely minimálisan szükséges volt rá, hogy ezeket a feladatokat megfelelően függetlenre elkészítsem.

A dolog egyik titka a scaffolding: először mindenkitől egy körülbelüli változatot kértem, amelyet a másiknak oda tud már adni, fals adatokkal: Egy konstansokkal kitöltött XML-t, egy megfelelő struktúrájú HTML-t, aztán következő körbe egy jól rendezett CSS-t, üres válaszokat visszaadó PHP-ket.

Ez főként akkor lehet működőképes, ha teli vagy kevéssé tapasztalt, vagy épp nagyon specializált fejlesztőkkel, esetleg egyetemistákkal, viszont abból tényleg van 2-3.

(BTW: az összes agilis módszertan - eXtreme Programming, SCRUM - feltételezi, hogy rendkívül tapasztalt emberekkel dolgozol, akik már évek óta az adott szakterületen vannak. Manapság, mikor minden projekt “agilis”, mégis honnan szednék össze ezt a tudást a fiatalok?)

Case Study: Tervezés webes fogalmakkal

Másik nagy kedvencünk a Typo3 rendszer volt. Ma már kissé idejétmúlt a legtöbb rendszerlib benne - főként CSS szempontjából - de tartalomkezelői tervezéshez nagy alapot nyújtott.

Az ilyen modellek alapja az oldal és a tartalomelem, vagy blokk. Az asszociáció megfelel a linkeknek, a rekordokat (=adatbázis-elemeket) pedig - typo3-as fogalmakkal - szintén oldalakhoz tudjuk rendelni. A leszármaztatás sajátos viszonyok miatt a sablonok master-jellegét tudta jól ábrázolni.

Az alábbi ábrán összegyűjtöttem néhány jelölést, bár így ezek együtt nem szoktak szerepelni. Két sztereotípiánk van, a jól felismerhető oldalon kívül (PI = speciális blokk, a Plug-In rövidítése, a szürkék pedig a rekordok)

Webes tervezés typo3-mal: típusok és kapcsolataik

(Megkérdezheti valaki, hogy lehet megkülönböztetni az oldalt az UML note-októl: nos, az eredeti jelölésrendszer pre-UML, másfajta nyilai is voltak, így ez nem okozott akkor fejtörést, de figyeljük meg: a note-ok általában landscape, az oldalak pedig mindig portrait ábrázolást kapnak. Opcionálisan: máshova a szamárfület!)

Nyilván ez egy elég rendszerközeli modell volt, a Typo3 látványosan ábrázolta az oldalstruktúráinkat, mégha nem is mindig tökéletesen (a hierarchia volt pl. az egyetlen kapcsolatmodell, amit szépen kezelt, mi tudtunk ábrázolni mást is.), IDE-ként pedig jól kezelte a pluginblokkokat. Éveken át küzdöttünk viszont a hírek és hírkategóriák kezelésével, amely áthatotta az egész aktuális rendszert, így valójában a rendszer modellje nem illeszkedett jól az ügyfél igényeihez.

Typo3 adminfelület: én szerettem, az ügyfelek viszont néha hisztit kaptak tőle (forrás: www.gcnpublishing.com)

A blokk és oldalak viszonya mai napig jól jön tartalommodellezésben, és más keretrendszerekben is jól alkalmazható, mégha máshogy is hívják.

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 adatstruktúrákkal ne foglalkozz. Nyilván pillanatok alatt le fog jönni az

• űrlapokból,
• adatlapokból és
• táblázatokból

úgyis, hogy milyen adatokra lesz szükséged.

Emlékezz: a modellek három dolgot ábrázolnak:

• elemeket,
• viszonyokat,
• és kölcsönhatásokat.

Ezek közül az elemek felismerése a legkönnyebb, viszont épp ezért a legkevésbé hangsúlyos.

De mik a kölcsönhatások? Azaz: mik lehettek a fő use case-ek? Erre kell rájönnöd első körben.

Ebben segíthet a rendszer igéinek kigyűjtése (gombok, menük feliratai), de én mégis azt mondom, inkább a

• méretekkel és az
• ismétlődések gyakoriságával
• (az elhelyezkedéssel)

foglalkozz. Nyilván az a legfontosabb, ami a főoldalról (vagy a leggyakoribb képernyőfajtákon) elérhető, nagy, és középen van.

A végeredménynek olyannak kell lennie, mintha a másik végéről fogtad volna meg a requirement analízist. Tehát pontosan olyannak amiről az előző requirement postban szó volt.

Ez azért van így, mert az az a formátum, amivel lehet dolgozni. Természetesen az ügyfél, pláne, ha informatikai végzettséggel rendelkezik, ezt el fogja bagatellizálni, de ne higgy neki! Ha kell, részletekben, és folyamatában, részről-részre csináld, de akkor a legfontosabbakat vedd előre, és győződj meg róla, az a legfontosabb, építésbe ne kezdj requirementek nélkül!

A viszonyokra sokkal nehezebb lesz rájönnöd, persze, ehhez már szükséged lesz az adatstruktúrákra is, de sokszor sajnos rejtve maradnak, illetve csak a fejlesztés egy későbbi szakaszában jössz rá.

Mi a baj a klónokkal?

A probléma a klónprojektekkel, hogy a legtöbb megrendelő nem túl segítőkész ilyenkor: minek kérdezel, ott az eredeti (aztán persze konkrétan rámutatva egy-egy adott részre kiderül, mégsem.).

Megmondom az őszintét: a legtöbb klónprojektem bebukott, mert nem vagyok jó klónozó, és félreértésekkel volt teli a dolog. Ezért minden tapsot megérdemelnek azok, akiknek ez sikerül (a programozók, nem a kitalálók! Azok így néha megússzák házifeladatukat…)

Látszatra pl. a belső használatú szoftvereknél néha tényleg olcsóbb saját fejlesztéseket készíteni, mint megvenni a konkrét terméket, de ez sokszor csak látszat: hosszabb távon kijön, a szoftverházak által tömegével árusított szoftverek jelentősen olcsóbbak, jobbak.

A belső klónprojekteket elég nagy számban váltja le előbb-utóbb maga a klónozott szoftver vagy versenytársa, akkor is, ha a projekt amúgy sikeres volt, (több, mint) dupla árat fizetve a funkcionalitásért. Ehhez persze az kell, hogy az eredeti termék jól adaptálható legyen (de erre a jobbak figyelnek.)

(Meg persze a klónozás gyakran eltereli a figyelmet az aktuális szituációról, környezetről, de ez ismét megrendelői kritika lenne.)

De ha ugyanolyan, az nem is jó?

Ötleteket lopni nem szégyen. Volt, hogy egy interfész-tervem egy-az-egyben hasonlított egy már meglévő, asztali szoftverre. Ennek két oka lehet pozitív esetben:

• Úgy a jó! Ha neked is az jön ki, hogy az ideális az adott helyzetben is az, amit láttál (pl. egy ikon elhelyezkedése, mérete, szimbólumkészlete), akkor egyszerűen úgy jó és kész.
  A baj az, hogy a végiggondolást a már meglévő minta sokszor akadályozza, nota bene, ezzel izzadós munkát spórolnak a concept-emberek, és néha áldásnak, nem pedig akadálynak tekintik.
• Így szokta meg a célközönség: általában a honlapokon a keresők a jobb felső sarokban vannak. Ez nem az egyetlen lehetséges helyük (és tudom, a honlap jelenlegi reinkarnációban nem is ott van nálam), viszont itt szokták meg az emberek.
  Így alakult ki a jelenlegi, néha leválthatatlannak tűnő asztal-ablak metaforarendszerünk is.

Végül egy jótanács azoknak, akik mégis enélkül a lépés nélkül vágnának bele:

Előbb-utóbb kialakul benned a specifikáció, de ez leginkább olyan, mint vakegér a labirintusban: ahelyett, hogy GPS-szerűen megmondanák, mikor merre kell fordulni, ehelyett folyamatosan mész valamerre, falakba ütközve pedig visszafordulsz. Az meg, hogy van egy kész szoftver, amit másolsz, legfeljebb abban segít, hogy nem ködből vannak a labirintus falai.

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…

Témajavaslatok:

• 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:

• Architect dolgok - modellezés a gyakorlatban
• Architect dolgok - agilis projekt
• Architect dolgok - informatika elméletben és gyakorlatban
• Architect dolgok - Use case-ek, modellek, követelmények
• Architect dolgok - Ajánló: Javascript in the enterprise
• Architect dolgok - Framework napok alatt
• Architect dolgok - Logika és Struktúra

Sorozatunkat megszakítva, mert már annyian cseszegettek miatta:
1) A szájt fájlrendszere érintetlen
2) A szájt adatbázisához most nem tudok hozzáférni (Márk, hogy lehet?), de az is érintetlennek tűnik
3) Ha a feedURL-t betöltöd egy böngészőbe, helyes
4) Ha nem google readert használsz, helyes
5) A google readeres ismerőseim átlag felénél jó a szájt, másik felénél spam van.

Szóval nem tudom, mi a baja. Alternatív RSS-nek itt van Gazs feedje (kösz, Gazs!), illetve egy Yahoo Pipes feed, ezek mennek a birodalmi readerrel is.

Persze, frissítenem kéne wordpress-t, ez nem feltétlen pusztán lustaság okán nem történik meg…