Webkafeen

[Steinmann]

Det skal sies av serverdrifting er en av våre tjenester, og faktisk noe vi drev med før vi startet med publiseringsløsninger. Derfor har vi kompetansen til å hoste vår egen løsning. Og jeg føler det gir bedre trygghet fordi sysadmin har mye bedre kjennskap til systemet enn om det skulle vært et eksternt system.

 

Utviklere og sysadmin har også i mye større grad mulighet til å samarbeide om problemer og utfordringer som måtte oppstå under utvikling.

[Bolson]

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?

 

Regner med at den var siktet til meg. Innelåsing kan du ha uansett om du kan ta med deg informasjonen eller ei (men kan du ikke ta med deg infoen er det ekstra ille). Som nevnt gjentatte ganger, innelåsing relaterer seg til byttekostnader.

 

Jeg skal eksemplifisere det med et eksempel fra en av mine kunder (ikke web, men annen rådgivning). Dette er et ekstremtilfelle, men illustrerer godt mulig effekt av innelåsing. De skaffet seg en ny webløsning for ca 2,5 år siden etter en anbudsprosess. Løsningen som ble valgt er utviklet og ble levert av en av de større softwarehusa i Norge (men det finnes ingen alternative leverandører, altså typisk potensial for innelåsing). Prislapp inklusive interne kostnader, kr 750 000. Ca 1 år etter at løsningen ble lansert bestemte leverandør seg for å droppe videreutvikling. Kunden hadde da bare et valg, skifte plattform, noe som kostet ca 300 000 kr (selv med spesialavtale). Hadde systemet som ble valgt første gang hatt flere leverandører hadde ikke det at den opprinnelige leverandøren droppet "systemet" hatt økonomiske konsekvenser i det hele tatt.

 

Jeg kan også ta et eksempel fra en annen kunde (heller ikke web, men innkjøpsrådgivning). De hadde også et system utviklet av, hostet og levert av bare en aktør. Også med typisk månedlige betalinger (abonnement). Nå trengte denne kunden en ny funksjonalitet i systemet, og spurte etter pris. Prisen den var anslått til 120 000 kr fra leverandør. Kunden syntes dette var dyrt, og gikk til en leverandør av et mer åpent system og fikk der en pris på 150 000 kr for komplett nytt nettsted inklusive ønsket funksjonalitet. Årskostnader ellers omtrent tilsvarende den gamle løsningen. Den nye leverandøren vurderte at rett pris på tilleggsfunksjonaliteten var ca 30 000 kr. Kunden valgte da fornuftig nok å skifte leverandør. Prisingen her fra opprinnelig leverandør var typisk prising muliggjort av innelåsingseffekter.

 

@qualbeen: Innelåsing eller lock-in har i realiteten intet med eierskap til informasjon å gjøre eller kontroll over data. Klart at har kunden ikke reell kontroll over data er situasjonen ennå verre, men det er ikke en forutsetning.

 

Ellers er serverargumentet ditt relativt tynt. Det finnes bøttevis av "spesialiserte" hostingsfirmaer for de store åpne løsningene. Firmaer som er ekstremt dyktige på sitt område. Og de fleste som utvikler løsninger utvikler for en spesifikk plattform.

 

Et par linker om innelåsing.

Wikipedia

Info.org

 

Så pr definisjon bedriver Keytec, NSN, Idium, CustomPublish med flere "vendor lock-in". Prinsipielt på samme måte som Apple, MS og andre. Det betyr ikke at for flertallet av kunder vil det nødvendigvis gi ulempe eller høyere pris over tid, men risikoen og potensialet ligger der. Og en viss % av kundene vil oppleve substansielle byttekostnader.

Endret 11. november 2008 av Bolson

[Cucum(r)]

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.

Eg forstår godt den tankegangen, og Keyteq er sikkert i ein posisjon kor dette gir fullstendig meining, sidan teknologivalget for det meste er konsistent og produkta ikkje er så mange (sjølv om kundebasen er svær).

Ser ein derimot på dei fleste store bedrifter rundt om i land og utland som primært jobber med internett (alt fra nyheter til nettprodukter), er hosting vanligvis outsourcet til store aktører som har lang fartstid og gode rutiner på dette. (f.eks. Rackspace internasjonalt, Ventelo er vel blant dei største i Norge?)

 

I det tidligare innlegget mitt formulerte eg meg nok som om at eg meinte at alle burde outsource hosting – det var ikkje meint slik. Eg tenkte meir på "tradisjonelle" bedrifter, som aviser o.l.

…og Keyteq er vel på ein måte ein stor hostingpartner i seg sjølv.

[Lovskogen]

Hvor mye billigere hadde flyttingen vært, om de skulle flytte fra Wordpress til TYPO3, Bolson?

[Vindstille]

Hvor mye billigere hadde flyttingen vært, om de skulle flytte fra Wordpress til TYPO3, Bolson?

Nå finnes ofte migrasjonsverktøy for mange av de store CMS-ene. Men hovedpoenget er vel at sansynligheten for at man vil komme i en situasjon hvor man må migrere er mye mindre med fri programvare pga:

 

1. Om produsenten skulle stoppe videreutviklingen finnes det ofte et community som kan gjøre det.

2. Ønsker man spesialtilpassede løsninger og man ikke er fornøyd med tilbudet produsenten gir kan man ofte gå til andre utviklere, eller velge å utvikle det selv.

[jorgis]

Hvor mye billigere hadde flyttingen vært, om de skulle flytte fra Wordpress til TYPO3, Bolson?

 

Om jeg kan komme med et innspill her, er dette ikke akkurat et realistisk scenario. Har du valgt Wordpress, og senere oppdager at det er utilstrekkelig, har du valgt feil (ikke tatt med evt. vekst eller kommende krav) eller fått eksepsjonelt dårlig rådgivning. Har du gjort en sånn tabbe vil det bli dyrt uansett hva du gjør. Kostnaden ved å bytte selve plattformen i bunn vil være høy uansett om du har proprietær eller åpen løsning. Dette er heller ikke poenget med å velge en åpen løsning.

 

Poenget med en åpen løsning (eller i hvert fall en konkurranseutsatt løsning) er at hvis en er misfornøyd med pris/servicenivå/hva som helst hos den opprinnelige leverandøren, kan en bytte leverandør uten de store kostnader en får når en er innelåst med en spesiell leverandør. Hvis en valgte en løsning basert på TYPO3 fra leverandør A, og leverandør A krever for mye for en forbedring eller for drift, kan en flytte løsningen til en annen leverandør med bedre vilkår. Dette fører igjen til at alle leverandører leverer bedre til lavere priser, grunnet konkurransen dem imellom.

 

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.

 

Det er ingenting som hindrer utviklerne fra å sette krav på hvilke plattformer kunden kjører løsningen deres på, så at dere bruker en kjent plattform in-house er ikke et gyldig argument. Det er heller ikke noe som hindrer dere fra å levere løsningen deres uten samtidig å frigi kildekoden. At kildekoden er levert med applikasjonen (som den må i PHP) er ikke ensbetydende med at kildekoden er fri, det finnes mange PHP-applikasjoner som ikke er fri kildekode. Hele dette forumet kjører på en ufri PHP-basert løsning.

Endret 11. november 2008 av jorgis

[Garanti]

Vurderer å gå over fra PHP til Ruby (on Rails) etterhvert, noen som anbefaler dette? Hvordan er støtte for bildebehandling (i hovedsak filtyper og resize) og annen media?

[loathsome]

Vurderer å gå over fra PHP til Ruby (on Rails) etterhvert, noen som anbefaler dette? Hvordan er støtte for bildebehandling (i hovedsak filtyper og resize) og annen media?

 

Er i samme situasjon som deg, kommer bare aldri helt "inn" i det.

[Haraldson]

Det er ingenting som hindrer utviklerne fra å sette krav på hvilke plattformer kunden kjører løsningen deres på, så at dere bruker en kjent plattform in-house er ikke et gyldig argument. Det er heller ikke noe som hindrer dere fra å levere løsningen deres uten samtidig å frigi kildekoden. At kildekoden er levert med applikasjonen (som den må i PHP) er ikke ensbetydende med at kildekoden er fri, det finnes mange PHP-applikasjoner som ikke er fri kildekode. Hele dette forumet kjører på en ufri PHP-basert løsning.

Siden forumet er så fantastisk stabilt, så tenkte du at det var et godt eksempel? Nå tror jeg de aller fleste bedrifter, enten med lock-in-løsninger eller konkurranseutsatte, har langt høyere oppetid enn dette forumet.

 

Når det gjelder å levere fra seg kildekoden, er jo det en risiko som med all annen programvare. Om noen har tilgang til alt sammen blir det (nesten) garantert misbrukt. Forretningsmodellen vår er uansett at vi er en totalleverandør på web, hovedsakelig innenfor det vi kan levere med produktene våre + eventuelle skreddersømmer (men om kravet fra kunden er helt egne applikasjoner sier vi nei). Dette innebærer drifting, utvikling, innholdsinnlegging ++. Så godt som ingen av våre kunder er interessert i å drifte løsningen selv — det er et tapsprosjekt for kunden.

Endret 12. november 2008 av Haraldson

[Magnus Holm]

Vurderer å gå over fra PHP til Ruby (on Rails) etterhvert, noen som anbefaler dette? Hvordan er støtte for bildebehandling (i hovedsak filtyper og resize) og annen media?

Jeg anbefaler dette absolutt, men du burde virkelig ta en titt på andre språk og rammeverk. Ta Python hvis det er det du foretrekker. Ta også en titt på Merb og Ramaze, samt Sinatra og Camping (den siden er utdatert, men jeg har stått for de største forandringene de siste månedene så bare spør meg hvis det er noe!) for små-ting. Rails har dog mange plugins og blog-poster som forklarer hvordan man gjør ting, så du er nok mindre "lost" der.

 

Ang. bildebehandling har vi et par stykker. Først og fremst så har vi RMagick som er stor, tung, treig, men gjør alt. ImageScience er et mye mindre biblioket, men kan kun resize og lage thumbnails

[Haraldson]

Anmeldelse av Stack Overflow.

 

Har ikke hørt så mye om systemet før, men jeg har tro på at man kommer mer til poenget der, og får bedre svar, enn man gjør her. For å bruke diskusjon.no som et eksempel.

[Steinmann]

Anmeldelse av Stack Overflow.

 

Har ikke hørt så mye om systemet før, men jeg har tro på at man kommer mer til poenget der, og får bedre svar, enn man gjør her. For å bruke diskusjon.no som et eksempel.

Husker de hadde noen kule programeringsquotes.

Liker tanken og systemet. Men kommer nok ikke bruke det med første tror jeg. Uten at jeg har noen grunn for det..

[Cucum(r)]

Anmeldelse av Stack Overflow.

 

Har ikke hørt så mye om systemet før, men jeg har tro på at man kommer mer til poenget der, og får bedre svar, enn man gjør her. For å bruke diskusjon.no som et eksempel.

Stack Overflow fungerer ekstremt godt. Bruker det fra tid til annan, når eg ikkje finn svar andre plasser.

[Cucum(r)]

Give up and use Tables

[Haraldson]

Give up and use crappy gifs?

[Steinmann]

Give up and use Tables

På innhold i en editor, som kunden kommer til å kuke med selv så er det ofte jeg må ty til tabeller.

De kommer til å gjøre det uansett så, og de klarer hvertfall å tulle til en nice divlayout. Uansett hvor enkel jeg gjør den.

[Bolson]

Give up and use Tables

 

Jeg sier bare uff, uff og atter uff.

 

Give up and use Tables

På innhold i en editor, som kunden kommer til å kuke med selv så er det ofte jeg må ty til tabeller.

De kommer til å gjøre det uansett så, og de klarer hvertfall å tulle til en nice divlayout. Uansett hvor enkel jeg gjør den.

 

Da er det betydelige mangler i editoren etter min mening. En god editor skal kunne konfigureres slik at de som legger inn innhold ikke skal kunne virkelig "ødelegge" design uansett kunnskapsnivå.

 

I tillegg bør det være enkelt for kunde å presentere innhold med ulike oppsett uten å risikere å knekke design.

[Steinmann]

Give up and use Tables

 

Jeg sier bare uff, uff og atter uff.

 

Give up and use Tables

På innhold i en editor, som kunden kommer til å kuke med selv så er det ofte jeg må ty til tabeller.

De kommer til å gjøre det uansett så, og de klarer hvertfall å tulle til en nice divlayout. Uansett hvor enkel jeg gjør den.

 

Da er det betydelige mangler i editoren etter min mening. En god editor skal kunne konfigureres slik at de som legger inn innhold ikke skal kunne virkelig "ødelegge" design uansett kunnskapsnivå.

 

I tillegg bør det være enkelt for kunde å presentere innhold med ulike oppsett uten å risikere å knekke design.

Her er det innholdet som skal presenteres da. Og ifølge kunder så MÅ det se likt ut i editor som på nettsidene.

-

 

Noen som har noen gode ideer til implementasjon av frakt kalkulator?

Problemet er når man kjøper en tv og en cd. Man kan jo da putte cd'n i samme pakke som tv'n. Men det vet jo ikke en slik kalkulator..

[Cucum(r)]

Kvifor kan ikkje kalkulatoren vite dette? Så lenge du har dimensjonane til produkta kan du jo regne deg fram til dette, med ein viss feilprosent.

[Arve Systad]

Her er det innholdet som skal presenteres da. Og ifølge kunder så MÅ det se likt ut i editor som på nettsidene.

 

Då må du vere flink gutt og forklare kunden at det er ikkje slik det fungerer osv.

Med anrde ord rett og slett gi kunden ei kort innføring i kva eit publiseringssystem er og korleis det fungerer.