Effectieve begin van implementatie fase 1

Na 2,5-3 dagen analyse zijn we bezig met coden, het moet snel gaan willen we nog een beetje ne fatsoenlijke client ontwikkelen na de analyse volgende week voor de client.

In het kort waar we mee bezig zijn:

• ReadoutPoint
• ontvangt werknemers om in de terminal te plaatsen
• houd de tijd van de terminals correct
• leest de terminals uit
• bezorgt de uitgelezen gegevens aan de server

• Registration server
• doet alles wat de readoutpoint doet behalve data verder doorsturen naar server (is nl zelf de server)
• deelt zijn tijd via timeprotocol zodat rop's hiertegen kunnen synchroniseren
• doet de data persistentie van de gegevens die hij zelf leest of die toekomen
  

Er komt nog een massa configuratie app om makkelijk veel registration servers te beheren maar die zal enkel wat xml managen in principe en qua gui niet zo heel veel verschillen van rop en registration server buiten dat er in de treeview telkens niveauke bijkomt.

Maar vandaag kwam er nog een verassings noodgevalleke binnen, het programma wat dat van ons hopelijk zal gaan vervangen had het weer verpest en gaf slechte rapportjes terug, dus ze kwamen hier af met nen usb stick met daarom wat files, en de vraag om van de werknemers waarvan geen fatsoenlijke rapportjes gegenereerd werden te zien of die data gered kon worden. Is ons dan ook vrij snel gelukt en nu heeft Yannick zelfs, na onze ervaring die we hadden met access en die sapdb een nood rescue databank app gemaakt in access voor als dat programma het weer verprutst.

Daarnaast een beetje op een zijspoor geraakt door het valideren van de commandline argumenten van ons programma, ik moest daar plots weer denken aan het decorator pattern en d8 dat moet lukken ... maar Yannick was met dat stuk bezig en begon er aan, tot we die nood data rescue moesten uitvoeren, omdat Yannick dan meteen voor een permanenter noodplan over ging heb ik mij gebogen over dat decorator pattern, en t'was idd niet simpel maar we hebben nu nen interface om extreem flexibele validation te doen op variable deleten, k'heb nu 2 voorbeeld decoraties gemaakt namelijk NumericalValidatorDecorator en MaximumNumericalValidatorDecorator, t'is misschien niet perfect qua naamgeving maar het werkt wel proper :)

Eerste week afgerond

De eerste week zit er al bijna op, gisteren niet geblogged, t'was ook niet zo "spannend" als de eerste dagen. Ik heb voornamelijk alles gerefactored naar de regels van de kunst volgens patterns waar Mr.Cornelis zoveel op gehamerd heeft de laatste maanden, maar ik moet zeggen dat dat toch wel bijzonder nuttig is. We proberen ook, nu we met de analyse bezig zijn, altijd de regel van "find what varies and encapsulate it" toe te passen wat vrij goed lukt en waardoor, door het zo te bekijken, we ook duidelijk de variaties in het systeem ontdekken.

We hebben het systeem ook al opgedeeld in kleinere stukken en die zijn als volgt:

• Readout point: leest 1 of meerdere terminals uit en verstuurd dan op een varierende manier die gegevens naar de server
• Registration server: ontvangt de gegevens van terminals en/of readout points
• Client: zal later met de gegevens die de registration server heeft geaggregeerd heeft nog een hele hoop zaken kunnen uitvoeren

Ons development process zelf, vooral de kleine gesprekken of ideeen die ons te binnen schieten en die heel nuttig zijn en waarvaar we dikwijls daarna als we aan de documentatie bezig zijn zeggen van: hadden we daar al niks op aan te merken gehad ... wel dat moesten we echt oplossen want we zijn zo al wel ideeen en opmerkingen kwijtgespeeld :P

Vanaf nu houd iemand een documentje open waarin we alles noteren, ook kleine discussiepunten die als vergader punten gezien kunnen worden komen daar in te staan zodat als we nog bepaalde documenten moeten opstellen later we die gegevens gewoon kunnen gebruiken in onze documentatie of verslagen. Ik denk dat we ons zelf daar veel hoofdpijn mee besparen als we niet moeten terugdenken aan het feit wat we nu een uur ervoor hebben gezegd en besloten :)

Al bij al gaat het heel goed en kunnen we volgende week dinsdag echt zwaar aan de slag met de database en programmeren, we hebben der nu 2,5 dagen analyse opzitten (1 dag sms project, 1,5 dag driver analyse en probleem/haalbaarheids analyse, maandag zullen we nog een laatste dag besteden om echt volgens het boek van larman wat use cases op te stellen voor readout point en registration server en dan verwacht ik dat we dinsdag volop aan het programmeren zullen zijn.

We zullen maandag of dinsdag ook het eerste bezoek van onze stagebegeleider, Mr. Lambrecht, ontvangen. Waarin we onze plannen duidelijk uiteen kunnen zetten om elke week iteratief te werken: maandag - analyse, di, woe, do, vrij voormiddag, vrij namiddag samen zitten met de mensen van hier, evaluatie, vergadering onder elkaar, documentjes opstellen etc, tot het project klaar is. Ik neem aan dat we ook verder zullen bloggen, prototypes posten, mss uml schemakes enz :)

ff technische kant toelichten

We hebben dus onverwacht op één dag de java versie van de driver kunnen implementeren.
K'zat vanmorgend op de bus (elke dag 3 uur, tijd genoeg om te denken dus) en dacht aan hoe het programma draaide & eruit zag, het had typische Java redraw probleem (grey rects) hoewel het toch SWT gebruikte, wat mij ff in verwarring bracht want het stond op windows look&feel en bij swt ziet ge dat verschil niet en is dat redraw probleem ook al veel minder.

Nu goed, Yannick bleef verder de tcp/ip logs uitpluizen, maar dat is echt veel werk. Niet onmogelijk, we hebben er nog wat naar zitten kijken en hebben duidelijke patronen kunnen ontdekken in de structuur hoe hij stuurt maar zelfs al hebt ge het protocol dan moet ge nog altijd wat patterns toepassen voor com-port & ethernet strategies etc.

Toen ik het programma had gedecompiled was het nog altijd vrij hard zoeken naar wat we nodig hadden, decompilen betekend niet direct dat ge bruikbare java code hebt, om dat echt terug te laten compileren zie ik niet zitten maar in combinatie met eclipse en de berehandige features die dat heeft zoals Call-hierarchy en goto declaration viel het nog redelijk mee om door al die code te zoeken, uiteindelijk vond ek dan de java driver wrappers rond de native dll file, nu ge zou zeggen ff standaard JNI (java native interface) toepassen en klaar. Daar komt het op neer, maar wat blijkt, de naamgeving voor JNI in de wrapper dll is: Java_[packagename]_FuncName();
Maw die mannen hun packagename moest ek initieel overnemen en heb ik later met een hex editor gewijzigd in de package die gebruikt zal worden in ons programma.

Morgen kunnen we ons nu nen halven dag bezighouden met de cleanup en dan is't tijd om aan de analyse te beginnen waarvoor we dees nodig hadden. Waarom we al hebben gecode voor analyse? ... alles steunde hier op, lukt dees niet kunt ge zelfs geen haalbaarheidsplan opstellen, als we het niet kunnen coden is't niet haalbaar, zo simpel is't en daarom had de analyse wat vertraging (met uitzondering van de analyse voor het ander project dat we hebben gedaan maar wat optioneel was)

Dag 2

Onze analyse van gisteren hebben we deze voormiddag gedemonstreerd, en is goed bevonden. Maar aangezien gisteren enkele mogelijke opdrachten naar voren kwamen kregen we vandaag de keuze of we het sms project zouden verder zetten of dat we naar het timecard project zouden gaan. Het is dus het timecard project geworden, en kmoet zeggen de software op zich gaat leuk zijn om te ontwikkelen, we zien zelfs op sommige plaatsen al waar we onze patterns is in de praktijk kunnen brengen maar vooral het reverse engineeringen van het protocol van het timecard toestel lijkt mij zeer interessant en daar zijn we nu dan ook volop mee bezig.

We gaan met knoppix, 2 laptops, switchke, het timecard toestel en een serial -> ethernet convertor.

Het sms project word zoiezo niet weggesmeten, als we op tijd klaar zijn met die project gaan we door nog zeker terug naar kijken, de opmerkingen die daar nu over gegeven zijn gaan we nog integreren in onze analyse en dan gaan we effectief volledig voor dit gaan.

Normaal gezien is het platform hier steeds Filemaker als db en programmeer omgeving, maar voor dit project mogen we enkel een Filemaker interface schrijven naar onze dll die het protocol implementeerd en dan het programma zelf om de timecards te beheren zal per uitzondering naar onze keuze zijn, dit zal waarschijnlijk visual studio 2005 worden omwille van de serieele poort ondersteuning, we zullen nog zel is kijken naar hoe dat zit onder java maar het word dus wschlk vs 2k5 met C#.

Het einde is in zicht ... van de eerste dag

Omdat we nogal een speciale situatie hebben waarbij we nog op het laatste moment van stage hebben moeten switchen hebben we vandaag de mogelijke opdrachten voorgeschoteld gekregen. Er zitten een paar zeer leuke tussen, en degene die het waarschijnlijk zal worden is een project waarbij we een timecard systeem, wat nu closed software is, reverse-engineeringen zodat hiervoor eigen software ontwikkeld kan worden.

Natuurlijk is dat niet het enige wat we hebben gedaan, er is ook al wat analyse werk verricht naar een andere opdracht waarbij we een SMS systeem zullen ontwikkelen gebaseerd op Filemaker Pro met een Filemaker-backend en PHP-frontend. Hiervoor zullen we waarschijnlijk niet zo heel veel tijd nodig hebben maar we moeten daar eerst een planning voor opstellen en zien hoe alles zich verhoud tussen de projecten onderling zodat we er zo efficient mogelijk aan kunnen werken.

Ik hoop morgen al praktisch aan de zaken te kunnen beginnen, prototypes voor de web-frontend maken maar ook kijken naar de FX.php, kijken of die gerefactored moet worden (want hij is niet zo heel proper) of misschien het adapter pattern toepassen, aangezien ik toch liever een iets propere interface heb om mee te coden, misschien pas ik wel de interface vanuit zen-ng toe aangezien die toch al wel bewezen heeft dat die functioneel in orde is.