Debugging During Robolectric Test Execution In Android Studio

I’ve been exploring testing in Android Studio via Robolectric and wanted to check the values of some variables in the code under test. I tried using System.out.println() to print the values, expecting that when I ran my test gradle task I’d see the output in my terminal, since I run my tests via gradle’s cli. What I got was the same test failure, but no output from my println() call.

For my next attempt, I added a breakpoint and ran the tests via the same cli command, but that didn’t work either. After a bit of searching I learned that I can debug a gradle task easily by finding the task in Android Studio’s Gradle tool window and selecting debug (you can right-click, or use the Run menu, or use the CTRL-SHIFT-D keyboard shortcut.

Android Studio Debug Icon

What I learned next is that doesn’t work right way, because by default Android Studio executes gradle via an in-process build, resulting in the following error:

Unable to open debugger port : “Socket closed”

In order to get around this, you need to disable the “Use in-process build” feature via the Compiler/Gradle preferences.

Android Studio "in-process build" pref

After I did that, I was able to debug the gradle test task, and see the output of my state in the Android Studio Debug tool window.

Now I’m back to having fun writing tests!

Thanks to Eugene who figured this out and posted the answer to his own question on Stackoverflow!

Book Review: The Principles Of Object-Oriented JavaScript

TLDR: If you want to understand how OOP works in JavaScript, read this book. It’s that simple. Read on if you want to hear me wax poetic, as this book certainly deserves the praise.

After Eloquent JavaScript rekindled my fascination with programming, dispelled my irrational fears of JS and dissolved my anger, I was still unsure about the way OOP worked with JavaScript. That’s not to say the author didn’t explain it: the topic is definitely covered, and I had some understanding of how it was supposed to work, but I still didn’t feel comfortable with it. I kept asking myself “Why can’t JavaScript just have classes like other languages?” My goal has been to be able to write professional-grade JavaScript, and I knew I couldn’t do that without using objects properly. I tried re-reading JavaScript: The Good Parts, but that didn’t really help. I was about to give up and put JavaScript on the shelf again when I got the press release for The Principles Of Object-Oriented JavaScript by Nicholas C. Zakas, in my inbox. The timing couldn’t have been better.

The best part of this book is that the author is able to pack so much useful information into 100 or so pages, without being cryptic. I was afraid when I got the review copy that I’d be dealing with “The Sutras of JS OOP”, a collection of JavaScript related aphorisms that would need to be unpacked by a guru in order to bring to light their true meaning. Luckily, Nicholas has mastered the art of being concise yet clear. I’d compare the book to a short and elegant function as opposed to a terse one-liner.

The Principles Of Object-Oriented JavaScript isn’t an introduction to JS, nor is it an intro to OOP. I wouldn’t recommend it if you’re just starting out with either, but you shouldn’t be scared to pick it up if you’re a JavaScript novice who’s read at least 1 other book on the topic. I’ve had years of programming-for-fun experience, and a couple of years of professional software engineering under my belt, but I lacked any real understanding of the way OOP worked in JavaScript, so this book suited me perfectly.

The book’s 6 chapters progress from an introduction of JavaScript’s types to a short discussion about popular patterns for working with objects. Each chapter builds on the material covered before it, and I’d recommend reading it in order, from cover to cover. There is enough sample code to demonstrate the concepts, and some helpful notes along the way as well. In some programming books the examples are so contrived that you lose sight of any real practical use of the features they’re intended to describe, but The Principles Of Object-Oriented JavaScript manages to avoid this for the most part. There are instances where a JS feature is explained and demonstrated with a sample followed by a warning to the reader to “not try this at home”, but I found those snippets to be more helpful than distracting.

Another reason I love this book is that somehow the author finds a way to pull back the curtain and let us peer into the world of JavaScript internals, without leaving us drowning in the deep end. He mentions internal methods that JavaScript calls when you work with objects, but is careful not to go off on what could be a very confusing tangent. It’s somehow just enough of a peek behind the scenes to whet your appetite to learn more about JavaScript and how it handles OOP. Of course the whole truth is that now I’m curious about what else the JS engine is doing when I’m not looking, but I’ve got to be careful or else I’ll lose sight of my goal which is to have no second thoughts about picking up a front-end heavy card off of my team’s story wall.

In closing, I highly recommend this book to anyone who is not quite sure of how object oriented programming is meant to be done using JavaScript. It’s my opinion that you couldn’t find a better book about the topic right now. It’s well written, concise, and packed full of great information. I’m going to read it again before letting anyone else have it 🙂

Book Review: Eloquent JavaScript

I was a JavaScript hater.

I hated JavaScript for poor cross-browser support. I hated JavaScript because it was only used for useless effects in web pages. I hated JavaScript because I could write it easily but get nowhere fast. I hated JavaScript because OOP is supposed to use classes, right? I hated JavaScript because JavaScript: The Definitive Guide was 1000 pages long and JavaScript: The Good Parts was 172 pages. I hated JavaScript because I didn’t understand it.

In a quest to be more useful to my team at work, I’ve been wanting to stop avoiding the “front-endy” cards on our story wall and the JavaScript that goes with them. It’s been difficult, but for no good reason. I kept trying to learn pro JS but couldn’t get past my fears and preconceptions. In order to get past all of that, I realized I’d need a fresh perspective, and that’s where Eloquent JavaScript, by Marijn Haverbeke came in and changed my life.

The book’s subtitle is “A Modern Introduction to Programming”, and so initially I was afraid that it would be too basic for me. I didn’t need to learn how to program, after all – I needed to learn how to program with JavaScript. I thought I’d give it a go anyway, since I’d tried other books that were meant for intermediate level readers and gotten basically nowhere with those. It turns out that after reading the introduction that I had discovered the fresh perspective I’d needed. What better a way to look at a programming language with a “fresh set of eyes” than to put aside my preconceptions about programming entirely?

At first that was difficult – trying to read the book through the eyes of someone who’d never written a program before – but after a few chapters I found myself feeling something I hadn’t felt in a while, a sort of fascination with this “programming stuff.” That’s not to say that after a couple of years as a software engineer I’ve already burned myself out. Still, in reading the first few chapters of Eloquent JavaScript and re-learning what variables are and what loops are for, I got thrown back to my childhood and the feelings of amazement I’d get after getting my first BASIC programs to run.

As the book progresses into more advanced concepts, Marijn’s tone is conversational but instructive. About halfway through the book I felt more confident in my understanding of the language, and eager to learn more. I never got bored, and while it continued to be a challenge to put aside what I already knew (or thought I already knew) I found myself gaining a deeper understanding of JavaScript and of computer programming in general. Each chapter teaches enough to get you started, but as it’s a small book, the chapters are necessarily concise. This isn’t a incredibly comprehensive book, it’s certainly not JavaScript: The Definitive Guide, but that’s a feature, not a bug. I’d say the book’s enough to get you started if you want to dive into JS and start doing useful work straight away.

I can’t stress enough the fact that this book has not only changed my mind about JavaScript, but has also renewed my love for programming. It’s amazing what a few anecdotes and a helpful examples can do when combined with a willingness to put aside your preconceptions. It’s been said that the surest way to prevent learning about something is to know about it. The mind seemingly has an automatic cutoff that prevents you from gaining new knowledge once it’s convinced it knows all it needs to know. If you are like I was, fearing JavaScript because I didn’t understand it, hating JavaScript because it’s different, avoiding JavaScript because someone else was around to do the work, I appeal to you: STOP! Get yourself a copy of Eloquent JavaScript, put your preconceived notions about it (and if you can, about programming, too), and open your mind. If you’re new to programming, start with this book. You’ll be getting perhaps the best introduction to programming available today.

Making my new FreeBSD 9 desktop feel like home

I decided to pull my old P4 box out of retirement to give FreeBSD 9 a try. For the most part, things are as I remember, however FreeBSD 9’s default Xorg uses HAL to manage all the devices, including the keyboard and mouse. What this means, as far as making X feel like “home”, is that I can no longer make my usual xorg.conf edits to replace Caps Lock (which is useless) with another Ctrl.  I have been using my keyboard with the Caps Lock key as a Ctrl for so long that it causes so much frustration even after a few minutes, so it’s usually one of the first things that changes. When I start using a new desktop.

My main computer is a Mac, and I was an early Lion adopter. At first, I didn’t like the “natural scrolling”, so I disabled it. I hated the idea of having to reset all the defaults every time I used a new Mac though, so I decided to give it another try. Eventually it really grew on me! So much so, that sitting at my FreeBSD desktop I would try to scroll up or down and get frustrated that everything felt backwards. I decided that in addition to my additional Ctrl key, I’d have to get the scrolling to reverse also.  Luckily, both of these changes are trivial, once you know what information to look for and what file to create and/or edit.

I won’t get into the entire story of how I ended up compiling every application on my system from ports – the short version of the story is that I installed vim and basically it installed X along with a million other things (that I knew I was going to use anyway).  If you don’t want that to happen you can avoid it by setting the WITHOUT_X11 variable.  That’s no different from earlier FreeBSD versions though, whereas this hald configuration stuff did throw me for a loop at first.  In any event, once I got Xorg and HAL (and dbus, etc) installed, I had to create an fdi file in /usr/local/etc/hal/fdi/policy/ which holds the configuration details. I don’t think the name of the file matters too much, I honestly stopped researching once I got the configuration working the way I wanted. Here’s my x11-input.fdi:

File Named: /usr/local/etc/hal/fdi/policy/x11-input.fdi
<?xml version="1.0" encoding="UTF-8"?>
<deviceinfo version="0.2">
    <match key="info.capabilities" contains="input.keyboard">
      <merge key="input.xkb.Options" type="string">ctrl:nocaps</merge>
    <match key="info.product" string="USB Receiver">
      <merge key="input.x11_options.ZAxisMapping" type="string">5 4</merge>

If you’re like me, you’ll want to just copy and paste this file, save it, and move on with life. Don’t do that (yet!). There are a few things you’ll need to know before you can roll with this as is. First – you’ll notice that my encoding is UTF-8. This is extremely important to take note of. If your system is not using UTF-8, this will not work.  It might seem obvious, but when I first found an fdi file and tried to do the old copypasta in/out in/out I got nothing for my trouble! That’s because the encoding was ISO-8859-1 and on my system it needed to be UTF-8. Get to know your system’s encoding.

Again, in the interest of full disclosure – there is more research to be done with regards to what exactly every piece of info in this file means – I didn’t look it all up because it started working.  I say this now because you’ll see the deviceinfo version atrribute is set to “0.2” and you might be wondering “why?” Well, I don’t know why. I’ve seen some 0.1 and some 0.2 – 0.2 sounded more recent, and so I am using it, and it works. I’ll look it up later 😉

Moving on in the file, you see one pair of device tags which have 2 children “match” tags.  This confused me at first – I thought I needed a set of device tags for each device.  As it turns out, one set is enough – the match tags inside actually are the most specific you need to get as far as “per device” configuration. The match tags essentially allow you to specify a key and value to search for, such that the merge tags within will apply the actual configuration to the device that’s “matched”. Makes sense right? You can apply the configuration to multiple devices my having a more generic match definition, or apply the config to one device only by matching for a more specific value for a given key.  At this point you’re probably wondering what exactly is being matched. Enter hal-device.

HAL gives you a command line tool named hal-device, which will tell you all sorts of information about the devices on your system. I recommend that when you run it you try piping it into a pager like less, or filtering the output with grep, because it’s going to be a lot of info. The hal-device command spits out the device info in a key/value format. If you run the following, you should see some information about your keyboard:

hal-device |grep -7 keyboard

The -7 gives you 7 lines of context surrounding each instance of the text “keyboard”. On my system the output look like this:

 usb.interface.description = ''  (string)
  usb.freebsd.devname = 'ukbd0'  (string)
  freebsd.driver = 'ukbd'  (string)
  freebsd.unit = 0  (0x0)  (int)
  input.device = ''  (string)
  info.subsystem = 'usb'  (string)
  info.product = 'Logitech USB Keyboard'  (string)
  info.capabilities = { 'input', 'input.keyboard', 'input.keys', 'button' } (string list)
  info.addons.singleton = { 'hald-addon-input' } (string list)
  input.x11_driver = 'kbd'  (string)
  freebsd.device_file = '/dev/ukbd0'  (string)
  info.category = 'input'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_46d_c315_noserial_if0'  (string)
  input.xkb.Options = 'ctrl:nocaps'  (string)
  info.bus = 'usb'  (string)

46: udi = '/org/freedesktop/Hal/devices/atkbd_0'
  freebsd.driver = 'atkbd'  (string)
  freebsd.unit = 0  (0x0)  (int) = 'atkbd.0'  (string)
  freebsd.device_file = '/dev/atkbd0'  (string)
  info.category = 'input'  (string)
  info.capabilities = { 'input', 'input.keyboard', 'input.keys', 'button' } (string list)
  input.device = ''  (string)
  info.addons.singleton = { 'hald-addon-input' } (string list)
  input.x11_driver = 'kbd'  (string)
  input.xkb.Options = 'ctrl:nocaps'  (string)
  info.udi = '/org/freedesktop/Hal/devices/atkbd_0'  (string)
  info.parent = '/org/freedesktop/Hal/devices/atkbdc_0'  (string)
  info.product = 'AT Keyboard'  (string)

Now that you see that, look above at the fdi file again. You’ll see how the XML format lends itself to this rather well – you can read it almost as English:

"match [the] key [named] info.capabilities [if it] contains [the value] input.keyboard".

Got it? Great. The merge tag then becomes a sort of command that says “set the value of the key named input.xkb.Options, which happens to be a type of string, to the value ctrl:nocaps”. Not so complicated right?
It gets a little trickier with the mouse, mostly because you may not realize that the mouse wheel scrolls along the Z axis.  To me, the Z axis represents layers on a web page, not mouse scrolling – but this is the way it’s referred to in X, and therefore in the HAL config files that deal with the X input devices.  You’ll also notice that the key I’m matching on is “info.product” – and I’m looking for “USB Receiver” – this is because for the particular wireless mouse I use (which happens to be USB, as you may have guessed), HAL lists the name as “USB Receiver”. Yours might not, in fact – it probably will not, be the same.  Use a command like:

% hal-device |grep -10 mouse
usb.level_number = 1  (0x1)  (int)
  usb.device_subclass = 0  (0x0)  (int)
  usb.device_protocol = 0  (0x0)  (int)
  usb.interface.class = 3  (0x3)  (int)
  usb.interface.subclass = 1  (0x1)  (int)
  usb.interface.protocol = 2  (0x2)  (int)
  usb.interface.description = ''  (string)
  usb.freebsd.devname = 'ums0'  (string)
  freebsd.driver = 'ums'  (string)
  freebsd.unit = 0  (0x0)  (int)
  input.device = '/dev/sysmouse'  (string)
  info.subsystem = 'usb'  (string)
  info.product = 'USB Receiver'  (string)
  info.capabilities = { 'input', 'input.mouse' } (string list)
  info.addons = { 'hald-addon-mouse-sysmouse' } (string list)
  input.x11_driver = 'mouse'  (string)
  freebsd.device_file = '/dev/ums0'  (string)
  info.category = 'input'  (string)
  info.udi = '/org/freedesktop/Hal/devices/usb_device_46d_c51b_noserial_if0'  (string)
  input.x11_options.ZAxisMapping = '5 4'  (string)
  info.bus = 'usb'  (string)
  usb.interface.number = 0  (0x0)  (int)
  usb.is_self_powered = false  (bool)
  usb.can_wake_up = true  (bool)
  usb.max_power = 98  (0x62)  (int)
  info.parent = '/org/freedesktop/Hal/devices/usb_device_46d_c51b_noserial'  (string)

To find the details about your mouse.  As you can see, my configuration has been applied to that the “button” that is triggered when this mouse wheel is scrolled down (5) actually scrolls up, because it comes first, hence 4, the “up scroll button”, scrolls down. Also note – that if I were to plug in some other mouse, the configuration might not apply! This mouse configuration change only applies where info.product = “USB Receiver”. I could just as easily use info.capabilities and look for contains “input.mouse”, similar to how I matched the keyboard, thereby applying this switch to all mice on my system. This is just an example to show you that you can apply configurations my matching different keys.  One benefit of doing it this way is that if my wife were to sit at this workstation, she’d be confused by the mouse – but all she’d need to do is plug her own mouse in and it would have the default scroll directions.

And there you have it! I spent a few hours hunting down this info, hopefully it took you less time to find this blog post! Enjoy! 🙂

Trac + Lighttpd + FreeBSD ports upgrade… = yikes

Took me a few hours to figure out that when I got:

“child exited with status 13 /usr/local/lib/python2.6/site-packages/Trac-0.11.5-py2.6.egg/trac/web/”

The problem was that I needed to chmod a+x /usr/local/lib/python2.6/site-packages/Trac-0.11.5-py2.6.egg/trac/web/

a+x might be a bit lenient, but it works now. When I rebuilt my ports the permissions changed to 644, which makes sense. Trac is back in working order now, although my fullblog plugin is acting up. Seems like a simple issue though…