Posts from 2013

Now That’s What I Call a History Lesson

2013-02-09 6:44

Software exhibit from MTV museum“Museums are boring!” If you hold such an opinion, it’s quite likely you haven’t been in those really interesting ones yet. Today (or yesterday, depending on PoV) I happened to be in such a place, and I can assert its awesomeness with unparalleled confidence.

It’s the Computer History Museum in Mountain View, CA. If you ever find yourself in northern California, I definitely recommend paying a visit there.
Inside, you can find all sorts of extremely cool exhibits from the somewhat short but wildly interesting history of computer science. Anything from early vacuum tubes, through Commodores and up to iPhones, with all the surprising stuff in between.

I couldn’t spend a whole day there, sadly, but I took a few pictures. Apologies for the low quality of some; although I took them with a device that won’t land in this museum for quite a while, it’s still just a phone.

Tags: ,
Author: Xion, posted under Computer Science & IT, Life » Comments Off on Now That’s What I Call a History Lesson

Complex Stubbing with Mockito for Java

2013-02-01 6:33

Mocks are used to “fake” the behavior of objects to the extent required by tests. Most of the time, they can be pretty simple: when calling a method with given set of (constant) argument, then return some predefined value. Mocking frameworks actually strive to translate the previous sentence directly into code, which can be seen in Java’s Mockito library:

  1. @Mock private SomeBuilder someBuilder;
  2. @Mock private SomeObject someObject;
  4. private void mockSomeBuilder() {
  5.     when(someBuilder.setFoo(anyString())).thenReturn(someBuilder);
  6.     when(someBuilder.setBar(anyInt())).thenReturn(someBuilder);
  7.     when(;
  8. }

What is evident here is that this mock doesn’t maintain any state. As a result, all stubbed method are completely independent and referentially transparent: they always return the same value for the same set of arguments. In reality, that property is even stronger because they are simply constant.

Simple mocks like those work for a good number of cases. Some may even argue that it’s the only way to mock properly, because anything more complicated is a sign of code smell. We can counter that by saying that some complexity is often unavoidable, and it’s up to developers to decide whether they want to put it test or tested code.

And thus more complex stubbing may be needed if, for some case, you prefer the former approach. When that happens, it’s good to know how to fabricate a bit more sophisticated behavior. In Mockito, it’s very possible to achieve almost arbitrary complexity by capturing arguments of stubbed calls and routing them to callbacks. This is done with the help of ArgumentCaptor class and the Answer interface, respectively.
When combined, they can result in pretty clever mocks, as illustrated with this example of some imaginary API for SMTP (e-mail sending protocol):

  1. @Mock private SmtpConnection smtpConnection;
  3. private void mockSmtpConnection() {
  4.     final ArgumentCaptor<String> recipient = ArgumentCaptor.forClass(String.class);
  5.     final ArgumentCaptor<String> subject = ArgumentCaptor.forClass(String.class);
  6.     final ArgumentCaptor<String> body = ArgumentCaptor.forClass(String.class);
  8.     when(smtpConnection.setRecipient(recipient.capture()))
  9.         .thenReturn(smtpConnection);
  10.     when(smtpConnection.setSubject(subject.capture()))
  11.         .thenReturn(smtpConnection);
  12.     when(smtpConnection.setMessage(body.capture()))
  13.         .thenReturn(smtpConnection);
  15.     when(smtpConnection.getOutgoingClientData())
  16.         .thenAnswer(new Answer<String> {
  17.         @Override
  18.         public String answer(InvocationOnMock call) {
  19.             return recipient.getValue() + "\0"
  20.                 + subject.getValue() + "\0"
  21.                 + body.getValue();
  22.         }
  23.     });
  24. }

Note that it doesn’t implement the real SMTP. That, presumably, would mimic the SmtpConnection class exactly, which of course is not the point of mocking at all.
The point is to provide sufficiently complete behavior so that code under test can proceed, reaching all the execution paths we want to exercise. In this case, something can call getOutgoingClientData and rely on certain string being present in the output.

Let’s just hope that this “something” actually has some good reasons to expect that…

Tags: , , , ,
Author: Xion, posted under Computer Science & IT » Comments Off on Complex Stubbing with Mockito for Java

License It, Please

2013-01-31 6:45

In a blog relayed to my news reader today via Slashdot, I found this bit about providing licenses to the open source code you publish. Or, more specifically, about not providing them:

If some ‘no license’ sharing is a quiet rejection of the permission culture, the lawyer’s solution (make everyone use a license, for their own good!) starts to look bad. This is because once an author has used a standard license, their immediate interests are protected – but the political content of not choosing a license is lost. [emphasis mine]

I admire how the author goes all post-modernistic by bringing up fuzzy terms like “permission culture”. It’s a serious skill, to muddy such a clear-cut issue by making so many onerous assumptions per square inch of text. The alleged existence of some “political content” involved in not choosing any license – as opposed to, say, negligence or lack of knowledge – is easily my favorite here.

On more serious note: what a load of manure. I won’t even grace the premise with speculation on how likely it is to have anything to do with reality – that is, how big a percentage of the ‘no license’ projects is made so by the conscious choice of their authors. No, I will be insanely generous and assume that it actually holds water. Doesn’t matter; the claim that this practice should be encouraged and that something valuable is lost if software project has a license is still sheer lunacy.

If you don’t explicitly renounce some rights to your code – by providing a license, as the most common way – they are all reserved to you. Regardless of what political or cultural weight you may want to associate with this fact, the practical one is implied by law. And it’s very simple: no one can safely do anything with that code of yours, for there is always a risk you will exercise your rights through prosecution.

Of course I know you wouldn’t do anything so clearly evil. But that’s no guarantee for many parties that treat the issues of copyright and liability very seriously: from solo freelancers to the biggest of companies, and from lone hackers to the most influential software foundations. If you care about your code being widely used and solving problems for as many people as possible, this is also something you should pay attention to.
Otherwise it may happen that for someone, your work is just the perfect piece of puzzle – but they cannot use it safely. They might ask you to fix your oversight, of course, but they might also go somewhere else.

And that is typically the “immediate interest” that you protect by licensing: letting others actually use your code. If you ask me, that sounds like something totally worthy of protection.

Tags: ,
Author: Xion, posted under Internet, Programming » 3 comments

Unpacking Ad-hoc Dictionaries

2013-01-27 8:04

Today I’d like to present something what I consider rather obvious. Normally I don’t do that, but I’ve had one aspiring Pythonist whom I helped with the trick below, and he marveled at the apparent cleverness of this solution. So I thought it might be useful for someone else, too.

Here’s the deal. In Python, functions can be invoked with keyword arguments, so that argument name appears in the function call. Many good APIs use that feature extensively; database libraries known as ORMs are one typical example:

  1. user = session.query(User).filter_by(email="").first()

In this call to filter_by() we pass the email argument as a keyword. Its value is then used to construct an SQL query that contains a filter on email column in the WHERE clause. By adding more arguments, we can introduce more filters, linked together with the AND operator.

Suppose, though, that we don’t know the column name beforehand. We just have it stored in some variable, maybe because the query is part of authentication procedure and we support different means for it: e-mail, Facebook user ID, Twitter handle, etc.
However, the keyword arguments in function call must always be written as literal Python identifiers. Which means that we would need to “eval” them somehow, i.e. compute dynamically.

How? Probably best is to construct an ad-hoc dictionary and unpack it with ** operator:

  1. def get_user(column_name, column_value):
  2.     return session.query(User).filter(**{column_name: column_value}).first()

That’s it. It may not be obvious at first, because normally we only unpack dictionaries that were carefully crafted as local variables, or received as kwargs parameters:

  1. def some_function(one_arg, **kwargs):
  2.     kwargs['foo'] = 'bar'
  3.     some_other_function(**kwargs)

But ** works on any dictionary. We are thus perfectly allowed to create one and then unpack it immediately. It doesn’t make much sense in most cases, but this is one of the two instances when it does.

The other situation arises when we know the argument name while writing code, but we cannot use it directly. Python reserves many short, common words with plethora of meanings (computer-scientific or otherwise), so this is not exactly a rare occurrence. You may encounter it when building URLs in Flask:

  1. login_url = url_for('login', **{'as': test_user_id})

or parsing HTML with BeautifulSoup:

  1. comment_spans = comments_table.find_all('span', **{'class': 'comment'})

Strictly speaking, this technique allows you to have completely arbitrary argument names which are not even words. Special handling would be required on both ends of function call, though.

Tags: , ,
Author: Xion, posted under Computer Science & IT » 2 comments

Going Apples

2013-01-24 8:42

So, I got myself a new laptop.

The main reason was that I wanted more powerful and – most importantly – slightly bigger portable computer. Up until now I used a cute 11.6″ machine that claimed to be a gaming laptop but worked pretty well as all-around development kit. The various trials and tribulations I had to overcome to make Ubuntu work reasonably well on this thing (it’s officially “not supported”) significantly increased my skills in tweaking Linux. And sometimes things worked so well that I actually managed to accomplish some work!

Nevertheless, the small size started to irk me quite a bit; the (small) additional mobility just wasn’t worth it. So this time I went for something just slightly bigger, but with a lot more pixels.


Alas, I got a 13″ Retina display MacBook Pro. Admittedly, I was a bit reluctant to be a semi-early adopter here, because the way increased resolution seems to work on these screens is a bit confusing. I mean, it’s apparently very natural to almost anyone: things look nicer, end of story. However, for someone who remembers how back in the days the difference between, say, 800×600 and 1024×768 made such a huge impact on UI scaling, the Retina’s quadrupling of pixel count may sounds pretty scary.

Just recall that the standard width for many website layouts is still around 960px, which translates to a little more than 1/3 (!) of Retina display’s width. Does it mean the web comes with big slabs of wasted whitespace and tiny column of content in between?…

Not really, as it turns out. By default, Retina cheats: the real (millimeter) size of UI elements is still roughly the same as on normal 13″ display running something around 1280×800. For typical GUI applications involving standard components and some text rendering, it’s indeed just making the interface sharper and more vivid. For pixel-perfect apps (such as games with set resolution), it seems the default solution is to stretch them proportionately; things might not look as nice then but they still work well.

Where the Retina display really shines is any serious text “processing”, be it reading websites, writing articles or – of course – programming. The additional level of detail might not be noticeable at first, however the difference becomes apparent when you look again on a screen with lower pixel density. There’s still some way to go in order to fluidly present even the smallest noticeable details to the sharpest of eyes, but it’s pretty short way.

I just shudder to think what resolution is needed to replicate the same sensation on 27″ or 30″ monitor :)

It’s Linux on the desktop, essentially

What about the operating system, though, the glorified OS X?

Besides handling that precious little screen very well – which cannot be said of some other systems – I don’t actually have much to say about it. With the rampant scavenging of UX concepts that goes back-and-forth between today’s platforms, the differences in look & feel of their graphical interfaces are mostly superficial. Whatever it is in the upper-right corner of your desktop – be it half-bitten apple, a rotated square or circle with dots – is unlikely to dictate the shape of your UI experience.

…Once you move the Dock to its proper position on the side, that is.

Under the hood, OS X is just a *nix, some say even more POSIX-y than what Linux currently is. This makes it a viable native choice for most developers, while the rest (i.e. those working with Microsoft products) can be accommodated via outstanding virtualization options. But all this goodness doesn’t come without few caveats.

Probably the biggest one is the horrendous functionality gap: lack of built-in package manager and installer. Life without apt-get really sucks, and the bottom-up effort coalesced into Homebrew cannot really make up for it. I was especially appalled when I had to revert to the old google-download-unpack method for installing new programs. Amazingly, the Mac App Store is still mostly useless some two years after its inception.

Will it blend?

Although I’m readily pointing out various quirks of the OS X platform here, I must say I’m not particularly concerned with them in the long term. I do not intended the Mac to become my primary system of choice, especially for development purposes. Its goal is to serve as handy portable computer, while simultaneously providing access to the third important platform to address any testing needs.

But that’s all aside of the most important perk: finally being able to visit those trendy coffee shops, of course! ;-)

Tags: , , , ,
Author: Xion, posted under Computer Science & IT, Life » 3 comments

California State of Mind

2013-01-19 9:29

I can think of multiple ways to spend half a day – twelve hours – enjoyably and/or productively. Sitting in a slightly uncomfortable position inside a scarcely lit tin can soaring a few miles above the ground is unlikely to make it into top 10. But if that’s what is needed to get to the other side of the planet, so be it. Slightly torpid back muscles are hardly a set back, after all :)

San Francisco International AirportThat other side is San Francisco Bay Area, of course, where I’ve went to visit the Google mothership. Finding yourself so far away from home is uniquely surreal experience, I must say, but this place makes it a whole lot more unusual.

For a European like me, it’s nothing short of bizarre.

Imagine a fairly typical, middle-class suburban area, where buildings reach at most three or four floors. Some apartment complexes, detached houses, shops, restaurants, cinemas, maybe a mall and a park… Now imagine this goes on and on, for dozens of miles, all with the same low housing density and without an easy way to tell where one town ends and the other begins.
It sounds like a poorly thought-out result of uncontrolled urban sprawl in some mildly developed, emerging country. Except that there are four-line highways going across the whole area, regularly passed through by one of the fanciest, most luxurious and modern cars. A good number of them is powered by electric engines, by the way, and it’s not exactly problematic to find a parking spot where you could charge such a vehicle.

Not to mention that some of them actually drive by themselves

But you don’t have to be on the lookout for Google’s Priuses in order to see the logos of IT companies. They are literally everywhere. A hip startup might still be in the garage, but they will have billboard next to the freeway. (I’ve seen one from, for example).
Meanwhile, more established companies will have their buildings and campuses pretty much next to each other, often with big swaths of land left around for further expansion. And the most successful ones will make their hometowns’ names known worldwide, with Cupertino (Apple), Mountain View (Google) and Palo Alto (Facebook) standing out as prominent examples.

In all this high-tech and Web-crazed environment, I cannot help but wonder where’s one thing that you would surely expect to see here. Something that the IT crowd babbles about for quite some time now and doesn’t seem to stop anytime soon. That crucial stuff that makes the Internet go round.

Clouds. So far, I haven’t seen any.

Go is Like Better C, Mostly

2013-01-09 22:55

The Go programming language is was on my (long) list of things to look into for quite some time now. Recently, at last, I had the opportunity to go through the most part of a comprehensive tour of Go from the official website, as well as write few bits of some Go code by myself.

Go-pherToday I’d like to recap on some of my impressions. You can treat it as “unboxing” of the Go language, much like when people post movies of their first hands-on experiences with new devices. Except, it will be just text – I’m not cool enough to do videos yet ;)

Some trivia

We all like to put stuff into our various mental buckets, so let’s do that with Go too.

Go is a compiled, statically typed programming language that runs directly on the hardware, without any underlying virtual machine or other bytecode-based runtime. That sounds good from the speed viewpoint and indeed, Go comes close to C in raw performance of equivalent programs.

Syntax of Go is C-like, at least in the fact that it’s using curly braces to delimit blocks of code. Some visual clutter is intentionally omitted, though. Semicolons are optional, for example, and idiomatic Go code omits them at all times.
But more surprisingly, parentheses around if and for conditions are straight out forbidden. As a result, it’s mandatory to use curly braces even for blocks that span just one line:

  1. if obj == nil {
  2.     return
  3. }

If you’re familiar with reasoning that suggests doing that in other C-like languages, you shouldn’t have much problems adapting to this requirement.

No-fuss static typing

Go is type-safe and requires all variables to be declared prior to use. For that it provides very nice sugar in the form of := operator, coupled with automatic type inference:

  1. s := "world"
  2. fmt.Printf("Hello %s!\n", s)

But of course, function arguments and return values have to be explicitly typed. Coming from C/C++/Java/etc. background, those type declarations might look weird at first, for they place the type after the name:

  1. func Greet(whom string) string {
  2.     return fmt.Sprintf("Hello, %s! How are you?", whom)
  3. }

As you can see, this also results in putting return type at the end of function declarations – something that e.g. C++ also started to permit.

But shorthand variable declarations are not the only way Go improves upon traditional idioms of static typing. Its interfaces are one of the better known features here. They essentially offer the support for duck typing (known from Python, among others) in a compiled language.
The trick is that objects do not specify which interfaces they implement: it’s just apparent by their methods. We can, however, state what interfaces we require for our parameters and variables, and those constraints will be enforced by the compiler. Essentially, this allows for accepting arbitrary values, as long as they “quack like a duck”, while retaining the overall type safety.

As an example, we can have a function that accepts a very general io.Writer:

  1. func SendGreetings(w io.Writer, name string) {
  2.     fmt.Fprintf(w, "Hello, %s!", name)
  3. }

and use it with anything that looks like something you could write into: file objects, networked streams, gzipped HTTP responses, and so on. Those objects won’t have to declare or even know about io.Writer; it’s sufficient that they implement a proper Write method.

Pointers on steroids

Talking about objects and interfaces sounds a bit abstract, but we shall not forget that Go is not a very high level language. You still have pointers here like in C, with the distinction between passing an object by address and copying it by value like in C++. Those two things are greatly simplified and made less error prone, however.

First, you don’t need to remember all the time whether you interact with object directly or through a pointer. There’s no -> (“arrow”) operator in Go, so you just use dot (.) for either. This makes it much easier to change the type of variable (add or remove *) if there’s need.

Second, most common uses for pointers from C (especially pointer arithmetic) are handled by dedicated language mechanism. Strings, for example, are distinct type with syntactic support and not just arrays of chars, neither a standard library class like in C++. Arrays (called slices) are also well supported, including automatic reallocation based on capacity, with the option of reserving the exact amount of memory beforehand.

Finally, the common problems with pointer aliasing don’t really exist in Go. Constraints on pointer arithmetic (i.e. prohibiting it outright) mean that compiler is able to track how each and every object may be used throughout the program. As a side effect, it can also prevent some segmentation faults, caused by things like local pointers going out of scope:

  1. func Leak() *int {
  2.     i := 42
  3.     return &i
  4. }

The i variable here (or more likely: the whole stack frame) will have been preserved on heap when function ends, so the pointer does not become immediately invalid.


If you ever coded a bit in some of the newer languages, then coming to C or C++ you will definitely notice (and complain about) one thing: lack of proper package management. This is an indirect result of the header/implementation division and the reliance on #include‘ing header files as means of specifying dependencies. Actually, #includes are not even that: they work only for compiler and not linker, and are in some sense abused when working with precompiled headers.

What about Go?… Turns out it does the right thing. There are no separate header and implementation units, only modules (.go files). Unless you are using GCC frontend or interfacing with C code, the compiler itself is also unified.

But most importantly, there are packages and normal import statements. You can have qualified and unqualified imports, and you can alias things you’re importing into different names. Packages themselves are based on directory structure rooted in $GOROOT, much like e.g. Python ones are stored under $PYTHONPATH.

The only thing you can want at this point is the equivalent of virtualenv. Note that it’s not as critical as in interpreted languages: standalone compiled binaries do not have dependency problems, after all. But it’s still a nice thing to have for development. So far, people seem to be using their own solutions here.

Tags: , , , , , ,
Author: Xion, posted under Programming » Comments Off on Go is Like Better C, Mostly

© 2017 Karol Kuczmarski "Xion". Layout by Urszulka. Powered by WordPress with