Bussen går et stykke fra, hvor vi bor, og derfor har vi efterhånden fået en hel lille tradition med at deles om tage min kones cykel der hen, og så lade den stå ved stoppestedet til, når vi kommer hjem igen.
I dag da jeg kom med bussen, da kunne jeg så konstatere, at nogen havde brugt cykelkurven som affaldsspand: der lå en halv pølse og noget sammenkrøllet pølsepapir i den - de glade givere havde i øvrigt ikke været særligt gode til at ramme, for der lå lige så meget på jorden omkring cyklen.
Og så er det, at man spørger sig selv: hvorfor? Den nærmeste skraldespand var stort set tom, og lå kun femten skridt væk - jeg ved det, for jeg talte dem, da jeg gik derhen med affaldet.
Gad vide, om det er nogen, som trænger meget til briller, men ikke har råd på grund af finanskrisen? Eller måske kom jeg helt uforvarende til at ødelægge en fremtidig installationskunstners allerførste værk?
mandag den 21. september 2009
onsdag den 16. september 2009
Tegnsætsudfordringer
Jeg har lige for nyligt skrevet som at bruge curl til test af ikke-trivielle C#-webservices - hvis man er usædvanligt skarpøjet, så vil man kunne have set, at jeg har lavet en potentiel tegnsætsfejl - men man kan ikke se det mere, for jeg har rettet eksemplet til; jeg vil gerne forklare her, hvor i den bestod:
XML-dokumentet sagde jo selv, at det var skrevet i UTF-8 tegnsættet - men faktisk var det endda skrevet i den delmængde, som også er kendt som US-ASCII. Hvis man kigger på headeren til content-type, som findes i scriptet, så kan man se, at mime-typen er sat til "text/xml". At burde derfor være idel lykke, ikke sandt?
Nej, så langt fra, for hvis man nærlæser RFC3023, så kan man i afsnit 3.1 se, at der på det stærkeste anbefales at angive et tegnsæt til typen text/xml - og hvis man ikke gør det, så skal indholdet fortolket som værende US-ASCII! Mit eksempel går derfor kun godt, fordi at det tilfældigvis holdt sig indenfor US-ASCII, men i samme øjeblik at man f.eks. prøver at skrive "ÆØÅæøå", så bryder det sammen på subtil vis.
Løsningen er derfor at ændre mime-typen til "text/xml;charset=utf-8".
Spørg lige om det var svært at finde, når man opdager problemet i en integrationstest, hvor webservicen som sagt er skrevet i C#, men hvor den skriver data ned i en Oracle-database, hvor det så senere læses af en server, som er skrevet i C++, som sender det over en socket-baseret legacy-protokol for at havne i MFC/C++ baseret klient?
XML-dokumentet sagde jo selv, at det var skrevet i UTF-8 tegnsættet - men faktisk var det endda skrevet i den delmængde, som også er kendt som US-ASCII. Hvis man kigger på headeren til content-type, som findes i scriptet, så kan man se, at mime-typen er sat til "text/xml". At burde derfor være idel lykke, ikke sandt?
Nej, så langt fra, for hvis man nærlæser RFC3023, så kan man i afsnit 3.1 se, at der på det stærkeste anbefales at angive et tegnsæt til typen text/xml - og hvis man ikke gør det, så skal indholdet fortolket som værende US-ASCII! Mit eksempel går derfor kun godt, fordi at det tilfældigvis holdt sig indenfor US-ASCII, men i samme øjeblik at man f.eks. prøver at skrive "ÆØÅæøå", så bryder det sammen på subtil vis.
Løsningen er derfor at ændre mime-typen til "text/xml;charset=utf-8".
Spørg lige om det var svært at finde, når man opdager problemet i en integrationstest, hvor webservicen som sagt er skrevet i C#, men hvor den skriver data ned i en Oracle-database, hvor det så senere læses af en server, som er skrevet i C++, som sender det over en socket-baseret legacy-protokol for at havne i MFC/C++ baseret klient?
tirsdag den 8. september 2009
C# Webservice og curl
For nyligt blev jeg bedt om at hjælpe på et projekt, hvor man havde brug for at udvide nogle webservices, som var skrevet i C#. Ja, det er ikke just min boldgade, men hvor svært kan det være? Og det er faktisk gået over al forventning.
At kalde det for webservices er måske lidt en tilsnigelse, for der er i vid udstrækning tale om et remote procedure call, også selvom det er pakket fint ind - der bruges godt nok plusord som "SOAP", "WSDL" og "Document Literal" (i en helt egenartig variation - bravo Microsoft!), men reelt skriver man en metode, og så bruger man værktøjer til at generere "det ind imellem".
Kigger man på den WSDL, som kommer ud af det, så bliver man ikke imponeret. At man har felter med en datatype, som kan være Null, betyder ikke at feltet skal være optionelt - jeg kiggede bl.a. på en webservice til at sende SMS'er, og der måtte man ifølge service definitionen selv om, om man ville angive telefonnummer og besked!
Kan man sluge den kamel (og det er noget af kamel at sluge for en person som jeg, der er til stærkt typede sprog), så må man sige, at det er ganske nemt. Og muligheden for at kalde den autogenerede metode via POST af en tilsvarende autogenereret formular, er tilnærmelsesvist genialt. Hvor er det dog nemt at få en hurtig test af det, som man lige har flikket sammen.
Men så var det, at jeg pludselig rendte ind i flg. besked på testsiden:
Den sad jeg så lidt og grublede over. Det kunne da ikke være sandt, at man ikke kunne teste sådan en webservice på andre måder end ved at lave en hel ny klient til den?
Så var det, at jeg faldt over cURL. Hmm. Sammen med afvisningen på testsiden var der jo et eksempeldokument - mon ikke det kunne lade sig gøre, at kalde webservicen direkte via cURL?
Dokumentet kunne f.eks. være dette:
Og cURL kan kaldes på flg. måde:
De to "-H" sætter headers på, og "-d" refererer til filen med ovenstående xml-dokument (som er body i beskeden). Sværere er det såmænd ikke.
Yeah!
At kalde det for webservices er måske lidt en tilsnigelse, for der er i vid udstrækning tale om et remote procedure call, også selvom det er pakket fint ind - der bruges godt nok plusord som "SOAP", "WSDL" og "Document Literal" (i en helt egenartig variation - bravo Microsoft!), men reelt skriver man en metode, og så bruger man værktøjer til at generere "det ind imellem".
Kigger man på den WSDL, som kommer ud af det, så bliver man ikke imponeret. At man har felter med en datatype, som kan være Null, betyder ikke at feltet skal være optionelt - jeg kiggede bl.a. på en webservice til at sende SMS'er, og der måtte man ifølge service definitionen selv om, om man ville angive telefonnummer og besked!
Kan man sluge den kamel (og det er noget af kamel at sluge for en person som jeg, der er til stærkt typede sprog), så må man sige, at det er ganske nemt. Og muligheden for at kalde den autogenerede metode via POST af en tilsvarende autogenereret formular, er tilnærmelsesvist genialt. Hvor er det dog nemt at få en hurtig test af det, som man lige har flikket sammen.
Men så var det, at jeg pludselig rendte ind i flg. besked på testsiden:
The test form is only available for methods with primitive types or arrays of primitive types as parameters....mand, og nu gik det ellers lige så godt med mine små "Hello, world!" eksperimenter.
Den sad jeg så lidt og grublede over. Det kunne da ikke være sandt, at man ikke kunne teste sådan en webservice på andre måder end ved at lave en hel ny klient til den?
Så var det, at jeg faldt over cURL. Hmm. Sammen med afvisningen på testsiden var der jo et eksempeldokument - mon ikke det kunne lade sig gøre, at kalde webservicen direkte via cURL?
Dokumentet kunne f.eks. være dette:
1:<?xml version="1.0" encoding="utf-8"?>
2:<soap:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
3: <soap:Body>
4: <TestData xmlns="http://test.example.org/ws">
5: <Id>Alfa</Id>
6: <list>
7: <item>
8: <field>NAME</field>
9: <oldValue>gammelt navn</oldValue>
10: <newValue>nyt navn</newValue>
11: </item>
12: <item>
13: <field>CITY</field>
14: <oldValue>Gammelby</oldValue>
15: <newValue>Nyborg</newValue>
16: </item>
17: </list>
18: </TestData>
19: </soap:Body>
20:</soap:Envelope>
Og cURL kan kaldes på flg. måde:
1:#!/bin/bash
2:curl -H "SOAPAction: \"http://test.example.org/ws/TestData\"" \
3: -H "Content-Type: text/xml;charset=utf-8" \
4: -d @testdata.xml \
5: http://localhost/TestWebService/TestWebService.asmx?op=TestData
De to "-H" sætter headers på, og "-d" refererer til filen med ovenstående xml-dokument (som er body i beskeden). Sværere er det såmænd ikke.
Yeah!
onsdag den 2. september 2009
Demo
Da jeg tidligere skrev om Kniberg scrum checkliste faldt der pludselig nogle brikker på plads for mig - og jeg vil gerne dele nogle af dem med jer her, men lov mig til gengæld, at tilgive mig på forhånd, hvis der i virkeligheden er tale om, at jeg er den sidste til at indse det indlysende!
Og hvad er det så, som er gået op for mig? Jo, at demo er vigtigt for et godt scrum.
Tit springes demo over, og vel som oftest fordi at det er en noget kunstig affære - en ceremoni, som der står i teoribøgerne, at man skal lave (som f.eks. førnævnte checkliste)- og så laver man det. Sådan har mange af de demoer, som jeg har deltaget i på diverse teams i hvert fald været, og er der noget, som vi ikke har tid til i en agil verden, så er det ceremoni!
Vi har også prøvet at efterrationalisere over det, og som oftest har det været noget med, at vi med demoen markerede, at vi var færdige - eller med andre ord en slags sejrsdans over sprintet. Hmm - hvis ikke man har styr på sit done-kriterium, så vil ikke nok så mange demoer hjælpe en ... og hvem har ikke oplevet en demo af noget, som i virkeligheden viste sig at være foilware? Nej, jeg mener ikke, at det er derfor.
Et andet argument var, at nu havde vi arbejdet på så mange forskellige ting i løbet af sprintet, at det var godt, at vi fik lejlighed til at vise det frem for hinanden. Hmm i anden - der er forhåbentlig kun et team, og det har forhåbentlig allerede arbejde sammen imod samme mål i et helt sprint ... så hvad er der lige at vise hinanden? Næh, det kan heller ikke være derfor.
Lad os i stedet kigge på nogle af de andre elementer i scrum:
Vi har for det første en Product Owner (ja, altså en rigtig en, som skal leve - eller dø! - med det, som vi laver, og ikke sådan en "produkt-stråmand", som man desværre alt for tit ser i stedet for), fordi at vi hele tiden vil lave de ting, som er til størst nytte.
Vi har for det andet retrospectives, fordi at vi hele tiden vil forsøge at gøre det bare lidt bedre (og fordi at vi ved, at gør man det hele tiden lidt bedre, så bliver det meget bedre på langt sigt!).
Hvad er demoen så? Jo, det er det sted, hvor vi som team får direkte feedback fra dem, som skal leve af og med resultatet af vores arbejde. Hvis Product Owner er en rigtig Product Owner, så er han helt essentiel for, at demoen giver værdi: for temaet skal opleve, hvor han griner og hvor han græder. Men det skal ikke kun være begrænset til Product Owner selv - der må meget gerne være andre slutbrugere til stede - de som også skal leve af, og med, det som temaet har frembragt.
Som et naturligt resultat af en demo vil hele teamet have en forståelse af, hvad som virkede godt, og hvad, som virkede mindre godt - og det er en viden, som teamet kan tage med direkte med tilbage i dets arbejde på løbende at forbedre processen.
Demo skal derfor falde rimeligt kort efter sprintets afslutning, og gerne inden retrospektiv, for en god demo vil danne et godt udgangspunkt for diskussionen på retrospektivet.
Teamet vil, når det har mødt brugerne, også naturligt få en bedre forståelse for baggrunden for de ønsker, som det fremover skal arbejde med realisere, og vil derfor være væsentligt bedre rustet til dette.
Demo har også en anden værdi - for i scrum fokuserer man hele tiden på, at levere noget, som gør en synlig forskel ... og hvordan kan man vise noget frem, som ikke gør en synlig forskel? Demoen er dermed en indikator af, om Product Owner og temaet tilsammen evner at fokusere på det rette ... falder det svært eller unaturligt at lave en demo efter et sprint, så spørg jer selv, om det er det rette, som man har brugt tiden på?
Endelig er der jo det faktum, at der ikke er noget mere motiverende end at vide, at man har gjort en positiv forskel - og det gælder også for et scrumteam.
Og hvad er det så, som er gået op for mig? Jo, at demo er vigtigt for et godt scrum.
Tit springes demo over, og vel som oftest fordi at det er en noget kunstig affære - en ceremoni, som der står i teoribøgerne, at man skal lave (som f.eks. førnævnte checkliste)- og så laver man det. Sådan har mange af de demoer, som jeg har deltaget i på diverse teams i hvert fald været, og er der noget, som vi ikke har tid til i en agil verden, så er det ceremoni!
Vi har også prøvet at efterrationalisere over det, og som oftest har det været noget med, at vi med demoen markerede, at vi var færdige - eller med andre ord en slags sejrsdans over sprintet. Hmm - hvis ikke man har styr på sit done-kriterium, så vil ikke nok så mange demoer hjælpe en ... og hvem har ikke oplevet en demo af noget, som i virkeligheden viste sig at være foilware? Nej, jeg mener ikke, at det er derfor.
Et andet argument var, at nu havde vi arbejdet på så mange forskellige ting i løbet af sprintet, at det var godt, at vi fik lejlighed til at vise det frem for hinanden. Hmm i anden - der er forhåbentlig kun et team, og det har forhåbentlig allerede arbejde sammen imod samme mål i et helt sprint ... så hvad er der lige at vise hinanden? Næh, det kan heller ikke være derfor.
Lad os i stedet kigge på nogle af de andre elementer i scrum:
Vi har for det første en Product Owner (ja, altså en rigtig en, som skal leve - eller dø! - med det, som vi laver, og ikke sådan en "produkt-stråmand", som man desværre alt for tit ser i stedet for), fordi at vi hele tiden vil lave de ting, som er til størst nytte.
Vi har for det andet retrospectives, fordi at vi hele tiden vil forsøge at gøre det bare lidt bedre (og fordi at vi ved, at gør man det hele tiden lidt bedre, så bliver det meget bedre på langt sigt!).
Hvad er demoen så? Jo, det er det sted, hvor vi som team får direkte feedback fra dem, som skal leve af og med resultatet af vores arbejde. Hvis Product Owner er en rigtig Product Owner, så er han helt essentiel for, at demoen giver værdi: for temaet skal opleve, hvor han griner og hvor han græder. Men det skal ikke kun være begrænset til Product Owner selv - der må meget gerne være andre slutbrugere til stede - de som også skal leve af, og med, det som temaet har frembragt.
Som et naturligt resultat af en demo vil hele teamet have en forståelse af, hvad som virkede godt, og hvad, som virkede mindre godt - og det er en viden, som teamet kan tage med direkte med tilbage i dets arbejde på løbende at forbedre processen.
Demo skal derfor falde rimeligt kort efter sprintets afslutning, og gerne inden retrospektiv, for en god demo vil danne et godt udgangspunkt for diskussionen på retrospektivet.
Teamet vil, når det har mødt brugerne, også naturligt få en bedre forståelse for baggrunden for de ønsker, som det fremover skal arbejde med realisere, og vil derfor være væsentligt bedre rustet til dette.
Demo har også en anden værdi - for i scrum fokuserer man hele tiden på, at levere noget, som gør en synlig forskel ... og hvordan kan man vise noget frem, som ikke gør en synlig forskel? Demoen er dermed en indikator af, om Product Owner og temaet tilsammen evner at fokusere på det rette ... falder det svært eller unaturligt at lave en demo efter et sprint, så spørg jer selv, om det er det rette, som man har brugt tiden på?
Endelig er der jo det faktum, at der ikke er noget mere motiverende end at vide, at man har gjort en positiv forskel - og det gælder også for et scrumteam.
tirsdag den 25. august 2009
Overskud i hverdagen
I denne sommerferie havde vi lavet en fælles liste over ting, som vi godt kunne tænke os, og børnene havde blandt andet fået skrevet på, at vi skulle tage en tur med Kulhuse-færgen M/F Columbus, når vi var i mormors sommerhus.
Vi måtte faktisk køre en omvej for at komme med over, overfarten er kort og vi har gjort det flere gange før - men det bliver helt opvejet af noget udefinerbart - måske er det hyggen, og måske er det fordi at turen faktisk er ganske malerisk, så vi havde alle høje forventninger.
Det var en smuk sommeraften, og straks da vi kom ombord, så fløj ungerne ud, for de skulle op for at hilse på skipper og hans papegøje. Og så gik snakken ellers, for skipper er en rigtig hyggelig fætter. Der var selvfølgelig mange spørgsmål, og skipper viste gerne, hvordan han kunne styre færgens to motorer.
Så faldt snakken på, at min store dreng havde været på Bakken for at fejre sin fødselsdag dagen før (han er stadig i den alder, hvor fødselsdage er noget, man praler af), og så spurgte skipper, som drengene ville have en karrusel-tur?
Det ville de rigtigt nok gerne, og da vi var kommet ned og havde stillet os i stævnen, så lod skipper færgen tage en 360o snurretur omkring egen akse! Vi var tæt nok på land til, at vi kunne se folk stå og måbe derinde, og drengene var ikke til at skyde igennem bagefter: det er helt sikkert en af feriens allerstørste oplevelser.
Det er virkelig at have overskud i hverdagen, og herfra skal lyde en stor tak til skipper!
Vi måtte faktisk køre en omvej for at komme med over, overfarten er kort og vi har gjort det flere gange før - men det bliver helt opvejet af noget udefinerbart - måske er det hyggen, og måske er det fordi at turen faktisk er ganske malerisk, så vi havde alle høje forventninger.
Det var en smuk sommeraften, og straks da vi kom ombord, så fløj ungerne ud, for de skulle op for at hilse på skipper og hans papegøje. Og så gik snakken ellers, for skipper er en rigtig hyggelig fætter. Der var selvfølgelig mange spørgsmål, og skipper viste gerne, hvordan han kunne styre færgens to motorer.
Så faldt snakken på, at min store dreng havde været på Bakken for at fejre sin fødselsdag dagen før (han er stadig i den alder, hvor fødselsdage er noget, man praler af), og så spurgte skipper, som drengene ville have en karrusel-tur?
Det ville de rigtigt nok gerne, og da vi var kommet ned og havde stillet os i stævnen, så lod skipper færgen tage en 360o snurretur omkring egen akse! Vi var tæt nok på land til, at vi kunne se folk stå og måbe derinde, og drengene var ikke til at skyde igennem bagefter: det er helt sikkert en af feriens allerstørste oplevelser.
Det er virkelig at have overskud i hverdagen, og herfra skal lyde en stor tak til skipper!
mandag den 24. august 2009
SVG
Jeg morede mig forleden med at skrive lidt om komposition på min fotoblog. I den forbindelse fik jeg lavet nogle skitser, som f.eks. den her:
Skitserne er lavet vha. programmet InkScape, som varmt kan anbefales - jeg er kun nået til tredje tutorial (og de to første går ud på at tegne flag, så dem bliver man ikke ligefrem udfordret af), og alligevel havde jeg lært nok til at kunne klare mig selv. Bevares, der er da stadig rigtigt meget at lære, men jeg er imponeret af ethvert program, som er så intuitivt, at selv jeg kan forstå det!
Den helt store fordel ved at tegne med InkScape er, at outputtet er i SVG-format (Scalable Vector Graphics) - og det er præcist hvad det giver sig ud for: i stedet for at arbejde med farveklatter i faste tern, så arbejdes der med streger og flader, og derfor kan tegningen udenvidere skaleres uden tab af opløsning eller information (selvfølgelig stiller det visse krav til ens omhyggelighed, hvis det skal skaleres voldsomt op). Og endnu bedre er det, at der er tale om en W3 standard baseret på XML.
Nu er HTML jo næsten XML, hvis man da lige kniber øjnene lidt i, når man kigger efter - og en af de store udfordringer med grafik på webben er at lave det skalerbart - så man skulle tro, at det ligger lige for, at bruge SVG som grafik-format på nettet?
Øhm, nej, det gør det altså ikke. Godt nok bliver det understøttet af alle tidsvarende browsere (jeg har f.eks. checket med Firefox og Chrome) - og inden du mugger over, at det ikke gælder nyeste version af IE, så bemærk venligst, at jeg sagde "tidsvarende" :-). Min holdning til Microsofts web-flagskib er da i øvrigt heller ikke blevet bedre af, at den misforstår det CSS, som jeg har fået klampet sammen til fotobloggen på en helt unik og egenartig måde. Så mellem os, så var jeg klar til at opgive dem, som stadig måtte ønske at bruge IE (psst ... men se lige her: Firefox 3.5).
Men så er det, at jeg opdager, at blogger/blogspot, som jeg baserer min blog på, ikke kan finde ud af, at billeder også kan være i SVG-formatet. Og heller ikke Picasa i webudgaven understøtter SVG, og det er ellers der, hvor jeg lader alle mine andre billeder komme fra (hvis nogen kender et godt sted, som ikke er så SVG-fjentligt som Picasa, hvor jeg kan få lov at hoste mine SVG-billeder, så sig endelig til!).
Der er altså ingen vej udenom at eksportere det fine, skalerbare billede, som jeg lige havde fået lavet, som faststørrelse bitmap - hvilken nedtur! Jeg vælger så at gøre det som i PNG-format, da det giver væsentlig færre "artifakter" end f.eks. JPEG, når der f.eks. er tale om stregtegninger, som de diagrammer, som jeg har lavet. Og Picasa web forstår da i det mindste PNG-formatet, og det gør alle tidsvarende browsere også, så det må da være godt, ikk'?
Arh, altså, ikke helt ... for hvis I kigger godt efter, så vil I kunne se, at Picasa Web "serverer" diagrammet tilbage i JPG-format. Billederne har altså endnu engang været en tur igennem format-konverterings-vridemaskinen, og det kan de kun blive ringere af. Jeg kan så trøste mig med, at de i det mindste er blevet nedskaleret, og tabet derfor nok ikke så stort som ellers.
Nå, men jeg har gemt originalen i SVG-format - så må vi bare håbe, at jeg engang om ikke alt for længe bliver indhentet af fremtiden...!
Skitserne er lavet vha. programmet InkScape, som varmt kan anbefales - jeg er kun nået til tredje tutorial (og de to første går ud på at tegne flag, så dem bliver man ikke ligefrem udfordret af), og alligevel havde jeg lært nok til at kunne klare mig selv. Bevares, der er da stadig rigtigt meget at lære, men jeg er imponeret af ethvert program, som er så intuitivt, at selv jeg kan forstå det!
Den helt store fordel ved at tegne med InkScape er, at outputtet er i SVG-format (Scalable Vector Graphics) - og det er præcist hvad det giver sig ud for: i stedet for at arbejde med farveklatter i faste tern, så arbejdes der med streger og flader, og derfor kan tegningen udenvidere skaleres uden tab af opløsning eller information (selvfølgelig stiller det visse krav til ens omhyggelighed, hvis det skal skaleres voldsomt op). Og endnu bedre er det, at der er tale om en W3 standard baseret på XML.
Nu er HTML jo næsten XML, hvis man da lige kniber øjnene lidt i, når man kigger efter - og en af de store udfordringer med grafik på webben er at lave det skalerbart - så man skulle tro, at det ligger lige for, at bruge SVG som grafik-format på nettet?
Øhm, nej, det gør det altså ikke. Godt nok bliver det understøttet af alle tidsvarende browsere (jeg har f.eks. checket med Firefox og Chrome) - og inden du mugger over, at det ikke gælder nyeste version af IE, så bemærk venligst, at jeg sagde "tidsvarende" :-). Min holdning til Microsofts web-flagskib er da i øvrigt heller ikke blevet bedre af, at den misforstår det CSS, som jeg har fået klampet sammen til fotobloggen på en helt unik og egenartig måde. Så mellem os, så var jeg klar til at opgive dem, som stadig måtte ønske at bruge IE (psst ... men se lige her: Firefox 3.5).
Men så er det, at jeg opdager, at blogger/blogspot, som jeg baserer min blog på, ikke kan finde ud af, at billeder også kan være i SVG-formatet. Og heller ikke Picasa i webudgaven understøtter SVG, og det er ellers der, hvor jeg lader alle mine andre billeder komme fra (hvis nogen kender et godt sted, som ikke er så SVG-fjentligt som Picasa, hvor jeg kan få lov at hoste mine SVG-billeder, så sig endelig til!).
Der er altså ingen vej udenom at eksportere det fine, skalerbare billede, som jeg lige havde fået lavet, som faststørrelse bitmap - hvilken nedtur! Jeg vælger så at gøre det som i PNG-format, da det giver væsentlig færre "artifakter" end f.eks. JPEG, når der f.eks. er tale om stregtegninger, som de diagrammer, som jeg har lavet. Og Picasa web forstår da i det mindste PNG-formatet, og det gør alle tidsvarende browsere også, så det må da være godt, ikk'?
Arh, altså, ikke helt ... for hvis I kigger godt efter, så vil I kunne se, at Picasa Web "serverer" diagrammet tilbage i JPG-format. Billederne har altså endnu engang været en tur igennem format-konverterings-vridemaskinen, og det kan de kun blive ringere af. Jeg kan så trøste mig med, at de i det mindste er blevet nedskaleret, og tabet derfor nok ikke så stort som ellers.
Nå, men jeg har gemt originalen i SVG-format - så må vi bare håbe, at jeg engang om ikke alt for længe bliver indhentet af fremtiden...!
torsdag den 20. august 2009
Undersættelse
Det skal ikke være en hemmelighed, at jeg godt kan lide mange af de ting, som Google går og laver, og deres webalbum er af dem. På det seneste er der kommet en visningstæller på hver enkelt billede, og den får jeg meget ud af at holde øje med (man må vel godt være lidt forfængelig?).
Men så opdagede jeg den her yderst til venstre lige under billederne:
[smiley] Ligner [spørgsmålstegn] ?!? ... hvad er nu det for noget? Ligner hvad? Mine billeder ligner det, som de er, nemlig billeder. Nå, men da jeg så prøvede at trykke på spørgsmålstegnet (det har jeg lært af mine sønner - er der noget, som man ikke forstår i et skærmbillede, så klik på alt hvad du kan finde!), så kom forklaringen: de snakker om, at man kan bruge den facilitet, hvis man kan lide billedet (ja, det er undersættelsen af det engelske ord "like").
I øvrigt en god ide, for tit kan man lide et billede uden direkte at have noget på hjerte, og så kan man så bruge den knap. Men nok ikke noget, som får den helt store udbredelse alligevel, for man skal være logget ind hos google, før at de vil registrere stemmen. Så topkarakter for ideen, bundkarakter for udførelsen!
...og forsøget på at lave en dansk oversættelse af brugerfladen - well, skal vi ikke bare sige, at den er uden for kategori?
Men så opdagede jeg den her yderst til venstre lige under billederne:
[smiley] Ligner [spørgsmålstegn] ?!? ... hvad er nu det for noget? Ligner hvad? Mine billeder ligner det, som de er, nemlig billeder. Nå, men da jeg så prøvede at trykke på spørgsmålstegnet (det har jeg lært af mine sønner - er der noget, som man ikke forstår i et skærmbillede, så klik på alt hvad du kan finde!), så kom forklaringen: de snakker om, at man kan bruge den facilitet, hvis man kan lide billedet (ja, det er undersættelsen af det engelske ord "like").
I øvrigt en god ide, for tit kan man lide et billede uden direkte at have noget på hjerte, og så kan man så bruge den knap. Men nok ikke noget, som får den helt store udbredelse alligevel, for man skal være logget ind hos google, før at de vil registrere stemmen. Så topkarakter for ideen, bundkarakter for udførelsen!
...og forsøget på at lave en dansk oversættelse af brugerfladen - well, skal vi ikke bare sige, at den er uden for kategori?
Abonner på:
Opslag (Atom)