Jul 28 2011

Introducing Aardwolf

Category: JavaScript,Mobile,Mobile web,Utilities — Aleksander Kmetec @ 1:34 am

I happen to work in mobile advertising, and mobile advertising these days is all about JavaScript-rich HTML5. And running modern HTML on mobile devices means having to deal with mobile WebKit and its quirks on a daily basis.

As you probably know if you’re in a similar position, no mainstream device running mobile WebKit today supports JavaScript debugging. When debugging rich media ads containing large amounts of JavaScript code in mobile browsers, this becomes a bit of a pain in the neck.

But it’s even worse when it comes to in-app advertising as those ads run inside stripped down WebView components, not inside full featured browsers.

If you think debugging JavaScript in a mobile browser is painful, consider this: on iOS the UIWebView component does not have a console like mobile Safari does, so if your script suddenly dies because of a runtime error, you have absolutely no idea what caused it. On Android you still see error messages printed to the device console, but you can’t debug using alert() statements because alert dialogs aren’t supported by default in Android’s WebView and most companies don’t bother adding support for them.

Add to this the fact that inside a third party application you can’t easily clear the cache or even reload the WebView contents for that matter, and you quickly lose a couple of hours debugging what would otherwise have been a trivial problem.

A remote JavaScript debugger for mobile devices would really make thing easier. So I decided to write one!

No, I don’t mean a remote console! I mean a real debugger with breakpoints, code evaluation when paused at a breakpoint, ability to step forward one statement at a time, create watch expressions and see the call stack.

I decided to base the functionality of this debugger on the idea of code rewriting as I have previously successfully used this approach several years ago to write a PHP profiler in pure PHP. The program would read PHP files, insert profiling timers at every entry and exit point of every function, and spit out self-profiling versions of the original PHP files.

Originally, I intended to the debugger it as an Android app and break execution by making calls into native code through a JavaScript/Java bridge, but upon explaining this idea to Jaka Jančar, a colleague at work, he pointed out it would also be possible to break execution using a synchronous XmlHttpRequest, thus ditching the concept’s dependency on Android’s WebView. A couple of days later I worked out all the details during a 2-hour train ride, then promptly shelved the project for six months. Having figured out all the theoretical problems, I couldn’t be bothered with such minor details as actually writing an implementation.

Then, one damn cold weekend in July, I finally sat down and managed to write something that sort of works. The result is Aardwolf1, a remote JavaScript debugger for Android/iOS, written in pure JavaScript.

And here it is in all of its buggy, unfinished and unstyled glory!

  1. Just some name I picked off of Wikipedia’s insectivore page. ↩

Apr 11 2011

The cost of a noisy workplace

Category: Ideas — Aleksander Kmetec @ 11:58 pm

Today, I finally moved into my own office at work. And by “office” I actually mean a small, narrow room that used to serve as a coatroom for the previous occupants of our offices. It has no real windows, no doors, and the walls are still covered in coat hooks.

Why would anyone want to leave a spacious office with a view of the city and work in a room like this?

It’s simple…

You see, the startup I’m working at is experiencing major growth right now. A growing company means an influx of new people. And new people mean a whole new level of noise in the workspace.

Moving into that tiny office is just my way of keeping my sanity until we find more space we can expand our offices into.

Somewhere today, a group of intelligent people isn’t getting anything done.

So just how fast do working conditions deteriorate as the number of people that work in close proximity increases? I’m afraid things get worse much faster than what you may think.

People working on problems don’t usually generate noise on their own. Sure, there might be some restless people who constantly fidget with something and an occasional individual who likes to hum and drum on the desk to the music he’s listening to through his headphones, but these are more of an exception than the norm. What usually generates noise is communication between people which can range from short verbal exchanges to full-blown conversations or even heated arguments. Because of this the amount of generated noise does not depend directly on the number of people in the same office; it depends on the number of possible connections between them. And the number of connections increases much faster than the number of people does. The formula for calculating this number is (n^2 - n) / 2 where “n” equals the number of people.

The following table illustrates this relationship:

# of people 2 3 4 5 6
# of connections 1 3 6 10 15

The same data one more time, on a chart:

As you can see, the number of connections between people increases at a much faster rate than the number of people does. Increasing the number of occupants of an office from 3 to 6 means that there are now twice as many people in the office, but the number of connections between them raises to five times the original number. That’s five times as many potential sources of interruptions!

This is why you can’t get anything done in a crowded office. This is why anyone can’t get anything done.

But wait, it gets worse…

It doesn’t end here, though. As the number of interruption-generating connections increases, so does the number of people being interrupted. The total cost of such interruptions grows at an even faster rate than the number of connections between people. To find out the total impact of interruptions we need to multiply the number of interruptions with the number of people being interrupted. Let’s call this number the total interruption factor, or TIF for short. The formula for calculating TIF is (n - 2) * (n^2 - n) / 2 where “n” once again represents the number of people in the office.

Let’s add these numbers to the table and the chart we created earlier:

# of people 2 3 4 5 6
# of connections 1 3 6 10 15
# of interrupted 0 1 2 3 4
TIF 0 3 12 30 60

We can now observe 2 things:

  1. As soon as the number of people increases beyond 2, there is always someone getting needlessly interrupted. This is why I’ve been saying for years that every office, no matter how large, is a two-person office.
  2. The same change as we used for illustration above, from 3 to 6 people, which doubles the number of people and increases the number of distractions to five times the original number, increases the total cost of these interruption to TWENTY times the original number! That’s right – doubling the number of people can increase total time loss twenty times. How about that?

Now imagine: if 3 people lose 15 minutes per day due to interruptions (that’s 5 minutes per person), how much does it cost you when 6 people lose 20 times as much time? Are you saving money by putting more people in the same room, or would getting another office be more cost-efficient? Unless your offices are located in an extremely expensive location and your developers are all severely underpaid, it’s probably the latter.

Because of all of this I’d say that by trying to save money on office space you’re actually shoveling money out the window – and annoying everyone in the process.

Related reading & viewing:

  • Peopleware: You should read the whole book. Twice. Every year. But the most important part in regard to this writeup is “Part II – WORKING ENVIRONMENT”. Make sure you read this book carefully, though: in many places it adopts a humorous, even sarcastic tone, often listing examples of bad practices. Simply skimming over it and skipping parts could easily give you some very wrong ideas.
  • A Pattern Language: some of the workspace-related patterns are already covered briefly in Peopleware, but you might be interested in the following ones: 82: Office connections; 146: Flexible office space; 148: Small work groups; 151: Small meeting rooms; 152: Half-private office; 183: Workspace enclosure.
  • Jason Fried: Why work doesn’t happen at work. YouTube Preview Image

Tags: , , , , ,

Jan 05 2011

The state of digital camera software

Category: Uncategorized — Aleksander Kmetec @ 11:20 pm

For more than half a year I’ve been planning on buying a new digital camera. My old pocketable Canon IXUS 60 compact had one too many encounter with mud, hard floors and spilled drinks and with half the buttons not working anymore, taking photos with it became a bit of a problem. I also wanted something a bit more powerful, so in December, following months of religiously studying camera reviews and after some careful deliberation, I finally got myself a brand shiny new Sony NEX-3.

Hardware-wise this is a modern camera. It fits into the new segment of mirrorless cameras with interchangeable lenses which didn’t even exist until a year or two ago. It also sports the same size imaging sensor as found in most DSLRs – one of only 2 mirrorless cameras with this property currently on the market.

When it comes to its software, though, it’s not nearly as advanced. As it was first released this camera’s software was universally criticized for having an incredibly unfriendly UI. It supported most settings commonly found on higher-end cameras, but getting to them and changing them was a lengthy and tedious process which involved navigating menus several levels deep for even basic adjustments like shooting mode and ISO.

Thanks to all those negative reviews Sony soon released a software update – a firmware image which had to be downloaded and flashed to the camera using special software. Now, it was nice of Sony to listen to their users and fix the menus, but doesn’t this method of updating software sound a bit… well… old-fashioned?

I find it hard to believe that in 2011 getting an updated firmware image from the manufacturer is the best way of fixing software deficiencies and adding new features to you camera. This means that we still need to nag the makers of the camera for every tiny little software change we want. Isn’t it about time cameras started supporting add-ons in the form of installable apps?

Why do cameras sold in 2011 still come with a fixed set of software features? Why do users have to choose between Sony’s automatic panorama stitching and Canon’s miniature mode instead of installing both features to whichever camera they bought? A lot of tweaks that take camera makers months to release could be done by someone over a couple of weekends. Heck, even today’s _phones_ support installing advanced photo-related features, so why not cameras?

Please, give us the ability to change or replace menus, customize on-screen information, assign custom apps to softkeys, create custom timers, use advanced manual focusing helpers, write automation scripts, create managers for user-defined settings, install software filters and effects, allow our cameras to be controlled from our phones instead of forcing us to buy remote triggers which only work with specific models, or even make it possible for us to write software which will be able to control 3rd-party lenses and possibly other hardware.

Please, give us a camera whose software isn’t stuck in the past decade.

Looking at today’s phones it seems to me that the perfect camera would be a lot like a cameraphone; except with more camera and less phone. And Sony, one of the few camera manufacturers who also make phones1, should be capable of pulling something like that off.

  1. Samsung is another company that makes both phones and cameras, but I can’t think of any others. ↩

Jun 06 2010

Is this how it all started?

Category: Uncategorized — Aleksander Kmetec @ 7:27 pm

I wonder if Tim Berners-Lee got his idea for the semantic web while reading Gary Larson’s The Far Side comics:

Tags: , ,

Apr 22 2010

Want iPad multitasking? Buy multiple iPads.

Category: Ideas,Mobile — Aleksander Kmetec @ 11:54 pm

A while ago I suggested on Twitter that the solution to iPad’s lack of multitasking is buying multiple iPads. People thought I was joking. When I shared the same idea with my coworkers they didn’t take me seriously either. Then a couple of weeks ago I came across an interesting piece in Newsweek in which the Fake Steve Jobs interviews the real Steve Wozniak. The interview itself is about what The Woz thinks of the iPad but it ends with the following gem on multitasking:

Wozniak: …By the way, I solved the problem of battery life and [the lack of] multitasking on the iPhone.
Interviewer: Really?
Wozniak: Yeah. I just have two iPhones, so if the battery runs down on the first one, I can use the other. And if I’m talking on one, I can use the other one to look something up. You would not believe how much use I get out of that.

Perhaps my idea wasn’t so far-fetched after all.

Sure, ditching your current setup and replacing it with multiple tablet computers would mean quite a change in how you use your computer. But many people would likely be perfectly happy with the alternative. Like those people, for example, who are ordering iPads faster than Apple can manufacture them.

With iPads having neither a keyboard nor a mouse and being small enough so that you can have several of them in front of you, I imagine switching between them should be a snap. Also, the added screen real estate of what is essentially a multi-monitor setup should also make it easier to work with multiple apps at the same time.

Of course, this idea is not new at all. You may have even seen it on TV decades ago. A user called derefr left the following comment over at HackerNews when I mentioned my idea:

[Using multiple iPads] makes complete sense to me—remember the scenes in Star Trek where someone is sitting at a desk absolutely covered in PADDs, each doing one little thing? We just need to wait for the price to come down :)

Being located in Europe, coming across even one, let alone two or three iPads has proven to be a bit difficult for me. So if someone reading this has had the chance to try working with more than one iPad at the same time it would be great to hear how well it works and what problems you’ve run into.

Tags: , , , ,

Nov 10 2009

Don’t — in Scala

Category: Ideas,Uncategorized — Aleksander Kmetec @ 9:49 am

While browsing Reddit yesterday, I came across this thread on Perl’s Acme::Don't module. The Acme::Don't module is a joke module which adds support for “don't“, the opposite of the “do” command. The “don't” construct accepts a block of code and then DOESN’T execute it, no matter what. Now, lately I’ve been playing around with Scala and I know that thanks to its flexible syntax it’s possible to create functions which look and behave just like control structures. This got me thinking… could I implement a useful version of “don't“?

After a couple of minutes I came up with the following 2 use cases (in addition to the original standalone don’t block):


dont { ... }
dont { ... } unless (condition)
dont { ... } until (condition)

Implementing the dont { ... } part is easy. The only thing needed to make this work is a function which accepts a block of code and doesn’t do anything with it.

Adding support for the unles/until part is a bit trickier, but still easy. For this to work, the dont function must return an object which contains methods named unless and until. These methods then evaluate the condition passed to them and execute the original block of code if/when the condition is true.

It’s probably best if I just show you the code:


def dont(code: => Unit) = new {
    def unless(condition: => Boolean) = 
        if (condition) code
    
    def until(condition: => Boolean) = {
        while (!condition) {}
        code
    }
}

(UPDATE 2010-12-28: Simplified the example above as per suggestion sent to me via email by Michael Lorton)

Now there’s nothing else left but to use it in an example:


/* This will never be executed */
dont {
    println("Hello? Can anyone hear me?");
}

/* This will only be executed if the condition is true */
dont {
    println("Yep, 2 really is greater than 1.")
} unless (2 > 1) 

/* Just a helper function */
var number = 0;
def nextNumber() = {
    number += 1
    println(number)
    number
}

/* This will not be printed until the condition is met. */
dont {
    println("Done counting to 5!")
} until (nextNumber() == 5)

Runnig the above code should print:

Yep, 2 really is greater than 1.
1
2
3
4
5
Done counting to 5!

Tags: , , , ,

Next Page »