Jump to content

siDDis

Medlemmer
  • Content Count

    9874
  • Joined

  • Last visited

Community Reputation

812 :)

About siDDis

  • Birthday 05/30/1983

Profile Information

  • Kjønn
    Mann

Recent Profile Visitors

25548 profile views
  1. Høres ut som du greidde deg veldig bra. Mange får kodestopp om de må programmere på intervju, derfor tror eg det har blitt mindre vanlig å bruke det.
  2. Tekniske intervjuer skal teste dine ferdigheter innenfor algoritmer og datastrukturer og hvor godt kjent du er med økosystemet. Selv om noen drar dette ganske langt, bare for at de skal stresse deg eller vise seg selv frem. Uansett så mener jeg at om kan du forklare interfaces, abstrakte klasser, ArrayList vs LinkedList vs Map sammen med Big O notation, dependency injection, rekursjon også litt om Maven/Gradle/Spring eller Java EE/ApacheMQ/Pulsar/Kafka/Hibernate/Lucene så vil du greie deg veldig bra! Kjenner du til f.eks nye rammeverk som Quarkus/Micronaut og GraalVM så viser du også at du er oppdatert på nye ting som skjer på Java siden. Det er også en fordel at en greier å nevne 2-3 nye ting som har komt i Java siden versjon 8. Merk du må ikke kunne alt det jeg har skreve ned her, men å kunne forklare noe av disse vil eg påstå gir deg en fordel.
  3. Torch har aldri vært offisielt støttet til Windows -> https://github.com/torch/torch7/wiki/Windows Men det har fungert enn stund ja.
  4. Det meste kan gjøres med Windows nettsky, men det er langt i fra en god brukeropplevelse. All nyutvikling av nye konsepter skjer på et Linuxsystem idag. Velger du Windows så, velger du også å måtte knote igjennom en haug med problemer. F.eks sjå på kor LANG tid det tok før deep learning (med GPU) var mulig på Windows plattformen. Verken Torch eller Tensorflow støttet det i starten. Det fungerer idag, men ikke optimalt. Og når det kommer til arkitekturer for datastrømmer (med Kafka/Pulsar) så er det viktig med sync write ytelse. Her er Windows sin FlushFileBuffers enda helt elendig i forhold til Linux fsync. Det er et flust med andre eksempler. Nettskyen abstraherer bort IT avdelingen. Det er der den største gevinsten er. Rett og slett få ting gjort uten å måtte vente på ny maskinvare, endringer, brannmurregler osv. Oset er framleis i stor grad relevant, rett og slett fordi framtidens applikasjoner for infrastruktur blir primært utviklet, testet og dokumentert for Linux. FreeBSD er annenrangs og Windows er prioritert med minst mulig effort.
  5. Det typiske er så enkelt at en ikke tror den personen vil passe inn.
  6. eh... ja, altså Windows systemer har jo blitt kraftig parkert dei siste 10-20 åra. Det man kan gjøre med Linux+nettsky idag tilsvarer fort 10-100x merverdi enn typisk on-premise med Windows. Derfor har også betalingsviljen for Linuxkompetanse også økt betraktelig på det globale markedet. Typisk eksempel som går igjen i mange bedrifter i dag er data liberation, og veien dit er 100% basert linuxteknologi.
  7. Kvifor bruke WSL når du bare kan bruke Ubuntu? Du slipper unna ein haug med fillefeil, f.eks til Java utvikling så er det noen biblioteker med kompilerte moduler som ikke er inkludert for Windows. Du har også problemer med lange classpaths. Velger du å utvikle på Windows så får du en vanskeligere kvardag. Alt dette kan jobbes enkelt rundt, men tida di går. Det er også noko som heiter at utvikling og prod bør være så likt miljø som mogleg for å minimere overraskelser, det inkluderer også utvikling på Ubuntu og deployment på Red Hat 🤦‍♂️
  8. Se videoen jeg postet tidligere idag, det er mot enda nyere Q90R
  9. Altså dette viser jo perfekt kor himla drit LED/LCD er mot OLED.
  10. Eg sitter med C9 og det er den første TVen som har fått meg til å glemme banding, for det har eg ikkje sett enda. Trolig fordi banding er veldig lett å eliminere med med ein deep learning algoritme som detekterer banding og fikser på det. Det burde være mye enklere enn f.eks DLSS som skal legge til detaljer.
  11. Skalering handler om å lagre sesjoner i en database, memcached/redis. Disse er også enkle å sharde sjølv. Også kan du horisontal skalere PHP/Java akkurat som du vil. Så brukes også Apache Trafficserver eller Varnish til caching av web content(kan også cache på sesjonsnivå) Men 1 maskin idag, kan håndtere såpass mykje trafikk at du sitter verkeleg godt i det om den maskina først skulle begynne å svette.
  12. Eg meiner at server side rendering ikkje er på nokon som helst måte utdatert, og er framleis den mest effektive måten å utvikle webapplikasjoner på. Når du drar fram FAANG som som teknologiledende, så drar eg fram mitt motargument om at dei og har ein skjult agenda i å lansere overkompliserte verktøy for å kunne meir effektiv distansere seg fra potensielle konkurrenter. Bare å lese historien om SOAP og Microsoft.
  13. Det er bare raskere å last inn nytt innhold dynamisk om rekalkulering av nytt innhold er begrenset. Det gjør jeg ofte selv også, så lenge det ikke går på kompromiss av state/hvor brukeren er og at det kodemessig er enkelt. Men det blir ikke raskere når browseren må rekalkulere boundaries på ørten elementer. Det å rendre en statisk side er langt raskare og mer effektivt enn det mange vil tro på. Her er det mange gode "usynlege" optimaliseringer som har blir gjort. jQuery er derimot et veldig bra verktøy, som abstraherte avvik fra standarden mellom browsere, dei fleste brukerane av jQuery derimot kunne jo knapt kode og griset vanvittig. Det ser vi også med React, Angular og Vue idag også. Sånn var også PHP i sin tid. Men browsere idag har såpass god og jevn oppførsel at jQuery er blitt heilt irrelevant.
  14. Problemet med SPA, er at nå må du kode "state", altså hvor du er på både klient siden og server siden. Det er ikke raskere, det er vanskeligere å cache. Og du mister oversikten over hvilket scope du kjører i, når plutseleg alt kjøre i same scope. Du begynner også å kode mykje meir ekstra JavaScript for å gjøre ting som vanlig HTTP og HTML gjør for deg. Kan ikke se at det er enklere, raskere, billigere på noen som helst måte. Event handling er pisseenkelt, du kan også få fin oversikt over hvilke DOM elementer som har en event attached til seg med en debugger. Kan ikkje sjå at Virtual DOM, Fibers osv ikke blir noe annet enn enda mer ekstra kompleksitet. Også så lenge du forstår hvordan Event Loopen fungerer, så forstår en betre også hvor komplekse DOM manipulasjoner en kan gjøre uten at det blir for mange nye beregninger som gjøres i rendering biten av event loopen. For dataflyt mellom kode og DOM elementer så bruker eg Observer Pattern med stor suksess. Tipper det også er betydelig enklere enn Redux/Flux. Finnes også andre design patterns her. Eg skriver verken mitt eget rammeverk eller bruker JavaScript rammeverk. Eg prøver å løse mest mulig med HTTP, HTML, CSS(Eller standard nettleseroppførsel) og minst mogleg JavaScript.
  15. Kan noen fortelle meg hva som er bra med React? Eg ser bare enkle ting som blir gjort vanvittig komplisert, med fleire bugs, med dårligere ytelse, og som tar minst 10x meir tid å lage enn å bare skrive HTML og CSS (nei du trenger ikkje javascript til all form for dynamikk). Kunne aldri falle meg inn å bruke det.
×
×
  • Create New...