Sep 7, 2012

My fellow designer, Mateusz Dembek (aka @dembsky) asked me to code his redesigned portfolio and blog. Today the work is done and the site has gone live. You can see it at dembsky.me.

Jul 12, 2012

I’m cooking something special, here in my lab. One of things the project requires is generating random and totally fake users, complete with e-mail address, username and other details. Some time ago I’ve used Forgery Ruby gem to generate such data and it worked quite well. So, I thought I’d port it to Python. A few hours later, here it is.

Jun 18, 2012

One of my last tasks before leaving Weeby was to release StatusBoard on GitHub. I was very happy to see the app being open-sourced as I had a lot of fun (and did some magic) during its development and wanted to use it outside the company. For more info please see the app’s GithHub page.

May 10, 2012

I was asked by one of fellow devs why I use accessors for instance vars in Python. Because I’m used to accessors after coding in Ruby and Objective-C, I replied and went with my own business. But today a post by Dropbox about optimizing Python code popped into my head. It states that Python function calls are slow. I coded a small snippet to see how accessors perform compared to just accessing an instance variable.

Jan 27, 2012

Some time ago I started using Mustache in apps I write to make tedious task of generating HTML in JavaScript easier and more fun. Now, Mustache does the job well and fits my needs. There’s one problem, however. When I first tried to use the Mustache template in browser I found that it was pretty much impossible. Somewhere in the Internets I found someone’s post where he suggested we should use wrap Mustache code in script tag with text/html type. At first I was like WTF? but then I was like Including all the templates in every HTML? Srsly? because this method wouldn’t work when loading templates from files. I was stuck.

Dec 21, 2011

Some time ago I invented a password generator that fits into a tweet.

Oct 11, 2011

One of my projects required me to write a small Web app that informs a user about status of a long-running server process. The idea is that the user triggers the operation from Web frontend, the backend spawns a worker (implemented as a standalone program), listens to notifications from the worker and passes them to the frontend. I was thinking about implementing (almost) realtime backend and frontend communication and came up with two solutions - WebSocket and Server-Sent DOM Events. I decided to go with Server-Sent DOM Events as they’re HTTP-based and one-way. While using WebSockets would be simpler (Socket.IO + TornadIO and it is on) I thought it’d be overkill for server-to-client communication.

Jul 24, 2011

@dembsky, my fellow designer who created graphics for I ♡ GIT, asked me to write an app for him to do a contest for a Dribbble invite. If you’ve got anything to do with graphics design and would like to be a part of Dribbble community you may want to take your shot in the contest. Rules are simple so is the app that I wrote.

Jul 1, 2011

I ♡ GIT is a small Web app I did to allow you to say why you love GIT. Just sign in using your Twitter or GitHub account and you’ll be able to say a few words about why GIT is cool. I got the idea when I said to myself Man I love GIT after doing some magic with it.

May 15, 2011

Imagine you’d like to publish a live stream from an event, say your dog’s first birthday. What tool would you use? You could set up a WordPress instance and publish the stream using it. That would do but wouldn’t be cool - people reading the stream would have to refresh the whole page and you’d have to mess with heavy CMS. You could use Twitter and publish the stream using a hash tag. That wouldn’t be cool either since your friends watching the event would have to be familiar with Twitter and anyone could tweet using the hash tag. What would really be cool is a dedicated app, that uses some sort of push technology to deliver your updates to all the users once you post them. Now that’s interesting, right? But coding such an app takes time and requires messing with browser quirks, setting up server and doing many things. And you haven’t got that much time - you have to prepare party for your doggy. This is exactly where Pusher kicks in. They provide you with backend for your live stream and a client lib that’s very easy to use and deals with all the dirty stuff for you. What you have to do is write an app that you’ll use to deliver messages to people and code some JavaScript that’ll handle incoming messages. That’s an easy task, isn’t it?