Gå til innhold

Jbrat

Medlemmer
  • Innlegg

    10
  • Ble med

  • Besøkte siden sist

Innlegg skrevet av Jbrat

  1. Kjenner jeg blir ganske provosert over denne artikkelen som nærmest fremstår som om den "taler på vegne av alle komfort pendlere".

    #1 Ditt store problem med nett løses langt på vei ved at du bruker mobilen din fremfor fellesnettet på toget

    #2 Jeg enig i at pri #1 er å ha en sitteplass (selv om man møter opp sent). Uten dette blir det ganske vanskelig å jobbe. - kaffe og aviser er for meg også uinteressant. Hadde vært bedre med tilgang på noe så enkelt som vann.

    #3 Må man sitte trangt, med PC i fanget risikerer man helseskader over tid. Undertegnede har pådratt seg nakkeprolaps som en direkte årsak av dette, og man trenger derfor også et anstendig bord å jobbe på.

     

    Oppsummert, Wifi er ikke nødvendigvis et stort problem i praksis. Å kaste bort tid på booking av seter og kaste ut personer er for meg en elendig kundeopplevelse. Å ha et kvalitetstilbud/arbeidsplass til mennesker som bruker store deler av livet sitt på toget anser jeg derimot som svært viktig.

  2. Det sies at telefonen ikke har noen klare ulemper - men den har en enorm mangel, den støtter nemlig ikke Progressive Web Apps. Android-baserte telefoner støtter i dag moderne Web Applikasjoner på en måte som gjør at de oppfører seg tilnærmet likt native apps. At dette ikke nevnes her er bemerkelsesverdig. En rekke store nettsteder er allerede PWA'er som f.eks. Twitter og Alibaba. Men iOS brukere får ikke glede av dette men må installere apper på 100vis av megabyte, drive med oppdatering av disse etc. Jeg byttet fra iOS til Android i år, etter å ha brukt iPhone i 7 år.

    • Liker 1
  3. Det virker på meg som om Purple.js fjerner absolutt alle fordelene ved å benytte Javascript på serversiden, for dette er vel egentlig rett og slett Java, sett bort i fra at man kan skrive i JavaScript, men det virker som om det ikke er stort annet enn en transpiler?

     

    Er det slik at Purple.js da ikke støtter asynkron kode i det hele tatt, og heller ikke Promises, async/await, timere eller noe slikt?

     

    Nå står det også veldig lite om hvilken motor som brukes i Purple.js, og hvilke versjoner av EcmaScript som støttes av Purple.js, men dette fremstår mer og mer som Nashorn pakket inn i fint papir med en sløyfe på, inkludert CommonJS og litt andre greier, men det er mulig jeg tar feil her også, jeg gidder ikke lese kildekoden, og dokumentasjonen er mildt sagt elendig.

     

    PurpleJS benytter p.t. Nashorn som motor. PurpleJS har også et http-rammeverk som minner en del om express.js - med bl.a. mulighet til å benytte templating språk som er implementert i Java - f.eks. Thymeleaf.

     

    Når det gjelder async har hovedfokus vært å gjøre det enklest mulig å komme igang med Javascript på serveren, derav fokus på bruk av multitreading og minst mulig async. Når det er sagt jobbes det med å se på hvordan PurpleJS kan benyttes også i async sammenheng bl.a. ved bruk av Netty i steden for Jetty.

  4. Noen fagmiljøer innen IT bygger stadig høyere teknologistacker for å løse de samme gamle problemene, mens andre bygger stadig tynner teknologistacker for å løse nye problemer.

     

    Det er mitt beste tips til filter når en skal spare tid på å sette seg inn i ny IT fordi det skjer så sykt mye at en kan ikke være oppdatert på alle mulige løsninger under pari. Denne inkludert.

     

    Hei Anders! Det skjer definitivt mye på teknologifronten - men jeg skjønner ikke helt hvilke "gamle problemer" du mener PurpleJS løser?

     

    Vil du si at MongoDB + Elasticsearch + NodeJS med Express + 3part CMS med tilhørende SQL server er en tynnere eller tykkere stack enn f.eks. Enonic XP - hvor alt dette er i praksis er tilgjengelig fra en enkelt runtime?

     

    Innlegget ditt falt også litt igjennom for meg siden du påstår at løsningen er under pari, når det fremgår så tydelig at du ikke har satt deg inn i den. Et slikt utsagn vil jeg kunne påstå er ganske tynt :-)

  5.  

     

    ... Men generelt gir det mer mening i mitt hode å skrive serverside kode i Java når man har et serverside miljø for Java allerede. 

    Fordelen man er ute etter i nodejs er at webutvikleren tar å lager interaksjon og presentasjon uavhengig av balansen mellom hva som bør ligge på klientsiden og server-siden og man kan også sikre en lav terskel for å få funksjonalitet ut i produksjon, fordi det berører ikke den "ekte" server-siden og konsekvensene er ikke så store hvis alt går galt. :-)

     

     

     

    Er det noe særlig smart å ha "to serversider?" Bugs er greit så lenge man ikke lager dem på "ekte" server? Hm ... 

    Antar det @tovar sikter til her er back-end vs server vs klient? Skillet må ikke nødvendigvis gå ved et http-kall.

  6. Men generelt gir det mer mening i mitt hode å skrive serverside kode i Java når man har et serverside miljø for Java allerede. 

    Vår erfaring tilsier at Java-utviklere flest både liker og egner seg best til å bygge back-ends - gjerne med kommandolinjen som grensesnitt :-). Når man bygger moderne webapplikasjoner og nettsteder krever disse ofte et tett samspill mellom server og front-end. Dette er nok også bakgrunnen for den store fremveksten av Node.js. Med hhv PurpleJS eller Enonic XP kan front-end folket også bygge endepunkter og tjenester på serveren uten å besitte Java-kompetanse. Nå har man i det minste muligheten til å velge tilnærming i Java-prosjekter, og ikke minst bruke de ulike verktøyene der man får maksimalt ut av de. For å komme igang raskt med PurpleJS: http://webagility.com/posts/purplejs-the-alternative-to-node.js-for-java-projects

     

    For ordens skyld vil jeg også påpeke at Enonic XP er langt mer enn en publiseringsplattform da det er en komplett stack med applikasjonsmotor, nosql database og identity-løsning. CMS'et er bygget på toppen av dette - og gir applikasjonsutviklere mulighet til å gjøre nettsteder av sine applikasjoner, ikke motsatt. Det finnes også et marketplace for Enonic XP: https://market.enonic.com :-)

×
×
  • Opprett ny...