CLOUDWORK ORANGE

the rumors of my death have been slightly exaggerated - although a constant lack of sleep makes me sometimes look as if i was.
so, well, yeah. i'm still alive. but since i recently (read: a year ago - we're using valve time here, ok?) became a dad, most of my time goes into trying to hack a child.
for example: it seems to be almost impossible to get the kid's internal sleep() function to accept values greater than four hours. or the good old echo(), which seems to internally convert every word randomly into an "AAAAA", "MMMM" or "DA*" (shouting is used intentionally). and don't get me started about whatever could be counted as output to any feed request …

nevertheless - i managed to find a few spare hours, in the middle of insomniatic nights, in wich i managed to start a few coding projects. the first being a price monitor and -history logger for amazon articles, to check some of their "interesting" pricing decisions and, of course, to get notified if a product reaches a specified price target or becomes part of a lightning deal.

this, naturally, lead to me buying a philips hue bride and then getting involved in some basic home automation, monitoring and building an (oh so hipster right now) magic mirror. a completely predictable chain of events.

unfortunately, due to the hefty loss in free time, it's all pretty much basic, ugly and uncommented code and therefore private stuff right now. but i'll try to comment, clean and then polish some of the scripts while updating this blog.

so what's to (hopefully) expect?

• overview of why i chose the protocols and hardware i, erm well, did choose (what an ugly sentence)
• philips hue: setup, using in app's automation and api connection via php
• wattcher & datalogger: setup, hacking the (awfully bad, slow and insecure) original tools and protocols
• homewizard: setup, connecting to wattcher, somfy, motion detectors, etc. and api connection via php
• magic mirror software: forking an existing open source, web-based package and adding motion detection, power meters, speech recognition voice synthesis and some under the hood changes / improvements
• magic mirror hardware: trying to make a spy glass out of a picture frame and reflection film, failing, retrying, failing again, ordering the spy glas instead of laminating it myself and waiting for the shipment …
• and finally: running into wifi / zigbee intererence and trying to resolve them by optimizing channel selection and later by switching to 5hgz on the wifi side

yepp, that's a long list. and counting in the tiny amout of time i can currently invest in writing, it's gonna take me a while to finish it.
but i'll take this post for a start and hope to get my first part (hard- and software overview) out there soon.

once upon a time in the late last century website were written for a specific browser. or multiple times if one was gracious. "this website is best viewed on internet explorer 5.5 in 800 x 600" was pretty common back then. it worked. sort of. of course users hated it when they tried to open a page in the "wrong" browser, but with only two major browsers – netscape and internet explorer – they surrendered in the fate.

then the new millenium came and with it some crazy ideas: web standards, cross browser compatibility and a plethora of new browsers. actually it got worse at first - websites had to rely on switches for different browsers, hacks for specific versions of that specific browser and so on, since users now got pissed when greeted with a "best before may 2001 when browser xyz version 6.032562 will completely screw up this layout".

but time went by and about 10 years later lots of those hacks and switches had disappeared. why? because most browsers had evolved into being standards compilant. some less (ie) some more (pretty much anything else). frequent updates of browser engines helped, too. now you had to do only 2 versions of a design. one for all the w3c compilant browsers and one filled with hacks and patches for good old ie.

well. ehem. f*ck. actually for ie9, ie8, ie7 and sometimes even for ie6 since lots of folks stick with the browser that shipped wither their system, never did any updates and seldom bought a new machine. bummer. still 4 to 5 versions. but it was manageable. and polyfills helped to get around missing features in older ies.

now, another five years later and even the internet explorer went over the edge (sorry for that) and is pretty standards compilant. hoooray! get out the champagne - one site fits them all. no more hacks, special css files for different browsers. pár°tèy.

oh. no. wait …

mobile devices are THE THING® nowadays. and android owns quite a big chunk of that market. no problem. ios' browser safari is based on webkit and so is android's stock browser. chrome is based on webkit, too and within the blink of an eye (oh no he did it again) opera became webkit / blink based, too. so we should be good to go, shouldn't we?

we should definitely be not. there is no such thing as the stock android browser. every big and minor version of android uses a different browser - some webkit based, some chrome based. and of course different versions of those engines. but that's not enough. nearly every manufacturer modifies the stock browser. some deploy completely different engines, some disable features, others enable features that are still experimental and known to be buggy and / or standards incompatible. but what's worst of all - they pretty much never get updated but sold for years. you can go shopping today and buy an android tablet that's still loaded with android 4.2 and there are no updates available for that thingy. the stock browser there is over three (3) years old. no updates. known bugs (e.g. try switching absolutely positioned layers to fixed positioning to make them sticky) and security problems. still there are neither updates available for the os nor at least for the browser itself.

here we are again. only this time the devil isn't called internet explorer but simply browser.

let's forget about android 3 (beginning of 2011). i rarely see them in the logs anymore but android 4 is still pretty frequent. and buggy. and fragmented. so workarounds become even more fine grained than with the ie. instead of two checks: "if this browser is ie with a version lower than 9 do xyz else do zyx" we now have 5: "if this os is android lower than version 4.4, but only if this device is a tablet, not a phone and the browser is not chrome or it is chrome but a version lower or equal version 18 do xyz else do zyx". and be sure - given time zyx will include quite a few more specific hacks for newer android / browser releases that have other bugs.

that's it. the same problem again, but even worse: old tech that never gets updated, either because people are lazy or there's simply no update available for this specific system. as well as that most peoply use and stick with the browser that shipped with their system. if you'd like to get to know more about the differences between android's default browser and android's default browser you can check out this slide: slides.com/html5test/the-android-browser

disclaimer: ai != artificial intelligence but ai == adobe illustrator

svgs in webdesign are great. especially when it comes to responsive design. having a company logo scale from 96px all the way to 320px@2x or whatever without the need to create 4, 6 or fricking 8 files is not only efficient on ressources but also on working time, read: customer's money. the same is true for icons, either linked or embedded ones.

that's not no say there are no caveats - support for legacy browsers is definetly one (that be ie). i had some trouble with not so crispy edges or sometimes jaggy edges or rendering errors on ie when running inside a vm. but that's nothing one can't cope with or at least work around. in case of legacy support my solution is pretty simple: ignore it. time is already taking care of this problem. soft lines or edges can be avoided most of the time by aligning vectors to a pixel raster, using the "most common" computed image size when working in illustrator and rendering errors within internet explorer inside a vm should affect about 4 people from which 3 at least are web designers that just use the ie for testing purpose.

so what's with the second part of the headline? illustrator writes svg code like microsoft word writes html code!

that may sound harsh but unfortunately it's true. for illustrator cs6 that is. since i'm not a friend of renting software, i'll have to stick with that version and no idea if the current one is any better at writing svg code. typical problems are empty groups (lots of them), way too many whitespaces and unnecessary comments. especially when it comes to small files i had icons where i could half the size of the svg. but of course manually cleaning every single svg file is no solution. so i had to write a small php script.

you can download a commented version of my svg minifier that has been stripped of all depenencies. the easiest way to use it would be to copy it into the folder where you keep your svgs and then instead of linking to [my_file.svg] link to [svg.php?f=my_file.svg]. since i'm also making heavy use of caching, it would be a good idea to apend a version variable like v=001 making that: [svg.php?f=my_file.svg&v=001]. e.g. by using a global variable like $GLOBALS['assets']['version'] in your config file and appending it to all static assets. that way you could force an update for any css, svg, js or whatever files after making bigger design or code changes while at the same time using browser caching. last but not least you could always add a .htaccess to rewrite your .svg calls to the svg.php one, making the use of the php script transparent.

so.
that's it for now. any improvements, ideas, bugs?