Javaa, erityisesti enterpriseä kehittäessä testisykli käännös- ja deploymentaikoineen on aivan liian pitkä. Tätä paikkaamaan on kehitetty lukuisia ratkaisuja, joista tässä artikkelissa minua kiinnostaa JRebel.
JRebel korjaa Javan (ja JVM:n) ongelman, ettei luokkia voida muuttaa käynnistämisen jälkeen. Tästä seuraa useamman vaiheen kautta JEE:n hitaat turnaround-ajat. JEE-kehittäjät kautta maailman ovat ottaneet sen ilolla vastaan. Aikaisempina [...]
Jatka lukemista →Erään projektin katselmoinnissa löysin (siis en itse keksinyt, nämä tulivat asiakkaalta) hyvät ja lyhyet kuvaukset eri rooleista scrumissa:
Miksi – liiketoiminnan omistaja Mitä – tuoteomistaja
Sitten voisi tietysti lisätä arkkitehdin ja scrum masterin ja monta muuta, mutta niille ne vain sotkevat tätä hienoa yksinkertaistusta. Jätän niiden kysymysten miettimisen lukijalle harjoitustehtäväksi.
Mikä tai kuka on liiketoiminnan [...]
Jatka lukemista →Ohjelmistokehitys on kuin standup-komiikkaa. Jotta vitsit toimisivat, niitä pitää esittää yleisölle. Yhä uudestaan, kunnes naurua alkaa kuulua. Yksin kopissa harjoittelemalla ei pääse rajaansa pidemmälle.
Samalla efektillä voidaan selittää laajalti ketterien menetelmien idea: Softaa esitellään asiakkaalle yhä uudestaan ja uudestaan, kunnes se on mitä asiakas haluaa.
Kutsukaamme tätä demoefektiksi.
Demoefekti on sitä, että kun softa pitää [...]
Jatka lukemista →Liiketoimintaa aloittavalla ohjelmistoyrityksellä on monia haasteita. Miten kehittää toimiva liiketoimintamalli? Mistä saada rahoitusta?
skreetch!
Ennen kuin softastartup tuottaa rahaa, pitää sen tehdä softaa. Ohjelmistostartupin koko idea on tehdä softaa, jota voidaan jollain enemmän tai vähemmän uskottavalla liiketoimintamallilla muuttaa rahaksi.
Mutta.
Softa-alan ammattilaisilla on todellinen ja aloittelevien yritysten kannalta harmittava taipumus näperrellä [...]
Jatka lukemista →Tänä tehokkuuden ihannoinnin aikakautena yleisenä totuutena pidetään, ettei mitään tehtävää pidä hieroa liian pitkään. Pitää olla selkeä näkemys siitä, milloin homma on valmis, ja silmät avoinna niin että havaitaan kun tila on saavutettu.
Ajatusmallissa on kaksi vikaa. Toinen on yksinkertainen ja selkeä, toinen vähän filosofisempi ja hankalahko.
Ensimmäinen on tietysti se, että osaava tekijä tietää [...]
Jatka lukemista →Metodologioiden huumassa unohtuu välillä korkeamman tason ajattelu ohjelmistokehityksestä. Ohjelmiston kirjoittamisen kustannusten (suorien ja epäsuorien) vähentämisen ylivoimaisesti tehokkain tapa on välttää ohjelmiston kirjoittaminen kokonaan.
Otetaan esimerkki: aikanaan Codentossa huomattiin joidenkin työntekijöiden tekevän jatkuvasti ylitöitä. Tätä haluttiin kontrolloida jollakin tavalla, jos ei vähentämällä päivittäisiä tunteja, laittamalla työntekijät kertymän sitä edellyttäessä pitämään vapaapäiviä.
Ohjelmistoyrityksenä Codentolla oli tietty suuri [...]
Jatka lukemista →Me Codentossa olemme kaikki* ohjelmistoarkkitehtejä, eli piirrämme kaavioita, joissa on monen värisiä laatikoita. Tämä erottaa meidät oikeista arkkitehdeistä, jotka tekevät julkisivuja, joissa on monen värisiä laatikoita.
Tämä ei kuitenkaan ole ainoa ohjelmistotyö jota teemme. Ohjelmistoalan moniosaajina toimimme tarvittaessa myös seuraavissa ammateissa:
Ohjelmistoarkeologi. Tämä Codenton lisäksi myös Vernor Vingen tuotannosta tuttu ohjelmistoammattilainen tutkii historiallisia jäänteitä ajalta [...]
Jatka lukemista →Viime aikoihin asti ohjelmistokehitystä on tehty lähinnä vesiputousmallilla, jossa projekti ensin määritellään, sitten suunnitellaan, sitten toteutetaan, testataan ja luovutetaan asiakkaalle. Malli on raskas ja epäkäytännöllinen. Koska asiakas on mukana vain alussa ja lopussa, hänellä ei ole kontrollia projektiin, ja alun määrittelyssä tehtyjä virheitä ei voida enää korjata.
Kuulostaako tutulta? Kaikkihan haukkuvat [...]
Ohjelmoijien kansanperinteeseen kuuluu erottelu kertakäyttökoodiin ja tuotantokoodiin. Tuotantokoodin erilaisia laatutasojakin nähdään yleensä olevan ainakin muutamia. Haluan kuitenkin tarkastella kertakäyttökoodin käsitettä.
Koska koodi kuitenkin jää olemaan, ja on riski sen uudelleenkäytöstä, pitäisi tunnustaa tosiasiat, eikä elää valheessa. Kaikki koodi pitäisi kirjoittaa vähintään minimaalisella tuotantokoodin tasolla: kehittäjän itsensä pitää ymmärtää se myös puolen vuoden päästä.
Ohjelmoijan tapa [...]
Jatka lukemista →Kukapa ei haluaisi ohjelmistoprojektiinsa hyvää tiimiä. Mutta mistä sellaisen saa? Ja mikä erottaa hyvän tiimin keskinkertaisesta? katsotaanpa kahta selitystä, konventionaalista ja vähän yllättävämpää.
Selitys yksi: Hyvä tiimi koostuu hyvistä tyypeistä.
Kooderien tuottavuuserot ovat valtavia. Hyvä kooderi käyttää tehtävään viidesosan siitä ajasta joka keskiverrolta kuluu, ja lopputulos on silti monin tavoin parempi. Sama [...]
Jatka lukemista →Yhteystiedot
Ota yhteys ja kysy Codenton palveluista! Puhelin 040-729 2733, info[at]codento.comTagit
aamiaistilaisuus agile ajankohtaista amazon arkkitehtuuri avoin lähdekoodi aws c CAP cvs ec2 eucalyptus futurologia git google hadoop hajautetut järjestelmät java kirjat konsultointi mapreduce näin meillä ohjelmistotuotanto ohjelmointi ohjelmointikielet pilvi projektit python rekrytointi s3 scala scrum skaalautuvuuden abc skaalautuvuus startup subversion suorituskyky tapahtumat tiedostojen synkronisointi tietokanta vaatimusmäärittely verkkopalvelut versionhallinta virtualisointi välimuistiArkisto
- helmikuu 2012
- tammikuu 2012
- joulukuu 2011
- marraskuu 2011
- lokakuu 2011
- huhtikuu 2011
- maaliskuu 2011
- helmikuu 2011
- tammikuu 2011
- joulukuu 2010
- marraskuu 2010
- lokakuu 2010
- syyskuu 2010
- elokuu 2010
- heinäkuu 2010
- kesäkuu 2010
- toukokuu 2010
- huhtikuu 2010
- maaliskuu 2010
- helmikuu 2010
- tammikuu 2010
- joulukuu 2009
