Webkafeen

[Cucum(r)]

@Sebba: Har de som lager programvaren nødvendigvis best kompetanse på optimal drift av servere. Det stemmer nok langt fra i de fleste tilfeller. Betyr det at du er dyktig i utvikling med PHP, Ruby etc at du er dyktig til å optimalisere Linux og Apache.

Vi har naturligvis egene folk som drifter serverene hos oss. Og ja, jeg kan garantere deg at våre sysadmins er best på å drifte VÅR applikasjon.

Ingen andre som vet hvordan den fungerer

Erfaringsmessig vil eg seie meg enig med Bolson her. Ei bedrift som spesialiserer seg på drift/hosting har i dei fleste tilfeller større sannsynligheit for å gjere det bedre enn in-house hosting. Fokus på kjernevirksomheit fører nesten uten unntak til bedre resultater. Edit: Dette er sjølvsagt med forbehold om at hosting/driftsforetaket veit kva dei driv med.

Det med at ingen andre veit korleis applikasjonen fungerer er jo tullball – det går fort å lære seg. :-)

 

Er skeptisk til innelåsing når det kjem til store prosjekter, men at Snekker Hansen ANS bruker f.eks. Keyteq eller NSN til firmasida si ser eg ingen verdens problemer med.

Endret 11. november 2008 av Henrik Lied

[Haraldson]

Tja, sjekk segmentet vi retter oss mot, Henke. Ikke mange Snekker Hansen-er lenger.

[Cucum(r)]

Tja, sjekk segmentet vi retter oss mot, Henke. Ikke mange Snekker Hansen-er lenger.

Hm, stemmer, har ikkje sett på "Referanser" sidan pre-redesign. Beklager, beklager.

 

Når det kjem til nettbutikker o.l. er det vanskelig å slå seg til ro med dei åpne løysingane, og da fins det jo insentiv for å gå for det beste på markedet.

Likevel, det går ofte tilbake til det eg sa tidligare – ei bedrift bør fokusere på kjernevirksomheita si, og i nokre tilfeller gir det fullstendig meining å satse på den løysinga som der og då passer bedrifta best, sjølv om det fins alternativ som ikkje fører til innlåsing.

 

Men for å stille spørsmål i staden for å komme med bastante uttalelser: Om ein av dei større kundane til din arbeidsgiver bestemmer seg for å bytte til ein konkurrent – korleis blir dette då håndtert? Får dei ein databasedump av dataene? Har dei moglegheita for å kjøpe KeyPublisher? etc, etc..

Endret 11. november 2008 av Henrik Lied

[Arve Systad]

Eg ser gode argument frå begge sider, og det heile bunnar vel ut i at om innelåsing er ein bra eller dårlig ting kjem veldig an på svært mange faktorar;

- Kvalitet på tjeneste

- Oppfølging

- Pris kontra å bruke fleire tredjepartar

- Krav til tjeneste

- Sikkert ein million andre ting

 

...samt at størrelsen på firmaet som skal kjøpe tjenesta vil vel vere med å påverke ting. Veldig store firma med store ressursar (Typisk store internasjonale aktørar) vil sjølvsagt stille heilt andre krav på alle nivå enn mindre firma.

 

I mine auge fins der ingen fasit, då det er såpass mange faktorar som spelar inn i kvar enkelt situasjon. Kva som passar best for firma X blir ein vurderingssak der og då. Klart det går an å trekke generelle linjer som at "Store firma vil i mange tilfelle tjene mest på slik, mens mindre firma vil ha det best med sånn.", men det blir berre eit grovt overslag uansett.

Endret 11. november 2008 av Arve Systad

[Haraldson]

Har dei moglegheita for å kjøpe KeyPublisher? etc, etc..

KP er ikke akkurat åpen programvare, så om de skal over til en konkurrent er det vel svært lite sannsynlig at de får kildekode og hele sulamitten. Med de større kundene er som regel prosessene så omstendelige, valgene så gjennomtenkte etc. — når firmaet først er kunde hos oss er det gjerne en god grunn til det. Og når et firma av det kaliberet først bestemmer seg for å bytte leverandør, skulle jeg tro det blir nye sider uansett. Det er min erfaring, i alle fall. Og jeg tror et slikt firma ville ha gjort det samme med en åpen løsning.

 

Eg ser gode argument frå begge sider, og det heile bunnar vel ut i at om innelåsing er ein bra eller dårlig ting kjem veldig an på svært mange faktorar;

- Kvalitet på tjeneste

- Oppfølging

- Pris kontra å bruke fleire tredjepartar

- Krav til tjeneste

- Sikkert ein million andre ting

Selvfølgelig. Det har vel vært et poeng jeg har prøvd å få fram veldig lenge. Ikke at 'innelåsing' er flott og det beste for alle kunder, men at meningene om det har vært ensidige og negative, mens åpne løsninger heves opp i skyene.

 

...samt at størrelsen på firmaet som skal kjøpe tjenesta vil vel vere med å påverke ting. Veldig store firma med store ressursar (Typisk store internasjonale aktørar) vil sjølvsagt stille heilt andre krav på alle nivå enn mindre firma.

I mange tilfeller, ja — i en del tilfeller nei. Det finnes både svære selskaper som leverer møkk, og bittesmå selskaper som leverer gull. Og vice versa. Som du sier.

 

 

Henke: Har du forresten noe innspill angående hCard? Du som er sånn microformat-nerd, mener jeg.

Endret 11. november 2008 av Haraldson

[Cucum(r)]

Har dei moglegheita for å kjøpe KeyPublisher? etc, etc..

KP er ikke akkurat åpen programvare, så om de skal over til en konkurrent er det vel svært lite sannsynlig at de får kildekode og hele sulamitten. Med de større kundene er som regel prosessene så omstendelige, valgene så gjennomtenkte etc. — når firmaet først er kunde hos oss er det gjerne en god grunn til det. Og når et firma av det kaliberet først bestemmer seg for å bytte leverandør, skulle jeg tro det blir nye sider uansett. Det er min erfaring, i alle fall. Og jeg tror et slikt firma ville ha gjort det samme med en åpen løsning.

 

Jepp, men korleis er moglegheita for å transportere med seg dataene? Det er det viktigaste slik eg ser det – at kunden har moglegheita til å ta med seg dataene han har lagt inn i systemet, uten mykje om og men. Viss dette er enkelt og greitt, ser eg ingen problemer akkurat der.

 

Ang hCard så kan du sjølvsagt skrive faks, så lenge klassenavnet stemmer overens med spesifikasjonen.

Endret 11. november 2008 av Henrik Lied

[Haraldson]

Flott, så det er rett og slett bare 'overskrifter' for linja, slik jeg mistenkte.

 

Angående transportering av data er jeg usikker. Ville en dump av filene og hele databasen ha hjulpet deg om du skulle ha overført et nettsted?

Endret 11. november 2008 av Haraldson

[Cucum(r)]

Flott, så det er rett og slett bare 'overskrifter' for linja, slik jeg mistenkte.

 

Angående transportering av data er jeg usikker. Ville en dump filene av hele databasen ha hjulpet deg om du skulle ha overført et nettsted?

Selvfølgelig – om det er mogleg er jo saken mykje mindre. Kostnader er det alltid ved overganger til nye platformer uansett, og ein databasedump er veldig greitt.

Har sjølv opplevd eit skikkelig grusomt datamigreringsprosjekt som innebar XML-filer uten konsistens (fælt Java-basert system), samt at 30% av innholdet var skrevet til ferdiggenererte flatfiler, og databaseinformasjonen fjerna, så screenscraping var den einaste måten ein kunne hente ut innholdet. Det er vel derfor eg har denne generelt innbitte skepsisen mot propitære og lukka system.

Endret 11. november 2008 av Henrik Lied

[Haraldson]

Jeg skulle tro det greit skulle la seg ordne å dumpe ut databasen for en site, altså. Uten at jeg har peiling, men tror det er ganske oversiktlig og greit å få til.

[Steinmann]

Jeg skulle tro det greit skulle la seg ordne å dumpe ut databasen for en site, altså. Uten at jeg har peiling, men tror det er ganske oversiktlig og greit å få til.

Dere skal ha rimelig spessiell databasestruktur om det ikke er mulig å dumpe enkelt innhold.

Produkter etc går jo også ann å dumpe, men da må man gjerne tolke litt mer.

[Cucum(r)]

Jeg skulle tro det greit skulle la seg ordne å dumpe ut databasen for en site, altså. Uten at jeg har peiling, men tror det er ganske oversiktlig og greit å få til.

Dere skal ha rimelig spessiell databasestruktur om det ikke er mulig å dumpe enkelt innhold.

 

Eit eksempel er jo pre-genererte statiske filer. Altså at input fra bruker blir generert til statiske filer i staden for å dynamisk hentast frå ei database. Ja, det fins fortsatt løysinger som dette.

[Haraldson]

Oppdaget plutselig at det er problematisk å posisjonere bilder i IE6. Regner med at det er hasLayout-problematikk, men ingen forsøk på å gi img layout har så langt vært suksessfulle. Noen forslag?

[Steinmann]

Jeg skulle tro det greit skulle la seg ordne å dumpe ut databasen for en site, altså. Uten at jeg har peiling, men tror det er ganske oversiktlig og greit å få til.

Dere skal ha rimelig spessiell databasestruktur om det ikke er mulig å dumpe enkelt innhold.

 

Eit eksempel er jo pre-genererte statiske filer. Altså at input fra bruker blir generert til statiske filer i staden for å dynamisk hentast frå ei database. Ja, det fins fortsatt løysinger som dette.

Tror G3 shoppen var skrevet i vb6 elns

[Bolson]

Tror det er viktig å presisere en ting her. Innelåsing har intet med om systemer er åpen kildekode eller om de er proprietære å gjøre. Nå er det vanskelig å etablere full innelåsing på et system som er åpen kildekode, fordi kunden gjør som han vil med kodebasen. Innelåsing er egentlig en økonomisk effekt av at leverandør kontrollerer hele (store deler av) verdikjeden, og således kan ta en høyere pris over tid en normal markedspris grunnet størrelsen på byttekostnader. Nå sier jeg ikke at Keytec og NSN gjør det, regnskapene tyder i alle fall ikke på det.

 

Samtidig medfører f.eks system basert på JSR-170/JSR-283 at man i teorien kan skifte hele løsningen uten å røre innholdet, i den sammenheng kan det nevnes at JSR-283 er under implementering i PHP. F.eks ville valg av en slik standard for "content repository" medføre at "inhouse"/proprietære løsninger mistet mye av byttekostnadene.

 

Byttekostnader (innelåsing) har også vel så mye med om det finne alternative leverandører av et system (ikke nødvendigvis ulike produsenter). EpiServer er et proprietært system (faktisk asp.net basert og med svært akseptabel pris for mange aktører), men det er over 100 firmaer globalt som "selger" det, dvs implementerer, hoster, videreutvikler og tilpasser, og faktisk konkurrer beinhard med hverandre om kundene. Faktisk har jeg i flere tilfeller anbefalt dette som system for kunder.

 

Generelt vektlegges potensielle kostnader ved innelåsing svært lite ved investeringsbeslutninger, selv om det har fått økt fokus i offentlige anbud (åpne standarder). Skal nesten garantere at hadde det blitt lagt inn, så hadde "løsninger" med "innelåsningstendenser" tapt mer eller mindre konsekvent gitt andre kriterier like. Men konsekvensen oppdager du først når du sitter der.

 

Men det er klart at koster et "inhouse" system kr 100 000 totalt i levetida, og alternativet (uten særlig innelåsing) 200 000 så vil allikevel "inhouse" systemet være rimeligere. Selv om man beregner inn potensiell effekt av innelåsing. Men er prisen kr 100 000 og 115 000 ville jeg uten tvil anbefalt det siste, gitt resten av kjøpskriteriene like og tilfredsstilt.

 

Ellers så kan databasedump hjelpe, og det er en enkel operasjon i alle SQL-baserte databaser (tar ca 10 - 15 min i både MySQL, MS SQL, Oracle med flere for en database for et 800 siders nettsted), men ofte er det så fundamentale forskjeller i databasedesign på to system at "screenscraping" går like fort som å lage en "importer". Problemet er i tillegg "filrepositoriene" (bilder/dokumenter).

 

@Henrik: Forstår godt din skepsis, som jeg klart deler. Etter over 20 år med "lukkede" løsinger med svært store byttekostnader innen de fleste områder av IT-løsninger søker jeg konsekvent å redusere innelåsing og lukkethet.

Endret 11. november 2008 av Bolson

[Steinmann]

http://spreadsheets.google.com/viewform?ke...4ESmnj0NfiFpHUg

[Lovskogen]

Er din definisjon av innelåsing at kunden ikke kan ta med seg informasjonen sin (gjøre en dump av databasen) og gå til en annen aktør med det?

[Magnus Holm]

<keygen>

[Steinmann]

http://jeffcroft.com/blog/2008/nov/10/djan...late-tag-sucks/

Old new, I know. Men ikke fått lest før nå.

Han har et poeng da gitt

[Cucum(r)]

http://jeffcroft.com/blog/2008/nov/10/djan...late-tag-sucks/

Old new, I know. Men ikke fått lest før nå.

Han har et poeng da gitt

Joda, greitt nok, det – men prosessen kan forenklast veldig ved å bruke name-parameteret i url-deklareringa i urls.py.

Eg bruker {% url %} for det meste når eg refererer til statiske deler av ein applikasjon.

 

Eksempel:

urls.py

url(r'^grupper/$', view=admin_views.group_list, name='telegenic_groups'),

example.template.html

<ul id="menu">
  <li><a href="{% url telegenic_groups %}">Grupper</a></li>
</ul>

 

…men når eg refererer til eit spesifikt objekt i databasen, bruker eg {{ object.get_absolute_url }}:

{% for entry in entry_list %}
<a href="{{ entry.get_absolute_url }}">{{ entry.title }}</a>
{% endfor %}

 

Eg kunne sjølvsagt spesifisert denne slik også:

{% for entry in entry_list %}
<a href="{% url entry_list entry.slug %}">{{ entry.title }}</a>
{% endfor %}

…men dette er slettes ikkje nødvendig (både treigare for Django å parse, og for deg å kode opp)

 

Men ja, det er dumt at den kaster ein 500-error. Det burde fiksast.

 

[qualbeen]

Flott, så det er rett og slett bare 'overskrifter' for linja, slik jeg mistenkte.

 

Angående transportering av data er jeg usikker. Ville en dump av filene og hele databasen ha hjulpet deg om du skulle ha overført et nettsted?

Husk på at vi støtter import og eksport av det meste av kundedata, produktdata, ordrer, etc. allerede til et knippe spesifikke formater. En database-dump er jo heller ikke noe problem å ordne - rent teknisk.

 

Så var det jussen: Det som er typisk i lock-in-situasjoner er vel at kunden juridisk sett ikke har kontroll over data. Med andre ord har man selv skrevet under på at firmaet man benytter har opphavsrett på kundespesifikke data. Selv har jeg ikke finlest standardkontraktene våre, men jeg håper (for kundens skyld) at vi i Keyteq ikke krever opphavsrett på informasjon kunden selv har lagt inn! Jeg klarer virkelig ikke å se for meg noe annet heller - men jeg vet jo ikke.

 

Skriver man som kunde under på at leverandøren man benytter, eier alt av informasjon som ligger på nettstedet, har man gjort en gedigen tabbe selv. I en slik situasjon er det vanskelig å kreve utlevering av data - med mindre man har en velvillig leverandør. Igjen: jeg kan ikke se for meg at Keyteq ville kranglet med kunden hvis en slik kontrakt lå til grunn og kunden ønsket å få utlevert "sine" data. Men jeg vet jo ikke...

 

Jeg har iallefall ikke hørt om noen kunder som har hatt denne problemstillingen hos oss, så jeg antar det ikke er tilfelle. Men her kan vel Hein og Tor som har litt lenger fartstid i firmaet eventuelt av-/bekrefte min påstand. (Hvis de ønsker - kanksje litt feil av meg å dreie tråden over på en analyse av Keyteq )

 

Ang. hosting av servere: Hos Keyteq bruker vi faktisk ikke designere, selgere, programmerere o.l. til drifting av maskinparken. Vi benytter driftskydinge folk. Ja, dette er nok litt utenfor kjerneproduktet vårt, men jeg ser overhodet ikke problemet med noen ekstra ansatte som ordner det tekniske. Det er en stor fordel som programmerer å vite med 100% sikkerhet hvilken maskin- og programvare løsningene våre benytter. Og ved å slippe å utvikle mot X antall php, java, .net, osv. -versjoner fordelt på ulike operativsystem og maskinparker, sparer vi masse penger. Penger som såklart kommer kunder til nytte. Så nei; fullstendig åpne løsninger er ikke alltid en økonomisk fordel.

 

Ett annet moment er at det kanskje ikke er kjempegøy for oss eller andre å servere all kildekode til kunde. Vi driver som tidligere nevnt i tråden ikke med open-source-løsninger, og dermed er det ikke alltid like aktuelt å servere omverdnen kjerneproduktet på et sølvfat!

 

Til slutt: hele dette innlegget er bare synsing fra min personlige side. Så ikke kom å klag hvis noe mot formodning viser seg å være feil. Tolk heller ikke innlegget på en offisiell uttalelse fra Keyteq, men istedet som en personlig uttalelse fra en hvilken som helst vanlig dødelig.