Irmen's blog

Image uploads by drag/drop or clipboard paste, without java and flash

Uploading images on a website by drag/drop or pasting from the clipboard:

http://joelb.me/blog/2011/code-snippet-accessing-clipboard-images-with-javascript/

This doesn't use Java or Flash :) Used on this site: http://pasteboard.co

I've got to replace my image upload applet by this....

IE's document compatibility modes

IE's document compatibility mode selection. See below. Do NOT want

The original can be found here, click this to also see the embeddd images that are not shown below.

Flash = dood.

Adobe ceases development of Flash on mobile devices

.... zit er Flash op mijn telefoon dan????? Kan me niet herinneren dat ik ooit één website bekeken heb op mijn Android telefoon waarbij ik Flash wilde zien. Sterker nog als er toevallig 1 langskwam was het gelijk "traag, weg met die zooi". Misschien gebruikt de Youtube app Flash onder water, maar ik denk van niet, want youtube doet het ook prima op mijn iPod en daar zit zeker geen Flash op.

Flash is alleen om dumpert.nl en Youtube te kijken op je desktop toch ?

En zojuist lees ik dat Silverlight mogelijk hetzelfde lot beschoren is. Ik denk dat ik dat ooit geïnstalleerd heb om 3fm te streamen, of was het uitzending gemist? Ondertussen vergeten. Beide doe ik al lang niet meer.

#goodriddance

Scene demo in je browser (WebGL)

Ok, ik had niet verwacht dat WebGL zo krachtig zou zijn, om er een hele scene demo mee te kunnen maken:

http://traction.untergrund.net/slamdown/

Werkt in Firefox 4 (en mogelijk Chrome). (dat is dan het nadeel, WebGL is dan weer niet overal evengoed ondersteund blijkbaar)

Hier nog één: http://azathioprine.digisnap.bplaced.net/

javascript 3d canvas

Bah, javascript in een browser is sneller dan hardcore 68000 assembler met een custom coprocessor destijds op mijn Amiga in 1994

http://www.smashcat.org/av/canvas_test/

peppercorn: stream and record gebaseerde form parsing (in python)

Zonet Peppercorn gelezen. Verfrissende kijk op die stomme platte html form submit data en hoe je dat handig kan parsen (in Python). In plaats van een platte 1-op-1 mapping van keys naar values wordt er door een paar slimme trucs een soort van stream gebaseerde hierarchische structuur van gemaakt die meestal veel beter aansluit bij het datamodel van je applicatie.

Ook best aardig dat er een parse techniek gebruikt wordt die op zichzelf staand ook de moeite waard is om te bekijken. Het is iterator parsing van de Effbot. Ik denk dat het tegenwoordig nog handiger kan met generators of zelfs generator expressions, maar het basis idee is hetzelfde.

Kill IE6! Kill it with fire!

yes Yes YES!!! Google about to end support for IE6.

Eindelijk een major bedrijf dat gewoon keihard zegt F.U. tegen de stakkers die nog IE6 gebruiken. (Ok, ok, Youtube heeft al een paar maanden een waarschuwingsbanner voor mensen die IE6 gebruiken).

IE6:

update: ook maar eens een ie6-warning popup ingebouwd op mijn eigen site. Als je een voorbeeld wilt zien klik dan deze testpagina.

XML Billion Laughs attack, huidige stand van zaken

Ik was jaren geleden al eens aan het kijken naar de zogenaamde billion laughs xml attack, waarbij een doodsimpel xml bestandje van een paar honderd bytes zo'n beetje alle XML parsers (en web browsers!) op hun knieen bracht (enorm geheugengebruik en 100% cpu usage). Dit vanwege een exponentiele entity reference expansie. Meer info op Wikipedia: Billion Laughs.

Ik was nieuwsgierig of er tegenwoordig al wat vangnetten zijn geplaatst voor dit soort attacks, dus ik ging mijn million laughs testbestandje eens openen in een aantal web browsers. De resultaten zijn hoopvol! Waar een paar jaar geleden alle web browsers finaal onderuit gingen, zijn de resultaten nu ongeveer als volgt:

• Firefox 3.6: geeft foutboodschap 'XML Parsing Error: recursive entity reference'.
• Safari 4: geeft foutboodschap 'error on line 29 at column 18: Detected an entity reference loop'.
• Chrome: zelfde foutmelding als Safari (logisch, want gebruikt ook Webkit engine).
• Internet Exporer 8: gaat vrolijk het xml bestand proberen te parsen, maar dat duurt even . Gelukkig is mijn testbestand slechts 'million laughs' en niet 'billion laughs' want anders had ik geen resultaat gehad na 30 seconden en 500 Mb geheugen gebruik.
• Oxygen XML Editor 10: leest het probleemloos in maar zodra ik op validate klik gaat het mis Even geduld hebben en dan geeft hij wel netjes antwoord maar het kost 30 seconden en 1Gb geheugen.
• Java6: score 2/4 (DOM en SAX ok, XMLReader crash, STAX StreamReader faalt)
• Python2.6: score 1/4 (alleen lxml is ok)
• .NET 3.5: score 1/1 (te beschermen met XmlReaderSettings, zie update comment)

Voor meer info, zie de read more.

SVG en Canvas in IE: als Microsoft het niet voor je doet, dan zelf maar

Ik geef niet zo heel veel om wat voor dingen Internet Explorer allemaal niet ondersteunt (HTML5, SVG, Canvas, proper CSS, fast Javascript, enz).

Maar ik zie het nog wel gebeuren dat ik een keer gebruik ga maken van SVG en Canvas dingen. Dan is het wel grappig om te weten dat er javascript libraries zijn, gemaakt door derden, die in meer of mindere mate die dingen ook laten werken in IE:

• SVG: Google SVGWeb
• Canvas: Excanvas
• plotting library: Flot

De SVG library rendert in Flash in IE, en gebruikt native browser SVG in browsers die wel bij de tijd zijn (Firefox, Safari, Chrome). Flot gebruikt onder water Excanvas geloof ik, om de plots in te tekeken.

Edit: Ok het kan nog extremer. In het kader van "If they won't fix it, we will!"...: vervang gewoon de hele IE render engine door die van Google Chrome!

HTTP header madness: diverse problemen met Yahoo YUI, Safari en Firefox

Afgelopen week een aantal vreemde problemen tegen het lijf gelopen rondom HTTP headers:

1. Apple's Safari normaliseert de HTTP headers die hij van de server krijgt.
2. Het Connection object uit Yahoo's YUI library voldoet niet aan de standaard bij het opvragen van HTTP headers.
3. Mozilla's Firefox doet raar met caching van HTTP headers.

Achtereenvolgens is dat dan 1) raar; 2) API bug; 3) bug. Hieronder zal ik uitleggen wat deze problemen precies inhouden.

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. controleer even of de file permissie van de wikiconfig file goed staat (chmod a+r) anders krijg je een error bij het opstarten dat hij wikiconfig.py niet kan importeren
8. 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.

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/