Tarkoitukseen sopiva ohjelmointikieli?

Ja lisäys vielä, että jos objektit ovat kovin monimutkaisia, niin kielten nopeuserot alkavat jo näkyä. En lähtisi tuollaista kyllä Javalla toteuttamaan.

"No kielellä ei niin ole väliä, vaan grafiikkakirjastolla. Jos laitteistoriippumattomuutta haetaan, niin OpenGL on oikeia valinta."

Ei vaan WebGL. Windowsissa OpenGL on deprekoitu ja siinä ohjelmoidaan DirectX:ää C#:lla. Mac OS:ia taas ei ohjelmoida C#:lla.

WebGL sen sijaan on molemmissa täysin tuettuna ja sitä voi ohjelmoida molemmissa Javascriptillä.

Javaw kirjoitti:

Ja lisäys vielä, että jos objektit ovat kovin monimutkaisia, niin kielten nopeuserot alkavat jo näkyä. En lähtisi tuollaista kyllä Javalla toteuttamaan.

Java on hyvin nopea kieli, ei ole nopeudesta kiinni se. Javan ongelma on se, että se toimi kaikissa päätelaitteissa ja voi tarvita erillistä ajoympäristöä. Se on siis väärä työkalu.

M-Kar kirjoitti:

"No kielellä ei niin ole väliä, vaan grafiikkakirjastolla. Jos laitteistoriippumattomuutta haetaan, niin OpenGL on oikeia valinta."

Ei vaan WebGL. Windowsissa OpenGL on deprekoitu ja siinä ohjelmoidaan DirectX:ää C#:lla. Mac OS:ia taas ei ohjelmoida C#:lla.

WebGL sen sijaan on molemmissa täysin tuettuna ja sitä voi ohjelmoida molemmissa Javascriptillä.

Lue lisää

Mtä vttua selität? Ei ole OpenGL:ää paprikoitu Windowsissa, ihan vaan OpenGL:ää ohjelmoidaan. Sitä paitsi nyt ei varmaankaan haluta mitään web-sovellusta.

" Eikö tämä periaattessa vähentäisi ohjelmointimäärän tarvetta, jos kaikki visuaaliset tapahtumat olisi valmiina ja valmiiksi animoituja? Eikö siis tällöin voisi antaa tavallaan vain käskyn jonkin valmiin (video)tiedoston toistamiseen? Jos nyt ollenkaan ymmärsin mitä siis viesteissänne tarkoititte."

Missä muodossa se animaatio/video olisi?

"Esineen pyörittelyn mahdollistaminen on on varmaan tätä mutkikkaampi koodata. Siis että valmiin ohjelman käyttäjällä olisi mahdollisuus pyörittää objektia. Mutta onko ohjelmointia ajatellen tällöinkään merkitystä objektin ulkonäöllä, jos se on valmiiksi renderöity?"

Vapaata pyörittelyä ei käytännössä saa valmiiksi renderöityä. Vaatii järkyttävän määrän kuvia.

Yksinkertainen tapa arvioida aikaa on se kun miettii millainen ohjelmoijan työpäivä on. Se että saa fokuksen siihen työhön kestää hetken, joten keskeytykset ovat ikäviä mutta niitäkin tulee ja hävikkiaikaa ei voi missään työssä täysin välttää ja joskus ihmiset myös mokailevat. Ohjelmoija ohjelmaa tehdessä kirjoittaa testejä, ja kirjoittaa koodia joita ne testit testaavat sekä korjaa vikoja. Työpäivän aikana saa hoidettua ehkä noin 12 asiaa, joista yksi asia on noin puoli tuntia. Tehollista aikaa tulisi siis 6h. Työpäivästä menee loput 1.5h kommunikointiin asiakkaan kanssa, syömiseen, sähköpostit, kahvitaukoon, paskanjauhantaan, jonkun ylläripylläri bugien korjaamiseen, muutama minuutti facebookkia aivojen virkistämiseksi tai johonkin muuhun säätöön.

Tästä noin 12 hoidetusta asiasta saadaan jos olisi vaikka 6kpl kirjoitettuja testejä, ja 6kpl toiminnallisuutta joita ne testit hoitavat.

Jos on viiden päivän työviikko, viikossa pitäisi siis saada ohjelmaan tehtyä noin luokkaa 30 juttua per kehittäjä.

Eli, se hintalappu menee siis sen mukaan, kuinka monimutkaisen ohjelman haluat! Kaikki monimutkaisuus lisää niitä testien kuin toiminnallisuuksien kirjoittamista.

Koko projekti pitää aloittaa miettimällä, että:

1. Mistä ja mitä tietoa tuodaan ohjelmaan sisään
2. Mitä tietoa ja minne ohjelmasta pitäisi saada ulos
3. Mitä tietoa ja minne ohjelman pitäisi tallentaa
4. Hahmoittamalla käyttöliittymänäkymiä niin loppukäyttäjän kuin hallintanäkymän puolelta, että mitkä napit siellä on ja mitä niiden pitäisi tehdä.
5. Kuvaus tallennettavista tiedoista esim. taulukkolaskentaohjelman tiedostoina, että taulukosta näkisi mitä kenttiä on tietoa
6. Määrittelemällä milloin ohjelma on valmis. Eli pitäisi muotoilla hyväksymistestit ja ohjelma on valmis sitten kun kaikki hyväksymistestit menee läpi.

Pointti siis on se, että pitäisi tietää ihan tarkkaan mitä halutaan, ja se pitää vielä muotoilla kirjallisesti, yksiselitteisesti ilman tulkinnanvaraisuuksia. Sitten vasta hahmoittaa sen monimutkaisuuden.

((((

Tässä lainausta hyväksymistestausten tekemisestä:

Sam: “OK, now these log files need to be backed up.”
Paula: “OK, how often?”
Sam: “Daily.”
Paula: “Right. And where do you want it saved?”
Sam: “What do you mean?”
Paula: “Do you want me to save it a particular sub-directory?”
Sam: “Yes, that’d be good.”
Paula: “What shall we call it?”
Sam: “How about ‘backup’ ”?
Tom (tester): “Wait, backup is too common a name. What are you really storing in this directory?”
Sam: “The backups.”
Tom: “Backups of what?”
Sam: “The log files.”
Paula: “But there’s only one log file.”
Sam: “No, there are many. One for each day.”
Tom: “You mean that there is one active log file, and many log file backups?”
Sam: “Of course.”
Paula: “Oh! I thought you just wanted a temporary backup.”
Sam: “No, the customer wants to keep them all forever.”
Paula: “That’s a new one on me. OK, glad we cleared that up.”
Tom: “So the name of the sub-directory should tell us exactly what’s in it.”
Sam: “It’s got all the old inactive logs.”
Tom: “So let’s call it old_inactive_logs.”
Sam: “Great.”
Tom: “So when does this directory get created?”
Sam: “Huh?”
Paula: “We should create the directory when the system starts, but only if the directory doesn’t already exist.”
Tom: “OK, there’s our first test. I’ll need to start up the system and see if
the old_inactive_logs directory is created. Then I’ll add a file to that directory. Then I’ll shut down, and start again, and make sure both the directory and the file are still there.”


Paula: “That test is going to take you a long time to run. System start-up is already 20 seconds, and growing. Besides, I really don’t want to have to build the whole system every time I run the acceptance tests.”
Tom: “What do you suggest?”
Paula: “We’ll create a SystemStarter class. The main program will load this starter with a group of StartupCommand objects, which will follow the Command pattern. Then during system start-up the SystemStarter will simply tell all the StartupCommand objects to run. One of those StartupCommand derivatives will create the old_inactive_logs directory, but only if it doesn’t already exist.”
Tom: “Oh, OK, then all I need to test is that StartupCommand derivative. I can write a simple FitNesse test for that.”

Tom goes to the board.

“The first part will look something like this”:

given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory does not exist when the command is executed
then the old_inactive_logs directory should exist
and it should be empty

“The second part will look like this”:

given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory exists
and that it contains a file named x
When the command is executed
Then the old_inactive_logs directory should still exist
and it should still contain a file named x

Paula: “Yeah, that should cover it.”
Sam: “Wow, is all that really necessary?”
Paula: “Sam, which of these two statements isn’t important enough to
specify?”
Sam: “I just mean that it looks like a lot of work to think up and write all
these tests.”
Tom: “It is, but it’s no more work than writing a manual test plan. And it’s much more work to repeatedly execute a manual test.”


))))

Eli, määrittele mitä haluat ensiksi. Niin tarkasti ja yksiselitteisesti niin selviää se kompleksisuus. Jos et määrittele tarkasti vaan teetät ohjelmaa puutteellisella määrityksellä, niin saat sitä projektisuunnitelmaa takaisin bumerangina useaan otteeseen jossa kehittäjät tarkentaa niitä vaatimusta, aika-arvion kasvaessa.


Sitten kun ohjelma on "valmis" ja testaat sitä niin huomaatkin että "ei se nyt näin vaan tarvisi tähän tälläinen muutos". Ja siitä tulee sitten uutta "sinne päin" aika-arviota. Epämääräisillä määrityksillä on tapana mennä niin, että varataan vaan rahaa tarpeeksi ja kehitystä tehdään niin pitkälle kuin raha riittää, tuli sitten mitä tuli.

Eli, määrittele tarkasti mitä haluat ja mikä on "valmis". Sitten ei ole tulkinnanvaraisuuksia ja hintalappu tulee tarkaksi. Ongelma kannattaa myös purkaa riittävän pieniin osiin, eli käyttöliittymä, palvelimessa oleva osa, datakonversiojutut jne. ovat erillisiä projekteja eikä edes yritä käsittää koko hoitoa yhtenä projektina.

M-Kar kirjoitti:

Tom goes to the board.

“The first part will look something like this”:

given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory does not exist when the command is executed
then the old_inactive_logs directory should exist
and it should be empty

“The second part will look like this”:

given the command LogFileDirectoryStartupCommand
given that the old_inactive_logs directory exists
and that it contains a file named x
When the command is executed
Then the old_inactive_logs directory should still exist
and it should still contain a file named x

Paula: “Yeah, that should cover it.”
Sam: “Wow, is all that really necessary?”
Paula: “Sam, which of these two statements isn’t important enough to
specify?”
Sam: “I just mean that it looks like a lot of work to think up and write all
these tests.”
Tom: “It is, but it’s no more work than writing a manual test plan. And it’s much more work to repeatedly execute a manual test.”


))))

Eli, määrittele mitä haluat ensiksi. Niin tarkasti ja yksiselitteisesti niin selviää se kompleksisuus. Jos et määrittele tarkasti vaan teetät ohjelmaa puutteellisella määrityksellä, niin saat sitä projektisuunnitelmaa takaisin bumerangina useaan otteeseen jossa kehittäjät tarkentaa niitä vaatimusta, aika-arvion kasvaessa.


Sitten kun ohjelma on "valmis" ja testaat sitä niin huomaatkin että "ei se nyt näin vaan tarvisi tähän tälläinen muutos". Ja siitä tulee sitten uutta "sinne päin" aika-arviota. Epämääräisillä määrityksillä on tapana mennä niin, että varataan vaan rahaa tarpeeksi ja kehitystä tehdään niin pitkälle kuin raha riittää, tuli sitten mitä tuli.

Eli, määrittele tarkasti mitä haluat ja mikä on "valmis". Sitten ei ole tulkinnanvaraisuuksia ja hintalappu tulee tarkaksi. Ongelma kannattaa myös purkaa riittävän pieniin osiin, eli käyttöliittymä, palvelimessa oleva osa, datakonversiojutut jne. ovat erillisiä projekteja eikä edes yritä käsittää koko hoitoa yhtenä projektina.

Lue lisää

Eli kuten näit niin tuollainen logitoiminnallisuus vaatisi 10 testiä, eli puhutaan alle kahden työpäivän jutusta.

Vaikea sanoa mikä tässä kyseisessä jutussa on tavoitetila, että onko kyse tuotekehityksestä vai halutaanko omaan käyttöön työkalua mutta yleisesti ottaen halvinta on käyttää valmiita ohjelmia. Ja jotta saa vähän perspektiiviä niin silloin ei yleensä kannata määritellä useita käyttöjärjestelmiä tms. kun on yleensä halvempaa ostaa uudet tietokoneet ja uudet valmisohjelmat kuin teettää kokonaan uusi ohjelma.

"Olisiko kellään heittä esimerkkejä minkälaisia palkkioita ohjelmoijille on maksettu jotain pikkuohjelmistoja koskien koko projektin osalta?"

Ensiksi tosiaankin kannattaa purkaa se ongelman laajuus, että kuinka pientä ohjelmistoa haetaan. Jokainen eri muotoista tietoa tallentava & käsittelevä osa on yksi komponentti, esim. palvelu joka huolehtii siitä 3D-mallitietopankista on yksi ohjelma.

Jos dataa täytyy tuoda tähän tietopankkiin jostain, jokaisen datamuodon tekevä konvertteri on yksi oma ohjelma.

Jokainen käyttöliittymä, niin se loppukäyttäjän näkymä, animaatioplayeri kuin joku ylläpito käyttöliittymä, on oma ohjelmansa.

Siitä voit laskea monta pikku ohjelmaprojektia siihen kokonaisuuteen kuuluu, jotka pitää purkaa osiin, määritellä ja tehdä pala kerrallaan.

"Yksi asia jota en saa päästäni on se, että olisiko joihinkin ohjelmointikieliin mahdollista tavalla tai toisella importata 3D-mallit jotka on mallintanut 3D-ohjelmalla valmiiksi."

Mikään ohjelmointikieli itsessään ei tajua mitään 3D-malleista. Ohjelmointikieli on työkalu jolla tehdään ohjelma joka lukee jollain 3D-ohjelmalla luodun mallin muistiin johonkin tietorakenteeseen. Sitten kun se 3D-malli on muistissa, voidaan ohjelmointikielellä tehdä ohjelma joka piirtää sen mallin ruudulle.

Sitä saattaa tietysti löytyä valmiita komponentteja tällaiseen, joko maksutta tai maksamalla. Valmis komponentti tietysti tekee riippuvuuden siihen ja se voi tehdä rajoitteita.

Mutta, ohjelmointihan on sitä tehdään sitä ohjelmaa joka esimerkiksi lukee jonkun 3D-mallin muistiin. Näitä asioitahan tässä projektissa ollaan selvästikin hakemassa.

"Eli kuinka saada ohjelman ruutuun tekstuureineen ulkonäöltään yhtäläinen interaktiivinen objekti jonka on suunnitellut 3D-ohjelmalla? Varmaankin hankalempi homma"

Ihan vaan ohjelmoimalla. 3D-mallin formaatti pitäisi toki tietää, että lukee siitä tiedostoformaatin spesifikaatiosta mitä se pitää sisällään, sitten kirjoittaa ohjelman joka lukee sen muistiin. Eiköhän siellä ole läjä koordinaatteja vertekseille, tekstuurikoordinaatit jne.

Aina siellä jokin reaaliaikainen piirtovaihe on mutta osa jutuista voidaan myös esirenderöidä. Näin on tehty vuosikymmeniä.

tattista