Uncategorized

Open source, closed doors? Peace of code.

Throughout my involvement with code, I’ve been curious as to both the volume and quality of code. As well as, how it feels in particular moments to be programming.

Not so long time ago the suitability of open-plan offices to R&D (generally, “anything needing precise concentration for rather long periods of time”) was revisited and, according to many articles or persons, programmers hate open-plan offices. This in turn translates to diminished productivity.

Part of the negative side of a open-plan office is due to interrupting the flow, or optimal mental state of a developer. Good managers know how to shield developers from completely unnecessary and fruitless disruptions. Apart from one-man shops (where you, the CEO, are also developers, sales-guy, coffee grinder and the janitor), developers rarely should directly handle individual service cases (ie. being helpdesk), nor should they have much direct daily output to sales activity. Developers often participate as technical aides in product design; write both payload code and tests (the ‘core’ of their trade), handle open bugs, and learn new things. Developers should not (in my opinion) be involved much in the back-office activities of a project, such as maintaining capacity and reliable availability of servers, configuring complex build systems; and they definitely should not be involved in mindless ramifications from organizational architecture change such as moving a lot of stuff from a folder to another, or having fencing with any office productivity / email / calendar suites. Well, the latter goes to every role (not just devs) in the company, and I know that it’s part idealistic to state that change shouldn’t incur painful and numbing experiences.

My stance on the open-floor plan issue is quite similar as the news. If I’m mostly in developer role, I prefer somewhat closed rooms. It doesn’t mean that each developer would sit in their own closet, but rather that a team is shielded from extraneous noise and distractions. A very good idea is to have easily available, temp quiet spaces for individual work. Booking them shouldn’t be necessary.

Joel Spolsky said very well:

The more things you (ie. developer) can keep in your brain at once, the faster you can code, by orders of magnitude.

There might be purely neurological reason behind this. Our sound perception works as a background thread, automatically. We kind of – computationally speaking – keep making sense of the word-stream that enters our ears. Thus the more there is sound signal in the enclosing space, the more we probably have to deviate from perfect concentration on the most important task.

The idea behind open-floor plans probably were to alleviate siloing (individual developers going solo, making things that become incomprehensible to others, and pose a business risk). By putting people together, the architects maybe thought of leveling and making the team advance in more even and predictable steps. Reality perhaps got in the way.

Uncategorized

3D-grafiikkaa Linuxilla, osa 1: alkulätinät

3D -grafiikka on mielenkiintoinen aihe, siinäkin mielessä että usein ensi-innostuksen jälkeen aihepiiri voi jäädä hyllylle. Grafiikka voi toisaalta olla elämänpituinen intohimo, sekä tuleva ammatti.

Esittelen tässä sarjassa 3D-grafiikan alusta “loppuun”, niin että pääset kirjoittamaan koodia Linuxilla. Esimerkeissä käytetään OpenGL ja GLUT kirjastoja, mikä lienee kohtuullisen yleinen vaihtoehto. Kaupallisiin tai muihin valmiisiin pelialustoihin todennäköisesti ei tutustuta. Voi olla, että jos käytän myöhemmin jotain tällaista, siitä erillinen sarjansa.

Tässä jaksossa…

  1. höpistään hieman taustoja grafiikasta
  2. juodaan kahvia
  3. mietitään miksi vasta sarjan seuraavassa osassa päästään koodaamaan

Mutta – se on lopulta kaikki vain pikseleitä!

Grafiikan ideathan ovat universaaleja, mutta lopulta iteratiivisen testailun ja viihtymisen vuoksi jollain laitteistolla ja softakirjastoilla homma on lopulta tehtävä. Eli kädet on lyötävä saveen, ja koodia kirjoitettava.

Ideatasolla ymmärrämme jo ihmisenä mistä grafiikassa on kyse; näemmehän jatkuvasti erilaisia pintoja, esineitä, ihmiskasvoja, taivaan, jne ympärillämme. Grafiikkaohjelmoinnissa luodaan illuusio siitä, että se, mikä (usein 2-ulotteisella) ruudulla näkyy vain tasossa, esittää tuota oikeaa kolmiulotteista maailmaa.

Joskus 3D-ohjelmointia ensimmäisen kerran lähestyessä voi mielen vallata kaaos: erilaiset konseptit pulppuavat tulvana mieleen, ja mikäli ei naulaa tiettyjä perusasioita jämäkästi kiinni, voi olla, että ohjelmointi jää sikseen.

Anna esineille oma rauhansa

Esineet elävät omaa elämäänsä. Eli ne voidaan määritellä riippumatta, miten ne myöhemmin tulevat esiintymään 3D-maailmassa. Tämä on eräs fundamentaali oivallus, joka ainakin itselleni toi mielenrauhaa. Jos olet leikkinyt 3D-ohjelmilla, aika nopeasti idea kolmesta akselista (X,Y,Z) ja esineiden muodostuminen näihin alkaa tuntua luontevalta. Suosittelen nimenomaan “aivotonta kokeilua”. Silloin saa tuntumaa myös ohjelmointiin. Älä aluksi yritä tehdä mitään mestariteoksia.

Aivan mainioita harjoituskappaleita ovat säännölliset laatikot, kuin myös pyramidi, tangot, palikat.

Asenna vaikka Blender, joka on täysin ilmainen ja erittäin laadukas softa. Blenderillä on tehty elokuvia ja pelejä, mutta nyt alkuun siitä on iloa nimenomaan 3-ulotteisten esineiden muovaamisessa. Ohjelmoinnin kannalta Blender ei ole mitenkään pakollinen, mutta se on kiehtova softa jos mallinnus kiinnostaa.

Illuusion ytimessä: projisointi

Kolmiulotteisessa grafiikassa esineet piirretään tasoon (monitorille) siten, p_projektiot_seinaettä niiden muoto muuttuu antaen illuusion katselukulmasta ja esineen etäisyydestä katsojaan. Kun soppaan lisätään valaistus, varjot, ja muita efektejä, gourmé -ateria on valmis! Yksinkertaistettuna siis näin.

Teknisesti kyse on projisoinnista. Esineistä, joilla on 3-ulotteiset koordinaatit, piirretään meihin, “katsojan silmään”, viivat, ja nuo viivat katkaistaan ruudun (tason) kohdalla. Jos olemme esineen sisällä, esimerkiksi talossa, jätetään taaksemme menevät esineet vain piirtämättä (meillä ei ole silmää takaraivossa). Matemaattisesti kyse on suhteellisen yksinkertaisesta ratkaisusta: jos projisoidun pinnan syvyys (z-koordinaatti) on negatiivinen, sen voi jättää huomiotta.

 

Tietokonegrafiikka kehittyi mustavalkoisesta 2-ulotteisesta grafiikasta ensin värigrafiikkaan. Oli “kova juttu” että esimerkiksi PC:lle löytyi CGA -grafiikkaominaisuuksia tukevissa korteissa 3 omituista väriä ja lisäksi musta. CGA-grafiikka näytti tuolta vieressä olevalta.

Hiljalleen 1980-luvun tienoilla tietokoneisiin ohjelmoitiin (softalla) 3D-grafiikan rutiinit itse. Jokaisella ohjelmoijalla oli siis kivinen mutta toisaalta antoisa tie kuljettavanaan, koska pikselin- ja viivanpiirrosta lähtien kaikki piti tehdä itse. Bresenham oli tuolloin kova sana – keksijänsä mukaan nimetty algoritmi, jolla saatiin tehtyä mielivaltainen viiva kahden pisteen välille, siten että se ei näyttänyt “tyhmältä” eikä kuluttanut yhtään liikaa prosessoriaikaa.

Alkoi grafiikkakorttien valtakausi. 2D -piirtämisen oltua “riittävän hyvällä” tasolla kolmiulotteisten rutiinien kilpavarustelu oli tuleva taistelutanner seuraavien parinkymmenen vuoden ajan. Muistimäärät kasvoivat myös näytönohjaimissa reippaasti alkuperäisistä. Tavallaan modernin peligrafiikan taustalla on sopiva määrä elektroniikan ja ohjelmistojen kehitystä.

 

Mikä OpenGL on?

OpenGL tarjoaa rajapinnan grafiikkakorteille. Sen tarkoitus on eriyttää laitevalmistajakohtaiset yksityiskohdat, jotta ohjelmoijat voisivat tehdä heille mielekkäitä asioita sen sijaan että miettisivät eri valmistajien ja korttimallien kanssa temppuilemista.

OpenGL-kirjasto kulkee versiossa 4 tällä hetkellä. OpenGL on tavallaan hyvin matalan tason, laitteistoläheinen yhteys. Kirjasto tarjoaa siis C/C++ kielelle funktiot ja vakiot grafiikkakortin ohjaamiseen. OpenGL:n tärkeimpiä ominaisuuksia on ohjelmoitavuus: sen avulla voidaan luoda uusia efektejä, jotka tietenkin lopulta lankeavat grafiikkakortin suoritettavaksi, mutta näin päästään grafiikkaohjelmoinnissa liikkumaan hieman korkeammalla tasolla.

Kun laitevalmistajat tarjoavat uusia ominaisuuksia raudalla, OpenGL seuraa kehityksessä näitä.

Entä mikä on GLUT?

GLUT taas on pieni kehikko grafiikkaohjelman yleisimpien peruselementtien tekemiseksi. GLUT liittyy enemmän Linuxin työpöydän ikkunointiin ja sen sellaiseen. Eli GLUT helpottaa “toimivan” kokonaisuuden protoilua. OpenGL:n mielestä maailmassa on sen sjiaan vain olemassa raakoja suorakulmion muotoisia alueita näytöltä, joihin piirrellään pikseleitä. OpenGL ei ota kantaa “käytännöllisempiin” asioihin ohjelman rakentamisessa.

 

Uncategorized

Viikonlopun saldona muutamia kuvia ja pullantuoksuista menoa! 

Kirjoittelin portfoliota. City of Steel sai paljon lisäsisältöä juoneen.

City of Steel is a story happening in a small unnamed city, merely known as City of Steel. The city is equally famous for its steel production as for its legendary Patron, who overlooks both in good and bad all activities in the area.

Then hard times hit, and disaster after disaster ravages the foundations of peace and prosperity. Old Patron is both physically and mentally dislocated. Facilities are shut down. The whole industry almost halts. People lose jobs. Some flee to other parts of the country.

Those that remained, became gloomy. The great Patron who single-handedly ran and owned the steel industry has
retreated and lives as recluse, having almost lost touch to the inhabitants he so much cared for.

Puhdasta englantia, tyypillisesti pelien kanssa tarinoin aina mieluummin tuolla kielellä. Varmaan peruja siitä, että opiskelin suurimman osan englannistani suoraan pelien manuaaleista ja niiden tarinoita kahlaten, Webster vierelläni 😉