63. TKMV - Karmaisevia asiakkaita ja 🕷🕸 koodissa

Mitä tehdä kun asiakas vaatii rahojaan takaisin huonojen teknisten ratkaisujen takia vaikka osasyynä on asiakkaan jatkuvasti muuttuvat vaatimukset? Mistä löytyy Tampereen paras kebab 🌯? Jakson sponsorina Zure.

Tsekkaa Zuren uramahdollisuudet!

KysymyksetEtsikääpä jostain haastateltavaksi asiantuntija, joka osaisi sanoa jotain viisasta webbipalveluiden hiilijalanjäljen pienentämisestä, aiheesta olisi kiva kuulla lisää. (Mikko)Heippa! Kiitos viime jaksosta, ihanaa, että käsittelitte clojurea. Tehkää pliiiis oma clojurejakso ja siihen suosittelen lämpimästi Metosinilta Jarppe Länsiötä (enkä edes ole metosinilla töissä, tämä on ihan aito suositus, eikä markkinointitemppu). Tsekatkaa esmes Jarpen ClojuTre - puheenvuoro vuodelta 2018: https://youtu.be/WtdegIqQbrgSemmonen kommentti, että oli hauskaa, kun kommentoitte, että clojurekoodi näyttää hassulta ja vieraalta; täysin samalta clojuristille muuten näyttää joku typescript, että miten semmosta voi tehdä 😃Tampereen paras kebab?Devaustyö käytännössä; yksin päkertäminen vs mob programming. Ensin kiitos todella loistavasta poodkastista, ja vielä suomenkielellä. Poljen 10,5 kilsaa suuntaansa töihin Oulun keskustaan ja tämä on yksi työmatkan suosikeista (Joni Jaakolan Väkevä Elämä -podcastin lisäksi). Kaikki webbidevaukset on tullut kuunneltua :) Sitten kyssäriin. Omalla kodestelu-uralla on tullut kokeiltua kaikenlaista koodin kehitystapaa. Niin yksin luurit päässä päkräystä, parityöskentelyä ja aina ihan mob ohjelmointia. Oletteko kokeilleet mob ohjelmointia ja jos olette, niin mitä mieltä menetelmästä? Jos ette ole, niin ehdottomasti kannattaa kokeilla ja jakaa kokemukset muiden kuulijoiden kanssa. Se voisi olla keino mm lähes virheettömään koodiin, sillä polku koodin syntyyn ja review tulee siinä samalla tehtyä. Tämän vuoksi veikkaan, että menetelmä maksaa lopulta itsensä takaisin helposti.Moro! Minut siirrettiin hiljattain projektiin, joka on aloitettu vuonna 2015. Projektin frontissa on käytössä Angular (2+). Angularin versiota on päivitetty ajan kuluessa, mutta sitä käytetään projektissa samalla tavalla kuin tuolloin vuonna 2015. Ajattelin lähteä hieman modernisoimaan Angularin käyttöä projektissa sitä mukaan kuin mikäkin komponentti tulee minkäkin tiketin myötä työn alle. Ehdin jo tekemään joitain muutoksia, jonka jälkeen minua kiellettiin jatkamasta muutosten tekemistä. Syyksi ilmoitettiin, että projektin frontin tulisi toimia yhdenmukaisella tavalla. Ymmärrän tämän tavallaan, mutta toisaalta koodi on ja pysyy vanhanaikaisena. Mitä mieltä olette tästä? React-maailmasta vastaava esimerkki voisi olla hookkien käytön kieltäminen vanhassa projektissa, johon on kuitenkin päivitetty viimeisin React. (Pitäisikö jo juosta?)Miten toimisitte tilanteessa jossa projekti on muuttuvien bisnes-vaatimusten takia päätynyt teknisesti hiukan suohon/velkaan ja asiakkaalle pitäisi myydä järjestelmän taustan refaktorointi joka ei näy loppukäyttäjille suoranaisesti mitenkään? Parissa aiemmassa tällaisessa tapauksessa on asiakas yrittänyt "huonoihin" teknisiin ratkaisuihin vedoten saada työt takuuseen vaikka ratkaisut oli ihan valideja päätösten tekohetkellä.Koodareita kuulemma tarvitaan kaikkialla. Olen kohta valmistuva tietotekniikan opiskelija ja minua kiinnostaa varsinkin fronttikoodaus aivan älyttömästi. En kuitenkaan ole onnistunut löytämään alata kolmen vuoden aikana työpaikkaa koulun ohelle. Vapaa-ajalla minulla onkin ollut aikaa tehdä omia koodiprojekteja joista nautin. Kysyn siis, onko teillä mielikuvaa mille alueelle koodialan työpaikat ovat sijoittuneet ja miksi minä en ole siellä? (Santeri)Jakson valinnatRiku: ProcreateAntti: GIPHY CaptureOta yhteyttä!@webbidevauswebbidevaus.fi