Jos unohdetaan kaikki puhe avoimen koodin "reiluudesta" ja miten Microsoft on on kaiken pahan alku ja juuri, niin kysyisin onko . Net ja varsinkin Visual Basic helpompaa. Javassa kun jatkuvasti tulee uusia kilkkeitä (esim. Ant) ja frameworkkeja jotka välttämättä ei tuo pahemmin lisäarvoa ohjelmiston kehittämiseen.
Esimerkiksi Ant tekee sen minkä mikä tahansa hyvä IDE tekee helpommin... Miksi "hardcore" java-koodarit haluavat tehdä kaiken vaikeimman kautta? En jaksa jatkuvasti opiskella uusia open source frameworkkeja jotka "helpottavat" sovelluskehitystä. Eikö tärkeintä ole keskittyä sovelluksen arkkitehtuuriin ja ns. "business logiikkaan" kuin käyttää aikaa näpräilyyn.
Esimerkiksi Oraclen JDeveloper toimii loistavasti Oracle:n IAS:n kanssa, esim. EJB:t menee hienosti eikä tarvitse itse kaiken maailman deployment descriptoreita käpristellä... Mutta tilanne muuttuu heti kun olet viemässä kyseisiä EJB:tä esimerkiksi Weblogic:lle. Näiden kaiken maailman deployment descriptoreiden tekeminen vie kauan, eikä todellakaan ole "tuottavaa työtä", vaan turhaa näpräilyä.
Kysymykseni kuuluu tarvitseeko . Net:ssä näin paljon olla tekemisissä erilaisten "konfiguraatio" tiedostojen kanssa? Olivat ne sitten XML:llää tai mitä tahansa... Käsitykseni mukaan ei tarvitse niin paljoa näpräillä vaan keskittyä kehittämään sovellusta.
Esimerkiksi Ant tekee sen minkä mikä tahansa hyvä IDE tekee helpommin... Miksi "hardcore" java-koodarit haluavat tehdä kaiken vaikeimman kautta? En jaksa jatkuvasti opiskella uusia open source frameworkkeja jotka "helpottavat" sovelluskehitystä. Eikö tärkeintä ole keskittyä sovelluksen arkkitehtuuriin ja ns. "business logiikkaan" kuin käyttää aikaa näpräilyyn.
Esimerkiksi Oraclen JDeveloper toimii loistavasti Oracle:n IAS:n kanssa, esim. EJB:t menee hienosti eikä tarvitse itse kaiken maailman deployment descriptoreita käpristellä... Mutta tilanne muuttuu heti kun olet viemässä kyseisiä EJB:tä esimerkiksi Weblogic:lle. Näiden kaiken maailman deployment descriptoreiden tekeminen vie kauan, eikä todellakaan ole "tuottavaa työtä", vaan turhaa näpräilyä.
Kysymykseni kuuluu tarvitseeko . Net:ssä näin paljon olla tekemisissä erilaisten "konfiguraatio" tiedostojen kanssa? Olivat ne sitten XML:llää tai mitä tahansa... Käsitykseni mukaan ei tarvitse niin paljoa näpräillä vaan keskittyä kehittämään sovellusta.
Vastaukset 24
Vanhimmat
En oikeastaan ole .Nettiä juurikaan käyttänyt, mutta muutaman vuoden kokemuksella MS tekniikasta ja Javasta.
- Ant ei ole Javaa vaikka on Javalla tehty (tosin en tiedä, että juuri muualla käytettäisiin)
- .Net VB on laajentunut kielenä verrattuna entiseen VB kieleen. Enemmän oliomainen. Oikeastaan aika samanlaista kuin C# ja Java, mutta syntaksi eri näköistä. Uusia ominaisuuksia ei ole pakko käyttää, mutta joku kuitenkin käyttää, niin pitäähän tuota ymmärtää ylläpidon takia.
- Java on tavallaan sekä matalan tason, että korkean tason kieli. Vaikeus on erottaa APIsta mitä kannattaa käyttää
- J2EE standardi on hieman tynkä. Ohjelma, jonka olet kehittänyt yhdelle palvelimelle ei kuitenkaan toimi heittämällä toiselle palvelimella.
- Oracle toimii varmasti IASin kanssa, mutta WebLogicilla ei taida olla vastaavaa kehitysväline/serveri ympäristöä. Ei ainakaan joku vuosi sitten.
- . Netissä todennäköisesti pääset vähemmällä, koska VisualStudio ja IIS ovat yhden toimittajan ympäristö. Ja siihen vielä kun liittää SQL Serverin, alkaa tuottavuus nousta.
Jos asiakkaasi jo muutenkin käyttää MS ympäristoä, ei sinne kannata mennä muuta tyrkyttämään.
Minäkään en ole pahemmin käyttänät . Net:iä.
Muutama tarkennus... Tiedän että Ant ei ole Javaa mutta se on "työväline" jota käytetään J2EE koodin "buildaamiseen". Minulla ei siinäänsä ole mitään Javaa vastaan, mutta minua ahdistaa kaikenlaiset Open Source projektit ja frameworkit joiden oppimiskynnys on suhteellisen korkea siihen nähden mitä niistä on hyötyä.
Juuri mitä tarkoitin oli se että ns. "aikaa menee hukkaan" kun kehittäjät pahimmassa tapauksessa korjailevat build.xml:lää ja opiskelet taas uutta frameworkkia joka kuitenkaan ei tuo mainittavia hyötyjä itse kehittämiseen.
Mitä juuri tarkoitin oli juuri J2EE, itse asiassa en kommentoinut Javaa itsessään vaan J2EE:tä. Standardi lupaa siirrettävyyden minkä tahansa toimittajan palvelimen välillä. Että muka EJB jonka olet tehnyt toimisi sellaisenaan toisella palvelimella... Kuitenkin halutessasi siirtää esim. EJB-jarrin IAS:sista Weblogic:iin joudut tekemään deployment descriptorit uusiksi, johon voi mennä jonkin aikaa (kaikki tämä ei ole tuottavaa työtä!)
Kokemus on opettanut että eri yrityksissä on eri kehitysympäristöt (esim. Eclipse ja Weblogic/ JDeveloper ja IAS) ja joidenkin ympäristöjen oppimiskynnys on aika korkea. Jos IT pyrkii automatisoimaan erilaisia asioita, miksi itse IT:n kehitystä ei pyritä automatisoimaan?
Tarkoitan sitä että jos kerran J2EE sovellus ei ns. "plug and play" tyyppisesti siirrettävissä sovelluspalvelimesta toiseen, mikä siinä on parempaa . Net verrattuna? (Unohtaen edelleenkin että Bill ja Microsoft on paholaisen ilmentymä maan päällä...) Eikö se ole niin että jatkuvasti tulee uusia työkaluja ja frameworkkeja J2EE:n jotka toteuttavat sen mikä .Net:ssä on vakiona?
- Open Sourcen "tuotteistus" ei ole aina kunnossa. En kovin paljon käytä.
- allekirjoitan täysin tuon frameworkki jutun. Kehitystyökalut pitäisi aina olla sellaiset, että voit keskittyä olennaiseen. Joskus frameworkki on hyödyllinenkin, jos sitä käytetään joka puolella. Tai sitten se pitää olla kätketty työkaluihin.
- .Netiin verrattuna "parempaa" on se, että sen voi siirtää. Tosin työläästi. Net toimii vain yhdessä ympäristössä. En tosin tiedä miksi ylipäätään pitäisi siirtää.
- .Netin etu on tietysti ollut myös se, että MSn omat kehittäjät ovat analysoineet Java maailman hyvät ja huonot puolet ja sitten yrittäneet kasata vain ne hyvät puolet. Aika näyttää miten kestävä se on, mutta ainakin DCOM maailma muuttui koko ajan.
Itse olen joutunut pohtimaan samoja asioita ja musta tuntuu, että jos nyt lähtisin tekemään jotain web projektia, niin valinta olisi stored proceduurit tietokannassa ja kevyt JSP web puolelle. Ja tarvittaessa hiukan rautaa lisää.
Oikeastaan olet ymmärtänyt ant työkalun idean hieman kapeasti, jos pidät sitä vain build työkaluna. Juuri se deploymentin automatisointi on vähintään yhtä tärkeä tavoite. Tosin automatisointi ei tässä tapauksessa tarkoita sun työtä, vaan sen kaverin, joka asentaa järjestelmäsi johonkin applikaatio-serveriin. Koska servereitä valmistaa eri tahot, joilla kullakin on omat hakemistorakenteensa, juuri sen descriptorin kuuluu kertoa serverille minne sun tiedostot kuuluu tämän serverin kohdalla laittaa. Mikkisoftan tapauksessa ei ole vastaavaa ongelmaa, koska sama firma toimittaa kaikki palikat.
Voit kääntää Javaa (myös J2EE:tä) ilman ant työkalua, jos välttämättä haluat. Jopa kääntäminen käsin komentoriviltä on aina mahdollista, vaikka isommassa projektissa ei kovin järkevää. Jos taas edustat vanhaa polvea, niin mikään ei estä käyttämästä make työkalua. Sitä muutkin käyttivät ennen, kuin ant työkalu kehitettiin tekemään asiat helpommaksi. Lisäksi kaupalliset applikaatio-serverit varmasti sisältävät myös IDE:n tai ainakin bluginin yleisimpiä IDE työkaluja varten, jolla voit napin painalluksella tehdä kaiken valmiiksi juuri tätä kyseistä serveriä varten. Joten ero Microsoftin maailmaan on pienempi, kuin luuletkaan.
Eli sun täytyy ymmärtää keskeinen ero. Jos ostat kaiken (kehitysympäristön, applikaatio-serverin, käyttöjärjestelmän...) Microsoftilta, olet aika erilaisessa asemassa, kun tehdessäsi jollakin kymmenistä vaihtoehtoisista kehitysympäristöistä kymmenille vaihtoehtoisille applikaatio-servereille koodia, jota voidaan ajaa ainakin Windowsissa, Unixissa, Linuxissa tai Mac OS:ssä. Kehittäjänä sun pitäisi kyetä hahmottamaan tämä olennainen ero ilman rautalankaakin, vaikka loppukäyttäjä ei tajuaisikaan, miksi kaiken pitää olla niin vaikeaa.
Niin kysymys on siitä että IDE kääntää koodin kyllä, mutta se "write once, run everywhere" on täysi vitsi. Koodia voi kyllä ajaa missä tahansa mutta ns. "parametrointi" tiedot joutuu tekemään uudestaan ja läheskään aina tähän ei ole työvälinettä joten XML:n joutuu tekemään käsin. Ja IDE:t mitä olen käyttänyt ei todellakaan mahdollista deployasta suoraan palvelimelle (Eclipse, Netbeans, JDeveloper)... JDeveloperissa pystyy kyllä helposti deployaamaan IAS:lle mutta esim. Weblogic:iin ei onnistu niin helposti (jos kyse on esim. EJB:stä)
Tottakai hahmotan sen että jos ostat kaiken samalta toimittajalta, niin olet aivan eri asemassa kuin avoimen ympäristössä. Mutta tarkoitan että kenen etu tämä avoin ympäristö on jos sovellukset eivät "oikeasti" ole siirrettävissä toiseen ympäristöön. Vaikka on helpompaa esim. siirtyä Weblogic:in käytöstä Websphereen. Väitän kuitenkin että se on kohtuullisen suuri kynnys. Esim. jos ympäristö käyttää EJB:tä, et vain voi poimia JAR:ia palvelimelta ja pudottaa sitä toiseen...
Niin vielä... Eikö juuri loppujen lopuksi ole ajateltava "loppukäyttäjän" etua. Sehän nämä sovellukset maksaa, onko todellakin sen edun mukaista että käytetään aikaa triviaaleihin asioihin? Sovellusten toimittamisen hinnoissa on kyllä aika paljon ilmaa... Tämä kun kuitenkaan ei ole mitään ydinfysiikkaa...
"Kehittäjänä sun pitäisi kyetä hahmottamaan tämä olennainen ero ilman rautalankaakin, vaikka loppukäyttäjä ei tajuaisikaan, miksi kaiken pitää olla niin vaikeaa."
Olen ymmärtänyt erään hyvin oleellisen eron, mikä on tällä hetkellä ollut molempien ympäristöjen suhteen. Opiskelin koulussa paljon javaa ja J2EE:tä ja tarkoitus oli päästä toteuttamaan opiskeltuja asioita. .Net:iä ja C#:ia en opiskellut ollenkaan. Nyt kuitenkin olen töissä sellaisessa firmassa, jossa teen hommia
.Net-ympäristössä C#:illa, eikä onnistunut saamaan mitenkään töitä java:n tai J2EE:n puolelta. Se oli tosi vaikeeta, kun haki lukuisiin paikkoihin, eikä mistään löytynyt hommia.
Jos Microsoft-maailma tarjoaa leivän pöytään, niin mikäs siinä, eikun sinne sitten ja voihan sitä vaikka kotona sitten harrastella javaa.
"Tottakai hahmotan sen että jos ostat kaiken samalta toimittajalta, niin olet aivan eri asemassa kuin avoimen ympäristössä. Mutta tarkoitan että kenen etu tämä avoin ympäristö on jos sovellukset eivät "oikeasti" ole siirrettävissä toiseen ympäristöön. Vaikka on helpompaa esim. siirtyä Weblogic:in käytöstä Websphereen. Väitän kuitenkin että se on kohtuullisen suuri kynnys. Esim. jos ympäristö käyttää EJB:tä, et vain voi poimia JAR:ia palvelimelta ja pudottaa sitä toiseen..."
Avoimien ympäristöjen kohdalla sovelusten/järjestelmien siirrettävyys toisiin ympäristöihin on pelkkää myyntipuhetta. Se on niin idealistista kuin olla ja voi. Tuskin ikinä tulee missään suhteessa toteutumaan.
Ajatellaas esim. TKHJ-ohjelmistotoimittajia, siis pitäisi olla mahdollista vaihtaa helposti SQL-standardin mukainen tietokanta toisen TKHJ-toimittajan ympäristöön. No harvoimpa kyetään tietokanta toteuttamaan SQL-standardin mukaisesti ja ko. standardi ei määrittele riittävän yksityiskohtaisesti tietokannan toteuttamiseen liittyviä asioita. Eikä TKHJ-toimittajatkaan toteuta standardia, kuin tiettyyn tasoon asti, tuskin kukaan heistä.
EJB-palvelimien suhteen tietääkseeni SUN:n J2EE-standardi antaa aika vapaat kädet. Seurauksena on kirjava joukko välineitä. Vaikka standardi määrittelisikin yksityiskohtaisemmin palvelimen toteutukseen liittyviä kysymyksiä, niin kuinkahan moni niitä noudattaa.
Avoimen ympäristön siirrettävyys on idealismia. Vastaavalla tavalla törmätään ongelmiin siirryttäessä arkkitehtuurin uudempaan versioon vaikka kyseessä olisikin ei avoin ympäristö.
Jos se porttaus on noista XML-tiedotoista kiinni, niin ei kovin pahalta kuulosta. Porttaa ensin .NET systeemisi Linux-palvelimelle, niin katsotaan sitten uudestaan.
Ihmettelen "nörtti jussi":n kommenttia !
Kun lukee mitä tahansa työpaikkailmoituksia, niin melkein joka paikassa haetaan J2EE -osaajaa.
Kokonaan toinen asia on, että jos noiden firmojen johto ymmärtäisi tekniikkaa, niin Javan käyttö vaativiin tehtäviin lopetettaisiin saman tien.
Javan huonoin puoli kun on tämä: Automaattisen muistinsiivouksensa takia (jota mm. Delphissä ei ole), ohjelmoija ei voi vaikuttaa siihen , milloin muistinsiivousajo käynnistyy. Ja kun se käynnistyy, javaohjelma ei sitten tee mitään muuta sillä aikaa kun muistinsiivousajo on käynnissä, muu toiminta palaa tauolta vasta kun se muistinsiivousajo on valmis.
Jos olet joskus ihmetellyt webbipalveluita, jotka toimivat useimmiten kohtuullisen nopeasti, mutta satunnaisesti webbiformin hyväksymisnapin painalluksen jälkeen ei sitten 30 sek - reilu minuutti ajan tapahdu yhtään mistään, ja vasrinkin, jos POST -käsittelijän URLissakin on sana "servlet" niin tiedä: kokemasi ylimääräinen viive palvelussa johtuu todennäköisimmin juuri tuosta muistinsiivousajosta.
Eli, vaikka javaa usein käytetään web-palvelimien aktiiviseen koodiin, kun halutaan webille dynaamista sisältöä, niin tosiasiassa java on täysin soveltumaton tuohon.
Tosin, eikös tuo C# ole myös ns. Managed -koodia ? Jos siinä on automaattinen muistinsiivous myös, eikö se sitten kärsi samasta ongelmasta ?
Delphillä koodatussa web -palvelussa ei ole ainakaan ohjelmasta itestään johtuvia viiveitä.
Eri asia sitten on, että jos palvelu pohjautuu tietokantaan, niin miten raskaasti ko. tietokantapalvelinta kuormitetaan ja mikä on sen kuormituskestävyys.
NetBeansilla saa aika paljon helpommin toteutettua J2EE-pohjaisen järjestelmän, JSP/JSF/Servletit, Session- ja Entity-EJB:t jne. Ei tarvitse konffata vaikeimman kautta mitään papujen asennuskuvaimia, vaan niihin on valmis väline, jolla homma hoituu helposti.
Itse tappelin Eclipse WTP:n kanssa ja usko loppui, siihen kun yritin saada aikaiseksi entity EJB-papua, tosin siitä alkaa olla jo vuosi aikaa. Voi olla, että siinäkin homma on helpottunut.
Kuitenkin NetBenassilla homma ei voisi enää helpompaa olla. Kaiken lisäksi saat siitä sellaisen välineen ilmaiseksi, jossa on mukana UML-mallinnus, integroituna sovelluspalvelin, ja sql-editori. Ko. softa menee suorastaan heittämällä koneeseen ei tarvitse mitenkään ihmeellisesti ja vaikeasti konffailla palvelimia ja homma pelittää.
Esim. .NET-maailmassa ei ole vielä toimivaa UML-mallinnusvälinettä, VisualStudio 2005:n välineellä voi vain vääntää jonkinnäköistä luokkakaavion tyyppistä notaatiota, muuta sillä ei pysty. Esim. sekvenssikaavioiden tekeminen puuttuu kokonaan.
Borlandilla on Eclipse-pohjainen väline, jonka lupasivat integroituvan VisualStudion, kuitenkin käytännössä sekään ei toimi.
Nykyään on ehdoton edellytys, että UML-mallinnusväline integroituu sovelluskehitysvälineeseen, muuten joutuu jumppaamaan, UML-kuvausten ja koodin välillä, kun päivittelee samoja muutoksia kahteen tai kolmeen paikkaan.
Siis tiivistettynä lopuksi, jos java-maailmassa homma menee liian vaikeaksi, kannattaa etsiä uudempia välineitä, siitä se on kiinni.
.Net-puolellakin joudutaan pakosti tekemään frameworkkeja, se on pakko muuten vaihtoehtona on aina pyörän vääntäminen uudestaan (siis rutiinikoodaukset). Juuri nyt opiskelen erästä asiakaskohtaista .Net-frameworkkia. Ilmeisesti näitä ei ole vielä niin paljoa, kun ko. arkkitehtuuri on niin paljon uudempi kuin J2EE.
-NetBeans on pienen start-up tms. yrityksen työkalu. Isommat pomot ei sitä hyväksy, kun ns. kaupalliset merkkituotteet kuulostaa enemmän proolta asiakkaan korvissa.
-UML on kyllä hieman ylimainostettu jutska. Sillä voi kyllä tiettyjä konsepteja kuvata esim. uusille projektiresuille ja ehkä hieman selkeyttää omaa ajatusmaailmaa. Mutta pitäisi käyttää vain konseptitasolla eli vain pääluokat ja tietyt sekvenssit. Kaikki muu dokumentointi on aivan turhaa. Korkeintaan siinä tapauksessa, jos koodista saa generoitua tai toisin päin automaagisesti.
- .Net puolella pitää käyttää Visio työkalua tähän hommaan.
Isojen pomojen mielestä kannattaa käyttää sellaisia työkaluja, joiden hankkimisesta myyjä maksaa.
Vain aloittelijat tekevät buildit IDE:llä. Kerropas miten esim. laitat pystyyn jatkuvan integraation ja nightly buildit automatisoidulla testipatteristolla, jos teet buildit vain IDE:llä?
En tiedä, eikä kiinnosta. On tavallaan ihan oikein että juuri sinunlaisten "nipanäsien" työpaikat siirtyvät Intiaan. Koodaaminen kuitenkin on ns. perushommaa mikä voidaan ulkoistaa. Onnea valitsemallasi tiellä...
Juuri tuollaiset "emmä osaa eikä kiinnostakaan"-nipanysät potkaistaan ihan ensimmäisenä ulos ennenkuin mitään offshore-hommia edes harkitaan.
Te helvetin näsäviisaat nörtit kun ette ymmärrä että asiakasta joka tilaa järjestelmän teiltä ei kiinnosta kuinka montaa kolmikirjaimista lyhennettä siinä käytetään, vaan että se toimii! Mitä valitettavasti ne eivät todellakaan aina tee. IT-ala on ainoa ala missä valtaosa kehitysprojekteista epäonnistuu tai myöhästyy. Ja kun koodaminen ei kuitenkaan ole mitään ydinfysiikkaa niin koodareitten tulisi ottaa vähän nöyrempi asenne ja havaita se että asiakas todellakin on aina oikeassa. On naurettavaa että yksinkertainen järjestelmä maksaa 40 - 50 tuhatta euroa. Vaikka kuinka haluaisit niin että ole järin fiksu, johan sen sun kirjoitusten tasosta huomaa...
Ja tiedätkö mikä siinä järjestelmässä maksaa? Niitten näsäviisaiden nörttien palkat. Miksi et itse tee parempaa järjestelmää 35 k€:lla kaikille halukkaille ja tule todella rikkaaksi? Miksi pitäisi olla nöyrä, jos voi kerrasta toiseen toimittaa epäonnistuneita & myöhästyneitä projekteja tupla liksalla sun keskiverto ydinfyysikkoon verrattuna.
Purkauksesi perusteella vaikutat yhdeltä niistä asiakkaista, jotka pokkuroivat kehittäjille projektista toiseen ja itkevät sitten selän takana, kuinka paskaa koodia taas tekivät. En ole vielä urallani tavannut asiakasta, jolla olisi ollut rahkeita päin naamaa protestoida laadusta. Saattaisi jäädä seuraavakin projekti tekemättä.
Sano seuraavalla kerralla näsäviisaalle nörtille päin naamaa suorat sanat, vai riittääkö sisusi ainoastaan täällä palstalla uhoamiseen. Kerro sitten meille kuinka it-projektisi etenee, kun nörtti kävelee ovesta suoraan kilpailijasi projektiin.
Niiden näsäviisaiden nörttien palkat tosiaan maksaa... Se johtuu monesta asiasta, myös siitä että asiakas ei hoida hommaansa kunnolla. Jolloin nörtit joutuvat päättelemään mitä haluavat.
Kyllä minä uskallan sanoa kehittäjille päin naamaa jos sovellus/järjestelmä ei vastaa mitä on sovittu. Mutta ihan vaan vinkkinä, kyllä niitä nörttejä riittää. Mikäli et satu tietämään niin ei Suomessa pahemmin ole pulaa IT-palveluntarjoajista. Tietenkin voi olla että järjestelmä voi olla vaikea siirtää toiselle IT-palveluntarjoajalle, koska ne nörtit eivät ole tehneet työtään kunnolla ja ovat jättäneet dokumentoinnin ja mallintamisen (tai ainakin sen päivittämisen) väliin. Kunnon ohjelmistoprojektin tulisi myös sisältää nämä.
Sinun kannattaisi katsoa peiliin, en tiedä missä työssä olet... (Pidetäänkö sinua jossain kellarissa) Mutta kun olin toimittajana niin kyllä asiakkaat kommentoivat aivan vapaasti ja samalla tavalla aioin toimia itsekin. Esimerkiksi jos teemme sopimuksen WM:n tai TE:n kanssa ja sovellus ei vastaa sitä mitä sopimuksessa sanotaan niin kyllä aivan varmasti kommentoin sitä. Jos joku näsäviisas räkänaama nörtti vetää siitä herneen nenään niin se on lähinnä sen ongelma, kun emme ole palkannut juuri sitä räkänaamaa tekemään kyseessä olevaa projektia. Se on toimittajan ongelma jos palkkaavat niin hienohipiäsiä nörttejä että vetävät herneen nenään pienemmästäkin kommentista. Kyllä niitä nörttejä riittää Intiassa ja Kiinassakin. Kokemuksen perusteella voin sanoa että niillä ei ole noussut kusi läheskään noin palkoa päähän. (Monessa projektissa nörttejä on lennätetty Intiasta)
Asia on rinnastettavissa autonkorjaajiin. Useimmiten nekin ovat vittumaisia koska asiakas ei tiedä asiasta pahemmin mitään... Ainoa erotus on että auton vieminen ulkomaille korjaukseen on kohtuu kallista, softan ei...
Toistaiseksi on Suomessa myös töitä riittänyt aivan riittävästi ja jos ei riitä niin aina voi ryhtyä masentuneeksi ja alkaa viettää eläkepäiviään. Joten sun vaahtoaminen ei mua liikuta pätkän vertaa. Niin kauan kuin sinä ja minä asumme Suomessa, sinä elätät minut joko palkan tai tukien muodossa. Kumpikin käy mulle. Tuet ovat kyllä alhaisia, mutta eipä tarvi aamuisin toimistolle raahautua. Että siinä sulle elämän reaaliteetteja.
Luuletko tosiaan, että töiden valuminen Intiaan on isokin painajainen. Jos intialaiset haluavat koodata sulle kympillä päivässä niin ei käy ihtään heitä kateeks. Aina sitä ennemmin työttömyyspäivärahalla elää, kuin Intiaan muuttaa sun ehdoilla koodaamaan. Eli voit vaikka kuinka ruikuttaa huonosta työstä tai asenneongelmasta, sinun tai sun kavereiden mielipide ei tee mulle kesää tai talvea.
"Miksi et itse tee parempaa järjestelmää 35 k€:lla kaikille halukkaille ja tule todella rikkaaksi?"
Kerropa minullekin, mikä on sellainen sovellus, jolle on niin paljon kysyntää, että jos sellaisen koodaan, saan sitä helposti myytyä 35000 €/kpl useita kappaleita?
Jos tuon tiedät, niin tulisitko myyntimiehekseni jos koodaan tuollaisen?
Mieluummin nimittäin itse keskittyisin kokonaan koodaukseen, ja sinä voisit hoitaa tuon systeemmin myynnin.
Teknisistä yksityiskohdista toki voin keskustella puhelimessa, hinta fiksulle soittajalle 7 senttiä/min 10 sentin aloitusmaksu/puhelu.
Tyhmät soittelijat voivat sitten maksaa paljon enemmänkin, jos eivät halua hyödyntää edullista vaihtoehtoa soitteluun.
Jos haluat ottaa yhteyttä, puhNroni löydät 2 klikkauksen takaa.
Visual Basiciahan ei enää oikeastaan ole vaan
VB.NET joka on olio-ohjelmointikieli.
Tosin C# hakkaa mennen tulleen VB.NET:n. Ja taitaa
olla tai ainakin joskus oli niin että VB.NET käännettiin ensin C#-koodiksi ja siitä sitten vasta bytekoodiksi.
Ei Ant Java-puolella "kaikkea" tee, esim. jos puljaat EJB:den kanssa niin tarvit XDocletin.
Totuus EJB:stä lienee se, että perussorsa pitää aina generoida stubeineen ja kääntää kun vaihtaa
sovelluspalvelinta. Siinä se koodin siirtyvyys.
Tuli tätä seuratessa mieleen yksi sovellus, joka on tehty MySQL:llä, Monolla ja Linuxilla, mikä on ollut oikea ratkaisu, koska pesuvoimaa tarvitaan vähän tavanomaista enemmän.
Sanotaan nyt näin, että pienissä sovelluksissa voi käyttää Javaa tai Microsoftin tuotteita :-)
kuinka paljon tuo sovellus vaati rautakomponentteja? Servereitä, verkkopalikoita, yms.