Uutiset:

Ilmoitustaulu mahdollisten ongelmien varalta (wikimedia.org / Etherpad)

Sähköpostia ylläpidolle: kantapaikanherra (at) gmail.com

Main Menu

Ohjelmointi

Aloittaja Juha, helmikuu 03, 2019, 10:01:17

« edellinen - seuraava »

0 Jäsenet ja 1 Vieras katselee tätä aihetta.

Hayabusa

Aivan varmasti tyhmiä on muuallakin kuin HSL:llä. Muistuu mieleen, että näilläkin palstoilla joku suorastaan kieltäytyi ymmärtämästä arvonlisäveron käsitettä ja määräytymistä. Olisiko sittemmin hakeutunut töihin lippujärjestelmien pariin?  ;)
An nescis, mi fili, quantilla prudentia mundus regatur

Jaska

HS kirjoittaa asiasta:
HSL:n selvityksen perusteella alvin poisto on osoittautumassa erittäin mutkikkaaksi käytännössä. Pelkästään tekniset muutokset HSL:n ja sen kumppaneiden lukuisissa myyntijärjestelmissä aiheuttavat miljoonaluokan kustannukset, ja ovat osoittautuneet osittain jopa mahdottomiksi.

Väliaikainen veronalennus lykkäisi HSL:n nykyiseen lippujärjestelmään suunnitellut tietoturvapäivitykset. Se lykkäisi myös uuden lippujärjestelmän käyttöönottoa arviolta kuudella kuukaudella.

Pelkästään HSL:n menetykset ovat noin kuusi miljoonaa euroa.


HSL ilmoittaa myös, ettei muutos ole mahdollinen aikataulussa eli ensi vuoden alkuun ja ehdottaa että raha annettaisiin HSL:lle, joka alentaisi sillä lippujen hintoja.

Tuolle saa nauraa naurismaan aidatkin. Paitsi että maksumiehiksi laitettaisiin kaikki.

Sitä en suostu uskomaan, ettei järjestelmässä ALVia voisi vaihtaa. Ongelman täytyy olla siinä ettei ole ajateltu että ALV voisi olla nolla, jolloin jotkut järjestelmäliittymät jäisivät pois käytöstä.

Vaikea ymmärtää HSL:n järjestelmää, jossa ALVin poisto lisäisi kustannuksia ja nostaisi matkalippujen hintoja.


Melodious Oaf

Lainaus käyttäjältä: Jaska - syyskuu 23, 2022, 18:01:46
Sitä en suostu uskomaan, ettei järjestelmässä ALVia voisi vaihtaa. Ongelman täytyy olla siinä ettei ole ajateltu että ALV voisi olla nolla, jolloin jotkut järjestelmäliittymät jäisivät pois käytöstä.

Myönnän että on mahdollista, että tossa on HSL:llä joku ihan kumma lehmä ojassa, josta en tajua mitään.

Mutta eikö semmonenkin periaatteessa olis mahdollista, että ongelma ihan todella on kaikkien niiden eri yhtiöiden erilliset myyntijärjestelmät ja se, että niissä arvonlisäveroa saatetaan käsitellä eri tavoin ja että niiden kytky HSL:n systeemeihin ei ole aina samanlainen?

Ne ei halua että tollasta muutosta tehdään ainakaan just tolla aikataululla, mutta tohon saattaa myös liittyä halu lypsää ja ajaa omaa taloudellista etua. Siihen taas saattaa kuulua jotain taustatekijölitä, mitä on ulkoapäin vaikea edes nähdä tai arvata.

Viestimällä asioista ulospäin just niin kuin ne nyt tekee ne tietysti pyrkii johonkin.

Nythän tommosella viestimisellä vois olla mahdollista myös pelata aikaa tai vähentää mainehaittaa sillä, että jos jotain ongelmia sitten tulee, ei voida sanoa ettei ne olis edes yrittänyt niitä välttää.

Ja tietysti siinä voi olla monta tekijää samassa  :D

Hippi

^
Luulisin, että maksujärjestelmä on HSL:n ja maksulaitteet asennetaan kuhunkin bussiin aina, kun bussifirma ottaa ajaakseen HSL:n reittejä. Minusta ne ainakin näyttää ihan samanlaisilta riippumatta siitä, minkä firman autoon ole noussut.

Sitä paitsi ei kai niissä maksupäätteissä sitä ALV:n laskemista pyöritetä vaan jossain palvelimella, mihin kukin tapahtuma välittyy.

Jos se nyt jotain järkevästi on tehty, niin matkastani Jumboon välittyisi vain "Yksi BC matka Hipin saldosta pois". Ei maksupääte, vaan joku palvelin välittää näytölle takaisin viestin "OK, saldo on nyt xx,xx euroa". Se miten se "yksi BC matka" on hinnoiteltu on siellä palvelimella tiedossa ja nyt siitä sitten osa on matkan hintaa ja osa ALV:a, joka viedään kirjanpitoon miten nyt viedäänkään. Tuosta pitäisi vaan saada nypittyä tuo ALV pois.

Noin siis kuvittelen sen toimivan.
If you see your glass as half empty, pour it in a smaller glass and stop complaining. ❤️

Melodious Oaf

^ No sulla on varmasti parempi kyky hahmottaa ja kuvitella tämän tyyppisiä asioita kuin minulla, ehkä luontaisestikin, ja sitten tulee vielä työhistoria ja kokemus siihen päälle.

Mulla ei ole edes kuin satunnaisia kokemuksia HSL:n matkustajana, niin se on aika lailla eos täällä päässä sitten lopulta

Hippi

^
No joo, ihan mielikuvituksesta tuon tempaisin. En ole tuon tyyppisiä sovelluksia koskaan ollut mukana tekemässä. :D
If you see your glass as half empty, pour it in a smaller glass and stop complaining. ❤️

ROOSTER

Tämä herättää kysymyksiä IT-porukan moraalista.

Lainaus käyttäjältä: https://www.is.fi/digitoday/tietoturva/art-2000009097454.htmlTiistaina julkitulleiden asiakirjojen mukaan Vastaamon tietoturva olisi ollut jopa vuosia retuperällä. Erään todistajan mukaan yhtiön tietoturvaohjelmistot ja palomuurit toimivat minimitasolla. Se ei ollut hänen mielestään riittävää, koska yhtiön palvelimilla oli arkaluonteista sisältöä.

Yhden vanhan työntekijän mukaan Vastaamon tietoturvaan ja it-infrastruktuuriin oli panostettu taloudellisesti ja resurssein hyvin vähän, jos edes sitäkään. Ex-työntekijän mukaan Vastaamolla mentaliteetti oli ollut, että "tehdään sitten, kun on pakko".
...
It-arkkitehtuurin kannalta kriittinen järjestelmä oli esimerkiksi laiton versio.

– Lähinnä hankittiin ilmaisia työkaluja, muun muassa virtualisointialusta oli piraattiversio, ilman ostettua lisenssiä, todistaja sanoi.
Yleinen mielipide on aina väärässä.

a4: Minulla on sellainen kokemus että kaikki vähänkin älykkäät laitteet jumiutuvat itsekseen, ennemmin tai myöhemmin ja jotkut useammin.
Omakin pää.

Gerardo: "Viidakko on äiti, eikä äitiä voi myydä tai ostaa. Äitiä voi vain suojella.  HS

Jaska

Tietomurron kohteeksi joutuneen Vastaamon tietojärjestelmien heikko laatu on ollut julkisuudessa murrosta alkaen. Nyt on saatu yksityiskohtaisempaa tietoa. Käytössä muistaakseni oli ex-toimitusjohtaja Ville Tapion hutaisemaa koodia. Tässä selvästi on "säästetty" ohjelmistokuluissa käyttäen mm. piraattiversioita. Yrittäjätoiminta luisui liiaksi laittomuuden puolelle seurauksena ikävä suuri tietovuoto, jossa potilastiedot vuosivat.

Hayabusa

Lainaus käyttäjältä: ROOSTER - syyskuu 27, 2022, 16:53:01
Tämä herättää kysymyksiä IT-porukan moraalista.

En tiedä onko olemassa luotettavia tutkimuksia eri ammattikuntien moraalista.
Eiköhän kuitenkin IT-miehet ja -naiset suurilta osin ole "puolel hyvien".
An nescis, mi fili, quantilla prudentia mundus regatur

-:)lauri

Lainaus käyttäjältä: -:)lauri - huhtikuu 20, 2022, 16:49:18
^

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - marraskuu 30, 2021, 12:22:56
Tähän viikonloppurojektiin voi tustustua osoitteessa: https://github.com/lazydistribution/tree_structure_testing. Sieltä voi myös downloadaa sen omalle koneelle.

Edit. toteutin tuon ajastuksen paremmin. Nyt ajatus toimii staattisella TimerFeature-toiminnolla. Aiemmin aikaleima sql-ajosta ja tietokantarivien määrä tallennettiin responssiin jo modelissa, nyt ne tallennetaan TimerFeature luokkaan. Nyt siis vasta Response-luokassa (luokka, jossa lopullinen json-tulostetaan) liitetään nuo seurattavat arvot responsiin selaimelle.

Toinen syy, miksi rojekti ei oikein etene, on se, että en edelleenkään tiedä, miten Ajax-endpontin koodi olisi järkevintä organisoida, ja se taas liittyy tuohon tähän viestiini ylle lainaamaani asiaan kosien aiempaa projektiani, jossa idea oli tehdä mahdollisimman kevyt "API".

Jos tuossa viime marraskuisessa rampagessa idea oli alun perin testailla vain puurakenteen renderöintiä, niin tein sen yhteydesssä ja siihen tarpeeseen sivuprojektina kevyen apin. Tälläkin kertaa mulla on ollut pääasiallisena motivaationani listata saksitut-ketjuun päätyneiden viestien lukumäärät per nimimerkki ascii-listaan ja sitten taas tälläkin kertaa on ollut vahvasti mukana yritelmä vastata kysymykseen mahdollisimman lightway-tietorakenteesta ajax-kutsuja varten, mikä tarjoaisi kuitenkin riittävästi järkeviä käytäntöjä, joita noudattamalla koodia on helppo seurata.

Viime marraskuun projekti oli edelleen ja selvästi liian raskas, koska en kokenut luontevaksi ottaa sitä nyt käyttöön. Se kelpaa hyvin argumentiksi sen käytännöllisyyttä vastaan.

Kehitinkin nyt siis vieläkin kevyemmän version, jos kohta endpointtien määrittely ei nyt edellisestä poiketen tässä versiossa tyydytä (en kamalasti pohtinut tätäkään toteutusta kunhan vain roiskin MVC-ratkaisuni mahdollisimman nopeasti pöytään). Nyt kuitenkin haluaisin ehkä sittenkin kirjoittaa endpointit samoin kuin ne voidaan kirjoittaa esimerkiksi Laravelin MVC-kirjastossa. Eli tyyliin funktiokutsu, joka ottaa parametreinä vastaan url-osoitteen loppuosan, jota ajaxilla kutsuttu ja sitten käsittelijä rakenteeltaan: ClassNameController@methodName, jossa ekana controller-luokan nimi sitten @-merkki ja sen jälkeen controller-luokassa olevan metodin nimi, joka kyseisen ajax-kutsun backendissä käsittelee.

Esimerkki endpointista jollaista haluaisin käyttää olisi seuraava:

Route::get('/users', 'UserController@index');
Route::post('/upload', 'FileController@upload');


nyt mulla kuitenkin on tällainen lista-toteutus

return [
    '/users' => 'UsersController@index',
    '/upload' => 'FileController@upload',
];

Mulla on käytössä App-niminen luokka, joka käsittelee nuo listana esitellyt endpointit, kun ajattelin esitellä suoraan App-luokan, jos jatkossa tarvitsee jotain järeämpää, mutta ehkäpä pitäisi duunaa nyt vain suosiolla tuo Route-luokka ja lisätä sitten joskus myöhemmin App-niminen luokka jos järeämpää tarvitsee. Mieluummin liian yksinkertainen ja pysytellä yleisimmissä nimeämiskonventioissa, jotta ei sido käsiä siinä mitä käyttöä tällä on jatkossa. On vain niin hankala tietää etukäteen käyttötarpeita.

Tää on tällainen ikuisuuskysymys sekä selvästi ikuisuusprojekti. Samaten voisi olla vieläkin fiksumpaa nähdä se vaiva ja ladata joka kerta käyttöön Laravel näihin pikku projekteihinkin. Oppisi käyttämään sitäkin pelkän näpertelytason osaamisen sijaan.

Kirjoitin jälleen uuden. Tällä kertaa vieläkin simppelimmän. Myös tuo haikailemani route-notaatio mukana.

Mitä tulee tuohon selainpohjaiseen kansioexploreriini, pitää ottaa luokat Laravelista ja laittaa ne tähän. Laravel-toteutuksessa ei olisi muutoin vikaa, mutta kun se ei toimi vanhemmilla konfiguraatioilla kuin kaikkein tuoreimmilla ja just ilmaantui yksi projekti, jota pitäisi edistää vanhemmilla konfiguraatioilla. Olisi mukava jos kansioexplorerini toimisi siitä huolimatta, millä versiolla kulloinkin pelailen. Ehkäpä tämä olisi juuri esimerkillinen tilanne tuolle itse rakentamalleni backend-kirjastolleni.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

Lainaus käyttäjältä: -:)lauri - toukokuu 06, 2022, 14:32:29
^
Mun ei muuten tartte frontendissä määritellä erikseen linkkien sisältöä. Kun kukin nappi tekee vain yhden asian kerrallaan jo olemassa olevalle url-osoitteelle tai query-parametreille, voin rakentaa osoitteet valmiiksi backendissä. Jos siis oikein tajusin. Pitää tosiaan olla tekemättä mitään tälle projektille niin tulee näitä oivalluksia, jotka kertyessään säästävät minut turhalta työltä.

Olen nyt pyöritellyt tovin tuota ja huomannut, että selain enkoodaa ja dekoodaa erikoismerkit kiusallisella tavalla. Muutoin ei olisi ongelmaa, mutta kun kansioiden ja tiedostojen nimissä voi olla noita enkoodauskirjasimia tyyliin plussia, prosentti-merkkejä ja numeroita. Oikeaa kansioita tai tiedostoa ei vaan löydy jos ja kun selain tulkitsee jonkun tärkeän merkin enkoodaukseksi. Huomasin, että kun mulla on esimerkiksi kaks kansiota "http://localhost/toc" ja "http://localhost/toc2" ja kun osoiterivillä on myös nuo lainausmerkit, selain tulkitsee numeron 2 enkoodaukseksi koska lainausmerkki siinä vieressä enkoodautuu prosenttikirjasimiksi tms. ja dekoodaa tuon numeron 2 prosenttimerkkien kanssa pois osoitteesta, tulkiten osoitteen "http://localhost/toc2" osoitteeksi "http://localhost/toc". En saa nyt toc2-kansiota auki selaimesta vaan se avaa ja sulkee toc2-painikkeesta toc-kansion.

Pitää ilmeisesti sittenkin base64-enkoodata nuo osoitteet osoiteriville, jotta saan ongelman pois päiväjärjestyksestä. Pitää vain askarrella sivun ylälaitaan haamukenttä, jossa näkyisi osoitteet ihmisen ymmärtämässä muodossa ja johon voisi syöttää osoitteet ihmisen ymmärtämässä muodossa. Softa sitten vain pyöräyttäisi osoitteen osoiteriville base64-muodossa. Näin voisin säilyttää ominaisuuden, että voin tarvittaessa kirjoittaa tavoittelemani osoitteen, jos en jaksa selata sitä kansiopuusta nappeja klikkailemalla auki.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

#236
Alko uusi rojekti töissä ja pääsen tekemään sen "uusimmalla" teknolokialla; Laravelin 8:lla. Aloittelinkin jo mutta paljon on nyt pähkäiltävää.

Pitäisi ladata ui mutta en tiedä, pitäisikö ladata vue vai react -yhteensopiva ui vai tarvitaanko kumpaakaan tai edes ui:ta. Tein jo yhden lomakkeen ja siinä ei tarvita laravel ui:ta, mutta ehkäpä se olisi kehittämisen kannalta hyvä idea ladata se, kun se avaa enemmän mahdollisuuksia frontendin kehittämiseen. Ehkäpä otan vue-yhteensopivan ui:n käyttöön, kun Udemystä löytyi hyvä tutoriaali vue-yhteensopivan Laravel-projektin pystyttämiseksi.

Samaten Laravelin autentikointi ja tietoturva -käytännöt eivät ole minulle entuudestaan tuttuja, eivätkä ne vaikuta toimivan ihan noin vain. Framewokkiin lähetetyllä lomakkeilla tulee olla yksilöllinen tokeni, mutta jos tarvitsen staattiselle sivulle yhden ja toisen api-kutsuun, en tiedä, kuinka molemmat saadaan staattista sivua ladattaessa. Staattiselle lomakkeelle yhden tokenin saa helposti, mutta api-kutsun tokenin saaminen vaikuttaa vielä täysin mystiseltä.

Sitten pitäisi voida kirjautua yleiseen osioon tokenilla ja ylläpitopuolelle perinteisin käyttäjätunnuksin.

Projekti ei ole kamalan laaja, mutta onneksi olemme saaneet puhuttua sille pitkän kehitysajan. Eniten kun mulla menee aikaa Laravelin opetteluun ym osin ???
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

#237
^
datepicker-lisäpalikka on sitten veikeä komponentti. Ajatus oli duunaa toi vanilla javascriptillä ja Bootstrapin css-tyyleillä mutta ilmeisesti datepicker-komponenttia ei saa ilman jQuerya. Input-kentän "date" olisi ollut muuten hyvä, mutta esimerkiksi mun selain tarjoaa amerikkalaista päiväyksen esitystapaa, enkä tiedä kuinka pakottaa date-päiväys suomalaiseksi päiväykseksi, joten pakko yrittää saada sama lopputulos aikaiseksi lisäpalikalla. Saa nähdä, saanko text-input-kentän addon-napilla toimimaan kuten tuo vakiona tuleva date-kenttä, sillä erolla, että päiväyksen formaatti olisi datepickerillä tehtynä oikea.

Edit (27.10.2022): nuo pulmat ratkesivat suhteellisen kivuttomasti. Seuraavaksi pitää ratkoa miten kuluva päivä voidaan valita nyt kun sen on saanut eri väriseksi kuin muut kalenteripäivät ja kuinka kääntää kalenterin tekstit suomeksi. Taidan vain hakkeroida javascriptillä nuo tekstikentät ja muutan tekstit sillä tavalla myös suomen kielelle. Varmaan löytyisi tähän kylkeen joku kielikirjastokin, joka hoitaisi homman kotiin, mutta koska tarvitsemani muutokset ovat niin pieniä, tämä suunnittelemani kirjastoa huomattavasti ohuempi purkkaratkaisuni lienee tässä kohtaa perusteltu.

Edit (28.10.2022): Piti laittaa timeoutilla odottamaan sata millisekuntia, kun lataaminen kestää kauemmin kuin minkä javascript ottaa ennen kuin uusi näkymä widgetistä on näytöllä. Sitä vaan, että jos ei odota, alkuperäiset tyylit eivät muutu. Täytyy tarkistaa olisiko tuossa promiset käytössä, jos on, ei ehkä tartte timeouttia, vaan voi laitaa softa odottamaan latautumisen valmistumisen eksaktia kohtaa.

Pitäisi yrittää löytää muuttuja, jolla saa vaihdettua vuosia nopeasti. Se on muistaakseni yksi asetus, joka pitää laittaa päälle, mutta en tiedä, onnistuuko ihan sillä, vai pitääkö sekin toiminnallisuus kirjoittaa ihan itse jollain toisella tavalla. Tuo olisi aika kriittinen toiminto kun kalentereissa pitää pystyä laitamaan päivämääriä eri vuosille. Toivottavasti onnistuu ilman purkkaratkaisuja.

Samaten valittu päivä ei jostain syystä jää värjätyksi. Pitää ehkä googlailla, olisiko joku vakiomuuttuja, jonka asettaa päälle ja sitten sinne tallentuisi automaattisesti joku luokka, jonka voisi sitten css:llä korostaa taustavärillä. Ei tosin ole tällä hetkellä kriittinen asia. Varmasti onnistuu käyttö ilman tuotakin ominaisuutta.

Edit: En malttanut antaa olla vaan ratkaisin tuon vuosi-ongelman. Se tosiaan oli vain yhden muuttujan takana. Tosin meni tyylien märittelyyn taas tovi aikaa.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

#238
^^
Lähdin liikkeelle helpoimman kautta. Olen rakentanut sivuston lähes kaikki sivut ulkonäöllisesti ja toiminnollisesti kuntoon. En ole ui:ta ladannut vielä, mutta mikäli onnistuu jo kirjoittamieni css- ja javascript-rivien siirto ui-ympäristöön päivitän järjestelmän ui-versioon. Ensi viikolla ehkä pääsee pohtimaan myös jo tietokantatauluja ja niiden sisältämien tietojen linkittämistä sivuille. Säästänen autentikoinnin ratkaisemisen viimeisiksi, sillä se on vielä aikalailla mysteeri vaikka jonkin laisia aihioita, kuinka tehdä se, on mieleeni jo juolahtanut.

Edit: Esittelin juuri tähän asti kasaan saamaani materiaalia asiakkaalle ja he olivat selvästi tyytyväisiä. Esimies oli myös. Alun perin esimies oli spekuloinut asiakkaalle, että ryhtyisin ensiksi rakentamaan taustalogiikkaa ja että sen vuoksi ei olisi tänään juurikaan näytettävää, mutta kun keksin lähteä rakentamaan ensin käyttöliittymää oli tavallaan "paljonkin" nyt näytettävää. Ensi palaverissa ei sitten tosin ole yhtä "paljon" uutta näytettävää, kun seuraavaksi alan ratkoa taustalogiikkaa, mutta toivottavasti saan paljon siitäkin ratkottua ennen uutta palaveria, jotta näkisivät edes jonkinlaista kehitystä projektissa (lähinnä, että sivuolla olisi tyhjien kenttien sijaan myös jotain tietokantasisältöäkin).

Edit (28.10.2022): Nyt on visu muuten kuosissa, mutta virhetilanteita varten tuleva sivu puuttuu ja ylläpito-sivut puuttuvat. Samaten tietueiden poisto on toteuttamatta. Pitää kysellä esimieheltä, millaista ideaa hän kannattaa. Laitanko listaukseen riville delete-napin, josta painamalla tietue poistuu vai jonkun valintaboksin kullekin riville ja listan alle napin, josta painamalla poistuu valitut tietuerivit, vai miten. No tämän kerkeää kyllä myöhemminkin. Ensi viikolla todennäköisesti pääsen siirtymään tietokannan rakentamiseen.

Edit: Pitää ensi viikolla asentaa vanhan palvelun tietokanta ja projekti, jotta voin paikallistaa minkä kentän arvo tallentuu mihinkin tietokantatauluun ja mihinkin ko. taulun kenttään. Onneksi ei ole kuin muutama taulu, mutta kenttiä on niissä todella paljon kun sivullakin on täyttökenttiä paljon. Täytän lomakkeet kirjoittamalla tekstikentiin uuden avaimet ja päivämääräkenttiin nousevalla/laskevalla logiikalla ja sitten paikallistan näin tietokantatauluista, mikä arvo on tallentunut mihinkin. Ehkei tuo ihan kamalan vaikea taski sitten olekaan... ...No ensi viikolla selvinnee. Esimies on messuilla kaiketi maanantaita lukuun ottamatta koko viikon, että olen aikalailla yksin projektin kanssa. Vanha järjestelmä on minulle entuudestaan tuntematon. Ehkäpä maanantaina saan vanhan järjestelmän asennettua ja ongittua esimieheltä, mistä mikäkin lomake löytyy niin onnistunee loppuviikko ilman opastusta. Ajatus on siis ottaa vanhasta järjestelmästä tietokanta ja syöttää niiden tietueet tähän uuteen järjestelmään.

Edit (08.11.2022): Viime viikko meni yhden akuutin projektin kanssa ja tällä viikolla taas päässyt tämän projektin pariin. Tää tietokantarivien liittäminen sivuille on kyllä varsin aikaa vievää puuhaa. Pitää olla pirun tarkkana, että kaikki oikeat muuttujat tulee luetuiksi oikeissa paikoissa. Sinällään kyllä hyvä, kun tekee tuota blokeissa, että eri routejen kohdalla pysyy muistissa kuinka samankaltainen operaatio tehtiin edellisessä routessa niin ei tarvitse testailla ihan niin usein kuin jos olisi tehnyt alusta loppuun aina yhden osion kerrallaan. No joo ehkä isommassa projektissa olisi ehkä fiksua tehdä jokin kokonaisuus kerralla valmiiksi, jotta asiakas pääsee testailemaan palvelun valmiita osia. Nyt kun tämä on ainakin toistaiseksi edennyt nopeasti on mahdollista, että koko palvelua testailemaan pääsee myös suht nopeasti. Kaikki riippuu siitä kuinka nopeasti onnistun toteuttamaan autentikoinnin ja kuinka nopeasti tämä saadaan vuorovaikuttamaan isäntäsoftan kanssa. Voi olla, että pitää tallentaa routeihin vielä muitakin avaimia kuin tuo yksi muuttuja. Samaten pitää muistaa muuttaa edit-buttonin toteutus form-muotoon sillä vain sillä tavalla voidaan varmistaa, että ei pääse hakkerit aktivoimaan editointia sivuston ulkopuolelta (liittyy tähän). Muut buttonit toimivatkin jo form-periaatteella. Sitten kokonaan oma leikkinsä on se, kuinka vanhan järjestelmän tietokantarivit syötetään tälle uudelle järjestelmälle. Voi olla että menee tietokannan fundeeraaminen vielä uusiksi.

Edit (10.11.2022): Nyt on softan oma tietokanta liitetty käyttöliittymään. Seuraavaksi pitää rakentaa listoihin sekä paginointi, haku että sorttaukset. Tosin tämän palikan kehittämisessä pitää kaiketi yrittää opetella syöttämään tietokantaan riittävästi hölynpölysisältöä, jotta näkee kaikki tekemänsä jutut livenä. Laravelilla tuo pitäisi olla helppoa, mutta kun en muista, kuinka se tehtiin, menee siinäkin sitten oma aikansa, että palautan proseduurin mieleeni.

Samaten pitää tehdä lomakkeiden kenttien kohdalla validointi, että syötetty tieto kelpaa tietokantaan sekä laitettava käyttöliittymään asianmukaiset virheilmoitukset, jos on johonkin kenttään syötetty tietoa väärässä muodossa.

Näiden jälkeen pääsen varmaan autentikoinnin kimppuun. Ensi viikolla pitäisi olla uutta näytettävää asiakkaalle, mutta kuten jo viime kerralla ounastelin, eniten oli näytettävää silloin. Tällä kerralla olisi kiva jos olisi tuo listojen toiminnallisuus saatu tehtyä mutta voi olla, että menee sen osalta tuonnemmaksi.

Pitää myös palaveerata esimiehen kanssa tuosta tietorakenteesta. Olen nyt laittanut tämän toimimaan niin, että kaikkia lomakkeita voi täyttää lähes missä järjestyksessä tahansa. Pitää varmistaa josko olisi kanssani sama mieltä, että tarjotaan noita yksityiskohtaisempia lomakkeita vasta sen jälkeen kun niillä lomakkeilla on tallennettua tietoa, joihin nämä yksityiskohtaisemmat liittyvät "alilomakkeina".

Edit (22.11.2022): ollu hiukka muita projekteja mutta pääsin tämän kimppuun taas eilisestä. Asiakas oli viime viikolla jälleen tyytyväinen. Nyt on listojen haku, sorttaus ja sivutus (poislukinen pikalinkki vikalle ja ekalle sivulle). Samaten kaikki käyttäjältä tulevat tiedot validoidaan nyt. Liitin softan myös isäntäsoftaan. Seuraavaksi pitää selvittää miten isäntäsoftasta tullut hyväksytty ohjaus kirjaa asiakkaan sisään tähän mun palikkaan. Esimiehen kanssa käytyjen keskustelujen perusteella olen tehnyt tämän tähän asti ihan niin kuin oli ajatellutkin, joten ei tartte muuttaa mitään.

EDIT (2.12.2022): Seuraavaksi pitää tutustua Laravelin http-lisäpalikkaan guzzleen, jotta keskustelu isäntäsoftan kanssa onnistuu.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.

-:)lauri

#239
^^^
Yritän lähteä kehittämään seuraavanlaista sisäänkirjautumista.

1. Tähän microserviceen tultaessa pääpalvelusta, mukana annetaan tokeni.
2. Tietokannasta poimitaan kirjautumistiedot tokenilla.
3. Syötetään kirjautumistiedot normaalille login-logiikalle.
4. Ohjataan oikealla roolilla käyttäjä oikeaan paikkaan.

En tiedä onnistuuko kohta 3. En tiedä, mutta veikkaan, että middlewaressa pitäisi muuttaa tokeni pyynnöksi, jossa käyttäjätunnus ja salasana, mutta kun en tiedä, onnistuuko se enää tässä vaiheessa, vai olisiko pyyntö pitänyt muuttaa jo joskus paljon aiemmin kirjautumistiedot sisältäväksi pyynnöksi. Toivottavasti ei ja että tämä lähestymistapani toimii.

Sitten en tiedä tallentuuko sisäänkirjautumistiedot sivulle siihen tokeniin, jonka Laravel generoi automaattisesti vai pitääkö kaiken lisäksi hakkeroida sisäänkirjautumistidot jotenkin esimerkiksi sivujen header-tietoihin vielä erikseen.

Edit (28.10.2022): Sain nyt sivut siihen pisteeseen, että sisäänkirjautuminen voidaan tosiaan ratkaista myöhemmin. Nyt sivut toimivat järkevästi. Jokaisessa routessa on ylimääräisenä parametrina tietueen id sitä varten, että selatessa sivustoja voidaan tietueen tietoja käsitellä eri sivuilla. Muutoin routet toimivat Laravelin käytäntöjen mukaan poislukien tuo ylimääräinen parametri.

Edit (22.11.2022): Joo elikkäs nyt asiakas tulee isäntäsoftasta tähän softaan kuten pitää. Nyt vain pitää keksiä kuinka tuo kohta 3 tehdään. Eka pitää tutustua hieman laravelin autentikointiin, jotta selkeytyy voinko ohjata käyttäjän suoraan mahdolliseen login-controleriin tms. vai onnistuuko sisään kirjautuminen kokonaan toisen controllerin kautta.

Edit (2.12.2022): Näyttäisi siltä, että Laravelilla on ajateltu myös minua. Näin alustavasti vaikuttaa siltä, että autentikointi edellytti minulta ehkä noin 6 riviä koodia. Tuossa kohtaa kun olen validoinut tokenin, riittää kappale Laravelin valmiita funktioita kirjaamaan käyttäjä sisään. Hieman sessioiden resetointia sitä ennen ja lopuksi oleelliset routet yhden autentikointimiddlewaren taakse piiloon. Eli tämä oli lopulta helppo taski.
Selvin merkki psykoosista on se, että kuvittelee ajattelevansa vain kylmän rationaalisesti ja loogisesti.