Slo-Tech - Od polmilijardne katastrofe, ki jo je podjetju Knight Capital povzročil hroščat algoritem za visokofrekvenčno trgovanje, je minil že dober teden. O incidentu je znanih več podrobnosti, hkrati pa se vsiljuje cel kup vprašanj, ki presegajo borzni parket. Knight Capital je programsko opremo razvijal v časovnem primežu. Newyorška borza (NYSE) je 1. avgusta začela uporabljati nov informacijski sistem Retail Liquidity Program za velike stranke, kar je terjalo prilagoditev programske opreme tudi na strani borznih hiš. Knight Capital je očitno zaostajal z razvojem, zato so bili pred sredinim (1. 8. 2012) začetkom trgovanja pred preizkušnjo bodisi zamakniti zagon lastnega sistema in tvegati osip strank bodisi lansirati nepreverjen program. Izbrali so katastrofalno narobe in v pol ure izgubili pol milijarde dolarjev.
V oči pa bode zlasti časovno okno. Posli se sklepajo v milisekundnih intervalih, kjer je pol ure cela večnost. NYSE je Knight Capital na neobičajen promet in čudne posle opozorila že dve minuti po začetku trgovanja ob 9.32 po lokalnem času. Nerazumljivo je, da je trajalo kar pol ure, da so sistem izključili. Ker so na kocki ogromni zneski, načeloma vsa podjetja zahtevajo, da imajo vsi njihovi programi gumb za takojšnjo prekinitev trgovanja (kill switch). The New York Times poroča, da novi program ni imel tega gumba, kar je že druga v vrsti nerazumnih napak (prva je vsekakor pomešanje povpraševanja in ponudbe, bid in ask). Še zlasti je to čudno, ker je navadno prvi dan delovanja novega sistema v pripravljenosti kup sistemcev in drugih strokovnjakov, ki budno spremljajo, da programi ne počnejo neumnosti.
Da bo mera polna, pa je SEC (ameriški ATVP) napovedal preiskavo, saj ima Knight Capital kot eden največjih zagotavljavcev likvidnosti (market maker) pogodbene obveznosti, ki naj jih v tem času ne bi izpolnjevali. SEC preiskuje tudi, kdo je odgovoren za polurni zamik med odkritjem napake in izključitvijo programa. H Knight Capitalu se mnogo strank še vedno ni vrnilo. Delnice podjetja so izgubile okoli 70 odstotkov vrednosti, podjetje mora pokriti 440 milijonov dolarjev škode, zato se jastrebi že zbirajo in pripravljajo na nakup Knight Capitala. Trenutno se podjetje le s težavo vleče iz dneva v dan, pogoji za kratkoročno financiranje pa so zelo hudi.
Marsikdo si zastavlja vprašanje, ali je razvoj absolutno varne in nehroščate programske opreme sploh mogoč. Odgovor je bržkone ne, a se lahko temu idealu zelo dobro približamo. Letalska industrija je na tem področju pionir, saj so tam vložki največji. Čeprav so se že dogajali incidenti zaradi tehnike, je šlo v teh primerih za nerazumevanje pilotov, kaj jim avionika sporoča ali želi od njih, medtem ko zaradi izključno računalniške napake ni strmoglavilo še nobeno letalo. Razvoj je tu precej rigiden, vsaka vrstica kode, za pisanje katere tako ali tako veljajo visoki standardi, pred implementacijo pa podvržena več pregledom strokovnega očesa in zatem uram testiranja. Rešitve so, a so zelo drage. Programe je treba pisati v okolju, kjer je spoštovano kakovostno delo, kjer je pregled kode nekaj običajnega, kjer je testiranje zelo pomemben del razvoja itd. To pa stane in ne daje takojšnjih rezultatov, ampak preprečuje milijardne katastrofe v nedoločljivi prihodnosti. Zgled za pisanje dobre kode je NASA, kjer je bil proces nastajanja kode za raketoplane dodelan do potankosti, ključne točke pa so hierarhija in zdrava mera tekmovalnosti, načrtovanje, sledljivost sprememb, dokumentacija, odpravljanje napak in vzrokov, ki so pripeljali do njih. Rezultat: 420.000 vrstic dolg program ima eno napako - komercialni program bi jih imel nekaj tisoč.
Teče torej večina naših naprav na malomarni programski opremi? Zelo verjetno. Ko pomislimo na programe, si predstavljamo Windows, Google in pametne telefone, mogoče celo bankomate, a to je le vrh ledene dobe. Vse od dvigal, letališč, elektrarn, industrijskih obratov do semaforjev krmili programska oprema. Nekdo jo je moral napisati in povsem zagotovo lahko trdimo, da večina te programske opreme ni bila podvržena strogim standardom letalske industrije. Fiasko Knight Capitala ni edini tovrstni primer; spomnimo se na 350-milijonsko luknjo švicarskega UBS-a, ker so sistemi zatajili med začetkom kotacije Facebooka. Leta 1999 je Mars Climate Orbiter po 10-mesečnem potovanju že prvi dan zgorel v Marsovi atmosferi, ker so inženirji spregledali, da plovilo pričakuje navodila v kilogramih in metrih, z Zemlje pa so jih pošiljali v funtih in inčih. Še bolj spektakularen je bil prvi let evropske rakete Ariane 5 leta 1996, ko je po 10 letih razvoja po vsega 37 sekundah zgorela, ker je program poskusil stlačiti 64-bitno število s plavajočo vejico v 16-bitno celo število (Ariane 5 so seveda kasneje dokončali in danes nosi satelite v vesolje).
V resnici je slabe programske kode ogromno, a dokler posledice niso milijarde škode ali človeške žrtve, tega nihče ne opazi. Oziroma prevod v Slovenijo: najemanje študentov za štiri evre na uro za pacanje programske kode je podobno, kot če bi študentje prevajali deklaracije na zdravilih. (Pa saj oboje že počno!) Isti vzorci se na višjih ravneh le ponavljajo.
Definitivno ni vsa krivda na programerjih ampak tudi na nenormalnih proračunih in rokih. Programiranje ni tovarna, kvaliteten TDD in testiranje pa so premalo razširjeni. Malo večji program nebo nikoli 100% pravilen, ker je poti do rešitve mnogo. Poleg tega kompleksnost ne raste linearno z zahtevnostjo programa.
Ko se bodo "menedžerji" oziroma tudi kadrovska zamislili katere programerje najamejo, koliko jim plačajo, dajo časa ter spodbujajo testiranje, bo verjetno tudi programska koda kvalitetnejša. Vendar to vse stane denar, ki ga raje pobašejo v svoje žepe, tako da se mora zgoditi kaj ogromnega da se kdo zamisli. Ceneje ni vedno boljše, se posebno pa v programiranju.
Programerji delajo po specifikacijah in več ali manj sploh ne znajo testirat programa, ni pa nujno, samo tako pač je v profi kanalih, če gledaš na okoli si že nekaj posebnega.
V resnici je slabe programske kode ogromno, a dokler posledice niso milijarde škode ali človeške žrtve, tega nihče ne opazi. Oziroma prevod v Slovenijo: najemanje študentov za štiri evre na uro za pacanje programske kode je podobno, kot če bi študentje prevajali deklaracije na zdravilih. (Pa saj oboje že počno!) Isti vzorci se na višjih ravneh le ponavljajo.
Bah, kot da je človeška koda (DNA) kaj boljša. Ko nas je bog delal je rekel good enough, za napake bo že poskrbela naravna evolucija. Tu očitno je isto. :)
Osebno ne dam prav dosti na to, kako je koda napisana, saj se mi zdi pokritost s testi precej bolj pomembna. Nekoliko pomaga, če je aplikacija narejena modularno, saj se lahko potem s testi pokrijejo že osnovne funkcije modulov, kakor tudi kompleksnejše funkcije aplikacije. Tudi za vsako funkcionalnost aplikacije je potrebno definirati včasih kar obsežen nabor testov, precej testov pa se definira tudi po odzivu strank.
Osebno ne dam prav dosti na to, kako je koda napisana, saj se mi zdi pokritost s testi precej bolj pomembna. Nekoliko pomaga, če je aplikacija narejena modularno, saj se lahko potem s testi pokrijejo že osnovne funkcije modulov, kakor tudi kompleksnejše funkcije aplikacije. Tudi za vsako funkcionalnost aplikacije je potrebno definirati včasih kar obsežen nabor testov, precej testov pa se definira tudi po odzivu strank.
To je pomoje se najboljsi nacin, formal verification (kot omenja pegasus) se vsaj meni zdi, da pri bolj kompleksnih programih ne moras naresti. Niti nisem videl, da bi ga uporabljali v npr. vesoljski/letalski ali avtomobilski industriji. Tam po mojih izkusnjah (res pa da sem omejen le na eno podrocje) ponavadi resujejo te probleme s stevilnimi testi in pa seveda raznimi varovalkami, da tudi ce gre kaj narobe ne gre vse v maloro (recimo pri kakasnih regulacijskih sistemih, je tudi do 90% kode varovalk).
Osebno ne dam prav dosti na to, kako je koda napisana, saj se mi zdi pokritost s testi precej bolj pomembna. Nekoliko pomaga, če je aplikacija narejena modularno, saj se lahko potem s testi pokrijejo že osnovne funkcije modulov, kakor tudi kompleksnejše funkcije aplikacije. Tudi za vsako funkcionalnost aplikacije je potrebno definirati včasih kar obsežen nabor testov, precej testov pa se definira tudi po odzivu strank.
Sorry, ampak zame mora biti koda napisana zelo pregledno in predvsem z dovolj dokumentacije, celovita pokritost s testi je pa pri finančnih zadevah nuja in tukaj se ni za zaje*avat. Kdor misli, da lahko špageti kodo al pa zmazke raznih študentov vleče v programe za finančne transakcije ali karkoli povezanega s financami, se moti. Tukaj ni prostora za napake. Že tako se vedno najde kak produkt, ki ga ne stestirajo dobro. Ampak take, ki tega ne počnejo, bi poslal nekam...
Asrock X99 Extreme 4 | Intel E5-2683V4 ES | 64GB DDR4 2400MHz ECC |
Samsung 250GB M.2 | Asus 1070 TI | 850W Antec | LC Tank Buster
Sorry, ampak zame mora biti koda napisana zelo pregledno in predvsem z dovolj dokumentacije, celovita pokritost s testi je pa pri finančnih zadevah nuja in tukaj se ni za zaje*avat. Kdor misli, da lahko špageti kodo al pa zmazke raznih študentov vleče v programe za finančne transakcije ali karkoli povezanega s financami, se moti. Tukaj ni prostora za napake. Že tako se vedno najde kak produkt, ki ga ne stestirajo dobro. Ampak take, ki tega ne počnejo, bi poslal nekam...
Včasih bi se zelo strinjal s tabo, vendar pa sem v zadnjih letih delal na več projektih, ki so jih sicer pisali dobri in izkušeni programerji, a so bili vseeno brez ene same vrstice komentarjev. Sam komentarje še vedno pišem, vendar sem iz izkušenj videl, da je mogoče precej dobro shajati tudi brez njih. Po drugi strani ti pa še tako pregledna, urejena in dokumentirana koda ne more preprečiti logičnih ali vsebinskih napak, torej zadev, ki so formalno sicer pravilne, a dajejo napačne rezultate. Priznam pa, da je vse skupaj precej odvisno od tega, kaj delaš. Sam delam poslovne aplikacije v Javi EE, tako da se osredotočam v glavnem na vsebino in skoraj nič na razne sistemske zadeve. V mojem primeru so zato najpomembnejši testi, ki so tudi relativno enostavno izvedljivi. Poleg tega pa je pogosteje mnogo hujše, če aplikacija da napačne rezultate, kot pa če bi crknila. Hkrati sem delal tudi na eni zadevi za mobilne telefone, kjer pa je bila vsebina relativno enostavna, je bilo pa v aplikaciji precej interakcije med različnimi nitmi in servisi. Tukaj pa vseh teh stvari ni bilo mogoče pokriti s testi.
sammy: Ja, zadnja moda je pač to, da je koda za-en-drek, če potrebuje komentarje (ki jih praviloma nihče ne vzdržuje, in so pogosto outdated, direkt napačni ali pa pomanjkljivi). Meni se zdi, da je mesto za vse, najprej za dobro organizirano kodo, ki je samodokumentirana (jasna imena spremenljivk, metod, ipd), funkcije/metode seveda dokumentirane (parametri, opis, predpostavke, itd.), že zato ker grejo v javadoc ali doxygen ali kaj pač. Si pa kar mislim, da je problem, tudi če imaš še take mojstre na voljo, pa jim daš v delo napihnjen, slabo specificiran projekt, ki mora biti končan včeraj. Ne bi se čudil, če je bilo tudi v tem primeru kaj od tega na tapeti. Tudi ne, če je bil na tapeti "Eh saj to vsak zna, dajmo študentom ali pa kar enim indijcem za katere prvič slišimo naredit; Bomo prišparali, pa se bomo potem nagradili."
Sorry, ampak zame mora biti koda napisana zelo pregledno in predvsem z dovolj dokumentacije, celovita pokritost s testi je pa pri finančnih zadevah nuja in tukaj se ni za zaje*avat. Kdor misli, da lahko špageti kodo al pa zmazke raznih študentov vleče v programe za finančne transakcije ali karkoli povezanega s financami, se moti. Tukaj ni prostora za napake. Že tako se vedno najde kak produkt, ki ga ne stestirajo dobro. Ampak take, ki tega ne počnejo, bi poslal nekam...
Včasih bi se zelo strinjal s tabo, vendar pa sem v zadnjih letih delal na več projektih, ki so jih sicer pisali dobri in izkušeni programerji, a so bili vseeno brez ene same vrstice komentarjev. Sam komentarje še vedno pišem, vendar sem iz izkušenj videl, da je mogoče precej dobro shajati tudi brez njih. Po drugi strani ti pa še tako pregledna, urejena in dokumentirana koda ne more preprečiti logičnih ali vsebinskih napak, torej zadev, ki so formalno sicer pravilne, a dajejo napačne rezultate. Priznam pa, da je vse skupaj precej odvisno od tega, kaj delaš. Sam delam poslovne aplikacije v Javi EE, tako da se osredotočam v glavnem na vsebino in skoraj nič na razne sistemske zadeve. V mojem primeru so zato najpomembnejši testi, ki so tudi relativno enostavno izvedljivi. Poleg tega pa je pogosteje mnogo hujše, če aplikacija da napačne rezultate, kot pa če bi crknila. Hkrati sem delal tudi na eni zadevi za mobilne telefone, kjer pa je bila vsebina relativno enostavna, je bilo pa v aplikaciji precej interakcije med različnimi nitmi in servisi. Tukaj pa vseh teh stvari ni bilo mogoče pokriti s testi.
Ojoj, človek mimo streljaš. To se morda obnese v one-band programiranju. Za resno delo mora biti spisan "pravilnik/vodič", ki se ga "morajo" vsi držati - pisanje komentarjev, poimenovanje spremenljivk in objektov, strukturiranje samega programa itd, itd...V večini primerov ni problem pisati kode, ampak popravljanje kasnejših napak; v kolikor je to čez kakšen mesec ni težav, po recimo kakšnem letu pa ti vsakršen komentar, pravilno poimenovana funkcija pride prav. Lahko bo tudi kdor za teboj popravljal ali spreminjal stvari in bo na dolgi rok prišparal precej časa in denarja.
To je seveda idealna pot, ki pa se v praksi seveda ne uporablja. Kriv je predvsem časovni pritisk ter zaposlovanje nekvalificiranega kadra in še veliko ostavih manjših stvari. Glavno je, da če bi se podjetja tega zavedala bi na dolgi rok bilo marsikaj lažje in ceneje, ampak nihče ne gleda 2 leti naprej.
Nisem programer ampak a folk resno pričakuje, da bo nekaj delovalo s 100% gotovostjo oz 100% brez napak? Še pri Hello World se lahko zatipkaš in ti nakoncu napiše Helol World pa je to že napaka. Folk pa bi pri par 10.000 vrstic kode pričakoval perfekcijo. Optimisti...
Preden se ubijete z raznimi "kje so testi"(ki so btw cisto neuporabni ce ne testirajo vseh moznih problemov in seveda tudi teste velikokrat pise clovek, ki je pisal kodo, ki jo testira...) prej poglejte link, ki ga pejstal terryww. Problem je bil veliko bolj simple kot vse teorije nesposobnosti programerjev v komentarjih.
To z najemanjem najcenejše delovne sile tako ali tako ni čisto nič novega. Tudi v strojništvu se dogagajo ogromni felerji, ko so kaki neizkušeni študenti zelo poceni, nimajo pa dosti pojma in izkušenj, potem pač projekt nasede. Ali pa cena zelo preseže tudi zelo dobrega projektanta. Včasih se pa tud kej polomi na ta račun in potegne zraven še večje stroške.
Preden se ubijete z raznimi "kje so testi"(ki so btw cisto neuporabni ce ne testirajo vseh moznih problemov in seveda tudi teste velikokrat pise clovek, ki je pisal kodo, ki jo testira...) prej poglejte link, ki ga pejstal terryww. Problem je bil veliko bolj simple kot vse teorije nesposobnosti programerjev v komentarjih.
To da nekateri dajo studentu pisati program je malomarnost in najvecji salabajzarizem kar obstaja. Kot prvo odzira mesto redno zaposlenemu, kot drugo ce koda ni "uredu" ne bo kazensko nikoli odgovarjal z denarno kaznijo medtem ko redno zaposleni dobijo lahko tudi kaksne dodatne neplacane ure itd. Kar pa se tice kvalitete kode vam povem da na visji soli katero obiskujem se gleda samo koncni rezultat - to da dela kar je zahtevano. Varnostni mehanizmi nobenega tam nobenega ne brigajo in isto je bilo v srednji soli. Pri izdelavi programa v srednji soli sem izdelal vec varnostnih mehanizmov z ozadju, ampak vsi so to videli kot "kompliciranje". Toliko o tem kam in kako gre ta svet...
Nisem programer ampak a folk resno pričakuje, da bo nekaj delovalo s 100% gotovostjo oz 100% brez napak? Še pri Hello World se lahko zatipkaš in ti nakoncu napiše Helol World pa je to že napaka. Folk pa bi pri par 10.000 vrstic kode pričakoval perfekcijo. Optimisti...
Nisi programer, si prav povedal. Ja, nekateri resno pričakujemo vsaj kodo brez napak. Tudi od načrtovalcev zahtevamo, da poznajo posel, da bodo specifikacije čimbolj točne, da lahko potem to implementiramo. Že tako se pojavijo napake, ker se naši načrtovalci ne "ujamejo" z uporabniki in naročniki. Če so že vsebinske napake, mora vsaj koda biti brez napak. In to pričakujem od sebe in sodelavcev na projektih kjer delam.
Preden se ubijete z raznimi "kje so testi"(ki so btw cisto neuporabni ce ne testirajo vseh moznih problemov in seveda tudi teste velikokrat pise clovek, ki je pisal kodo, ki jo testira...) prej poglejte link, ki ga pejstal terryww. Problem je bil veliko bolj simple kot vse teorije nesposobnosti programerjev v komentarjih.
Mogoče malce OT, ampak ali pri nas študenti na FRI in FERI sploh slišijo kaj na temo procesa pisanja programov (programiranje ni samo pisanje kode)?
Na FERI je posebej predmet, pri katerem se učimo razvoja in testiranja programske opreme. Problem je, ker večina študentov "spi". Čez izpite se pa že nekak prešlepajo. 10-ka še ni dokaz, da zadevo znaš in obvladaš.
bolj ko se oddaljujes od sistema/procesorja, večja je verjetnost napake. V bolj high level, off the shelf, -insert more crap- zadeve se podajas, uporabljas 3rd party librarye, ki so prekompleksni, da bi jih razumel, večja je verjetnost, da bo nekaj hudo zajeb* počilo.
Tukaj se skriva pravi hudič. V starih dobrih (mojih) časih si za karkoli pametnega moral ven potegnit asembler in nivo znanja programerja je bil na zelo visoki ravni (je bilo pa developerjev 10x, 100x manj in prav je tako, četudi narediš tank za vozit na joystick, ga je hudimano nevarno dati 5 letnemu otroku), in kogarkoli srečam, da je v tistih časih kodiral, je za nekaj rangov boljši developer od vsega današnjega (pa se globoko opravičujem če sem koga uzalil) "ološa", ki vleče free knjiznice iz interneta, kode sample predeluje, brez da bi pravzaprav nastudiral kako koda sploh dela in zakaj, uporaba neka kvazi RAD orodja in se jim v svojem lastnem šalabajzerstvu zdijo sami sebi strašno pomembni, da sestavljajo skupaj neke kocke, za katere sploh ne vejo kako interno delujejo (in se slepo zanašajo na garbage collectorje :D :D)
TO je pokop kvalitete. S takšnimi hordami napol spečenih osebkov morajo potem po hitrosti razvoja tekmovati tisti, ki vedo kaj delajo in jih boli glava od tega, da bi v produkt vtaknili nekaj, kar interno nimajo časa naštudirat vendarle pa že iz guts feelinga vedo, da bo še problem, njihov management pa tako ali tako samo EUR vidi in sanja kako bodo pa lahko služili še večje bonuse, če bodo uporabili neko tuje delo zastonj (cena je relativna, eno plačaš v EUR, drugo v času, tretjo spet v fixanju tujih bugov,...) in prav silijo v sranje. Za piko na i, pa namesto, da bi s tem da razviješ svojo tehnologijo, pa čeprav nekaj kar off the shelf že ponuja, razvijal tudi svoj kader, da so vedno boljši, raje ustvarjaš horde zombijev, ki po nekaj iteracijah ni sposobna več vzdrževati lastnega produkta.
Human beings, who are almost unique in having the ability to learn from the
experience of others, are also remarkable for their apparent disinclination
to do so.
Ojoj, človek mimo streljaš. To se morda obnese v one-band programiranju. Za resno delo mora biti spisan "pravilnik/vodič", ki se ga "morajo" vsi držati - pisanje komentarjev, poimenovanje spremenljivk in objektov, strukturiranje samega programa itd, itd...V večini primerov ni problem pisati kode, ampak popravljanje kasnejših napak; v kolikor je to čez kakšen mesec ni težav, po recimo kakšnem letu pa ti vsakršen komentar, pravilno poimenovana funkcija pride prav. Lahko bo tudi kdor za teboj popravljal ali spreminjal stvari in bo na dolgi rok prišparal precej časa in denarja.
Sam sem tudi forsiral take zadeve, vendar sem kasneje ugotovil, da tako zelo pomembne niso. Povsem zadosti so že dovolj jasna imena razredov, metod in spremenljivk in uporaba metod, ki niso daljše od enega zaslona. Komentarji sicer malenkost olajšajo popravljanje po enem letu, niso pa nujni.
Mogoče malce OT, ampak ali pri nas študenti na FRI in FERI sploh slišijo kaj na temo procesa pisanja programov (programiranje ni samo pisanje kode)?
Na FERI je posebej predmet, pri katerem se učimo razvoja in testiranja programske opreme. Problem je, ker večina študentov "spi". Čez izpite se pa že nekak prešlepajo. 10-ka še ni dokaz, da zadevo znaš in obvladaš.
Na FRI smo imeli predmet v višjih letnikih, kjer si moral pisati unit teste, imeti določeno pokritost kode z unit testi, se držati kodirnih standardov, imeti dosežene določene metrike programa, uporablati version control, certifikate itd... Pri nas ni bilo spanja, saj je bilo na koncu treba oddati seminarsko z upoštevanjem vsega tega. In ta je bila zelo obsežna. Bila pa je v javi in C#. Definitivno super zato da ljudje spoznajo kako izboljšati svojo kodo.
bolj ko se oddaljujes od sistema/procesorja, večja je verjetnost napake. V bolj high level, off the shelf, -insert more crap- zadeve se podajas, uporabljas 3rd party librarye, ki so prekompleksni, da bi jih razumel, večja je verjetnost, da bo nekaj hudo zajeb* počilo.
Tukaj se skriva pravi hudič. V starih dobrih (mojih) časih si za karkoli pametnega moral ven potegnit asembler in nivo znanja programerja je bil na zelo visoki ravni (je bilo pa developerjev 10x, 100x manj in prav je tako, četudi narediš tank za vozit na joystick, ga je hudimano nevarno dati 5 letnemu otroku), in kogarkoli srečam, da je v tistih časih kodiral, je za nekaj rangov boljši developer od vsega današnjega (pa se globoko opravičujem če sem koga uzalil) "ološa", ki vleče free knjiznice iz interneta, kode sample predeluje, brez da bi pravzaprav nastudiral kako koda sploh dela in zakaj, uporaba neka kvazi RAD orodja in se jim v svojem lastnem šalabajzerstvu zdijo sami sebi strašno pomembni, da sestavljajo skupaj neke kocke, za katere sploh ne vejo kako interno delujejo (in se slepo zanašajo na garbage collectorje :D :D)
TO je pokop kvalitete. S takšnimi hordami napol spečenih osebkov morajo potem po hitrosti razvoja tekmovati tisti, ki vedo kaj delajo in jih boli glava od tega, da bi v produkt vtaknili nekaj, kar interno nimajo časa naštudirat vendarle pa že iz guts feelinga vedo, da bo še problem, njihov management pa tako ali tako samo EUR vidi in sanja kako bodo pa lahko služili še večje bonuse, če bodo uporabili neko tuje delo zastonj (cena je relativna, eno plačaš v EUR, drugo v času, tretjo spet v fixanju tujih bugov,...) in prav silijo v sranje. Za piko na i, pa namesto, da bi s tem da razviješ svojo tehnologijo, pa čeprav nekaj kar off the shelf že ponuja, razvijal tudi svoj kader, da so vedno boljši, raje ustvarjaš horde zombijev, ki po nekaj iteracijah ni sposobna več vzdrževati lastnega produkta.
Mogoče malce OT, ampak ali pri nas študenti na FRI in FERI sploh slišijo kaj na temo procesa pisanja programov (programiranje ni samo pisanje kode)?
Na FERI je posebej predmet, pri katerem se učimo razvoja in testiranja programske opreme. Problem je, ker večina študentov "spi". Čez izpite se pa že nekak prešlepajo. 10-ka še ni dokaz, da zadevo znaš in obvladaš.
Na FRI smo imeli predmet v višjih letnikih, kjer si moral pisati unit teste, imeti določeno pokritost kode z unit testi, se držati kodirnih standardov, imeti dosežene določene metrike programa, uporablati version control, certifikate itd... Pri nas ni bilo spanja, saj je bilo na koncu treba oddati seminarsko z upoštevanjem vsega tega. In ta je bila zelo obsežna. Bila pa je v javi in C#. Definitivno super zato da ljudje spoznajo kako izboljšati svojo kodo.
joebanana bi se mogoče dalo dobiti to seminarsko oz. vsaj kake smernice katere knjige so dobre, standardi.. etc
bolj ko se oddaljujes od sistema/procesorja, večja je verjetnost napake. V bolj high level, off the shelf, -insert more crap- zadeve se podajas, uporabljas 3rd party librarye, ki so prekompleksni, da bi jih razumel, večja je verjetnost, da bo nekaj hudo zajeb* počilo.
Tukaj se skriva pravi hudič. V starih dobrih (mojih) časih si za karkoli pametnega moral ven potegnit asembler in nivo znanja programerja je bil na zelo visoki ravni (je bilo pa developerjev 10x, 100x manj in prav je tako, četudi narediš tank za vozit na joystick, ga je hudimano nevarno dati 5 letnemu otroku), in kogarkoli srečam, da je v tistih časih kodiral, je za nekaj rangov boljši developer od vsega današnjega (pa se globoko opravičujem če sem koga uzalil) "ološa", ki vleče free knjiznice iz interneta, kode sample predeluje, brez da bi pravzaprav nastudiral kako koda sploh dela in zakaj, uporaba neka kvazi RAD orodja in se jim v svojem lastnem šalabajzerstvu zdijo sami sebi strašno pomembni, da sestavljajo skupaj neke kocke, za katere sploh ne vejo kako interno delujejo (in se slepo zanašajo na garbage collectorje :D :D)
TO je pokop kvalitete. S takšnimi hordami napol spečenih osebkov morajo potem po hitrosti razvoja tekmovati tisti, ki vedo kaj delajo in jih boli glava od tega, da bi v produkt vtaknili nekaj, kar interno nimajo časa naštudirat vendarle pa že iz guts feelinga vedo, da bo še problem, njihov management pa tako ali tako samo EUR vidi in sanja kako bodo pa lahko služili še večje bonuse, če bodo uporabili neko tuje delo zastonj (cena je relativna, eno plačaš v EUR, drugo v času, tretjo spet v fixanju tujih bugov,...) in prav silijo v sranje. Za piko na i, pa namesto, da bi s tem da razviješ svojo tehnologijo, pa čeprav nekaj kar off the shelf že ponuja, razvijal tudi svoj kader, da so vedno boljši, raje ustvarjaš horde zombijev, ki po nekaj iteracijah ni sposobna več vzdrževati lastnega produkta.
Se strinjam z vsem napisanim :/ Sploh s tretjim odstavkom.
joebanana bi se mogoče dalo dobiti to seminarsko oz. vsaj kake smernice katere knjige so dobre, standardi.. etc hvala
Seminarske ti žal nebom pošiljal. Bom pa pogledal, ko pridem domov, če imam kje prosojnice kako mora biti narejeno, s čim in razlaga orodij. Kot vidim na spletu predmeta porazdeljeni informacijski sistemi ni več na bolonjskem uni. Verjetno je kakšen podoben.
Spomnim se da smo uporabljali za javo JUnit, Javadoc, Redmine, Metrics, EclEmma, Java kodirni standardi... Predvsem v obliki pluginov za Eclipse. Delo je potekalo v parih. Eden je pisal kodo v C#, drugi v java. Oba dela smo povezali in tudi spisali vse potrebne unit teste. Za C# smo uporabljali ekvivalentna orodja.
Za kodirni standard lahko za javo uporabiš kar od razvijalcev jave, Java code conventions. Za različne programske jezike pa obstaja različen kodirni standard.
V službi delam web, vendar za unit teste ponavadi ni denarja. Uporabljam pa generiranje dokumentacije, MVC frameworke. Z ekstra kvalitetno kodo žal nimam preveč izkušenj, je pa tudi res, da projekti ponavadi niso kritični.
Kar je povedal -io- se sam 99% strinjam. Današnja RAD okolja za GUI programiranje so že na tako visokem nivoju, da lahko opico naučiš tapkati. Žal je koda zadaj vedno katastrofalna, samo, da dela. Obup.
Jaz sem sicer starejši in RAD okolij skoraj nikoli ne uporabljam, ker imam drugačne projekte. Takšne, kjer prvih 4 dni berem 1000 stranske specifikacije, preden napišem prvo vrstico kode.
Islam is not about "I'm right, you're wrong," but "I'm right, you're dead!"
-Wole Soyinka, Literature Nobelist
|-|-|-|-|Proton decay is a tax on existence.|-|-|-|-|
Kar je povedal -io- se sam 99% strinjam. Današnja RAD okolja za GUI programiranje so že na tako visokem nivoju, da lahko opico naučiš tapkati. Žal je koda zadaj vedno katastrofalna, samo, da dela. Obup.
Jaz sem sicer starejši in RAD okolij skoraj nikoli ne uporabljam, ker imam drugačne projekte. Takšne, kjer prvih 4 dni berem 1000 stranske specifikacije, preden napišem prvo vrstico kode.
Predvsem je odvisno od tega, kaj aplikacija dela. Ne moremo v isti koš metati Nasinih aplikacij za upravljanje vesoljskih plovil in spletne aplikacije za rezervacijo sejne sobe. Pri slednji je pristop "samo da dela" čisto OK.
Predvsem je odvisno od tega, kaj aplikacija dela. Ne moremo v isti koš metati Nasinih aplikacij za upravljanje vesoljskih plovil in spletne aplikacije za rezervacijo sejne sobe. Pri slednji je pristop "samo da dela" čisto OK.
Res je. Vendar se to frazo dandanes močno zlorablja, tudi ob dosti višjih zahtevah kot je rezervacija sejne sobe.
Predvsem je odvisno od tega, kaj aplikacija dela. Ne moremo v isti koš metati Nasinih aplikacij za upravljanje vesoljskih plovil in spletne aplikacije za rezervacijo sejne sobe. Pri slednji je pristop "samo da dela" čisto OK.
Heh, žal, žal, žal,... lahko. A si sploh lahko predstavljaš kaj danes spaca gmota "na-pol-pečenih", če ji rečeš: "naredite tole, samo da dela"? Verjetno ne bi delalo sploh. Če jih prisiliš v Nasine standarde, jih tako ali tako nikoli ne bodo dosegli ampak zadeva bo vsaj za silo delala.
Še drugi del zgodbe, vsaka aplikacija se enkrat zacne z necim majčkenim, morda čisto nečim drugim, npr. rezervacija sejne sobe se lahko enkrat preobrazi v rezervacijo sedeža na letalu. In z denarno mentaliteto managementa tako ali tako nekaj kar dela NIKOLI ne redizajniramo in začne se rakavi razvoj aplikacije, kjer se nivoji in nivoji zelenega sluza lepijo na osnovo, ki postaja vedno večja in začne metati senco na luno. Vmes se najde nekdo drug, ki ima vsega dovolj in začne delati na enak način novo aplikacijo, ki je na zacetku super, potem pa se spet začne postopek sluzenja (pozna kdo Foxit reader? Nerota?).
Ergo, na začetku dobi kompetentne ljudi, DOBRO jih plačaj in naredi raje manj vendar dobro. Seveda pa se bo ta izjava zdela gradbincem, vodovodarjem, managerjem in podobnim pravo bogokletstvo.
Human beings, who are almost unique in having the ability to learn from the
experience of others, are also remarkable for their apparent disinclination
to do so.
-io-: sicer ne zagovarjam malomarnosti pri pisanju kode, vendar sem se v 15 letih vodenja softwerskega oddelka naučil, da od pretirane natančnosti ni nobenih koristi. Od začetka sem tudi sam zagovarjal in zahteval zelo visoke standarde pisanja kode, vendar to še ni zagotovilo, da se napake ne bodo pojavljale. Java ima kar dobro definirane standarde pisanja kode in ti mi čisto zadoščajo. Kakovost aplikacij (število napak, ki jih javijo uporabniki) pa se je drastično izboljšala z uporabo unit testov. Testiranje (priprava testov) resda vzame precej časa, a je v mojem segmetnu zelo pomembno. Testi se definirajo glede na specifikacije in nobena verzija ne more biti nameščena, če ne prestane testov. Pri pisanju kode lahko greš v skrajnosti v obe smeri, vendar nadrejeni in stranke vidijo le končni rezultat, zato si pretirane pikolovskosi enostavno ni mogoče privoščiti. Glavno vodilo, kar se tiče kakovosti je, da aplikacija deluje zanesljivo in pravilno ter da se pravilno odziva tudi na kombinacije napačnih vhodnih podatkov. Naše aplikacije delujejo 24 ur na dan vse dni v letu. S tvojo izjavo o DOBRO plačanih kompetentnih ljudeh se pa strinjam, vendar se na žalost na tovrstne zadeve gleda precej kratkoročno.
Se pridružujem reklami za Code complete. Uporabna pa še prav zanimivo branje. Glede tistega duvanja "starih" programerjev ki "raje kot po knjižnicah posežejo po assemblerju" pa si mislim svoje. Zakrnelk se mi zdi še najprimernejša beseda. Pa programiram v assemblerju, kadar je potrebno, že iz "tistih zlatih cajtov". Potrebno je uporabljati primerna orodja. Včasih so to knjižnice, ki jih ne razumeš (oziroma boljše povedano nočeš razumeti), ker boš sicer naslednjih100 let razvijal najboljšo stvar.
> Zgled za pisanje dobre kode je NASA, kjer je bil proces nastajanja kode za raketoplane dodelan do potankosti, ključne točke pa so hierarhija in zdrava mera tekmovalnosti, načrtovanje, sledljivost sprememb, dokumentacija, odpravljanje napak in vzrokov, ki so pripeljali do njih. Rezultat: 420.000 vrstic dolg program ima eno napako - komercialni program bi jih imel nekaj tisoč.
Bullshit Stalne težave z Appollo misijami in Space Shuttle Columbia disaster ...
Some nanoparticles are more equal than others
Good work: Any notion of sanity and critical thought is off-topic in this place
Ni bil posledica napake programske opreme ampak defektnega HW - ob vzletu odpadla izolacija iz glavnega tanka je poskodovala termicno zascito na shuttlu. Try again.
zee
Linux: Be Root, Windows: Re Boot
Giant Amazon and Google Compute Cloud in the Sky.
Ni bil posledica napake programske opreme ampak defektnega HW - ob vzletu odpadla izolacija iz glavnega tanka je poskodovala termicno zascito na shuttlu. Try again.
Defekten je bil SW ki je evaluiral obseg poškodbe in so na podlagi tega odobrili pristanek.
Some nanoparticles are more equal than others
Good work: Any notion of sanity and critical thought is off-topic in this place
Kateri dokumentarec? Ker mogoče si raje pogledaš kaj kvalitetnega, recimo Moon Machines, da biš videl, da v nobeni misiji ni bil problem v SW, pa je bil kar pomemben del (brez njega ne bi bilo misije na luno)
Where all think alike, no one thinks very much.
Walter Lippmann, leta 1922, o predpogoju za demokracijo.
