Ideas Worth Spreading: Issue Tracking

Real-world metaphors are quite abundant when discussing topics related to IT and programming. They seem to be particularly useful when introducing newcomers, although it’s equally easy to point out mature and established techniques that originate from non-digital world (OOP anyone?…). Regardless, the flow of ideas seems to be extremely one-directional, and I think that’s very unfortunate. There’s wealth of concepts specific to IT or software industry that the general public would benefit from knowing about.

One of those, in my not-so-humble opinion, is the idea of issue tracking. I suppose vast majority of readers is intimately familiar with it but let’s put it into words anyway, for the sake of clarity and explicitness. The concept revolves around a system which allows its users to create tickets describing various issues pertaining to some particular project, or part of it, or process, or any similar endeavor. Those tickets necessarily consist of title and content, very much like emails. Usually though, they also have few additional fields that are more meta, and describe the ticket itself. Typical examples include:

• A type or category for ticket. In software project, the distinction between bug and feature request is of utmost importance, although several more kinds of tickets (e.g. documentation-related tasks) are pretty well known too.
• Status of a ticket, indicating what’s currently happening with the issue in question. Did it arise only recently, or some work on it has been already done? Maybe it was successfully resolved, or maybe there are more information needed to push the case further… Either way, that’s what ticket status should tell us.
• Person currently responsible for issue – the one it has been assigned to. For new issues, this field usually points at project manager, who is subsequently dividing work among members of their team.

Lastly, every ticket allows for discussion in a forum-like manner, and for adding comments to any metadata changes we make.

That’s it, in a nutshell. It doesn’t seem very complicated and frankly, it may not sound very innovative either. Why do I think such a concept is worthy of attention in broader context, then?…

Pimp My WLAN

About two weeks ago I moved to Netherlands, landing in a medium-sized but cozy town of Groningen. This of course deserves a general blogpost on its own right (more than a single one, in fact), but the story I wanted to share today is extremely specific. For the most part, it’s also purely technical, exhibiting typical hacker’s dynamics. An overarching theme is an “itch” that needs to be scratched.

Let’s start then, first by defining the problem at hand.

On architectural features

I happen to live in a square which is referred to as town’s center, where significant fraction of buildings – maybe even majority – look kinda like this. Don’t pay too much attention to the outside appearance, as it can be very misleading. Despite their seemingly old architectural style, they’re often quite new and modern, but have been “retrofitted” to match the surrounding urban landscape. Final effect is rather pleasing aesthetically, I’d say.

What is more important and relevant here, though, is the size of windows. By my standards at least, they are simply enormous – and this fact precludes simple evaluation. (On one hand, there’s a lot of sunlight! On the other hand, there’s a lot of sunlight…). Moreover, it hints at how remarkably long the vertical distance between floor and the ceiling is. In my case, it’s about 2.8 m (that’s 9 ft for you Imperalists), having a significant impact on how spacious the apartment feels.

On insufficiently vertical waves

But for the issue I want to talk about, this was actually a downside. The matter concerns Internet access, which is shared among mine and three neighboring apartments through a Wi-Fi network with a single access point. In theory, the area it has to cover spans just couple of meters. In practice, however, it’s hindered not only by walls and doors, but also – and maybe even primarily – but this significant distance along the vertical axis.

See, most of the typical household wireless routers have directional antennae which are deliberately set to output signal mostly in the horizontal plane. While this allows for a single AP to easily cover even big apartment, it is also a liability in a setting similar to mine. Because the access point is on ground floor, it fails to appropriately cover the higher levels. And since this includes the very place I’m living in, I’ve been having rather annoying problems caused by signal’s low strength and quality: dropped packets, lost connections, and all that stuff. Even web browsing (or similar activities that doesn’t really depend on latency) has been very cumbersome, despite sitting less than 5 meters in straight line from the access point! It’s almost amazing how one can get screwed over by such simple design limitation like the direction of an antenna.

So, you can easily see how this was a problem that yearned to be solved. But how? One does not simply make the waves go further, right?…

On re-purposing of the old hardware

Actually, this is perfectly possible: devices known as WLAN repeaters do just that. Serving as sort of amplifier, they can extend the range of wireless network by relaying its signal between base access point and the final receiver, e.g. WLAN interface in a laptop. Basic physics suggest that it obviously cannot be done for free, so side effects include decreased performance of such range-extended networks due to reduced bandwidth. But where applicable, this solution is usually worth its while.

The Router

My scenario was definitely one of those, as I vastly prefer “not ideal Wi-Fi connectivity” to “almost no Wi-Fi connectivity at all”. So I went to investigate how I could procure such a device. Specifically, I had an old router lying around unplugged and useless – and it quickly gained my attention.

I cannot say that I’m any sort of expert when it comes to telecommunication, electronics or hardware of any kind (that’s vastly below the level abstraction I typically operate on), but I have some basic idea of what a wireless router really is. Elementary deduction suggest it’s a transceiver, an equipment able to receive and send out radio signals. What those signals are – that should be pretty much irrelevant, as long as (1) they fit into physical characteristics of the device and (2) the only thing we want to do is to propagate them further.

In short, it should be capable of acting as a repeater! Yay?

On awesomeness of the open source

Well, not really – not at a first glance, at least. While many routers feature the repeater option in their firmware, mine is somewhat old and low-end model: it doesn’t even support IPv6, not to mention goodies like the 802.11n band. Acting as a relay was also on this “nay” list, because being an ordinary access point is pretty much the only thing this inconspicuous black box used to know.

But thanks to one impressive piece of hackery, it was possible for its limitations to be lifted. What I’m talking about is DD-WRT – a community project that provides a custom firmware for variety of different models of popular routers. This firmware is very powerful and allows to easily tap into device’s hidden power, exposing capabilities omitted in vendor software. In my case, it promised to provide the crucial Client Bridge feature: ability to create more then one virtual, wireless interface and form a bridge between them in order to relay network traffic.

On thrills & perils of low-level hacking

I set to try it out – and it turned out to be non-trivial, to say the least. Some steps of the process were amusing due to their obscurity – like setting up a local server for the archaic TFTP protocol. Turns out it was needed for the actual transfer of new firmware and a small Linux distro that works on top of that. I suppose you have to do same when installing Linux on a microwave, but admittedly, I haven’t tried that just yet ;)

The most troublesome part was actually the very beginning. It involved connecting to the device via Ethernet wire and then telnetting at the right moment during it’s boot-up. This way, it is possible to access the RedBoot bootstrapping shell and perform all kinds of surgery on software internals.
Unfortunately, the instruction for making this happen was hopelessly unclear. I spent good several quarters troubleshooting any potential issues, even going as far as to use Wireshark to monitor any traffic originating from the router, looking into how it identifies itself within this crude two-node network.

Fortunately, I’ve later found a much better instruction that didn’t lack the rather important part about holding down the RESET button for, well, long time. From there everything went rather smoothly.

On trickery of network management

The last part was tweaking numerous options and settings in DD-WRT’s web interface in order to make the router talk to its cousin downstairs. This level of abstraction was obviously much more comfortable for me to work at. Still, there was some sorcery involved, as in deciding whether I’d like to have my own subnet or operate within existing one – essentially a choice between WLAN-to-WLAN router or “switch”. The second option was of course much more appealing because it was completely transparent to clients. Choosing it, I didn’t have to reconfigure the vast multitude of my 3 (three) devices that use Wi-Fi :)

This variant ended up being more complicated, though. And again, I have found both good and rather crappy instructions on how to make it happen – but unlike last time, now they were both coming from the DD-WRT wiki. Well, seems like documentation is not among the strongest sides of this project…

It works!

But rest assured: this story has a happy ending :) Yes, it was preceded by juggling IP configuration of my PC and few reboots of the router, but it would be malicious to consider this as something more than a little nuisance.

So, what’s the point in all of this?… I guess the bottom line would be about not being afraid to experiment if something needs to be improved. Risk aversion is powerful, true – but sometimes even failure is not that bad, especially if everything remains inside the realm of software. Here, even if you “blow” something up there will be no holes left to cover with duct tape ;-)

Looking Back, and Maybe Even Forward

Also known as Obligatory New Year’s Post.

It was quite a year, this 2011. No single ground-breaking change, but a lot of somewhat significant events and small steps – mostly in the right direction. A short summary is of course in order, because taking time to stop and reflect is a good thing from time to time.

Technically, the biggest change would be the fact that I’m no longer a student. Attaining MSc. some time in the first quarter, I finished a five year-long period of computer science studies at Warsaw University of Technology. While there are mixed views on the importance of formal education, I consider this a major and important achievement – and a one with practical impact as well.

Being a polyglot is fun

My master thesis was about implementing a reflection system for C++. Ironically, since then I haven’t really got to code anything in this language. That’s not actually something I’m at odds with. For me, sticking to just one language for extended period of time seems somewhat detrimental to development of one’s programming skills. On the other hand, there goes the saying that a language which doesn’t change your view on programming as a whole is not worth learning. As usual, it looks like a question of proper balance.

This year, I’ve got to use a handful of distinct languages in different contexts and applications. There was Java but mostly (if not exclusively) on the Android platform. There was JavaScript in its original incarnation – i.e. on client side, in the browser.
Finally, there was Python: for scripts, for cloud computing on Google App Engine, for general web programming, and for many everyday tasks and experiments. It seems to be my first choice language as of now – a one that I’m most productive in. Still, it probably has many tricks and crispy details waiting to be uncovered, which makes it likely to grab my attention for quite a bit longer.

Its status always has contenders, though. Clojure, Ruby and Haskell are among languages which I gave at least a brief glance in 2011. The last one is especially intriguing and may therefore be a subject of few posts later on.

Speaking and listening

2011 was also a busy year for me when it comes to attending various software-related events. Many of these were organized or influenced by local Google Technology User Group. Some of those I even got to speak at, lecturing on the Google App Engine platform or advanced topics in Android UI programming. In either case it was an exciting and refreshing experience.

There were also several other events and meet-ups I got to attend in the passing year. Some of them even required traveling abroad, some resulted in grabbing juicy awards (such as autographed books), while some were slightly less formal albeit still very interesting.
And kinda unexpected, too. I learned that there is bunch of thriving communities gathered around specific technologies, and they are all just around the corner – literally. Because contrary to the stereotype of lone hacker, their members are regularly meeting in real life. Wow! ;-)

Odkrycie archeologiczne

Sprzed prawie czterech lat pochodzi pewien niewielki (~2KLOC) projekt uczelniany, na który natknąłem się kilka dni temu w swoich przepastnych archiwach i postanowiłem upublicznić. Jest to implementacja prostego (acz zupełnie funkcjonalnego) serwera FTP, napisana w czystym C pod systemy POSIX-owe. Nie spodziewam się bynajmniej, aby mogła znaleźć rzeczywiste zastosowanie jako kawałek oprogramowania. Jest ona jednak całkiem interesująca jako kawałek kodu.

Wielu znany jest zapewne “syndrom następnego pół roku”. Polega on na tym, że gdy po pół roku (plus/minus kilka miesięcy) spoglądamy na stworzony przez siebie kod, widzimy go tak, jakby napisał go ktoś zupełnie inny. Zazwyczaj wręcz trudno nam się w nim połapać i szybko dochodzimy do wniosku, że teraz napisalibyśmy go zdecydowanie lepiej. Nasz twór traktujemy więc jako bezwarto… ekhm… legacy code (;]), i uważamy to za naturalną kolej rzeczy.

Jednak moje niedawne znalezisku okazało się pod tym względem sporym zaskoczeniem. Nietypowe jest bowiem to, jak przetrwało ono próbę czasu. Na jego podstawie muszę dojść do lekko szokującego wniosku, iż Xion₂₀₀₇ potrafił – o zgrozo – pisać dobry kod. Robił to wprawdzie ostrożnie i raczej niepewnie (czego dowodem była przesadna ilość komentarzy), ale koniec końców udawało mu się to całkiem nieźle. Wysyłając mu wiadomość z przyszłości, mógłbym wprawdzie wspomnieć o zaletach podziału kodu na pliki krótsze niż 800-linijkowe, lecz poza tym do niewielu rzeczy mógłbym się przyczepić. To zupełnie akceptowalny, czytelny i przejrzysty kod w C…

Madness!

Prezentacja o C2DM

Zamieszczam slajdy z prezentacji, którą wygłosiłem dzisiaj w ramach Polidea Talks. Dotyczy ona androidowego wynalazku znanego jako Cloud to Device Messaging (C2DM) i będącego odpowiednikiem apple’owych Push Notifications z systemów iOS i OSX. Dla nie do końca zorientowanych spieszę z wyjaśnieniem, iż jest po prostu dość sprytny sposób na to, by urządzenie mobilne mogło “natychmiast” otrzymywać informacje ze zdalnego serwera – bez konieczności regularnej synchronizacji, która zużywa baterię i nie tylko.

  Push! - Instant notifications on Android through C2DM (591.7 KiB, 1,974 downloads)

Slajdy są tym razem w klasycznym PDF-ie. Chwilowo nie mam żadnej lepszej alternatywy dla starego, dobrego PowerPointa :)

GDD w Pradze

Miałem ostatnio okazję wzięcia udziału w jednej z lokalnych edycji konferencji Google Developer Day. Na to wydarzenie składa się cykl wykładów prowadzonych przez przedstawicieli Google, traktujących o technologiach webowych, mobilnych i tym podobnych tematach. GDD, w którym akurat ja uczestniczyłem, odbywał się wczoraj w Pradze.

Przyznam, że nigdy wcześniej nie brałem udziału w podobnym wydarzeniu, więc było to bardzo interesujące doświadczenie. Większość z prezentowanych tematów wydawała się niezwykle ciekawa, a ze względu na to równoległy przebieg aż pięciu ścieżek wykładowych należało dokonać bardzo trudnego wyboru, których sesji chcemy posłuchać. Miejmy nadzieję, że wszystkie tak czy siak wkrótce trafią na YouTube :)

Od siebie dodaję kilka zdjęć. Ich jakość nie jest aczkolwiek powalająca, bo zostały wykonane sprzętem, którego główne przeznaczenie jest zgoła odmienne ;)

Update: Oficjalna galeria zdjęć z imprezy jest już dostępna.

Piękna i JavaScript

Publikuję slajdy z prezentacji The Beauty and the JavaScript, którą wygłosiłem w zeszły poniedziałek w ramach Polidea Talks – cyklu wykładów wygłaszanych w różnych odstępach czasu przez osoby pracujące w Polidei. Jak sugeruje nazwa, rzecz dotyczyła języka JavaScript i bynajmniej nie przedstawiała go w specjalnie pozytywnym świetle ;) Chciałem aczkolwiek pokazać, że przy odrobinie dobrej woli i zręcznym unikaniu pułapek da się z nim żyć, co obecnie jest często koniecznością.

  The Beauty and the JavaScript (27.6 KiB, 1,545 downloads)

Sama prezentacja jest też pewnego rodzaju ciekawostką, bo została przygotowana jako dokument HTML do oglądania w przeglądarce WWW. Do renderowania slajdów używa biblioteki S5, która napisana została w – a jakże – JavaScripcie. Rozwiązanie to sprawdziło się zresztą całkiem nieźle w przypadku prostych slajdów, takich jak niniejsze.

Całość jest też dostępna jako gałąź w repozytorium na GitHubie.