Yleistä keskustelua webdevauksesta

[goldenscan]

Huomasin minuutin testin aikana pienen bugin. Sain pienen suoran luvuilla 2,3,4,5,5

Tuo neljän nopan pieni suora on sääntömuunnelma ei bugi, näin ainakin luulisin.

Joo kyllä tuo sääntöjen mukaan meni, Suomessa myytävässä Yatzyssä on vähän erilaiset pisteytykset kuin tuossa alkuperäisessä Yahtzeessa. Säännöt löytyy tuolta alakulman napin takaa

Hieno peli. Mutta tässä riittää pohdittavaa:

Kiitos, hyviä kehitysideoita, täytyypä tutkia noita mainittuja tekniikoita ja katsoa mitä saa aikaiseksi.

Kiitokset muillekin palautteesta!

 

[©©©]

Hyvältä näyttää, tässä oma versioni, ei ihan loppuun asti hiottu. Tehty täysin vanilla-javascriptillä. Ulkoasussa hyödynnetty hieman Materialize.css
http://yatz.aittis.com/

Tässäkin vähän säännöt ovat omat, eli 4 samaa ei ole normisäännöissä myös kaksi paria vaan kaksi paria pitää olla kaksi eri paria esim. 2x2 ja 2x3, ei 4x2

 

[aittis]

Tässäkin vähän säännöt ovat omat, eli 4 samaa ei ole normisäännöissä myös kaksi paria vaan kaksi paria pitää olla kaksi eri paria esim. 2x2 ja 2x3, ei 4x2

Totta

 

[Fanboys Suck]

- serveriyhteys voisi olla esim. websocketien päässä, jolloin kommunikointi "käyttäjä heitti noppia" --> "serveri palauttaa arvot" olisi jouhevaa (esim. http://socket.io)

Miten se olisi jouhevampaa kuin jquery/JS/ajaxilla? Tuskin tarvitaan mitään kovin reaaliaikaista yhden json elementin siirtoon. Opettelumielessä tietty sitten eri asia.

- highscore listauksen voi palauttaa esim. JSONina, joka haetaan `fetch()` APIa käyttäen (vaatii tosin polyfillin osalle selaimista). Tällöin ei tarvita serverikutsuja varten esim. jQuerya.

Sama juttu, jquery on ihan riittävä.

- jokaisella on mieltymyksensä serveripäästä, mutta itse suosin node.js:ää, joka taipuisi tähänkin tapaukseen todella nopein kääntein.

serveripäähän riittää nopanheittoon ja higscorelistaan melkein mikä tahansa, omasta kokemuksesta tai halusta oppia jotain uutta se on kiinni mielestäni enemmän. Ties vaikka Noden kanssa pitää asentaa grunt ja joku math library että saan RND:n käyttöön. Lopputulema että serveripuoli onkin yhtääkkiä 60 megaa ja joku pakettimanageri ja muut rönsyt päälle.

 

[Zvona]

Miten se olisi jouhevampaa kuin jquery/JS/ajaxilla? Tuskin tarvitaan mitään kovin reaaliaikaista yhden json elementin siirtoon. Opettelumielessä tietty sitten eri asia.

Mmjoo.. hahmottelin ideaa opettelemisen sekä mahdollisen moninpeliaspektin näkökulmasta. socket.io on todella simppeli (luo huone, pub/sub eventit ja loppu hoituu itsestään)

Sama juttu, jquery on ihan riittävä.

jQuerystahan taitaa saada irrallisia paketteja ulos, joten pelkän ajax:in käyttöönottaminen lienee ihan mahdollista. Tosin en näe syytä, miksi ei käyttäisi standardia, joka nyt ei vain jostain syystä ole jalkautunut IE:hen (siksipä polyfill).

serveripäähän riittää nopanheittoon ja higscorelistaan melkein mikä tahansa, omasta kokemuksesta tai halusta oppia jotain uutta se on kiinni mielestäni enemmän. Ties vaikka Noden kanssa pitää asentaa grunt ja joku math library että saan RND:n käyttöön. Lopputulema että serveripuoli onkin yhtääkkiä 60 megaa ja joku pakettimanageri ja muut rönsyt päälle.

Noden kanssa riittää tässä tapauksessa Express tarvittavien endpointien mappaamiseen. Enkä näe, että serveripuoli paisuisi ainakaan tässä tapauksessa. Eniten ehkä rummutin tässä JS:n käyttöä, kun se kerran tuntuu luonnistuvan OP:lta.[/QUOTE]

 

[Fanboys Suck]

jQuerystahan taitaa saada irrallisia paketteja ulos, joten pelkän ajax:in käyttöönottaminen lienee ihan mahdollista. Tosin en näe syytä, miksi ei käyttäisi standardia, joka nyt ei vain jostain syystä ole jalkautunut IE:hen (siksipä polyfill).

Jquery on varsinkin minifoituna pakettina aika pieni verrattuna moneen muuhun frameworkkiin nykyaikana. Se tulee mm. bootstrapin kylkiäisenä. Eli sen palvelut saa useimmiten "ilmaiseksi". Eikä jonkun ajax funtion kirjoittaminen pelkällä javascriptilläkään mikään kummoinen homma ole.

Ja expressin tarvitseminen noden oheen jonkun json tiedoston lähettämiseen/tallettamiseen "proves my point" Samantien asentaa sitten vaikka dreamfactoryn ja tekee apista alustariippumattoman kun tarvii jatkossa skaalata ja varautua eri varastointisysteemeihin tai tehdä seuraava angry-jatsi mobiileille laitteillekin

Tarkoituksenani ei ollut kritisoida ehdotuksiasi sinänsä. Mielenkiintoisia tekniikoita, ja jos JS:n opettelu myös serveripäässä kiinnostaa tai on muuten intresseissä niin nuo on niitä peruspalikoita mitkä tulee varmasti jossain välissä vastaan.

http://tilde.town/~snoopy/

 

[Merri]

Jos tässä vaiheessa alkaa opetella devaamista frontin puolelle, niin kannattaa suoraan panostaa uusimpien standardien opetteluun. On melkein turhaa opetella jQueryä, joka on toki hyödyllinen, mutta väistämättä myös jo vanhan koulukunnan juttuja. jQueryllä on vaikea toteuttaa ylläpidettävää koodia suuremmissa projekteissa, koska se keskittyy enemmän kivan API:n tarjoamiseen kuin siihen, että se ratkaisisi konkreettisia kehittämisen ongelmia isommassa mittakaavassa. Joten: fetch, ES6, ES7, natiivi DOM, keskittyminen niihin selaimiin jotka jo tarjoavat uusimpia ominaisuuksia suorilta. Nykyään ainut selain joka tosissaan matelee vastaan vanhankaltaisuuttaan on IE11 ja jos et ole tekemässä yritysasiakkaille, niin on aivan turha aiheuttaa itselleen päänsärkyä opettelemalla sen kankeuksia (muutoin kuin huvin ja haasteen vuoksi). Standardien opettelu taas ei mene hukkaan, koska ne ovat pysyviä. Kirjastot, frameworkit ym. taas viuhuvat lyhyemmällä elinkaarella. jQueryä on toki käytössä internetissä todella laajalti, mutta jos tähtäimessä ei ole alkaa Simppelit Sillipurkit Oy:n ja muutaman tusinan muun pikkufirman alaiseksi purkkakoodidevaajaksi, niin tähtäin ehkä kannattaa sojottaa muualle.

React on tällä hetkellä aika selvä tämän hetken "voittaja", koska sillä on mahdollista kehittää isoa ohjelmistoa niin, että tila pysyy hallinnassa (varsinkin jos avuksi ottaa vaikka Reduxin). Sen opettelu on hyvää jo siitä syystä, että se opettaa kuinka arvokasta ja hyödyllistä tilan kulkeminen yhteen suuntaan on. Plus miksi on todella hyvä asia, että sama inputti tuottaa aina saman lopputuloksen. Reactiakin toki voi käyttää väärin, mutta pääosin kaikki oppaat ym. kannustavat oikeisiin asioihin. JSX on myös tosi hieno asia, koska yleensä JavaScriptiä kirjoittaessa HTML on tavallaan turha taito, mutta JSX:n kautta konteksti pysyy selkeämmin käsissä. Vielä kun maltti riittäisi aina siihen, että tekisi aina riittävän pieniä ja atomisia komponentteja.

Alkuperäiseen Angulariin ei tosiaan enää kannata käsiään sotkea. Ja se on muutenkin vähän semmoinen... hmmh, sanoisinko bäkkärikoodareille suunnattu fronttiliittymä. Se on myös todella hankala oppia, koska päätään saa hakata tovin jos toisenkin, että ymmärtää mitä varten mikin palanen on olemassa. Karkeasti: menee liikaa aikaa frameworkin opetteluun ja liian vähän aikaa todellisten ongelmien ratkomiseen. Ilmeisesti Angular meni hyvin läpi erityisesti niissä piireissä, joissa sen tarjoamat abstraktiot muistuttivat bäkkäripuolelle toteutettavia vastaavia. Mutta pääpiirteittäin Angularin juna meni nelisen vuotta sitten. Uudet projektit tehdään jollain ihan muulla.

Mitä taas Node-puoleen tulee, niin ensi vuoden aikana saatetaan ehkä vihdoin päästä riittävän selkeään ja helppoon kokonaisuuteen sen osalta. Kaikki sen ympärillä on ollut niin kiivasta ja kun sopassa on vielä ollut kehittyvä Babel ja Webpackit sun muut tuoreehkot ratkaisut korjaamaan ongelmia tai tuomaan uutta teknologiaa tarjolle aiemmin, niin ei ole ollut kauhean helppoa pysyä kärryillä asioista. Nyt selaimissa alkaa olla uusien standardien tukia ihan suorilta, mikä vähentää polyfillauksen ja transpiloinnin tarvetta merkittävästi; kenties Babel on turha 2018/2019. Aika näyttää.

Kärryillä pysymiseen auttaa kuitenkin yksi vanha hyvä neuvo: keskity yhteen asiaan kerrallaan. Helpottaa oppimista huomattavasti oli asia mikä hyvänsä. Ihminen ei ole kovin hyvä moniajaja.


Lopulta fronttikehittäminen ei ole pelkästään sitä, että lykkää kasaan läjän JavaScriptiä, joka kontrolloi DOMin kautta sitä mitä ruudulla näkyy. Frontti tarjoaa myös asioita, joita muut palvelut käyttävät hyväkseen: on hakukoneet ja sosiaaliset mediat. Sitten on toisaalta erikoisempia tapauksia kuten ruudunlukijat ja selainten natiivit toteutukset mm. näppäimistöllä selaamiseen, jotka yleensä unohdetaan helposti tai joita ei peruskehittäjät edes ajattele, mutta joiden huomiointi hyvällä tavalla tuppaa jännästi myös aiheuttamaan sekä paremman HTML:n kirjoittamisen että etuja hakukonenäkyvyydessä - ja käytettävyyskin kohenee joskus kun oppii huomioimaan asioita, jotka eivät näy päälle päin. Lopultahan on sitten vielä nämä universaalit JavaScriptit eli saman koodin ajo selaimessa että palvelimella, sekä mukautuva (responsiivinen) kehittäminen, jotka ovat omia mukavia monimutkaistajiaan. Löytyy paljon asioita pohdittavaksi jos tahtoo todenteolla erikoistua fronttipainotteisesti webdevaukseen.

 

[Carcha]

Nopeasti liikkuu tämä alue ja täällä päässä on tilanne sellainen, että leipätyönäni hakkasin vaniljaista JavaScriptiä ja jQueryä (HTML5+CSS3 rinnalla toki) pidemmänkin aikaa, kun niillä vielä pärjäsi. Tähän pienenä lisänä se, että työelämässä olemassaolevat järjestelmät olivat luokkaa "kukaan ei ikinä maksa edes osaa tämän mastodontin refaktoroinnista", jolloin uusien fronttiteknologioiden käyttöönottamien oli semisti haastavaa. Aina silloin tällöin jokin valonpilkahdus tuli, joka salli jonkin uuden oppimisen työn puitteissa ilman, että sen lisäämisellä jo-olemassaolevien kirjastojen kylkeen oli valtava impakti sivuston suorituskykyyn selaimen päässä.

Uusien kikkareiden perässä on tullut juostua pidemmän aikaa ja aina johtopäätös on se, että uusi teknologia, kirjasto tai framework on opittava vapaa-ajalla, kun työympäristö ei enää oikein salli tällä saralla kehittymistä siinä kahdeksan tunnin aikaikkunassa, mikä päivästä löytyy. Ja jotta tämä kahdeksan tuntia päivässä muuttuisi vielä haastavammaksi, olen päässyt / joutunut tehtäviin, jossa käsienheiluttelu ja tiiminvetäminen vie lähes kaiken ajan tekniseltä työltä. Onneksi suuntautuminen ei ole koskaan ollut pelkästään frontin suuntaan - viimeaikoina vapaa-ajan aktiviteetit ovat pitäneet sisällään termejä kuten Vagrant, Ansible ja Docker. Hieman toiselta kantilta lähestytään siis. Sen ovat saaneet tuntea myös kotona majailevat pavelinkoneet.

Koska tiedonjano ei nimenomaan rajoitu vain yhdelle verkkosovelluksien osa-alueelle, on varsin hankalaa keskittyä vapaa-ajallaan vain yhteen uuteen juttuun pidemmällä aikajänteellä, jotta saisi kiinni sen, mitä työn parissa ei pysty sisäistämään. Toki viisihenkinen perhe saattaa tähän myös vaikuttaa.

No, vielä kun alle kolmekymppisenä aivot toimii ja uudet temput on opittavissa, on nykyinen työ pistettävä vasaran alle ja laskettava verkkoja vesille, mitä tässä on jo varovaisesti tehtykin. Ei riitä kellossa tunnit eikä kalenterissa illat kaiken uuden oppimiseen ainoastaan vapaa-ajan puitteissa. Nimittäin tällä menolla jää allekirjoittaneen tekninen kyvykkyys frontin saralla armotta menneisyyteen ja suunta on ainoastaan jonkin korporaation keskijohtoon, jossa powerpointtien vääntäminen ja sähköpostipalvelimena toimiminen oikeuttaa jokuseen kiloeuroon kuukaudessa. Ei kiitos.

Fiilikset ovat tämän artikkelin mukaiset: https://hackernoon.com/how-it-feels-to-learn-javascript-in-2016-d3a717dd577f#.pa7tz46av

Erittäin hyvin sanottu siellä perällä.

 

[Paapaa]

On melkein turhaa opetella jQueryä, joka on toki hyödyllinen, mutta väistämättä myös jo vanhan koulukunnan juttuja. jQueryllä on vaikea toteuttaa ylläpidettävää koodia suuremmissa projekteissa, koska se keskittyy enemmän kivan API:n tarjoamiseen kuin siihen, että se ratkaisisi konkreettisia kehittämisen ongelmia isommassa mittakaavassa.

Avaatko tätä vähän. Millä tavalla ja millaisissa tilanteissa jQuery haittaa ylläpidettävän koodin kirjoittamista? En muutoinkaan ymmärrä, miksi jQueryn perusteita ei kannattaisi opetella. Näppärä kirjasto moneen pikkuasiaan ja hyvin helppo opetella ainakin peruskäyttö. Äärimmäisen yleinen ja moni kirjasto nojaa sen käyttöön.

Vaikea uskoa, että yksikään webdevaaja voisi olla käyttämättä ikinä jQueryä mihinkään.

 

[©©©]

Jep, täällä käytetään jQueryä joka päivä...

 

[Merri]

jQuery ei itsessään haittaa ylläpidettävän koodin tekemistä, enemmän kai ongelma on siinä, ettei se myöskään kannusta siihen. Toinen asia johon jQuery ei ota mitenkään kantaa on tilanhallinta ja se on usein varsin hähmäisesti toteutettu. Yleensä kun vaikka törmään johonkin joka tekee transioita ja sitten hajoaa kun en käyttäjänä toimi kuten devaaja on olettanut (eli alan vaikka vähän rämpätä nopeammin kuvia galleriassa), niin taustalla on jQueryllä toteutettu ratkaisu. Tila vaan ei pysy hanskassa.

Nopeina käytännön esimerkkeinä löytyy vaikka Oikotien kuvagalleria, joka muistaakseni aiemmin hajosi tyystin jos sitä alkoi rämpätä. Nykyisellään se vaan joko pistää transitiot lineaarisesti putkeen (eli jää pahasti käyttäjän toimista jälkeen) tai sitten jättää huomiotta käyttäjän tekemän muutoksen jos kuvanvaihto tapahtuu kesken transition. Jimm'sin galleriassa taas jos klikkaat nopeasti pari kuvaa lävitse, niin kuvan päälle ilmestyy ja jää pyörivä pylpyrä. Toki nämä ei ole jQueryn itsensä mokia vaan devaajan osaamattomuuden seurausta, mutta toisaalta myös osoitus siitä, ettei jQuery pyri ratkaisemaan ongelmaa.

Lisäksi jQuery tehtiin alkujaan näppärän API:n lisäksi tarjoamaan ratkaisu selainten epäyhteneväiseen käyttäytymiseen. Nykyisin vaan selaimet toimivat jo hyvin yhteneväisellä tavalla. Polyfillaustakaan ei tarvitse enää tehdä aivan niin paljon kuin vielä jokunen vuosi takaperin ja tilanne paranee kokoajan. En vain näe enää syytä jQueryn käyttämiseen kun fetch on paljon parempi ratkaisu kuin XHR tai jQueryn ajax ja toisaalta Reactin toimintatapaan tutustuneena jQueryn tapa tehdä asiat tuntuu vähän siltä kuin puukottaisi DOMia.

Esimerkiksi vaikka alkuperäisen tilan palauttamiseen tarvitsee jQueryllä kirjoittaa koodi erikseen kun Reactilla vaan vaihdetaan kahden (tai useamman) eri renderin lopputuloksen välillä. jQueryn kanssa on usein alkuperäinen HTML, muutos toiseen tilaan, muutos takaisin alkuperäistä HTML:ää vastaavaan tilaan. Jos muutat alkuperäistä HTML:ää, niin tarvitsee myös erikseen muistaa muuttaa jQueryn tilanmuutoskoodit. Reactilla tätä ongelmaa ei ole, koska sekä alkuperäinen tilanne että muutos tapahtuu samasta renderistä. Tämä vähentää merkittävästi riskiä sille, että devaaja tekee moan, kun taas jQueryn kanssa ei ole kovinkaan epätavanomaista, että joku käy muuttamassa HTML:ää eikä muista, että siihen saattaa liittyä jQuery-koodia. Tämmöisiä hajoamisia on tullut korjattua moneen otteeseen; olen verrattain iloinen siitä, ettei töissä ole enää PHP:lla renderöityjä sivuja, joihin tehdään tilamuutoksia jQueryllä

 

[Merri]

Vielä jatkona voisi oikeastaan kai todeta, että jQueryllä pääsee nopeasti toteuttamaan asioita ja se on helppo heittää projektiin kuin projektiin mukaan, mutta jos jo ennalta on tiedossa, että projekti tulee olemaan pitkäkestoinen eli sen parissa vietetään vuosia, niin silloin aloittamisen ketteryyttä kannattaa korvata enemmän työtä ja ajatusta vaativilla, mutta pidemmän päälle hyvää kokonaisarkkitehtuuria ylläpitävillä ratkaisuilla. Yleensä siis hyvä nojautua mm. standardien käyttöä puoltaviin ratkaisuihin ennemmin kuin hienouksiin ja helppouksiin.

Yhtenä esimerkkinä näiden asioiden miettimisen tärkeyttä korostaakseni voisin heittää, että kerran yksi projekti pykättiin konsulttien työstämänä todella nopeasti pystyyn: ensimmäinen jokseenkin yleisölle esittelykelpoinen versio saatiin kolmessa kuukaudessa linjoille. Tekniset ratkaisut eivät kuitenkaan olleet ylläpidettäviä: kieleksi oli valittu CoffeeScript, paradigmaksi funktionaalisuus mallia Bacon ja fronttia mulkutettiin jQueryllä. Lisäksi Reactia käytettiin ilman JSX-tukea (tai siis CoffeeScriptin tapauksessa CJSX).

Oikeastaan kukaan muu kuin konsultit eivät tienneet mitä koodi teki, koska CoffeeScript on luoteeltaan hauskaa kirjoittaa, mutta sen lukeminen jälkikäteen tai toisen henkilön toimesta on erittäin hankalaa, koska se pyrkii tuomaan luonnollista kieltä maailmaan, jossa yksiselitteisyys on haluttava asia. Baconia taas käytettiin siihen, että toimittiin Reactin toimintatavan vastaisesti: Reactissa propsien pitäisi valua päätason komponenteista sisempiin komponentteihin, mutta Baconista käytettiin Busia siihen, että sisempien komponenttien tila hallitsi päätason komponenttien rendausta. Tämän kanssa saa jo aikamoisesti veivata aivojaan, varsinkin kun noita Busin kyhäämiä streameja mulkattiin komponentista toiseen, jolloin oli hankala ymmärtää missä muodossa tila kulki. Lisäksi sitten aina kun Reactin renderöimä lopputulos ei miellyttänyt, niin oli heitetty jQueryä kehiin! Tällä "paikattiin" Reactin rendausta, mikäli tämä ei sattunut vastaamaan haluttua lopputulosta. Toki XHR-pyynnöt myös tehtiin jQueryn avustuksella.

Tämän ihanan projektin tila oli ensikuukautensa aikana sellainen, että jos sivun jätti selaimeen yöksi auki, niin aamulla töihin tullessa koneesta oli syöty melkein kaikki vapaa muisti

 

[mopnex]

Aika laaja alue tässä käsittelyssä. Perusteista on kuitenkin paras aloittaa jos on nyt pyrkimässä alalle. Netti on täynnä hyviä (ja toki huonoja) resursseja, näistä voisi mainita Udacityn tietyt kurssit (Googlen), Codeschool jne... Tärkeämpää kuin tietty osaaminen tietyn frameworkin ympärillä on kasvattaa ymmärrystä siitä, että miksi asiat on tehty miten ne on tehty. Tähän vaaditaan se, että pohjalla on tuntemusta ihan JavaScriptistä, DOMista ja siitä miten selaimet toimivat (parsing, render, paint jne...). jQueryn ohi on ehkä aika osittain ajanut, kun samoja DOM manipulaatiota voidaan suorittaa paremminkin. Nykyään tarve jQueryn valtille, eli yksi API kaikille selaimille, on vähenemään päin. Jos JavaScript ymmärrystä on, jQuery on vain yksi, tosin isohko, kirjasto siihen kylkeen.

Itse olen työkseni tehnyt näitä hommia viimeaikoina enimmäkseen React+ Redux + ES6/TypeScript kombolla. AngularJS on tullut myös käytettyä vuosia sitten, mutta myös jQueryä. Angular olen myös käyttänyt ihan tuotannossa (eli "angular 2" monelle, vaikka tuo 2 on vain versionumero). Itse teen myös hieman hommia rajapintojen parissa, joten backend devauksestakin on kokemusta. Aika laaja-alaista osaamista pitää olla, ymmärtää eri päätelaitteet ja eri käytettävyysasioita sekä saavutettavuuspuoli. Backend devailussa tuo on taas eri suuntaista, mm. integraatioiden suuntaan jne...

Tällä hetkellä oma mielenkiinto on enemmän funktionaalisessa suunnassa. Elm kieli on tullut tutummaksi, ja aina vakiona kaikessa mukana ramda. inferno vaikuttaa myös hyvältä kirjastolta, ja siihen kun ottaa kirjastoja sopivasti niin pääsee aika hyvällä mallille (mm. ramda). Itse en allekirjoita Angular "2" monimutkaisuutta, React + React Router/Router5/... + Redux/Mobx on vähintään yhtä mutkikas alkuun. Noiden yhteen naittaminen myös vaatii enemmän tuntemusta. Angular tekee myös taustalla erittäin hienostuneita asioita, joiden itse toteuttaminen veisi aikaa. Eli valitse tarpeen mukaan. Angular on myös suosittu, tämä vuosi on käännevuosi siinä että sitä myös otetaan laajemmin käyttöön. Google myös käyttää sitä sisäisesti ja ulkoisesti, toisinkuin aiemmin täällä virheellisesti sanottiin. Ensimmäiset Angular projektit tulivat Googlelta jo kun Angular oli betassa mm. Google Fiber -sivusto.

Mitä siis itse suosittelen:

• JavaScript ES6 / ES2015 osaamista
• Eri JavaScript ohjelmointimallit pintapuolisesti
• Testaaminen, tämä muutti omaa ajattelu tapaa => ratkaisut ovat parempia kun ne ovat helposti testattavia
• HTML, CSS taitto
• CSS paradigmat
• Selain (DOM, paint, render jne...) ei niinkään eri selainten erot (koska tämä puoli kaventuu eniten ja nopeiten) - perusperiaatteet pysyvät
• Joku kirjasto, yrittää ymmärtää miksi näin on tehty? Esim. inferno/preact/react
• ...

Listaa voisi jatkaa loputtomiin. Alkuun pääsee helposti, mutta JavaScript on kielenä yksi mutkikkaimmista erilaisten poikkeusten ja erikoisuuksien takia. Ylläpidettävyys on yksi tärkeä tekijä myös oikeissa projekteissa, mistä asiakas maksaa rahaa. Myöskään projekteissa ei voi sooloilla. Itse mieluusti käyttäisin Elmiä, mutta realiteetti on se että ei sitä yksin sanella. Tiimin päätös.

 

[©©©]

Mites toi Angular 2? Katsoin siitä videon ja toihan on ihan pätevän näköinen framework. Erityisesti pidän siitä miten servicet on toteutettu pelkällä luokalla ja komponenttisysteemi näytti selkeältä tyyppeineen. Tässä tämä video: Angular 2 In 60 Minutes - YouTube

 

[Zvona]

Oikeastaan kukaan muu kuin konsultit eivät tienneet mitä koodi teki, koska CoffeeScript on luoteeltaan hauskaa kirjoittaa, mutta sen lukeminen jälkikäteen tai toisen henkilön toimesta on erittäin hankalaa, koska se pyrkii tuomaan luonnollista kieltä maailmaan, jossa yksiselitteisyys on haluttava asia. Baconia taas käytettiin siihen, että toimittiin Reactin toimintatavan vastaisesti

Ymmärrän tämän. Ja voin melkein arvata, että minkä firman konsultit ovat kyseessä .

Mutta itsekin Baconiin törmänneenä, funktionaaliset kielet vähän huonosti hallitsevana, olen ollut konsulttina melko solmussa _jo kirjoitetun koodin_ osalta. Ei siinä auta kuin koputella kollegaa olkaan ja todeta, että "mä en nyt tajua mitä tämä `myObject.flatMapLatest(() => {...}).throttle(number).filter(() => {...}).merge(value)` loppujen lopuksi tekee. Tämän vuoksi olen oppinut välttelemään myös esim. Cycle.js:ää, vaikka sinänsä pätevä tekele on kyseessä.

Lisäksi tuo "koodin kuorruttaminen" on monessa projektissa pienoinen ongelma etenkin, jos devaajat vaihtuvat kesken matka. Kun aloitetaan jQuerylla ja päädytään sen hetkiseen bleeding edgeen, niin silloinhan sen jQueryn pitäisi kadota koodista kokonaan. Refaktorointi tuntuu (testauksen lisäksi) kuitenkin kammoksuttavan etenkin asiakkaan päätä, joten sellainen "nyt tarvitsee 10htp siihen, että vain kirjoitellaan asioita uusiksi tulevaisuuden ylläpidettävyyden vuoksi" ei naposta.

Ja kuten on todettu, niin web-/mobiili-devaamisen hallitsemisen lista on loputon. Itse olen luonteeltani "learning by doing" ja esim. React upposi minuun tekemisen myötä kuin veitsi voihin. Samat asiat tulivat tutuiksi päivässä, parissa kuin katselemalla eggheadin videoita viikon verran. Näin siis omalla kohdallani.

 

[mopnex]

Mites toi Angular 2? Katsoin siitä videon ja toihan on ihan pätevän näköinen framework. Erityisesti pidän siitä miten servicet on toteutettu pelkällä luokalla ja komponenttisysteemi näytti selkeältä tyyppeineen. Tässä tämä video: Angular 2 In 60 Minutes - YouTube

Angular (AngularJS vs. Angular) on hyvä. 2 viittaa versionumeroon, ja Angular 4 on tulossa kohtapuoliin (tällä hetkellä betassa). Observer-patterni ja streamablet tuossa ainakin tulee tutuksi. Paljon asiaaa kerralla, mutta ei huono. Jos malttaa tehdä TypeScriptiä myös siten, että tyypittää omatkin juttunsa hyvin, niin kyllä tuolla projektin jos toisenkin tekee.

 

[Fanboys Suck]

Vielä jatkona voisi oikeastaan kai todeta, että jQueryllä pääsee nopeasti toteuttamaan asioita ja se on helppo heittää projektiin kuin projektiin mukaan, mutta jos jo ennalta on tiedossa, että projekti tulee olemaan pitkäkestoinen eli sen parissa vietetään vuosia, niin silloin aloittamisen ketteryyttä kannattaa korvata enemmän työtä ja ajatusta vaativilla, mutta pidemmän päälle hyvää kokonaisarkkitehtuuria ylläpitävillä ratkaisuilla.
Reactissa propsien pitäisi valua päätason komponenteista sisempiin komponentteihin, mutta Baconista käytettiin Busia siihen, että sisempien komponenttien tila hallitsi päätason komponenttien rendausta. Tämän kanssa saa jo aikamoisesti veivata aivojaan, varsinkin kun noita Busin kyhäämiä streameja mulkattiin komponentista toiseen, jolloin oli hankala ymmärtää missä muodossa tila kulki.

Miten tämä Reactin "väärä" käyttö erosi jQueryn väärästä käytöstä? Olisiko lopputulos ollut selkeämpi ja helpommin hallittava jos olisi käytetty PHP jQuery yhdistelmää? Yksi asia minkä olen sisäistänyt tässä vuosien mittaan on se, että tee sillä mikä soveltuu parhaiten tehtävään ja millä saat laadukkainta jälkeä, älä sillä mikä sattuu olemaan päivän muotisana.

 

[Merri]

Sanotaanko että tekijöiden into ei takaa tekemisen laatua

Tuon projektin tapauksessa meni monta muutakin asiaa pieleen; oikeastaan ainut hyvä asia alussa oli se, että päästiin tuotantoon ja saatiin Node pyörimään pannuilla. PHP + jQuery olisi ollut tuttu ratkaisu, mutta en usko että kaikkia nykyisiä toimintoja olisi kyetty toteuttamaan samalla tasolla ja vauhdilla, mihin nykyisellään on päästy; ja tahtotilana oli myös korvata aiempi PHP + jQuery -pohjainen toteutus. Toki oli riski ottaa Node ja React projektiin, varsinkin kun valintahetkellä molemmat olivat vasta alkaneet nousta tietoisuuteen. Päivitysruljanssit ovat olleet aikamoisia. Kääntöpuolena täytyy kuitenkin todeta, että jos Reactia ei olisi valittu, niin olen aika varma etten olisi yhtä hyvä ohjelmoija kuin nyt. React, Node, ES6 jne. on pakottanut ajattelemaan asioita eri tavalla. Jopa se, että tuo projekti tehtiin aluksi päin honkia ei-halutuilla teknologioilla on auttanut kehittymään ja toisaalta ymmärtämään missä oma taitotaso, ymmärrys ja arvot koodaajana menevät.

Reactin ja Noden kanssa on toki sitten omat ongelmansa, mutta ainakaan enää ei tule bugeja, jotka johtuisivat rikkonaisesta HTML:stä tai siitä että templaatti ja jQuery ovat epäsynkassa. Reactin kanssa valtaosa fronttia koskevista bugeista on puhtaita tilaongelmia; leiska on mennyt rikki todella harvoin.

 

[Fanboys Suck]

ainakaan enää ei tule bugeja, jotka johtuisivat rikkonaisesta HTML:stä tai siitä että templaatti ja jQuery ovat epäsynkassa.

Tokihan kaikki käyttää jotain template engineä sekä js:n ja normi HTML kanssa. Mutta olen samaa mieltä että itsensä haastaminen on näissä koodaushommissa tärkeää ja jos projektit antaa pienen oppimiskäyrän anteeksi niin sitä parempi kun voi palkalla oppia uutta.

 

[©©©]

Tutustuin tuossa hiljattain Angular 2 frameworkiin ja sain sen hienosto toimimaan quickstartin mukana tulevalla liteserverillä. Nyt kun kokeilin laittaa saman sovelluksen Flaskin päälle herjaa, että ei löydä main.js vaikka siellä se on, polku on vaan väärin mistä se sitä etsii. Missähän tuota main.js suhteellista polkua säädetään? Vaihdoin Flaskissa static-kansion nimeksi 'Client' jonne työnsin koko angular sovelluksen.

 

[AION]

Molemmat Yatzee pelit näyttää ihan kivalta, jotka tossa edellisellä sivulla oli mutta miksi JS on kirjoitettu pre 2015 standardilla. Käsittääkseni nyt on 2017?

Eli kannattaa vaan suoraan alkaa opetalla EcmaScript 2015 (ES6) versiota ja siitä ylöspäin. Kieli on aika paljon muuttunut. Toki vanha toimii edelleenkin mutta uudessa on niin paljon juttuja, joita tullaan tarvitsemaan (ja ollaan tarvittu jo vuosia) isommissa projekteissa. (Lexical this, block scopetut functiot, promiset, luokka hierarkiat jne jne jne).

Kaikki modernit selaimet tukevat jo ES2015 tason koodia ja jos joutuu jotain vanhaa IE:n paskaa vielä piiskaamaan niin siihen on sitten saatavilla Babelit ja muut kääntäjät

Ja jos ajatellaan ihan siltäkin pohjalta, että kaverit täällä opettelee nyt ekaa JS juttua ja olevat työelämässä niissä tehtävissä vasta muutaman vuoden päästä niin tuolla pre - 2015 koodilla voi olla aika hukassa siellä.


Sitten tuo jQuery. Se on ihan ok opetella mutta on menossa jo ulos. Angular (tai React tai VUE) ei sitä tarvitse ja sen käyttö ei ole edes suositeltua. Se on ihan ok työkalu silti mutta en pidä "sen" opettelua mitenkään kovin kiinnostavana. Varsinkaan sen takia kun se on niin laaja kirjasto, jossa on vähän kaikkea. On ihan perus query selectori, DOMin muokkausta, AJAXit, animointia jne jne jne. Nykyään selaimen oma query selector on ihan pätevä, esim Reactissa leikitään referensseillä. Sillon ei tarvitse tuota jQueryn selectoria. Sitten taas kirjastot, jotka ovat pelkästään ajaxia varten tehty ovat ehkä parempia sitten ajaxissa. Esim superagent.

 

[Fanboys Suck]

Sillon ei tarvitse tuota jQueryn selectoria. Sitten taas kirjastot, jotka ovat pelkästään ajaxia varten tehty ovat ehkä parempia sitten ajaxissa. Esim superagent.

Tai miksi ei käyttäisi suoraan fetchiä, ei tarvitse mitään kirjastoa.

 

[jhalmu]

Mä tein just tän opastuksella tuon pääosiltaan. Koodi oli jo vähän vanhaa mutta samalla oppi hakemaan tietoa + kommenteissa oli oikeat tulokset miten pääsi eteepäin tuoreemmalla versiolla. Oli tosi avaavaa ja tuli mukavaa onnistumisen iloa. Samalla kommenteista ym löytyi myös vinkkiä mihin kannattaa suunnata seuraavaksi.

Vähän samalla lailla aloitin LAMP-opiskelut aikoinaan, että joku ihan rumakoodausta mutta nopeaa. Ainakin seuraavaksi kokeilen ton tuoreempaa videota:

.

Innostus koodaamiseen lähti taas pitkästä aikaa kuin törmäsiin Elecroniin, siitä on paljon uutta ja vanhaa videota nähtävillä:

Atom editorina näyttää nyt jäävän. Bootsrapstudio tuli pahus ostettua kun yön pimeinä tunteina tulee kaikenlaista ostettua. No toivotaan että sitä vois hyödyntää joskus ulkoasun tekoon ja sitten siihen sitten toiminnallisuudet.

Aikoinaan perus js ja jqeryt sekoittivat vaan tän ei niin matemaattisen pään. Ja lopahti into. Mulle oppiminen on parasta just näin. Aikoinaan LAMP oppiminenkin lähti ihan rumaa mutta nopeaa ja siitä sitten oppi tekemään vähitellen oikeinkin. Usko menee jos ei näe toimivia lisää, editoi ja poista -nappeja

Toki html/xhtml on opittu aikoinaan hyvin strictinä ja kaikissa sivuissa piti olla validaattoriin linkki

 

[jhalmu]

Mä liityin tänne kuukausimaksulliseksi: Scotch Web Development , on ollut tosi laadukasta, minkä huomaa että olen jaksanut kuunnella esim javascriptin perusteita: Huomaa että tuo tuo hienosti esiin myös "best paractises", joten tuntuu että oppisi oikein ekalla kerralla. Tuolla pitäisi olla katettuna kaikki mistä olen nyt kiinnostunut.

Electron tosiaan oli alkukohta josta kiinnostuin taas, mutta mennyt nyt perusteiden opettelemiseen. Mukavana plussana esim pelkästään videot vs coden virittäminen ja mitä lisäosia kannattaa asentaa ja miksi. Ja joku perusopetus gitistä ennen kuin lähtee syvemmälle. Nyt tosiaan javascriptikin tuntuu ihan selkeältä (= vähemmän pelottava) tavaralta, joka on ihan kiva tunne. Itse kun en ole hirveän matemaattis-looginen ihminen niin nousee yksityiskohdat joskus ikäviksi pullonkauloiksi. Vähän kuten OOP php:ssä aikoinaan.

Mutta joo, vähitellen on hyvä selvittää miten omaan käyttämään web-hotelliin saa nodet ym, sillä kun pyörii nyt vaan harvoin kirjallisia päivityksiä saava wordpress.

Edit: Havaittavissa toistoa pienillä twisteillä. Onko se paha, miettii yövuorolainen.

 

[oxbird]

Mistä löytää vapaasti käytettäviä HTML/CSS-teemoja (mieluiten FOSS-lisenssillä)? Tein jo verkkosivun HTML:llä, haluan tilapäisratkaisuna visuaalista ilmettä ennen kuin luon koreat puitteet itse.
Google-haulla tuloksia odotetusti löytyy valtavasti, mistä tahansa en koodia uskalla kopioida. Vaatimuksena on, että kolmannen osapuolen skriptejä ja linkkejä ei tule sivulle.

 

[Hyrava]

Mistä löytää vapaasti käytettäviä HTML/CSS-teemoja (mieluiten FOSS-lisenssillä)? Tein jo verkkosivun HTML:llä, haluan tilapäisratkaisuna visuaalista ilmettä ennen kuin luon koreat puitteet itse.
Google-haulla tuloksia odotetusti löytyy valtavasti, mistä tahansa en koodia uskalla kopioida. Vaatimuksena on, että kolmannen osapuolen skriptejä ja linkkejä ei tule sivulle.

Mulla olisi vähän samanlaisesta kiinnostusta. Oma nykyinen projekti on sellainen sillisalaatti SSI, PHP, HTML, CSS, JS, Python, Shelliskriptejä, ... ettei mitään rajaa ja ajattelin että tuota voisi vähän modernisoida välillä. Nykyinen netti-interface on HTML4/CSS1 -aikakaudelta (ja jopa frameilla toteutettu) joten varmaankin olisi pikkuhiljaa uusinnan tarpeessa. Sain täältä jo vinkkiä serveripuoleen joka vähensi skriptien määrän murto-osaan (ja vähenee sitä mukaa kun kerkiän siirtämään toiminnallisuutta serveripäähän). Itselläni tuo ettei ole ulkopuolisia resursseja on pakollinen koska tuo on suljetussa verkossa ilman (suoraa) yhteyttä nettiin.

Jos jostain löytyisi jotain kivoja pohjia mitä voisi lähteä muokkaamaan omaan makuun, HTML ja CSS on nykyisellään aika ruosteessa mutta koitan opiskella codecademyn sun muiden nettikurssien avulla vähän perusteita. Aikanaan tuli kyllä ylläpidettyä paria sivustoa "notepad"-menetelmällä mutta on vähän päässyt unohtumaan vuosien varrella eli aikanaan HTML ja CSS on ollut ihan tuttuja juttuja.

 

[jhalmu]

Löytyiskö tuolta: free html templates - Google-haku

 

[jase]

Taikasana lie bootstrap

Eli ihan pelkällä Bootstrapilläkin pääsee jo pitkälle, mutta noita ilmaisia templaattejakin löytyy jonkin verran.

 

[Rantakemisti]

Taikasana lie bootstrap

Eli ihan pelkällä Bootstrapilläkin pääsee jo pitkälle, mutta noita ilmaisia templaattejakin löytyy jonkin verran.

Ääni näille responsiivisille frameworkeille. Turhaa pyöritellä jotain HTML temploja tai teemoja kun näillä pääsee samaan lopputulokseen sekä saattaa myös oppia jotain. Monet noista temploistakin nojaavat johonkin valmiiseen frameworkiin.

Twitterin Bootstrap, Skeleton ja Foundation taitavat olla tunnetuimmat. Näitä löytyy pilvin pimein esim. Sencha Touch, Onsen UI, Ionic, Semantic UI, SproutCore, HTML KickStart, Framework 7, Base, Kendo UI, Montage jne.

 

[kjns]

Itse on tullut "harrasteltua" webbikoodausta pikkujätkästä lähtien varmaan kohta 20 vuoden ajan, mutta koskaan en ole mennyt ihan hirvittävän syvälliselle tasolle siinä.

Alkuun tuli askarreltua ihan sitä staattista html:ää kun broidin kanssa rakenneltiin äidin firmalle jotkut perustason nettisivut vuonna miekka ja kilpi. Sitten on jotain pieniä omia projekteja ollut ja mennyt aikojen saatossa ihan vain tekemisen ilosta, aina välillä tulee innostus tehdä jotain, mutta se meinaa aina muutaman kuukauden päästä lopahtaa ja homma jää vähän puolitiehen. Kyllä tässä vuosien varrella on tullut jonkinlainen osaaminen kuitenkin kerättyä html:ästä, css:stä, php:stä ja mysli-tietokannoista, ja noilla avuilla sitten ole tullut pari omaa pienimuotoista php/mysql-pohjaista nettisivua / cms-viritelmää tehtyä, ja ruuvaillut jotain Wordpress-pohjaisia saitteja uuteen uskoon.

Tavallaan tekisi mieli tehdä enemmänkin, mutta tuntuu ettei päivässä tunnit riitä harrastamaan kun ei näitä hommia työkseen tee. Joskus on myös kiinnostanut yrittää päästä alan hommiin, mutta alkupalkat on aika ankeita jos ei ole jo oikeasti hyvä kehittäjä. Pitäisi paljon kehittyä ennen kuin pääsisi järkeville liksoille, ja sen tasoisen ammattitaidon hankkiminen tuntuu aikamoiselta haasteelta tällä hetkellä.

Noihin JS-hommiin on tehnyt mieli perehtyä seuraavaksi, ehkä se siitä lähtee kun seuraava inspiraation hetki iskee, niiden kanssa voisi taas kokeilla sitten jotain uusia kikkoja

 

[Monologi]

Webbiohjelmoinnista..

Kattelin, että jQuery pystyy suoraan linkittämään sivulle, että ei tarvitse sitä erikseen asentaa ja sama juttu Bootstrapin kanssa. Bootstrap tarvitsee tuon jQueryn toimiakseen. Ainakin nappuloita noilla pystyisi hieromaan värikkäimmiksi ja hienommiksi.
Onko näitä muita tarpeellisia vastaavia? Tai jotain nykyaikaista, että ei sivusto näyttäisi joltain 90-luvun viritelmältä.

Kuitenkaan Nodea ei taida pystyä, mutta tällä kait on tekemistä sivujen nopeuden kanssa, että esim. PHP on hitaampaa koodia. Node kait pitäisi olla asennettuna palvelimelle suoraan.

Websocket taisi ja liittyä nopeuteen tai ainakin esp8266 ohjautui nopeammin sen avulla.

 

[Rantakemisti]

Kattelin, että jQuery pystyy suoraan linkittämään sivulle, että ei tarvitse sitä erikseen asentaa ja sama juttu Bootstrapin kanssa. Bootstrap tarvitsee tuon jQueryn toimiakseen. Ainakin nappuloita noilla pystyisi hieromaan värikkäimmiksi ja hienommiksi.
Onko näitä muita tarpeellisia vastaavia? Tai jotain nykyaikaista, että ei sivusto näyttäisi joltain 90-luvun viritelmältä.

Bootstrap on vain responsiivinen framework sivustolle ja enemmänkin CSS-teema eikä varsinaisesti mitään ohjelmointia. Bootstrap toimii ihan hyvin ilman jQuerya, jos sivustolle ei tule mitään Bootstrapin interaktiivisuutta (mobiilinavia yms.).

Aiheesta enemmän keskustelua ketjussa Yleistä keskustelua webdevauksesta

Ääni näille responsiivisille frameworkeille. Turhaa pyöritellä jotain HTML temploja tai teemoja kun näillä pääsee samaan lopputulokseen sekä saattaa myös oppia jotain. Monet noista temploistakin nojaavat johonkin valmiiseen frameworkiin.

Twitterin Bootstrap, Skeleton ja Foundation taitavat olla tunnetuimmat. Näitä löytyy pilvin pimein esim. Sencha Touch, Onsen UI, Ionic, Semantic UI, SproutCore, HTML KickStart, Framework 7, Base, Kendo UI, Montage jne.

 

[Monologi]

Bootstrap on vain responsiivinen framework sivustolle ja enemmänkin CSS-teema eikä varsinaisesti mitään ohjelmointia. Bootstrap toimii ihan hyvin ilman jQuerya, jos sivustolle ei tule mitään Bootstrapin interaktiivisuutta (mobiilinavia yms.).

Aiheesta enemmän keskustelua ketjussa Yleistä keskustelua webdevauksesta

Kiitti tarkennuksista. Tuon viestin voi siirtää tuonne oikeaan triidiin.

 

[Rantakemisti]

Kiitti tarkennuksista. Tuon viestin voi siirtää tuonne oikeaan triidiin.

Siirsin nämä pari viimeistä viestiä tänne tuolta "Pieniä kysymyksiä ohjelmoinnista"-ketjusta.

 

[Paapaa]

Onko näitä muita tarpeellisia vastaavia? Tai jotain nykyaikaista, että ei sivusto näyttäisi joltain 90-luvun viritelmältä.

Kuitenkaan Nodea ei taida pystyä, mutta tällä kait on tekemistä sivujen nopeuden kanssa, että esim. PHP on hitaampaa koodia. Node kait pitäisi olla asennettuna palvelimelle suoraan.

Websocket taisi ja liittyä nopeuteen tai ainakin esp8266 ohjautui nopeammin sen avulla.

Iso osa client-puolen kirjastoista on käytettävissä niin, että se ladataan CDN:stä, eikä sitä kirjastoa tarvitse tarjoilla omalta palvelimelta. Node on tosiaan ympäristö, jossa voidaan ajaa JavaScriptiä ja näin esim. toteuttaa palvelin. Websocketilla voidaan toteuttaa reaaliaikaista kaksisuuntaista kommunikaatiota, esim. chätti. Siihen on helppokäyttöisiä kirjastoja, esim. socket.io. Mutta lähtökohtaisesti tuo vaatii myös palvelinpuolen koodailua. jQuery on tosiaan työkalu, jolla sivustoon on helppo tehdä muutoksia, esim. klikkauksen jälkeen laittaa sopiva animaatio pyörimään kun odotellaan dataa.

Sivun ulkoasun päivittäminen ei ole välttämättä mikään triviaali asia. Paljon riippuu siitä, miten ne sivut on tehty. Hyvässä sivussa sisältö ja ulkoasu on visusti erillään ja niiden muokkaaminen ei ole loputtoman vaikeaa. Perus HTML ja CSS kannattaa opetella. Jollain Wordpressillä (ei omaa kokemusta) teemojen vaihtelu pitäisi olla varsin helppoa.

Eräs yleinen suuntaus nettisivun ulkoasussa on Material-tyyli. Sellaista voi saada aikaan esim. Documentation - Materialize avulla. Nuokin saa ladattua CDN:stä. Sivuilta löytyy valmista esimerkkiä, jolla pääsee alkuun.

 

[Monologi]

Mitä ilmaista editoria kannattaa käyttää linux puolella terminaalissa ja entä windows puolella?
Se ainakin kiinnostaa, kun nuo editorit osaa värjätä käskyt eri värillä sekä osaavat arvata ennakkoon käskyn.

Sitten noista kaikista ihmeen "palikoista", että onko jonkinlaisia lego-palikoita amatööreille ja joku saitti, mikä on hyvin tuettu asiaan liittyen. Yksinkertaisia juttuja vähällä koodin hakkaamisella, mutta merkittäviä.

Onko jotain saittia, mikä käy läpi visuaalisesti noita "palikoiden" käyttöjä ja koodin?

Mitään suurta ei ole tarkoitus tehdä vaan hyvin minimaalista koodauksen osalta ja pienessä ajassa. Naurettavan pienen firman sivut, mutta pintapuolisesti nykyaikaiset ja olen kuvitellut, että noilla "palikoilla" pystyisi siihen suorilta.

 

[Paapaa]

Mitä ilmaista editoria kannattaa käyttää linux puolella terminaalissa ja entä windows puolella?
Se ainakin kiinnostaa, kun nuo editorit osaa värjätä käskyt eri värillä sekä osaavat arvata ennakkoon käskyn.

Terminaalissa kannattaa opetella vim. Aluksi vaikuttaa kököltä, mutta on lähes de facto -standardi terminaalieditoriksi ja todella kykeneväinen. Alkujärkytyksen jälkeen alkaa sujua. Pidä vain tärkeimmät näppäinoikotiet vaikka paperilla edessäsi. Mutta miksi haluat editoida terminaalissa? Kannatta ottaa käyttöön kunnon editori ihan graafiselle puolelle. Itse käytän Sublime Text 3:a, muita erittäin hyviä on Atom, Brackets, Visual Studio Code jne. Voit siis tehdä ne sivut niin, että ensin testaat omalla koneellasi niiden toimintaa ja vasta sitten kun homma toimii, siirrät ne nettiin.

Sitten noista kaikista ihmeen "palikoista", että onko jonkinlaisia lego-palikoita amatööreille ja joku saitti, mikä on hyvin tuettu asiaan liittyen. Yksinkertaisia juttuja vähällä koodin hakkaamisella, mutta merkittäviä.

Onko jotain saittia, mikä käy läpi visuaalisesti noita "palikoiden" käyttöjä ja koodin?

"Palikoilla" on yleensä omat sivut, jotka opastavat. Bootstrapin sivuilla on kerrottu seikkaperäisesti kaikki ominaisuudet esimerkkien ja koodipätkien kera. Sen avulla pääset hyvin alkuun. Myös W3Schools Online Web Tutorials sisältää ohjeita. Lisäksi perus HTML:ää, CSS:ää ja JavaScriptiä voi opetella koodikoulusivuilta, esim. Learn to code

Paljon helpottaa, jos on joku selkeä ajatus sivujen lopullisesta ulkoasusta - esim. piirros, mockup tai joku netistä löydetty muu sivusto.

 

[Monologi]

Iso osa client-puolen kirjastoista on käytettävissä niin, että se ladataan CDN:stä, eikä sitä kirjastoa tarvitse tarjoilla omalta palvelimelta. Node on tosiaan ympäristö, jossa voidaan ajaa JavaScriptiä ja näin esim. toteuttaa palvelin. Websocketilla voidaan toteuttaa reaaliaikaista kaksisuuntaista kommunikaatiota, esim. chätti. Siihen on helppokäyttöisiä kirjastoja, esim. socket.io. Mutta lähtökohtaisesti tuo vaatii myös palvelinpuolen koodailua. jQuery on tosiaan työkalu, jolla sivustoon on helppo tehdä muutoksia, esim. klikkauksen jälkeen laittaa sopiva animaatio pyörimään kun odotellaan dataa.

Sivun ulkoasun päivittäminen ei ole välttämättä mikään triviaali asia. Paljon riippuu siitä, miten ne sivut on tehty. Hyvässä sivussa sisältö ja ulkoasu on visusti erillään ja niiden muokkaaminen ei ole loputtoman vaikeaa. Perus HTML ja CSS kannattaa opetella. Jollain Wordpressillä (ei omaa kokemusta) teemojen vaihtelu pitäisi olla varsin helppoa.

Eräs yleinen suuntaus nettisivun ulkoasussa on Material-tyyli. Sellaista voi saada aikaan esim. Documentation - Materialize avulla. Nuokin saa ladattua CDN:stä. Sivuilta löytyy valmista esimerkkiä, jolla pääsee alkuun.

Löysin esp8266 valmiin esimerkin millä sivun kautta ohjataan releitä ja siinä koodissa sitten löytyi linkit juurikin noihin CDN:ään(jquery ja bootstrap). Paransivat huomattavasti nappuloiden hohdokkuutta verrattuna niihin tavallisiin harmaisiin nappeihin.

Nodea yritin asentaa orange pi zeroon, mutta se tartti myös sen npm niin se ei suostunut asentumaan. Toki tuo pelkkä node toimi joten kuten rajoittuneena. Raspberry pi:hin tuo olisi asentunut suorilta. Kuulemma, jos olisi kääntänyt niin ehkä olisi toiminut orangepizerossa. Jätin sikseen, kun on noita pilvipalvelimia, missä on valmiina kait tuommoinen node.

Wordpress ilmaisena versiona ei voi käyttää firman sivuina niin en sen takia siitä niin äkkiseltään innostuisi tai ainakin hinnasto paljastaisi sen firman sivuiksi. Wordpress vaikuttaa enemmänkin sellaisten harrastelijoiden sivuilta, missä paistaa se Wordpress logo.

Pitääpä tutustua tuohon materializeen.

 

[Monologi]

Terminaalissa kannattaa opetella vim. Aluksi vaikuttaa kököltä, mutta on lähes de facto -standardi terminaalieditoriksi ja todella kykeneväinen. Alkujärkytyksen jälkeen alkaa sujua. Pidä vain tärkeimmät näppäinoikotiet vaikka paperilla edessäsi. Mutta miksi haluat editoida terminaalissa? Kannatta ottaa käyttöön kunnon editori ihan graafiselle puolelle. Itse käytän Sublime Text 3:a, muita erittäin hyviä on Atom, Brackets, Visual Studio Code jne. Voit siis tehdä ne sivut niin, että ensin testaat omalla koneellasi niiden toimintaa ja vasta sitten kun homma toimii, siirrät ne nettiin.

Jostain syystä olen käyttänyt nanoa, mutta siirryn tuohon vimiin.
Tähän zeroon ei ole vielä luotettavaa työpöytä käyttistä niin sen takia tuolla terminaalissa tulee säädettyä.
Tosiaan voisin windows koneella käyttää helposti noita editoreita, mutta zero niin kuin on pieni palvelin niin näkee heti tuloksen ja näkyy vaan sisäverkossa niin kait ihan turvallista.
Käytin vanhahtavaa graaffista KompoZer editoria kehyksien säädöissä joku tovi sitten ja tuo oli täysin ilmainen, mutta 2010 viimeksi päivitetty..
Oliskin joku tuoreempi ja täysin ilmainen.

"Palikoilla" on yleensä omat sivut, jotka opastavat. Bootstrapin sivuilla on kerrottu seikkaperäisesti kaikki ominaisuudet esimerkkien ja koodipätkien kera. Sen avulla pääset hyvin alkuun. Myös W3Schools Online Web Tutorials sisältää ohjeita. Lisäksi perus HTML:ää, CSS:ää ja JavaScriptiä voi opetella koodikoulusivuilta, esim. Learn to code

Paljon helpottaa, jos on joku selkeä ajatus sivujen lopullisesta ulkoasusta - esim. piirros, mockup tai joku netistä löydetty muu sivusto.

Tullut tuota freecodecampia käytyä läpi noiden juttujen kanssa.
Mietin vaan, että onko tässä valmiissa maailmassa tehty jotain tosi interaktiivista copy&paste tapauksille, että ei tarttisi edes ymmärtää muuta kuin muutos.

 

[Rantakemisti]

Wordpress ilmaisena versiona ei voi käyttää firman sivuina niin en sen takia siitä niin äkkiseltään innostuisi tai ainakin hinnasto paljastaisi sen firman sivuiksi. Wordpress vaikuttaa enemmänkin sellaisten harrastelijoiden sivuilta, missä paistaa se Wordpress logo.

Ihan näin sivuhuomatuksena, onkohan mahdollisesti mennyt sekaisin wordpress.com ja wordpress.org? Molemmissa on kyse maailman käytetyimmästä sisällönhallintajärjestelmästä enkä puhuisi mistään harrastelijoiden järjestelmästä. Kyseistä julkaisujärjestelmää käyttää sellaiset sivustot kuin: The Wall Street Journal, Forbes, The Next Web, The New Yorker, Harvard Business Review, Nikon, Nasa, Time jne.

WordPress.org sivuilta voit ladata uusimman version ohjelmistosta ja asentaa sen omalle palvelimelle. WordPress.com on taas palvelu, joka tarjoaa ilmaiseksi käyttöön WordPressin. Tässä vielä jonkun randomsaitin vertailu: Kotisivut yritykselle: WordPress.com vai WordPress.org?

 

[Monologi]

Ihan näin sivuhuomatuksena, onkohan mahdollisesti mennyt sekaisin wordpress.com ja wordpress.org? Molemmissa on kyse maailman käytetyimmästä sisällönhallintajärjestelmästä enkä puhuisi mistään harrastelijoiden järjestelmästä. Kyseistä julkaisujärjestelmää käyttää sellaiset sivustot kuin: The Wall Street Journal, Forbes, The Next Web, The New Yorker, Harvard Business Review, Nikon, Nasa, Time jne.

WordPress.org sivuilta voit ladata uusimman version ohjelmistosta ja asentaa sen omalle palvelimelle. WordPress.com on taas palvelu, joka tarjoaa ilmaiseksi käyttöön WordPressin. Tässä vielä jonkun randomsaitin vertailu: Kotisivut yritykselle: WordPress.com vai WordPress.org?

Jotenkin tuli sellainen dejavu tunne, että tästä on aikaisemmin minulle mainittu. Ei vanha muista..

Kiitti korjauksesta.

 

[Sampsa]

Ihan näin sivuhuomatuksena, onkohan mahdollisesti mennyt sekaisin wordpress.com ja wordpress.org? Molemmissa on kyse maailman käytetyimmästä sisällönhallintajärjestelmästä enkä puhuisi mistään harrastelijoiden järjestelmästä. Kyseistä julkaisujärjestelmää käyttää sellaiset sivustot kuin: The Wall Street Journal, Forbes, The Next Web, The New Yorker, Harvard Business Review, Nikon, Nasa, Time jne.

WordPress.org sivuilta voit ladata uusimman version ohjelmistosta ja asentaa sen omalle palvelimelle. WordPress.com on taas palvelu, joka tarjoaa ilmaiseksi käyttöön WordPressin. Tässä vielä jonkun randomsaitin vertailu: Kotisivut yritykselle: WordPress.com vai WordPress.org?

ja https://io-tech.fi

 

[Rantakemisti]

ja https://io-tech.fi

Piti muuten alunperin kirjoittaa se tuonne listaan mutta näemmä unohtui.

 

[Monologi]

Kävin freecodecampia läpi niin siellä oli huikea koodin pätkä, joka kait liittyi siihen, että sivu avautuu siististi millä tahansa näytön koolla ja kännykässä.
Olikohan se ihan perus html5 koodia?

Ei kun se taisi olla bootstrap --> Learn to code and help nonprofits

Tälläisiä "palikoita" tarkoitin juuri huikeina. Vähän koodia, mutta merkittävä.

 

[eiltanen]

Vanillajs ja välillä Vue.js jos on dynaamista kamaa. Itellä on vähän sellainen "get the job done" -asenne eli mietin, mitä haluan sivulla näyttää ja sitten teen sen. Jotenkin jännästi huomaa, että kun tietää, mitä haluaa, usein se yksinkertaisin ja suoraviivaisin tapa on helpoin, oli kuinka tylsä tahansa. "Tylsä" ja "perinteinen" eivät kyllä istu web-kehityksen maailmaan.

Ei mulla ole mitään frameworkeja yms. vastaan, jotenkin vain usein esim. sivujen toteutuksia katsoessa tulee mieleen ajatus "mitä tällä kaikella oikein halutaan saada aikaan?" Ja miksi sitä ei vaan tehdä suoraan.

Tosin aika harvassa tapauksessa varmaan sisältöä ja teknistä puolta hoitaa samat tyypit.

 

[jhalmu]

Mitä mä nyt esim oon nyt katellut Angular 2:sta katellut (riviäkään vielä koodia kirjoittanut), niin se tosiaan antaa paremmat mahdollisuudet kehittää tuotetta isommalla porukalla, koska siihen on tarkempi käsikirjoitus ja jokainen voi rakentaa pientä palaansa erikseen. Sen takia se on enemmän framework kuin esim eka versio Angularista. Isompien framevorkkien hyvyys on kerrottu olevan myös siinä, että niissä on tehty vaikkapa perus crudit jo valmiiksi ettei niitä tarvitse kirjoittaa tai muuten lyhyemmällä kirjoittamisella saa enemmän aikaa kun itseframeworkki tekee ne sinulle. Ikävmpänä puolena näissä yleensä sitten onkin, että manuaali on paksu varsinkin jos frameworkki on sellainen että "elefantti pitää syödä isoina paloina".

itse tykkäsin muinaisina aikoina php4 koodarina että firmalla oli runko valmiina perustoiminnoille ja sitten jos asiakas toivoi jotain lisää, niin se tehtiin mukavan quick'n dirty (tai niin hyvin kuin osattiin ja yleensä ihan toimivasti) ja se lisättiin sitten tähän runkoon. Se oli sellaista esi-wordpress -toimintaa. Php4:llä oli mukava vaan kirjoittaa enempiä ajattelematta kunnes homma toimi (varsinkin kun oli mietittynä jo kaikki perus turvallisuusjutut).

Mutta se riitti eikä hommien kokoluokkaan tarvinnut mitään intialaista-insinööriä avuksi. Ja kun oli perus CMS valmiina niin eniten aikaa meni leiskan tekoon. Mutta kääreenä tähän, että itseasiassa Angular 2:sessa saa kanssa tehtyä sen perus-pohjan valmiiksi ja käyttää sitä - tai antaa komentokehoite joka tekee sellaisen sinulle. Se kannattaako sitä käyttää on sitten ihan keisskikohtainen juttu, että laajeentuuko sivusto tai aplikaatio myöhemmin jns vai onko näin hyvä. Valmista pitää kuitenkin saada

 

[Monologi]

Mitä tuota Angular 1:stä kattelin niin sillä pystyi esim. tallentamaan sivujen kautta esim. ostoslistan sinne. Aika veikeä, mutta tälläiselle nyypälle tuo koodi oli jo aika paha. Tietty copypastella eteenpäin, jos tarve.
Tullut vaan kateltua noita js juttuja tuubista..
En tiedä uskallanko edes vilkaista Angular 2:sta.

 

[Gize]

Bootstrap navbarin kanssa kikkailen tässä, milläs se taustaväri nyt taasen tulikaan dropdown menulle silloin kun hiiri päällä (hover)?

Tällä tulee muut mutta sehän ei tuohon dropdowniin vaikuta, silmät jo ihan ristissä kun koodia katsellu jo pidempään

.navbar-custom .navbar-nav > li > a:hover, .nav > li > a:focus {
    text-decoration: none;
    background-color: #33aa33;
}

 

[Paapaa]

Bootstrap navbarin kanssa kikkailen tässä, milläs se taustaväri nyt taasen tulikaan dropdown menulle silloin kun hiiri päällä (hover)?

Tällä tulee muut mutta sehän ei tuohon dropdowniin vaikuta, silmät jo ihan ristissä kun koodia katsellu jo pidempään

En tiedä, tarkoititko sitä itse nappulaa vai niitä linkkejä menussa, mutta jotain tällaista:

.dropdown-menu a:hover {
  background: red !important;
}

.dropdown-toggle:hover {
  background: red;
}

Voit sitten käyttää ID-attribuutteja, jos haluat kohdistaa muutokset vain johonkin tiettyy dropdowniin.

 

[Gize]

En tiedä, tarkoititko sitä itse nappulaa vai niitä linkkejä menussa, mutta jotain tällaista:

.dropdown-menu a:hover {
  background: red !important;
}

.dropdown-toggle:hover {
  background: red;
}

Voit sitten käyttää ID-attribuutteja, jos haluat kohdistaa muutokset vain johonkin tiettyy dropdowniin.

Kiitos!

Nimenomaan linkkejä menussa, laitoin tuon ekan pätkän niin sain homman hoidettua Mitäs muuten tuo jälkimmäinen .dropdown-toggle määrittää?

Vielä olisi tavoitteena saada alavalikon (dropdown) aktiivinen sivu eri värille, eli nyt aktiivinen dropdown valikko esim. Tuotteet on eri värillä, kuten pitäisikin, mutta alasivut (tuotenimet) on kaikki samanlaisia pohjiltaan vaikka oltaisiin siellä aktiivisella sivulla (esim. tuote XX alavalikossa). Eli pitäisi siis saada naviin background color activelle, dropdowniin, olikohan tarpeeksi hankalasti selitetty