4waisenkinder

This article describes still rarely supported Shadow DOM features. If you want to see them in action, make sure you use Chrome Canary with turned on “Experimental web platform features” found at about:flags.

This is the second article of a tutorial series (I do not know yet how many articles will follow, but let us call it a series) about how to get started with web components and polymer.js. In case you missed the first article you can check it here. This article will describe things to improve the checkbox component, that got built up in the last article. By improving I mean making the web component more configurable and making it stylable from the “outside”. Additionally it will cover some mistakes that were made in first place, but let us just dive into it. ;)

I play around with the d3.js library for a while now and I always thought that stuff like gradients and shadows are not so easy to create with SVG and that it is simply not made for that. The reason for that is, that when I’m browsing through the d3 example gallery there is so much awesome data visulation, but shadows and gradients are not really present. I know, we are inside of the “flat design era” right now, so who should care about that, but I really like shadows, when they are at the correct places. Gradients on the other hand make very often the tiny tiny difference of a good design and a great design.

This article describes still rarely supported Shadow DOM features. If you want to see them in action, make sure you use Chrome Canary with turned on “Experimental web platform features” found at about:flags.

I spent a lot of time on codepen the last days to train my CSS skills and to relax a bit (it is really awesome to just play around there while watching a movie). One thing I created was a styled checkbox. And while doing that, the idea came to me, that this checkbox is a perfect use case to start playing around with this magic thing called “web components”, that is heavily around since a few month and is probably the “next big thing” in web development.

Today I ran into an issue that let me dive into the Backbone.js library. Very often developers just use the stuff that is in there because it just works fine, but when it does not do what it is supposed to do the best way is to have a look into the used library and figure out what is going on.

My case was the following:

I had some lines for getting the index of a particular model stored inside of a Backbone collection.

Recently I started developing my first grunt plugin called grunt-photobox. The goal was to make the layout QA-process before shipping a new feature much easier. It should take screenshots of every relevant site and compare it to the last one – post about how to use it here.

The base for that should be phantomjs. It’s a headless webkit browser, that gives you all functionality a “real” browser has plus a few features for making screenshots or reading files from disk for example. You can run it via command line and pass in a script to execute inside the scope of phantomjs.

1

$ phantomjs script.js

Recently at work we ran into the issue, that we had a broken layout in production. Everybody knows that and sure everybody produced that already. Most of the time it is not a big deal, but it is an uncomfortable situation to get the message like “Hey, the product detail page is broken.”. We implemented grunt a few weeks before and got the idea to make the check for broken layout a bit easier for us and the QA-Team than clicking through the whole site in different screen sizes.

A few people may have noticed, that npm install grunt was failing today. According to the pull requests made, it was failing for 10 ( ! ) hours. When you think right know, that this is not a big deal, you probably do not use it in production. Because then it becomes a big problem very quickly.

Many people run their test suite at Travis CI these days. At Travis you got the possibility to run your test suite against different programming languages and different versions of these ( e.g. node 0.8 / 0.9 / … ). Figuring out if there will be any problems or exceptions before switching to a new language version are easily done this way ( always assuming you are following the principles of test driven development ). Test your stuff at Travis first, then switch your server to the new version of language XY.

Two month ago I released my first npm module. I got really excited (and I am still) about releasing something and showing it to the world. Since then the statistics written on top of the module page at NPM are checked by me on a daily basis. Unfortunately these statistics do not seem to be really precise. They are jumping from day to day and should not be taken to serious in my mind (No offense meant. I really like NPM and I think it is a great service).

That is the reason why a friend of mine wrote a tiny script to read the statistics directly from where the data is stored – a CouchDB available for everyone. The script will be part of a library for geeky stuff and tools later on, but that is another story.

Today I had the idea about showing this kind of information whenever I open a new terminal window to save some time and “pimp my terminal”.

Hey, I study Media and Computer Science in Berlin and I need your help. The last goal of my studies is to write my bachelor thesis and I want to show you what it is about.

I am in colaboration with Travis CI (you may have heard about it) and my goal is to analyse the data Travis produces everyday. Data about every build that is triggered by any open source project over the world doing continuous integration.