Kategooria ‘Tarkvaraarendus’ artiklid

1926. aastal ilmus Henry Fordi kirjutatud raamat “Täna ja homme”, mis andis edasi autori mõtteid muuhulgas Fordi tehaste töökorraldusest. Soovitan kindlasti lugeda, kuna tegemist on ka Toyota Production System-i ja Lean-i ja kaudselt ka igasuguste väledate arendusmetoodikate alusega. Tõsi, üllatusin ka ise, et masstootmise looja kirjutab raiskamise vältimisest.

Igal juhul tahtsin välja tuua ühe lõigu selle kohta, kuidas Fordi tootmises Ford-T nukkvõlli kaheksa nuki ajastust automaatselt testiti. Loe edasi »

Niisamuti nagu mitmete teiste eesti keelsete sõnadega on ka sõnapaari tarkvara – riistvara tõlkimisega veidi kehvasti läinud. Ja ma ei püüa siin kiruda, et tarkvara on tegelikult rumal.

Asi on nimelt selles, et inglise keelsed väljendid software – hardware ei anna absoluutselt mingit vihjet selle kohta, et üks vara oleks teisest nutikam ega ka seda, et teine vara on tööriistadega seotud.

Minu arvates on tõlkes kaduma läinud mõte, et software-i on võimalik pidevalt muuta ja edasi arendada, seevastu hardware on selline vara, mida muuta ei saa. Seega on minu ettepanek mõelda iga kord tarkvara tehes, et seda võiks, saaks ja peaks tulevikus muutma. Muidu võiks ta olla ka riistvara.

Üks tüüpilisi töövestluse küsimusi on: kas sa oled motiveeritud tööd tegema? Kui inimene on juba nii kaugele jõudnud, et on töövestlusel, siis mingisugune motivatsioon tal on. Variante võib olla mitmeid: keskkonna vahetus; arengu võimaluste  / väljakutsete puudumine eelnevas kohas; suurem palgasoov jms.

Ühes artiklis jäi mulle huvitav seisukoht meelde: ettevõtted ei pea motiveerima enda töötajaid, vaid nad ei tohi seda ära võtta. Seetõttu töövestlusel tasub vastu küsida, et mida nad teevad, et sult seda ära võtta. Esmapilgul tundub see veidi jabur, kuid võib-olla veenab teid ettekanne “Väledate metoodikate mõõdikutest”.

Kui alustame mingi hobiga, siis me teeme seda selle enda pärast. Meil on kirg mingi tegevuse vastu, kuid seda on võimalik lõhestada ning nii juhtub tavaliselt kui hobist saab meie töö, aastate pärast juba vaikselt vihkame seda. Siit väike soovitus: ära tee enda hobist tööd.

Loe edasi »

Selle aasta lõpuks peaks välja tulema ReSharper 5 Visual Studio 2008 ja 2010-le. Siiski, kes soovib seda varem juba katsetada, siis on võimalik seda läbi Early Access Programi teha.

Selle versiooni suuremad edasiminekud on veebi arendamise osas. Nüüd on võimalik MVC ja tavalise ASP.NET-i peal genereerida vajaminevat koodi ja kiirelt parandada vigasid. Lisaks on seal osas ka navigeerimist paremaks tehtud. Veebiarendus hakkab ka nüüd R#5 jaoks olema esmaklassiline kodanik.

Märkimisväärne uuendus on ka koodi analüüsis – võimalik on otsida koodi struktuurilisi/mustrilisi vigasid ehk halbu lõhnu. See on suurepärane töövahend meeskonna koodi ühtlustamise osas ning uute koolitamisel.

Kui Visual Studio 2010 oskab kenasid UML diagramme luua, siis R#5 seevastu näitab lihtsamalt, kuidas väärtused või meetodi väljakutsed aset leiavad. See kiirendab oluliselt koodist arusaamist (juhul kui pole üks suur kauss spagette).

Väiksemate väärtuste hulka võiksid kuuluda koodiviited (bookmark) ja ka NUniti integratsioon. Rohkemat infot leiate R# uuenduste nimekirjast.

Kellel suurem huvi koodi kirjutamise produktiivsuse tõstmise katsetamiseks on, võiksid heita ka pilgu peale Telerik JustCodeile, kuigi sellel on vähem võimalusi. Oleks tore ka kuulda, mis teile uues R# meele järgi on ja mis puudujääke on.

Tarkvara arendamine on pidev tegevus; pidevalt ilmuvad uuendused ja vigade parandused. Kõik see on meeldiv, kuid uuendamine alati pole, eriti kui peab vana maha võtma ja uue paigaldama. Kerkivad mõned küsimused: kas seadistused jäävad alles? kas kõik seaded on varundatud? Palju meeldivam on see, kui rakendus imeväel ennast uuendab ja ise midagi tegema ei pea. Nii toimivad paljud töölaua rakendused praegu, kuid samalaadselt võiksid ka meie klient-server rakendused uueneda.

Peamiselt on meil vaja uus kood kokku kompileerida, lisada talle uus versiooni number, andmebaasi skeem uuendada ja andmete kohandada. Väga palju polegi. Automatiseerimiseks sobivad lihtsad skriptid: kõige algupärasem variant oleks teha konsooli skript, kuid selleks peame väga hästi tundma iga kasutatava rakenduse parameetrite süntaksit.

Loe edasi »

Väga lihtne küsimus teile: mitu kasutajakontot sul kokku on? Ma ise ei soovi seda väga lugedagi, kuid tean, et nende haldamiseks on mul vaja haldusvahendit. Mõnes kohas on konto ainult selleks, et saaks väga salajasi tegevusi teha (näiteks videot alla laadida, et saaks mõnel vabal momendil seda vaadata).

Kuidas te ennast tunneksite kui toidupoodi minnes kassas küsitakse su käest kliendikaarti ja kui seda pole, siis ei saa ka kahjuks ostu sooritada?

Probleemi osas näen ma kahte lahendust: kasutada BugMeNot häid võimalusi või teavitada analüütikuid ja arendajaid, et igal rakendusel ei pea olema kasutajakontod.

Loe edasi »

On teada üks kutsehaigus, kus igat ettejuhtuvat probleemi püüab spetsialist lahendada vastavalt oma professioonile. Juristid arvavad, et kõik probleemid saab lahendada vettpidavate lepingutega. Programmeerijad arvavad, et iga probleemi lahendamiseks on vaja kirjutada programm. Hiljem kui programm on valmis, tuleb seda hooldada ja käigus hoida, aga administreerimine ei ole arendajatele motiveeriv tegevus. Tutvustan Saikus kasutatavaid teenuseid, mis aitavad meil igapäevaselt oma töödega hakkama saada ilma, et peaksime pool (jah, ma pingutan üle) tööajast toetavate tegevuste tarkvarade haldamisega tegelema. Loe edasi »

Koodi versioonime on küllaltki elementaarne nähtus (jah, mõned tõesti ei tee seda, kuid selles situatsioonis ei taha väga ükski meeskond olla), kuid andmebaas on jäänud tihti tahaplaanile. Esimesi praktikaid on hoida meeskonnas ühte jagatud andmebaasi. See võib alguses hea mõttena tunduda, kuid kahjuks pole versioonimisest haisugi ja meeskond näeb erinevaid jõukatsumusi selle haldamisel.

Selleks, et versioonida andmebaasi peame selle mingil moel koodihoidlasse saama. Teame, et SQL skripte annab küllaltki lihtsalt teha ning võiksime teha kolm faili: Create, Data ja Destroy. Nüüd tuleb need lihtsalt käivitada enda lokaalses masinas ja ongi andmebaas arendamiseks olemas ja versioonihalduses. Lahendus töötab küllaltki hästi, kui meil on paar tabelit ainult.

Loe edasi »

Süsteemide loomisel tuleb igal meeskonnas oleval inimesel viia läbi hulgalisi otsuseid. Valed otsused jäävad tihti kummitama ning viivad meid seisu, kus järgnevad otsused on mõjutatud oluliselt eelmistest. Sellest tulenevalt võime teha parima otsuse, kuid valik otsustest ei pruugi enam nii laialdane olla.

Arendajad otsustavad lähtekoodi tasemel, analüütikud kliendiga koos olles, projektijuhid ajaplaani loomisel, arhitektid süsteemi üldkontseptsiooni tasemel – on näha, et rollide põhiselt teeme otsuseid vastavalt tööspetsiifikale. Mõned otsused hõlmavad kogu meeskonda ja tihti ka tellijat, kuid see on igapäevaste tööga seotud otsuste puhul väike osa ja samas väga oluline.

Loe edasi »

Ekstreemprogrammeerimisest on saanud alguse kasutajalood (User Story). Neid on nime järgi lihtne segamini ajada kasutuslugudega (Use-Case), kuid sisu poolest on need vägagi erinevad.

Esmane kasutus kasutajalugudel oli seda võtta märkmena, et sellisest funktsionaalsusest on vaja rääkida ja ehitada. Neile lisati märkuseid ja hinnati punktisüsteemis keerukuse järgi või ideaalsetes päevades. Kasutajalood jagati ülesanneteks, millele lisati reaalsem ajakulu juurde.

Loe edasi »