Gå til innhold

torbjørn marø

Medlemmer
  • Innlegg

    797
  • Ble med

  • Besøkte siden sist

Innlegg skrevet av torbjørn marø

  1. Du er enig med meg, det vet du da godt

    Jeg er ikke direkte uenig nei. Men jeg syntes ikke nødvendigvis at påstandene dine er berettigede eller relevante å komme med i denne tråden. Og jeg synes du er alt for bastant og kategorisk - du ser alt i svart/hvitt. Klart fyren kan være webdesigner selv om han har laget en Silverlight-only webside - han kan da ha laget mange andre ting vi ikke kjenner til. Det er også klart at det finnes bruksområder for plugin-only webløsninger. Og klart det er nyttig å eksperimentere, og å teste grensene for hva teknologien kan tillate. Å stå og preke absolutte sannheter fører ikke til noe interessant.

  2. Var på et HTML5-foredrag med en web-dude fra Opera i fjor, og han sa at man ikke behøvde å bruke HEAD og BODY-taggene lengre. Siden har jeg stort sett droppet dem - alt fungerer like fint uten dem ser det ut til. Er dette riktig oppfattet? Hvorfor bør man gjøre det? Hvorfor bør man ikke gjøre det?

  3. Når det er sagt, kan du ikke kalle deg en webdesigner når du lager en fullstendig webløsning i Silverlight--det er ikke det Silverlight er ment til (ikke Flash heller for den saks skyld). Om du ikke er godt kjent med HTML5, CSS3 og stilrene designmanerer blir du rett og slett forbisett av seriøse webløsningsaktører. Veien fra grafisk designer til webutvikler er ofte lang, og jeg har sett flere som har måttet tømme den proverbiale koppen for å kunne fjerne seg med mange gamle uvaner.

    Hvem utnevnte deg til webutviklingspoliti?

  4. Det finnes masse gode grunner til å benytte SP. Jeg jobber for tiden med en del enterprisesoftware der vi har flere systemer som snakker med samme database. Ved å benytte SP som eneste tilgangsmetode til datene sikrer vi at flere applikasjoner kan snakke med samme database uten at inkonsistent koding skader dataintegriteten.

    Å bruke databasen som et integrasjonspunkt ser mange også på som et anti-pattern (meg inkludert). Men det har i lange tider vært en vanlig praksis mange steder. Er du i en slik situasjon så blir SP din eneste mulighet til å sikre konsistent forretningslogikk. Dilemmaet er da altså at SQL sjelden er det beste språket for å beskrive slik logikk.

     

    Som det sies over her; SP er ingen beskyttelse mot dårlig SQL, siden det rett og slett er SQL. Det det imidlertid er er en strålende metode for å sikre konsistente data inn og ut fra en database når man har en mer kompleks som ikke tillater "SELECT * FROM tabell".

    Poenget mitt kom kanskje ikke helt frem. Vanslig praksis blant databaseadministratorer fra fossefall-tiden var å fjerne tilgangen til alt annet enn SP for alle andre enn seg selv, og så tilby et SP-lag som alle apper og utviklere måtte bruke. Og det var databaseekspertene som skrev SP'ene, ikke utviklerne. SP var altså verktøyet de brukte for å hindre at utviklerne fikk rotet med SQL overhodet.

     

    Min oppfatning er at det er dette som gjorde SP'teknologien populær. Selvsagt har det bruksområder (som jeg påpekte), men først og fremst (hevder jeg) har det vært en beskyttelsesmekanisme.

     

    .. som førte til at databaseadministratorene ble en flaskehals for å få levert funksjonalitet. Behov måtte spesifiseres og leveres over muren til en annen avdeling som så kodet SP'ene. Er så glad det ikke finnes så mange slike steder lengre.

     

    (Bra blogg forresten, herved lagt til i Reader :) )

    Takk ;D

  5. SQL har ingenting i koden å gjøre er å sette det på spissen, men jeg mener definitivt at man bør prøve å standardisere databasekallene best mulig ved å bruke SP der det passer seg seg sånn.

     

    Men kan være enig med deg i at forretningslogikken lever best i koden.

     

    Stored procedures eksistserer først og fremst som en forsvarsmekanisme som databaseadministratorer bruker for å beskytte databasen sin mot ubrukelige programmerere som skriver dårlig SQL. Denne modellen har vi nå heldigvis beveget oss bort fra, og da er SP kun nyttig i helt spesielle tilfeller hvor man trenger nærhet til dataene og kraften som ligger i databasemotoren.

  6. Bøker har aldri gitt meg noe som helst.

     

    snipp

     

    Edit: dette er sånn det virker for meg iallefall. Kan fungere annerledes for andre.

    Det laserlars anbefaler er veldig bra, men man bør lese litt i tillegg for å sørge for at fundamentet er på plass. Hull i kunnskapen kan for eksempel føre til at du gjør ting unødvendig tungvindt.

     

    Den beste kilden til hva som er de mest brukte/mest populære programmeirngsspråkene er forresten TIOBE. Der ser du at Java og C ligger på topp, og at C# og C++ følger et lite stykke bak. Men språkene er verktøy, og ulike verktøy egner seg best for ulike oppgaver. For å lære programmering, spesielt når du gjør det på egenhånd, anbefaler jeg et dynamisk språk. F.eks. Python, Ruby, eller (grøss) PHP.

     

    Tenk også på at de beste arbeidsgiverne verdsetter kunnskap om litt sære språk - det viser at du ikke bare følger strømmen, men er villig tl å lære noe som ikke alle andre kan.

    • Liker 1
  7. Vil ha kvalitet fra bunnen av (selv om det bare er fritidsprosjekt kan det jo alltids hende at det blir tatt skikkelig i bruk senere)

    Bare et råd å ta med på veien:

     

    Å lære seg programmering fungerer sånn at du må gjøre det igjen og igjen og igjen, og etterhvert finne ut hva som fungerer best i ulike situasjoner. Så når du skal starte et nytt prosjekt er det bedre å bare hoppe i det, og ha i bakhodet at du alltid kan endre det du gjør, og kanskje starte helt fra scratch igjen om du ender opp med noe som ikke er så lett å jobbe med.

     

    Forsøk ulike strukturer, og vurder underveis hvor enkelt/vanskelig du føler det er hver gang du skal implementere noe ny funksjonalitet. Må du gjøre endringer mange ulike steder, eller kan du utvide løsningen din uten å rote med eksisterende kode? Er det lett å finne frem etterhvert som løsningen vokser? Etc.

     

    Det kan hende det er litt for tidlig for deg å tenke på denne måten - i starten kan det være greit med klare og tydelige regler - men etterhvert må du begynne å eksperimentere. Husk at du ikke må ha alle svarene før du kan lage noe. Gjør det heller quick and dirty først, sånn at du får noe opp å kjøre. Da ser du hvordan det virker, og du kan refakturere koden til den blir fin og medgjørlig.

     

    Lykke til med hobbyprosjektet!

    • Liker 1
  8. Designet virker rotete pga. mange bokser inne i andre bokser, og for mange bråkete annonser. Det er alt for mye som trekker oppmerksomheten min. Fokuser mer på innholdet.., mer luft, større font. Tror det hadde vært bedre å skrive teksten som en "artikkel" enn å spre det rundt i bokser. Og hvis du skal bruke bokser bør de passe sammen i størrelse og posisjon (harmoni og symetri).

  9. Spørsmålet ditt er veldig åpent, og jeg er ikke sikker på hvilket behov du egentlig forsøker å dekke. Virker som om du trenger å få haket av et punkt i en formell kravliste knyttet til oppgaven i stedet for å dekke et behov knyttet til selve løsningen?! Sånn er det jo ofte under utdannelsen...

     

    Kan ikke hjelpe deg i forbindelse med dokumentasjon, men jeg ville sett litt på automatisert integrasjons-/interaksjonstesting. Altså skrive kode / bruke verktøy som bruker webløsningen du har laget, og som kan verifisere forventet oppførsel. Mange måter å gjøre det på, og ikke alltid det funker så bra, men gir ofte stor verdi når man får det til.

     

    F.eks. kunne du skrevet enhetstester i JavaScript som brukte Phantom.JS: litt info om det her.

     

    Andre verktøy som ofte brukes til dette er blant andre Watir (om du vil bruke Ruby), Watin (for .NET) og Selenium (ulike språk). Alle disse kan automatisere browsere på en eller annen måte. Jeg har litt erfaring med alle disse, men har mer tro på at headless browsere som Phantom.JS er veien å gå akkurat nå.

  10. Vi lyste akkurat ut noen ledige stillinger for vår utviklingsavdeling i Bergen. Annonsen ser du her!

     

    Skrev også en liten bloggpost: Vil du jobbe med meg?

     

    To av stillingene krever spesiell kompetanse - mobilt internett og mobile apps, men utenom det ser vi også etter generelle systemutviklere. Vi har hverken avgjort hvor erfarne kandidatene må være eller satt strenge krav til hva du må kunne - for oss er det viktigere å finne folk med den rette instillingen og motivasjon til å lære og til å lage gode løsninger. Så jeg vil oppfordre både gamle og nye utviklere til å søke!

     

    Har du noen spørsmål om PSWinCom eller stillingene er det bare å fyre løs her.

  11. Er det noensinne feil å bruke predikert and (altså ikke utføre uttrykket på høyre side dersom det venstre ikke er sann) i et boolesk uttrykk?

    Altså && vs. & i C språkene, AndAlso og And i BASIC.

    Å basere seg på slik oppførsel er skummelt fordi det ikke kommuniserer så godt. Men i noen kulturer (les: Common Lisp) tror jeg det er ganske vanlig. AT man f.eks. i stedet for å skrive:

     

    (if (and (some-test) (some-other-test))
       (do-something))
    

     

    ..skriver:

     

    (and (some-test) (some-other-test) (do-something))
    

     

    Det du mener, ikke sant?

     

    Men det er ikke akkurat det du spør om. Tolker spørsmålet ditt som om man noen ganger trenger å bruke "and" som utfører alle predikatene uansett, og jeg kan se for meg det også, men synes det blir enda mindre leselig. Da ville jeg i stedet ha mappet over alle predikatene, og til slutt testet om alle var true (om du skjønner).

     

    F.eks. i Ruby:

    if [some_test(), some_other_test()].all?
       do_something()
    end
    

     

    Dette er nødvendig om testene har side effects som er nødvendige!

     

    :)

  12. Herr Marø, dette hadde jeg ikke ventet av deg. Kan du ikke ta deg tid til å formulere et svar selv, så bør du la være å poste her inne. Dessuten har artikkelen du linker til lite å gjøre med det trådstarter spør om.

     

    Siden det ikke var noen svar her så følte jeg for å hjelpe, selv om jeg ikke kjenner Java noe særlig lenger. Jeg beklager at jeg ikke skrev noe mer, men hadde ikke tid.

     

    På meg virket det som om TS trodde han kunne pakke en ressursfil inn i en jar og så forholde seg til den som om den lå på filsystemet. Det går vel ikke?! Så løsningen er embedded resources, og linken min viser hvordan man legger det til og så aksesserer det. Hvis TS er interessert så leser han artikkelen og finner ut av det. Jeg har desverre ikke noe mer å tilføre, men følte det jeg gjorde kunne løse TS's problem...

  13. Mange, mange år siden jeg gjorde noe slikt. Erstattes enten med polimorfisme eller en eller annen form for dispatch table. Kommer jo veldig an på hva problem du skal løse dette her, men sånn kode som det der har en tendens til å råtne fælt over tid. Sier ikke at svære switcher, eller nøstede switcher for den saks skyld, er direkte feil, men det finnes ofte bedre måter å løse det på som dokumenterer bedre og som er enklere å utvide og endre over tid.

  14. Men hvilke sider/utgivere innen programmering er det verdt å studere på?

    Online sertifisering har til nå ikke vært noe å trakte etter. Det skjer derimot en aldri så liten revolusjon nå, hvor de store utdanningsinstitusjonene som Cambridge og MIT begynner å tilby online kurs som er helt åpne for hvem som helst og helt gratis. Se http://web.mit.edu/newsoffice/2011/mitx-faq-1219.html . De skal visstnok også kunne gi deg en sertifisering ved endt kurs, men mulig det koster en liten slant (har ikke sjekket).

     

    Noen arbeidsgivere ser nok på sertifiseringer, og det kan være greit å ha om man mangler utdannelse/erfaring, men å ha noe "virkelig" å vise til, noe du har gjort, er langt bedre. De fleste arbeidsgivere vil også teste dine kunnskaper, uavhengig av hva du kan på papiret, så i praksis går det som regel an å si klart å tydelig hva du kan, uten å skrøne på deg noe, og du vil da ikke stille noe dårligere enn en som har noen "uoffisielle" sertifiseringer.

×
×
  • Opprett ny...