It lives!
Eller "godt nyttår" som det også heter i starten av et nytt år...
2009 har fått en stille og rolig start her på berget, men fortvil ikke, jeg har ikke gitt meg enda. Først og fremst vil jeg ønske alle gamle og nye(?) lesere godt nyttår, om enn noe sent.
Sein start
Desember var svært aktiv på cjohansen.no, med JavaScript-julekalenderen. Denne medførte "noe" mer jobb enn forventet, og når det hele var over var jeg for å være ærlig ganske mett på å skrive for en liten stundt. Men den siste tiden har opp til flere emner surret i hodet, selvom jeg enda ikke har fått prioritert tid til å skrive dem ned.
2008
Mange syns det er moro å oppsummere året som gikk, og jeg kan forsåvidt sympatisere med det. Men jeg har ikke tenkt til det, annet enn å notere at jeg skrev en god del artikler ifjor, og du finner dem allesammen i arkivet. Selv er jeg ganske godt fornøyd med deler av den nevnte julekalenderen, selvom jeg kanskje hadde ønsket meg noe mer input fra dere som leste det. Det er enda ikke for sent!
2009
Det er langt mer interessant å snakke om 2009. Hittil i år har jeg brukt tiden jeg i desember brukte på å blogge til å kode. Aller mest har jeg kodet på Juicer, et prosjekt jeg såvidt introduserte i julekalenderen. Juicer er et Ruby-bibliotek og kommandolinje-program for å kombinere, syntakssjekke og minifisere CSS og JavaScript-filer (ved hjelp av blant annet Yui Compressor og JsLint). Omtrent som en liten kompilator. Jeg tror den blir ganske nyttig, og kommer tilbake med en bedre presentasjon når jeg har nådd målet jeg foreløpig har satt meg. Det er planlagt å skje om ca to uker.
Validatious
Jeg har noen planer for valideringsrammeverket mitt, Validatious, også. For det første har jeg laget en MooTools-bro ala Prototype.js-broen som allerede eksisterte, og får vel også lage en for jQuery. I tillegg har jeg skrevet om noe backend-logikk for enhetstestene fra PHP til Ruby via Sinatra (et lettvekts bibliotek for webapper som er skikkelig morsomt å jobbe med). Til slutt flytta jeg koden fra et lukket svn-repository til det langt hyggeligere og mer åpne Github.
Neste skritt på stigen er å pusse opp websiden littegrann, og da først og fremst lage flere eksempler som viser fleksibiliteten i rammeverket.
Rails-plugins
Jeg har noen planer for noen Rails-plugins også, da spesielt validatious_on_rails, som søker å automatisere klientsidevalidering fra valideringer satt i ActiveRecord-modellklasser. Dette gjorde jeg litt på i november, og det er vil fungere, jeg må bare gjøre det ferdig. Jeg har også et par andre plugins opp i erme, jeg mangler bare noen timer i døgnet...
En del kodeprosjekter på gang altså, men litt blogging vil jeg også prøve å få tid til.
cjohansen.no i 2009
For det første: jeg skal fjerne julepynten snart, lover! :)
Det er 2 år siden jeg startet å blogge fast nå, og jeg liker det veldig godt. Så godt at jeg har litt lyst til å prøve å nå flere med skribleriene mine. Av den grunnen ønsker jeg å teste å skrive litt på engelsk. Dette vil jeg veldig gjerne ha innspill fra dere som har lest cjohansen.no over en lengre eller kortere periode på. Er det dumt å bytte til engelsk? Har bloggen mye verdi i kraft av å være norsk, eller i kraft av innholdet?
Jeg har ingen umiddelbare planer om å fullstendig legge ned norsk aktivitet, men det er enkelte ting, særlig det som dreier seg om open source-kode jeg skriver, som jeg ønsker å presentere på engelsk for at det skal bli tilgjengelig for flere. Jeg tar som sagt gjerne innspill på dette.
Temaer
I nær fremtid håper jeg å få skrevet litt om:
- Flash-inkludering med standarder og JavaScript
- mod_rails/phusion passenger + git + capistrano
- mer om JavaScript-testing (blant annet oversette noe fra kalenderen til engelsk)
- og mer
Jeg håper og tror 2009 blir et spennende år, hva tror dere? Og ikke minst - hva er deres planer for 2009?
Comments
Thomas Raddum
(http://www.superform.no)
16. januar, 23:35
Blogget i et par år sier du, spennende å høre om blogge-erfaringer. Selv har jeg skrevet i det små til og fra siden 1998, men har fått litt terskel på det nå. Det er mange bloggere etterhvert, og mye uinteressant. Har ikke lyst til å bli nok en ullprodusent. Bruker superform.no mest til sosial-media eksperimentering, men kjenner at det begynner å friste å skrive igjen. Skal følge deg og la meg inspirere. Feeden din er herved på plass.
Aksel Nordal
17. januar, 12:28
Jeg er rimelig tent på Juicer-prosjektet ditt, ettersom jeg selv har jobbet med videreutvikling av et liknende system (ref min kommentar i julekalenderen - dog uten den nyttige @depend kommandoen).
Jeg har imidlertid en feature-request - en kobling mellom juicer-kompilatoren og html-output. F.eks.
1) Webkomponenten bør enkelt kunne konfigureres til å skru av kompresjon og minimering (mens man jobber i et uviklingsmiljø).
2) Videre bør webkomponenten legge til headerne "expires" (dvs far-future), "modified" og "if-modified-since", samt gzippe outputen (konfigurerbart, selvsagt :-)). I et prodmiljø er dette svært nyttig, ettersom brukeren bare trenger å laste ned små js/css-filer første gang. Ved behov for å rulle ut nye filer, endrer man bare version-paremetet - som skaper en ny og unik url og således flusher browser-cachen.
3) Til sist, men ikke minst, bør den ferdig-kompilerte versjonen av js/css-filene caches i minnet eller til disk, for å slippe å kompilere en ny pakke for hver nye bruker som finner veien til nettestedet ditt. Her kan version-paremeteret igjen være til hjelp. Alternativt kan det genereres en md5-hash av filnavn og timestamp for å sjekke behov for rekompilering.
--------
Mulig dette er feil sted å kommentere, men håper du ser nytten av kommentarene ovenfor. Jeg hadde ihvertfall blitt glad hvis du utvider juicer slik beskrevet over ;-)
Christian
18. januar, 02:12
Aksel: Kult, takk for innspill! Jeg har allerede tenkt over flere av problemstillingene du nevner, men i utgangspunktet i konteksten av en Rails-plugin som benytter Juicer-API-et til å gjøre noe ala det du foreslår.
Som du foreslår hadde det vært enda kulere om man fikk en fritt brukbar webkomponent som kunne kjøre på siden av webappen ellers, som en liten lettvektssak. Ideer til hvordan dette funker på baksiden? Skal det integreres mot systemet ellers blir det jo platform-spesifikt, og det var her jeg så for meg Rails-pluginen (og kanskje andre lignende ting).
Dette er forøvrig et sted godt som noe å kommentere, og jeg setter stor pris på tilbakemeldinger og innspill. Jeg kommer til å fokusere på å ferdigstille nåværende versjon av Juicer først, men vil deretter sette igang med noe ala det du foreslår. Noe jeg jobber med som også blir nyttig her er "cache busters" for bilde-url-er i stylesheetene, slik at disse også oppdateres i brukerens cache. Ser for meg en "soft" variant (bilde.gif?678637) og en "hard" variant (bilde-383942.gif). Den siste krever server-oppsett, men unngår standardkonfigurasjonen til Squid, som ikke oppdaterer cache på den første varianten.
Dersom du har flere idéer rundt dette eller andre ting knyttet til Juicer, gi gjerne beskjed! Jeg har forøvrig såvidt notert meg noen tanker i denne åpne trackeren: http://cjohansen.lighthouseapp.com/projects/22836-juicer/
Aksel Nordal
18. januar, 13:19
Selv har jeg jobbet med php-webkomponenten Smartoptimizer (http://farhadi.ir/works/smartoptimizer). Smartoptimizer gjør mye av det samme som Juicer: kombinerer og minimerer - i tillegg til å sette opp expires/modified headere, gzippe outputen og serialisere CSS-grafikk om til base64-data. Videre caches output i en filcache med md5-hash generert av de inkluderte filenes navn og timestamp.
Mitt bidrag i denne settingen har vært mindre justeringer av koden for å støtte relative filbaner (hhv for Linux og Windows), mulighet til å skru av og på kompresjon via URL-parametre, samt en Java-komponent på toppen som bygger unike URL-er i dev-miljø (vha timestamp på url-en) og faste URL-er i prod-miljø (versjonsnr).
Det som skiller Juicer fra Smartoptimizer er syntax-kontroll mot JSLint, YUI for kompresjon og @depend-annoteringen, noe som er veldig bra! I praksis nærmer man seg en JIT-kompilator, der evt. kompileringsfeil (dvs. JSLint som rapporterer) kan rapporteres direkte i nettleseren i form av en alert-box eller console.log-linje.
Jeg er ingen Ruby-programmerer selv, men slik jeg ser det skal det ikke altfor mange kodelinjer til for å skrive wrappere i Java, PHP, ASP.NET, Perl m.fl. som håndterer request/response-logikken, og henter data fra Juicer via en shell-kommando eller en webservice.
Jeg følger ellers med videre i spenning...
sfreud
28. januar, 23:19
+ Alle med interesse for dette er som regel svært komfortabel med å lese faglitteratur, APIer og dokumentasjon på engelsk, og vil derfor ikke merke forskjell.
+ Flere kan lese bloggen din.
Ellers må jeg si det er kult å se at du kan blogge om web uten at det blir teit (feks stabel som stack-sortering).
Christian
29. januar, 08:31