Välkommen till linuxportalen.se!

Linuxportalen.se är Sveriges största och aktivaste webbplats för användare av öppen- och fri programvara.

Du besöker Linuxportalen.se som gäst vilket begränsar din möjlighet att använda webbplatsens alla funktioner. Genom att registera dig som medlem får du inte bara möjlighet att söka bland webbplatsens innehåll, skapa nya och delta i befintliga diskussioner, skapa din egen blogg, kommunicera med andra medlemmar genom privata meddelanden och delta i omröstningar. Du får också tillgång till Veckans Kadavro - en seriestrip unikt skapad för Linuxportalen.se!

Registeringen sker snabbt och är helt kostnadsfri - tveka inte, bli medlem idag!

Vad är KISS?

De flesta utvecklare, ingenjörer och annat slödder hyllar principen "Keep it simple stupid - KISS", eller på ren svenska "Håll det enkelt, dummer".

På en abstrakt nivå så innebär det att hålla gränsnitt, dvs hur saker samverkar så enkla som möjligt. Att man inte lägger till extra komplexitet ifall det inte finns mycket starka skäl att göra så. Att man kanske kan offra några procents prestanda för att kunna fortsätta hålla program och deras kommunikation så enkel som möjligt. Därmed blir det mesta enklare att förstå, underhålla och utöka.

Kända exempel på KISS är UNIX:s klassiska "pipes" vilka gör det enkelt att sammanlänka program som från början inte var tänkta att bli sammanlänkade. Man har enkla småprogram som gör en sak bra men när de sätts ihop kan man lösa komplicerade problem utan att lösningen i sig blir alltför komplex.

Så vi är alla stolta över pipes, grep, wc och kanske sed. Fast den stoltheten täcker bara 70-talet och kanske början av 80-talets teknik. Vilka programmeringstekniska problem har vi övervunnit sedan dess där vi bibehållit denna heliga princip?

KISS handlar om att hålla saker enkla, men vad som är enkelt när saker är små behöver inte vara enkelt när antalet objekt och förbindelsepunkter ökar.  Ta som exempel ett företag med två anställda, de kan utan vidare kommunicera muntligt, via telefon eller via epost.

Ökar vi antalet till tre så blir det hela genast svårare. Då kan vi inte längre ringa varandra med vanlig telefoni utan tvingas ta till en tjänst liknande "gruppsamtal", vi kanske inte längre får plats i samma kontorslokal utan tvingas röra oss mellan kontorrum. E-post kan fortfarande hanteras ganska väl i det här fallet.

Om vi plötsligt skalar företaget till tio anställda, en personalstyrka som kanske inte heller finns på samma kontor så kan vi inte längre kommunicera muntligt. Vi kan möjligen ha gruppsamtal mellan delar av personalen, men att ha nio personer i luren samtidigt blir ganska förvirrande. Det blir något lättare med ett konferens/video-system men det höjer komplexiteten avsevärt. E-post fungerar i det här fallet ifall alla är intresserade av samma information och har samma behörighet. Men om vi här börjar anta att bara vissa delar av företaget ska få ta del av viss information, att man börjar en epost-diskussion och plötsligt vill bjuda in en ny, man trådar upp diskussioner osv. Då blir det genast en spagetti med alla dessa "RE : " och "FW : ".

Google lanserade nyligen Google Wave som ett försök att förenkla e-post genom att göra det lättare att föra gruppkonversationer, dela filer och bjuda in nya personer i en diskussion, spela upp gamla diskussioner osv. Vi får se hur det artar sig. Man kan invända att det här är ett exempel på Vendor-styrd Cloud Computing där man plötsligt går från det öppna systemet "E-post" till ett system hårt styrt av Google. Frågan är hur ett distribuerat system skulle se ut. Varför inte låta Google Wave testa sina vingar och lära därifrån? Kanske kan dess idéer utvecklas till ett oberoende system inom några år?

Man skulle kunna hävda att det är KISS att hålla isär diskussioner och fildelning. Det må vara klokt, men vad skulle i så fall fildelningsverktyget vara? Vill vi ha versionshantering så finns system såsom GIT, BZR och SVN. Men då får vi plötsligt utbilda hela företaget inom detta. Ju fler verktyg vi inför, ju mer måste vi lära ut.

Dropbox är ett exempel där man lyckats ganska väl vad gäller enkel versionshanterng. för den enskilda användaren så är det bara att installera en klient, välja en mapp och börja jobba mot mappen. Inget "commit, uppdate, commit"-tänk. Dennes filer synkas automatiskt utan att något behöver göras. Nu är ju dock inte Dropbox avsett för att flera användare ska kunna jobba mot samma filer samtidigt. Vad som händer i det fallet är att Dropbox anser att den personen modifierat filen senare än den andre, därmed är det den senares version som gäller. Alla förändringar lagras i en logglista som man kan övervaka och röra sig genom via ett webb-gränssnitt. Men även detta kanske är komplicerat för gemene man.

Frågan är hur man enkelt skulle kunna integrera något som dropbox med vanlig e-post. Även om det vore enkelt att ge en länk i en konversation så är frågan hur man skulle kunna följa hur filer ändrats. Jag kanske är intresserad av att se "vad som hänt", både vad gäller konversationer och vad gäller filuppdateringar. Visst kan jag båda kika i "dropbox-loggen" och i min e-postklient men då ska jag plötsligt ha två program uppe för att följa status. Vad händer om jag inför ännu en "status-tjänst" som inte hanteras av varesig Dropbox eller min e-postklient. Är det då KISS att ha X stycken program öppna, en för varje sak? Om å andra sidan allting kunde skötas från min e-post-klient så skulle var och en få så mycket mail att det vore omöjligt att hålla reda på allt. "Ah, men då får var och en filtrera sin e-post". Jovisst, men då blir det återigen mer utbildning .....

Det enkla består av ett fåtal enkla byggbitar. Vad gör vi då ifall vi har 1000 bitar som måste passa ihop? Jo vi klumpar ihop delar av dem och låtsas att de bara är en bit. Det ger oss ett fåtal "låtsasbitar" som vi i alla fall låtsas att vi kan överblicka. Det hela kallas att "abstrahera". Vi har då skapat oss något som är "enkelt" men det finns i regel en hel del komplexitet under ytan. Tar vi något såsom ljuduppspelning så räcker det i vissa fall med funktionerna "playAudioFile", "pause" och "stop". I andra fall vill vi kunna hantera spellistor av ljudfiler. Får vi VÄLDIGT många låtar måste vi hantera det genom en databas, vill vi kunna styra ljudåtergivningen behöver vi en mängd reglage och nya gränssnitt. Är det fortfarande KISS vi talar om? Om vi väljer att använda mpg123, mplayer och amarok omväxlande så kan vi växla mellan olika nivåer av komplexitet beroende på våra krav. Men ska vi införa det som företagspolicy så får vi plötsligt utbilda X personer i Y olika program.

Vår värld blir hela tiden mer komplex, därmed tvingas vi införa nya abstraktioner för att orka med. Därmed glömmer vi vad som finns under ytan och när något därunder strular så står vi i regel chanslösa. Det är den stora faran med abstraktioner, de får oss att tappa kontakten med vårt fundament. Samtidigt är de nödvändiga för att vi ska kunna hantera vår vardag.

Det jag vill komma fram till är att det är så lätt att kasta ur sig "Keep it simple, stupid", när det i själva verket är mycket svårt och ibland nästan omöjligt finna en lösning som passar för olika behöv både idag och imorgon. Kom inte skramlade med pipes och UNIX-permissons, då är ni fast i 70-talet och ignorerar dagens komplexa miljö Wink

Vad har ni för tankar kring ämnet?

 

Alternativ för kommentarvisning

Välj ditt önskade sätt att visa kommentarerna och klicka på "Spara" för att verkställa dina ändringar.

dikatlons bild

<quote>Vår värld blir hela tiden mer komplex, därmed tvingas vi införa nya abstraktioner för att orka med. Därmed glömmer vi vad som finns under ytan och när något därunder strular så står vi i regel chanslösa. Det är den stora faran med abstraktioner, de får oss att tappa kontakten med vårt fundament.</quote>

Hmm? Är det inte så då att abstraktionen i regel gör att koden blir väldigt modul-bar, det i sin tur leder till att när något strular i fundamentet så är det lätt att avlusa? Mitt mål vid programmering är iaf just sådan. Att lösa problemet torde ju vara en bra dokumentation av API och klasserna samt exempel som är väl definierade för hur allting fungerar. Men abstraktion går inte och göra förstås ända till allra lägsta graden. Eller har jag fel där?

Och varför inte göra så att framföra ett alternativ i koden att skriva ut dom funktionerna som abstrakteras, det gör ju att allting kommer att bli väldigt enkelt att identifiera problemet.

Nu vet jag inte om det var just till detta du ville komma. Men det var några tankar.

- ARCH LINUX -

Kristians bild

Javisst. Så är det även med kodbasen jag arbetar med. Men mer generellt så är det mycket i livet som du tar för givet, komplexa system som du inte har kompetens/tid att gå in på djupet kring - "någon annans kod". Kanske just du vet en del om bilar, men många bara hoppas att bilen ska starta när de vrider runt nyckeln. Varför startar inte bilen? Vilka lager ska man börja söka igenom? Det kräver god kunskap kring ämnet. Sen kanske det inte heller är meningen att man ska kunna lösa allting själv?

 

---------------------------------------

 

tux-svens bild

Jag imponeras av dina intressanta bloggar. Tack!  Jag kommer att tänka på motsatsen, hur vi som grabbar ritade hur man tände en lampa genom en kedja med vältande vattenglas och hoppande katter o.s.v. till slut fick vi något som slog till på strömbrytaren så lampan tändes.  Det gällde att få en så lång och komplicerad kedja som möjligt.

Jag tror att alla kan inte kunna allt om allt.  Vi måste ha avgränsade "boxar", som utför viss funktionallitet, och som är verifierade för denna funktionallitet.

Du själv litar t.ex på att CPU:n har de förmågor som står i specen?

När du tänder lamporna i en modern bil är det en ganska komplicerad procedur med signaler över CAN-bussar. Trots detta vrider du fortfarande bara på ett vred eller drar i ett reglage.

Det komplicerade måste vara väl gjort och noga verifierat,  Då kan det hållas osynligt.  Enkelheten måste i första hand gälla användargränssnittet.

En Mobiltelefon t.ex är så komplicerad i tekniken att man blir imponerad av att det verkligen fungerar i verkligheten.

Även de mest otekniska brukar klara av att använda dem trots detta.

Håll användarupplevelsen så enkel som möjligt anser jag.  Även om tekniken bakom skulle bli mer komplicerad.  Tekniken skapar man vid fåtal tillfällen och har bra resurser tillgängliga.  Användarna använder tekniken ofta och har oftast mindre resurser tillgängliga (kunskap, tid att lära nytt osv)

---

Windows are for houses, Linux is for computers!

 

valdermans bild

Du verkar helt ha missuppfattat principen. Att ha en massa olika program öppna för att göra olika saker är inte KISS, det är WIMP - Weakly Interacting Massive Programs.

KISS är heller inte, som du verkar tro, en motståndare till organisationer. Tvärtom kan du tillämpa samma princip - enkla individuella komponenter som kommunicerar genom tydligt definierade gränssnitt - även inom organisationer.

Angående dina tankar om e-post låter det som att du försöker slå i en spik med en såg. E-post är inte avsett att vara ett medium för gruppdiskussioner, lika lite som vanlig post. Du kan istället använda en e-postlista så blir det genast betydligt enklare - alla skriver till listan, listan vidarebefodrar till alla medlemmar.

Slutligen ställer jag mig även väldigt frågande till din attityd (om jag tolkade dig rätt?) att det är bättre med ett enda program som integrerar en stor mängd funktionalitet än att ha en komponent för varje deluppgift. Varför skulle det vara bättre än att låta en dropbox-monitor hålla koll på dropbox, en e-postklient på din e-post, etc. och låta en enkel aggregator sammanfatta det hela åt dig?

--
あるユーモアのないアホのため、シグナチャーをカエルことにした。カエルさん

Kristians bild

Angående dina tankar om e-post låter det som att du försöker slå i en spik med en såg. E-post är inte avsett att vara ett medium för gruppdiskussioner, lika lite som vanlig post. Du kan istället använda en e-postlista så blir det genast betydligt enklare - alla skriver till listan, listan vidarebefodrar till alla medlemmar.

Jag tänkte kanske mer på fallet där man böjer ett enkelt koncept för kommunikation såsom e-post så långt att det nästan går av. I något läge måste man "byta häst" därför att ens krav inte längre passar kostymen.

Å andra sidan vill man inte ha flera program öppna, å andra sidan vill man inte att program ska vara för hårt sammanklistrade i en klump. Men med en aggregator kan du bara få samverkan i en riktning, inte mellan moduler. Visserligen ska överdriven sådan undvikas (för det ger extra komplexitet) men ibland är det oundvikligt.

System såsom D-Bus har skapats av en anledning, just för att underlätta kommunikation mellan olika subsystem. Men ska det fungera så måste varje program vara anpassat för D-Bus precis som att UNIX-program är anpassade till deskriptorerna stdin/stdout/stderr.

Å ja, jag och många andra kör Emacs. En stor hemsk klump som kan göra allt enligt en del, andra ser det som ett alternativt shell där enskilda moduler kan göra en sak bra men fungera tillsammans under ett tak.

 

 

---------------------------------------

 

valdermans bild

Varför skulle dessa moduler ha interaktionsproblem? De bör helt enkelt läsa det de är avsedda och läsa, och skriva sin utdata till vad det nu är för kommunikationskanal till aggregatorn. (Använder aggregator som sammanfattande uttryck för "vad som helst som samlar ihop informationen," vilket skulle kunna vara en RSS-aggregator, en hopsamlardemon kör med DBus, systray, etc.)

--
あるユーモアのないアホのため、シグナチャーをカエルことにした。カエルさん

Kristians bild

Precis Smile Vad ska de skriva till? Enkla filer, xml, dbus eller något annat? I en tid då alla skrev rader och kolumner till stdout och läste från stdin så var det enkelt. Men idag har vi andra sätt att få in och utdata och det är ju där problemet finns.  Vem ska översätta mellan alla dessa in och utkällor?

 

---------------------------------------

 

valdermans bild

Sådär på rak arm skulle jag nog göra nånting som läser in data från en eller flera backends, sammanfattar det och skriver det till en eller flera frontends, där backend och frontend har någon sorts enkel pluginstruktur, antingen kontinuerligt eller på begäran.

--
あるユーモアのないアホのため、シグナチャーをカエルことにした。カエルさん

marremuss bild

 Hej Kristian o alla,

inom statistiken används akronymen "KISS" mest för att försöka argumentera för dumheter som inte fungerar, men på ytan verkar logiska. Man skall akta sig när sådana reoriska grepp används. Innebär "stupid" att man måste vara dum för att svälja argumenten?

 

MarreM

 

 

 

Ora et Labora

Nä det menas bara "Varför krångla till saker", åtminstone tolkar jag det så.

jeffs bild

"inom statistiken används".

------

Jo du jeff det såg jag tänkte mest på den sista meningen.

"Innebär "stupid" att man måste vara dum för att svälja argumenten?"

Vad har ni för tankar kring ämnet?

Ett program per uppgift tycker jag är ett bra upplägg, samtidigt tycker jag det är rimligt att bunta ihop sammanhängande uppgifter. Det är dumt att skapa fyra olika kalkylatorer när man kan göra en som hanterar de fyra räknesätten... Smile Var gränserna går kan bli lite lurigt att bestämma.

Jag skissar som bäst på ett nytt projekt som jag har haft i tankarna något år. Det handlar om ett par olika funktioner/program i form av hmmm ...hjälpmedel. Jag pendlar mellan att göra ett delprogram per uppgift och att göra något integrerat paket av det hela.

Om jag väljer att göra flera program blir det ändå några gemensamma klassbibliotek som de delar på.

Programmen/t kommer att ha grafiska användargränssnitt och en möjlig lösning vore att göra dem dels separata och dels ett samlande paraplyprogram. Jag vet inte om det blev begripligt men i mitt huvud verkar det framkomligt...