Irmen's blog

Upgraden moinmoin wiki

UPDATEN VAN MOINMOIN WIKI

Omdat ik elke keer vergeet hoe MoinMoin geupgrade moet worden die ik hier als wiki software gebruik, heb ik het maar eens uitgetypt:

1. download nieuwe moinmoin versie van de download site De meest recente versie op dit moment: moin-1.6.0.tar.gz
2. uitpakken en cd naar de installatie directory
3. moinmoin installeren in standaard Python framework locatie, en de default moinmoin data files in ~irmen/moininstalldata plaatsen (eerst inloggen als root!) :
   $ python setup.py install --install-data='/Users/irmen/moininstalldata'
4. kopieer de static htdocs files uit de moininstalldata naar de web server in snakelets, en zet de file ownerships op www:www:
   $ cp -r ~irmen/moininstalldata/share/moin/htdocs ~irmen/Projects/www_snakelets/webapps/wiki/
   $ chown -R www:www ~irmen/Projects/www_snakelets/webapps/wiki/htdocs
5. kopieer de static system en help files naar de juiste plaats, en zet de file ownerships op www:www:
   $ cp -r ~irmen/moininstalldata/share/moin/underlay ~irmen/Projects/www_snakelets/moinmoin/python/
   $ chown -R www:www ~irmen/Projects/www_snakelets/moinmoin/python/underlay
6. check of er iets is gewijzigd in de wikiconfig.py. meestal kun je deze file gewoon ongewijzigd laten. Bestaande file: ~irmen/Projects/www_snakelets/webapps/python/wikiconfig.py Vergelijk met: ~irmen/moininstalldata/share/moin/config/wikiconfig.py
7. bij opstarten van Snakelets webserver logt hij de moinmoin versie en naam. als er bij het tonen van een pagina nog iets mis gaat, is er misschien iets gewijzigd in de Request.py, dan moet je wikisnakelets/wiki.py editen.

Known bug: in de default 1.6.0 versie zit een bug die Moin doet crashen als de browser geen language header opstuurt. Zie hier. Dus de daar gelinkte patch heb ik toegepast. Het wachten is op 1.6.1...

Snakelets+Frog survives Slashdotting... but with slight hiccups

Cliff Wells' blog entry titled "Why the Light Has Gone Out on LAMP" was featured on Slashdot. Cliff uses Frog as his blog tool... So this is the first time -that I know of- that Snakelets+Frog had to withstand a Slashdot effect

Cliff mailed me about it, to tell me two things:

1. the server survived (only one or two timeouts)
2. there were some problems with users placing comments

While it is good to know that Snakelets can withstand a moderate slashdotting, the following problems sometimes occured in the commenting system of Frog:

• Frog was using the same comment id for multiple comments (ouch!)
• User got exception traceback in Frog code, it was no longer able to fetch an id from the request scope

It seems Frog has concurrency and/or timeout issues with placing comments. These are bugs that have to be fixed. So expect a new Frog version sometime soon

update: I have found and fixed a problem in Frog related to the double-id issue. The traceback crash is still there.

Tooltips (mouseovers) in non obtrusive javascript+CSS

BoxOver

Deze tooltip 'engine' is als blackbox aan te roepen zonder enige custom javascript te hoeven gebruiken.

Gebruik: 1. Onderaan de pagina moet je de .js file includen <script src="boxover.js"></script>

2. Voor ieder html element op de pagina dat je van een mooie custom tooltip wil voorzien (zoals een popup helptekst) zorg je dat in de "Title"-property de tooltip-parameters van een waarde voorziet.

voorbeeld: <img src="helpicoon.gif" title="header=[Help voor bruto jaarinkomen] body=[help tekst over het bruto jaarinkomen] hideselect=[on] fade=[on]" /> Dit is ook echt alles!

Wat je hier ziet is dat a) de header en body van de tooltip worden gevuld, b) alle selectboxen op de pagina even verdwijnen om te voorkomen dat ze door je help tekst heen komen en c) dat de tooltip met een fade-in wordt weergeven.

Er zijn nog meer veel parameters en voorbeelden beschikbaar op de website! En het ding is gratis (GNU licence).

(staaf)grafieken in CSS

Een van de meest gebruikte grafieken is toch wel de staafgrafiek denk ik. Staafgrafiekjes in een website kun je met een of ander server-side component ingewikkeld gaan zitten maken en dan een korrelig gifje gaan ophoesten. Waarom zou je het zo omslachtig, traag en lelijk doen, als je met een beetje CSS ook perfecte staafdiagrammen kan maken op basis van normale HTML tables/lijsten?

Een aantal voorbeelden:

• simpel voorbeeld inclusief lelijk gifje als vergelijking
• zowel horizontale als verticale diagrammen
• erg fraai voorbeeld met gradients
  (gebruik een willekeurige browser behalve IE, omdat die niet kan omgaan met de transparency. Voor IE zul je de "platte" versie moeten gebruiken die ergens genoemd wordt)

Some slight server changes

I've updated the Snakelets server software on this site.

The changes:

• Slight URL change for my Blog pages. The /snake/ prefix is gone. (If you access the "old" page, you will be automatically redirected)
• No more Apache reverse-proxy. Snakelets itself is now running on port 80 directly. Easier maintenance, more flexibility and hopefully also a tad faster than the old setup.
• New Snakelets CVS version has the option to run as a different user. This is, like with Apache, required from a security point of view.
• My Python WIKI is again available in the latest MoinMoin version running as a Snakelets webapp (it was running as CGI under Apache).

The new Snakelets code is only in the current CVS version, there's no new official release yet.

Better web app development frameworks - a screencast

Others have linked and blogged about it already but I just put this up here too because I too think its rather interesting and amusing. I'm talking about the screencast movie from Sean Kelly in which he compares several web application frameworks: Java J2EE, Rails, Zope(+Plone), Django and TurboGears.

The movie is here: better-web-app.mov (its 380 megabyte and is around 30 minutes playtime).

Like Joel Spolsky writes on his blog, "Warning to J2EE programmers: After seeing this presentation, you will never want to touch J2EE again for web development."

opeens verticale spacing tussen images in xhtml/html4 strict

Ik heb een paar images die zowel horizontaal als verticaal precies tegen elkaar aan moeten vallen. Als ik mijn pagina in HTML4 transitional maak, dan zag het er uit zoals ik wil hebben: 4 plaatjes, 2x2, zonder ruimte ertussen.

Toen ik er een HTML4 strict, of een XHTML strict pagina van maakte, verscheen er opeens een paar pixels verticale ruimte tussen de plaatjes zodat ze niet meer op elkaar aansloten

Wat blijkt het heeft iets te maken met de verticale alignment van de images, dus als je een stukje css toevoegt die de alignment op bottom zet, dan verdwijnt de tussenruimte weer. Je kunt ook van img weer een block-element maken, in strict mode is het namelijk een inline-element (en dit maakt ruimte voor letters die onder de baseline uitsteken).

img {
   vertical-align: bottom;
}
/* of: */
img { 
   display: block; 
}

Op de Mozilla developer site is een uitgebreid artikel te vinden over dit probleem.

Waarom websites maken die voldoen aan web standaards (management-spraak versie)

"Waarom zou ik extra geld besteden om deze website om te bouwen zodat hij ook goed werkt in een andere browser dan IE?"

Een veel te vaak gehoorde opmerking helaas. Hieronder dan een en ander aan informatie, gericht voor management in plaats van de hard core technici. Wellicht nuttig omdat aan argumenten zoals "W3C DOM functies werken in alle moderne render engines" managers en projectleiders meestal een broertje dood hebben.

• Why You Should Consider Budgeting a Site Redesign for Firefox 1.5 Now (Yes Firefox) (marketingsherpa)

  This special report is written specifically for marketers. You’ll learn the Six Business Benefits of a Redesign, and get a suggested Five-Step Action Plan, plus lots of useful additional info hotlinks.

• Wat zijn de voordelen van het gebruik van webstandaarden? (webstandards.org)

Meer informatie voeg ik hier toe zodra ik wat vind.

Firefox 1.5 has been released

Get it!

Commentaar op AJAX (en web applicaties)

Ik heb daarnet een artikeltje geblogd dat ik wel eens wat wil experimenteren met AJAX, maar het is ook goed om eens stil te staan bij wat het nou eigenlijk is. En hoe abominabel het eigenlijk is gesteld met veel "web applicaties".

Sommige mensen beweren (terecht of onterecht, dat moet je zelf maar uitmaken) dat web applicaties in een web browser de ontwikkeling op user interface gebied weer tien jaar hebben teruggedraaid. In sommige gevallen ben ik het hier zeker mee eens! Hoewel er een markt is voor web applicaties, gebeurt het helaas ook maar al te vaak dat een systeem dat zich eigenlijk helemaal niet leent voor implementatie als web applicatie, toch op deze wijze wordt opgezet. En de gebruikers daarvan moeten dan werken met een traag, simpel, gebruiksONvriendelijk, soms zelfs irritant systeem. Terwijl een 'normale' applicatie (dat wil zeggen, een echte desktop applicatie bijvoorbeeld gemaakt in Java, VB, Delphi of C#) veel beter zou zijn geweest omdat het daar wel mogelijk is om geavanceerde user interface mogelijkheden toe te passen (drag-drop die goed werkt, snelle verwerking, meerdere windows, etc etc)

Verder is er ook nog commentaar te leveren op de hele AJAX hype. Iemand op slashdot:

Take a reliable, stateful transport protocol (TCP) and lobotomize it so that connection state gets thrown away. This is http. Take a platform-independent object technology (Java) and lobotomize it so that dumb xml data structures get passed to "stateless" objects (in other words, procedures), and all processing must happen at one end of the connection. This is Web applications. Take gui technology and lobotomize it so that screens must refresh one page at a time. This is a browser. So: having gone from a world of functional, stateful, distributed applications engineered to a true software model, we are now back (despite all the self-congratulatory rhetoric about "objects") to procedural programming and dumb terminals (meaning Web browsers). In other words, 1970s technology with pictures. Any half-wit can see that this situation is broken. How do we fix it? The Ajax answer is to keep all of the lobotomized bits and build increasingly Byzantine layers on top of the existing mess in order to re-introduce the capabilities that were hacked off in the first place. Brilliant.

Een beetje overdreven, maar lees het nog een keertje door en denk er eens over na. Het is wel een beetje waar wat hij zegt of niet soms?

AJAX, toch maar eens mee gaan prutsen

Hier heb ik wat interessante dingen verzameld waar ik eens mee aan de gang wil om een AJAX applicatie te maken (Asynchronous Javascript And XML):

• Kupu client-side editor
• FCKeditor erg uitgebreide client-side editor
• Sarissa a cross-browser ECMAScript library for client side XML manipulation, including loading XML from URLs or strings, performing XSLT transformations, XPath queries and more. Supported: Gecko (Mozilla, Firefox etc), IE, KHTML (Konqueror, Safari) Let op: Safari ondersteuning schijnt niet helemaal correct te zijn...
• Mochikit make Javascript suck less. A highly documented and well tested, suite of JavaScript libraries that will help you get shit done, fast. MochiKit's creator, Bob Ippolito, is well-known in Python circles and has created a library that is natural to use for both Python and JavaScript programmers. It provides functions for performing asynchronous operations (AJAX, anyone?), logging (unless you really love alert boxes!), working with lists of data (and who doesn't), plus some amazing DOM tools.
• YUI The Yahoo UI library containing nice widgets and css and ajax stuff.

Ik ben er nog niet uit of ik als server code iets ga maken in mijn eigen Snakelets, of ook tegelijk maar eens Turbogears ga uitproberen (waar Mochikit al in zit dus).

The way forward with Web Standards

"Even though Web standards are being embraced by many Web authors, some businesses are reluctant to invest in standards-based Web sites without concrete reasons to do so. To help Web authors interested in advocating Web standards, this article assembles arguments and information about Web standards into one document and explains Web standards in terms of how they affect business. After outlining what Web standards are and how they are used, the article clearly demonstrates that adopting Web standards can improve many aspects of a Web site, such as: the amount of bandwidth used, load times, providing a foundation for accessibility, device independence and quality assurance processes. The article refutes several negative myths about Web standards and describes strategies for embracing standards. This article will lay the foundation for further research by MACCAWS into the nature of the business benefits Web standards."

Article here: http://www.maccaws.org/kit/way-forward/