Do androids dream of electrical sheep ?

Motivated by the book 'Rise of the Robots' by Martin Ford, José Carlos Fernandes wrote this gloomy, but nonetheless interesting article on unemployement due to a rise in automation. I specially like the irony of illustrating the article with photos from USA child labor at the turn of the last century. For an article discussing how automation might bring an widespread unemployment, the photos serve as remainder that not so long ago everybody had a job, whether they liked it or not.

I am not going to speculate if indeed automation, and software, will in the near future an end to jobs and work as we know it today. In part because I have not (yet) read the book. And in part because what I found curious were the comments to the article.

Many of the comments revolved around the topic of what will people do for money, in a future where pretty much all work is done by robots. The problem is that in such a future, money serves no purpose. In human societies, in all degrees of complexity, cooperation is done by trading services and goods, not necessarily with the help of money. Not so long ago, my great-grandfather payed the barber with a selamin of corn for a shave and an haircut. Myself, yesterday I payed 13 euros for an haircut at my local barber. Although the two haircuts separated by about one hundred years, we can agree that the cooperation process remains essentially the same. One human got its hair trimmed, the other got a physical token in return.

My point is that if all jobs are taken over by machines, there would be no need for this cooperation. What can I possibly give the machine in return for cutting my hair ? The question does not even make sense because humans and machines do not form a society in the way we tradiotionally conceive them. Why would you and me need money, or corn, for if we can satisfy our needs without given anything in return ?

Some of the commenters brought the idea of mininum guaranteed income. Since all jobs are taken over by robots, everybody gets a state allowance to cover for their needs. This is wrong because, as I have stated before, why should people pay the machines for their products or services ? I suspect that attention given to the problem of what will people do for money actually is a proxy for a more important problem.

A few of the commenters were enthusiastic about automation because it would all but eliminate the labour costs and therefore drive prices down and create a world of abundance. Apart from the wrong notion that money, or corn, would be needed in this utopian future, it also shows a grave misunderstanding about how prices are formed.

The cost of something is determined by many factors, marketing bullshit being the main one. Nonetheless, the minimum cost of a product or service cannot be zero because it still requires energy and materials to provide the service or manufacture the good. And we all know that energy and materials are scarce. In a future where all jobs are done by machines, it would still require energy and materials to build said machines and more energy and materials for them to deliver services and goods. Even if humans could get any service or product for free because all work is done by machines, it does not mean that there would not be shortage or rationing of some products. I suspect that without the basic price mechanisms to regulate access to services and goods, we would quickly enter a world of reckless resource usage.

At this point, some could bring back a modified form of guaranteed minimum income. First price the output the machines based on some metrics, then given people an allowance that would cover their needs. The world would become one big zero-sum game. The itsy bitsy problem with this is that well.... it won't work. It is called Comunism and has been tried before, and still is ongoing in some countries, and all it produced was poverty and loss of personal freedoms.

Tagged , ,

I wrote a testing tool and all I got was this t-shirt

I did not kept a record of the time spent developing Isabel, but it was far more than just an handful of coffee fueled nights. My best estimate is three to four months, working at night and some weekends, or about one month if I had done it full-time. Except for a few limitations, see the 'Known Issues' section of Isabel, it implements the functionality that I had initially planed. On the way, I also wrote a basic Qt object inspector, using Tk, which is useful for identifying the Qt objects relevant to a given test scenario. The interface is admittedly ugly, but it mostly works.

Unfortunately, Isabel ended not being used at my work for reasons that I cannot explain here. Not that it is the end of the world, after all there are more ways than one to skin a cat. And to be honest, the journey in itself is more important than the destination. Which begs the question, what did I learn from this endeavor ?

First and foremost, I now have a much better understanding of Qt, X11 and the Linux linker. Sure, I could have acquired this knowledge, Qt in particular, from some training courses. But nothing beats the fun, and pain, of learning while trying to build something. The second lesson I am taking home is knowing when to quit. During the development, I had to find and fix bugs armed with nothing more than Google, GDB and caffeine. The ugly truth is that the time and effort needed to fix some bugs are just too high. Either you learn to live with the bug, or you take a different approach to solve your problem. Nobody more than me hates delivering something other than a perfectly finished product, but my time and resources are limited. Nothing more than common sense lessons, I agree, but you also agree that common sense is far less common than it should be.

Something else happened while I was developing Isabel: I became a critic of Qt. Please, do not get me wrong. The framework is well thought, I like the signals and slots mechanism and the quality of the UIs is generally very good. It is just that the framework comes with batteries included. Take a look at the Qt modules, and you will find many functionality other than the traditional widgets management offered by other frameworks. Granted, most if not all of these modules are relevant to GUI applications and would otherwise have to imported by the developers from a third party. However, my point is that by extending far beyond the traditional scope of UI frameworks, Qt makes it very hard to draw a line between the view logic and the rest of the application. Unless your development team is able to make a firm commitment to the separation of concerns, it is going to be a pain when you need to change your code for the next big UI framework thing.

And do not get me started on QtQuick. On paper, it is excellent. You can create a interface without getting down and dirty with a C++ compiler. The problem is that QtQuick objects are mostly implemented as runtime magic. And that makes testing a pain in the keister.

Tagged , ,

X11, a well known stranger

Life is funny, sometimes you live next to the same neighbor for years and yet never exchange more than the polite greetings dictated by social norms. That is he case with me and X11. More than 15 years ago, I ditched Windows 98 for Red Hat Linux 5.1 and didn't look back ever since. Well, there was a brief 6 months affair with Windows XP, but we all make mistakes. The point being that X11 has been by my side for more than 15 years and our ... uhm.. relation never passed beyond the startx script. Thanks to Isabel, now I was going to take my relation with X11 to the next level. But first, a lesson in the subtleness of technical terminology.

Google it, and you will find a ton of articles on how to capture X11 events. However, I want Isabel to log, or record, X11 events. Unfortunately searching for how to log X11 events produces an overwhelming amount of links on how to capture events. The difference between capturing and logging events ? In the first case, your code asks the X11 server to give you all events targeted for a given window. The responsibility to what happens to said events lies entirely on your side. On the other hand, logging events is not something that X11 allows. Your code has to poll the X11 server for the state of the mouse and keyboard, and you must look for state changes and deduce what the user is (or not) doing.

In what concerns Isabel, both approaches give the server the user input events although capturing events is a little easier to implement. The catch is that if the Isabel server is capturing the input events, the Qt application won't receive them. Isabel has to generate an identical stream of events and feed it back to the X11 server. Because this is one the features required by Isabel, I decided that Isabel would capture events. It was a very dumb decision.

I began by writing a simple test program that would capture a mouse or keyboard events, print some info to stdout, then create an identical event and feed it to X11. The capturing part worked great, as I could see all input events being printed on stdout. The generation of fake events, that did not work all. The consequence was that I was locked out of my own computer because all of my key presses and mouse actions were captured by the test program. I had to force the computer to switch off in order to regain control. An intelligent person would have realized that I should first get the event generation working, and only then capture events. I am no such person, and it was only after the fifth or sixth forced power cycle that I decided to change my strategy. The problem was that no matter how hard I tried, X11 ignored all of my artifical events except for mouse motions events. A few days latter, grudgingly, I changed strategy again and gave logging X11 events a try. Talk about the procession of Echternacht.

Quite contrary to my initial suspicions, logging X11 events turned out to be not that hard to implement and it works reasonably well provided the X11 server is polled fast enough. I tried different sampling times, and 10 milliseconds hit the sweet spot. I admit it is a rather high sampling rate, unless your typical users are hyperactive coke and amphetamine addicts, but I did not notice any performance degradation at this high sample rate. This approach also has the added bonus that all X11 input events are recorded, irrespective of what window has the focus. I just implemented a mouse and key logger... cool !

Now that the Isabel server is able to record the X11 user input events, it is time to tackle the event generation problem. Now, most of you will be quick to point to the XTEST extension. I knew of its existence, while X11 is well documented, XTEST docs are quite terse. And no, function signatures do not count as documentation. The result was that I spent days knee deep in the X11 docs, unsuccessfully trying to find a way to generate events. After which, in despair, I turned to the XTEST extension. Driven by nothing other than common sense and caffeine, I was able to hack together a solution of which I am not very proud. All event generation is implemented with calls to the XTEST extension, except moving the mouse. That is implemented with an X11 call. Don't ask, just know that it hurts me too.

And now the moment of truth, let us test the solution with a Qt application. The recording and then replay of mouse events worked without a glitch, the keyboard not so much. Although it worked fine with my simple test program, it consistently failed to generate symbols that required modifiers. For example, on my QWERTY keyboard pressing SHIT+1 produces the symbol '!', and in fact Isabel recorded the correct sequence of keys being pressed and then released. But on the Qt application, all I got was the symbol '1'. Why ?

As it turns out, I was testing Isabel with Qt5.4 and one of the changes from Qt4 to Qt5 was the interaction with the X11 server, Xlib was replaced by xcb. This change appears to have introduced a bug which prevents Isabel from generating symbols that required keyboard modifiers. So while Isabel works flawlessly with Qt4 applications, in Qt5 it cannot simulate the use typing certain keyboard symbols. By the way, this is not a limitation of Isabel, it also happens with xdotool, for instance.

Tagged , ,

Why u no work ?

After much coffee and toil, I had made the first prototype and now it was time to play. I copied a very basic Qt application from its examples, build and launched it with the Isabel server code injected using LD_PRELOAD. The server is listening for requests, nothing crashed and the application behaves as expected. So far, so good. Until I launched the client and made my first request. The server replied by crashing. Why ?

I pull out GDB to investigate, and everything looks good with the application and server. I decide to go and make myself an espresso, and on returning the application has crashed. This time without even interacting with the client. Hum... this type of erratic behavior is usually a symptom of misbehaving threads. The trouble is that I did not expressively created any threads. Could be that the server is is not playing nice with the signal/slot mechanism or the Qt event loop. The trouble is that the server code looks kosher. But is it ?

In order to eliminate the server as the cause, I added an echo request where text sent by the client is echoed back in upper case. The modified server was injected on nano, a Linux text editor. In this way I am guaranteed that the only Qt libraries in use are those loaded by the server.

This time, no crashes occur when the server is idle. But as soon as a client connects, the server is no more. A few espressos and much googling latter, I found the reason. The server does not have a Qt event loop. This is by design, because it should use the one from the application under test. But I forgot that the server is the first library being loaded, before all others. And that only after all shared libraries were loaded, does the process begin to execute. The consequence is that when the server networking objects are created there is no Qt event loop.

The solution to this problem was not easy, as the Qt documentation is only good when you known what to look for. I have to thank Robert Knigth, which made the very useful QtInspector. Looking at its source code it was easy to find how to wait until the Qt event loop is up and running and only then initialize the server.

After this first road bump, I became confident that Isabel was working and decided to throw it a pure QtQuick application. All looks good until I ask the server for the list of objects. The reply is an almost empty list. Argh... why ?

For this particular problem, the Qt documentation helped. As it turns out, QtQuick objects are special. First they are displayed inside a QQuickView, which inherits from QWindow and not from QWidget. And second, the basic QtQuick object is QQuickItem and not QObject. After some C++ casting magic, I got my list of QtQuick objects. This was an easy one to fix.

Once I had the Isabel basics covered, I upped the game and decided to try to read and manipulate properties of QObjects. The properties are instances of QVariant and being lazy, I used a very simple serialization approach. First serialize the QVariant to a binary string, then base64 encode and send it to the client. It worked, in the sense that the client got the data and could reverse the base64 encoding. The problem was that the result was binary gibberish. To be honest, I suspected this would happen. But in my naivety, I still hopped that it would work basic types like integers and strings.

Another glance at the Qt docs, and the root cause was found. As it turns out, Qt uses a serialization protocol so that QVariant data can be stored and read independently of the underlying hardware architecture. Although this is great news for Qt developers, the Isabel client is not a C++ Qt application and thus cannot properly un-serialize QVariant data sent by the server.

Some of you might point out that since I am so much in love with Python, I could just use PyQt and use its QVariant implementation. Granted that this is a simple solution to the problem, but it is not without its disadvantages. Since PyQt development lags behind Qt there is no guarantee that PyQt supports the version of the serialization protocol used on the server side.

But my greatest objection is that it would destroy the client/server strict separation of concerns. After all, one of the main reasons behind deciding for this design pattern was not to restrict how the client was implemented. Another reason not to break the pattern is that although Isabel is targeted at Qt applications, from the perspective of the client the testing functionality is independent of the framework used to build the application under test. By making the client depend on PyQt I would be breaking the design pattern. To most of you, this probably sounds like zealotry. You are right, but I like my design patterns the same way I like my scotch, pure.

Moving on, after some googling I found the ridiculously easy to use QtJson library. With just two little files and with a compatible license, QtJson provides the functionality to JSON encode only a few data types, but enough for the needs of Isabel. The disadvantage is that many of the complex properties, like coordinate transformations, are not supported. But I will still chalk this problem as solved because I am only interested in data types that represent data shown to the user. That is to say, numbers and strings in the vast majority of the applications.

After all these ordeals, I though that Isabel was playing nice with Qt applications and I could move on to the X11 user events. With an ego as big as the world, I tested it on a small in-house application. I was about to call all of my colleagues and showoff when I noticed a strange thing. The server library was being loaded multiple times, all but the first succeeding. To make matters worse, parts of the application stopped working. What the .... ?

It turns out this particular Qt application was forking some processes. If you remember how fork works in Linux, after the call the child is an exact copy of the father. So exact in fact, that the child environment variables (LD_PRELOAD being one of them) are inherited ipsis verbis from the father. This of course forced the child to load the server library, followed by a server failure because the child code would be replaced by a non-Qt application. The child would then exit, parts of the application stopped working and a perfectly good opportunity for gloating was lost. But there is an happy ending to this story. After modifying the server to remove the LD_PRELOAD environment variable once it loaded, all was good again.

To summarize an already long post, at first the server was crashing the Qt application because the library had no access to the application Qt event loop. Then I found out that QtQuick objects need some special care before the server can access them. Next was the object properties serialization problem, solved with QtJson although many of them are end up on the client as empty strings. And finally, fixed a bug in the server that was causing it to be loaded multiple times. It was not easy, but I got Isabel to play nice with Qt and QtQuick applications.

Tagged , ,

Beam me up Scotty

At this point of the game, I have the basic outline for Isabel. I am using the client/server pattern, where the server implements the test functionalities. The server is implemented with the Qt networking library, the client is in Python. And the protocol messages are defined with Google's protobuf.

However, I am missing a crucial piece: how does my server code get access to the Qt application code ? It is out of question to add the server source code to the Qt application source. There are a few reasons why I don't want to do this. First, adding a back-door just for testing (or any other purpose for that matter) is just bad practice. But even if you do it only for testing purposes, then most likely you will spend a significant amount of development forcing two conflicting set of requirements, testing vs client, into your product. And last, my goal is to test the application from the user perspective. To the best of my knowledge, users don't use the source.

Some would argue that the users also don't have access to the application internals, like I plan to do with Isabel. But the reason for Isabel to access the Qt objects is a practical one. There essentially two ways in which Isabel can "see" the Qt application. Either it has access to the Qt objects that implement the GUI elements or it uses screen scrapping fu. Of these two, the first approach is by far the simplest to implement because Qt comes with introspection.

Going back to the original problem, I need to be able have access to the data and code of a process running in Linux. One approach would be to use a bare-bones debugger, which in Linux means resorting to ptrace and friends. The debugger just needs to be able to stop the process at arbitrary instants when it needs to peek or poke the process data. With some effort, it might be possible to automatically parse the process memory and read the relevant Qt application object data. On the other hand modifying the data is a bit more tricky as something as simple as changing a string implies a quite a few constructor calls. It would however, be feasible to modify fixed size data like integers, doubles and booleans.

I have only one, but strong, objection to the simple debugger approach. At the risk of excessively repeating myself, Qt has introspection built in. This is a much simpler and safer approach to accessing the application internals than scanning and modifying the process data segments.

A much simpler alternative is to actually inject the Isabel server, as a shared library, onto the application under test. I am talking about, of course, of the LD_PRELOAD trick. This is an environment variable in Linux, which allows the user to any set of shared libraries (yes, any) before all others onto the target application. Once loaded, they look and feel just like the libraries that are normally loaded by the process. Through LD_PRELOAD, the Isabel server code can access any part of the Qt application, including making calls to the process code. As an example, with the following code snippet the server can list all Qt objects implementing the top widgets in the application:

QList<QWidget*> widgets = QApplication::topLevelWidgets();

Q_FOREACH(QObject *object, widgets)
        qDebug() << object->metaObject()->className();

The beauty and simplicity of LD_PRELOAD come with a price though. It only works with Qt applications dynamically linked against the Qt libraries. That is to say, it only works with Qt open source applications as proprietary applications are usually statically linked against the Qt libraries. The consequence is that I won't be able to use Isabel at work. Bummer.....

Any sane person would have stopped here, but I am no such thing. Besides, I am curious to see how far I can go with Isabel.

Tagged , ,

The dynamic duo

A core concept of Isabel is the strict separation between the test scripts and the application under test. So strict in fact, that they run on different computers. This is possible by the use of the client/server pattern. The Isabel functionalities are implemented on the server, and made available to the test scripts through the client.

In addition to the evident advantages in maintaining a separation between the testing scripts and the application under test, implementing a client/server is pretty trivial. Since I am targeting a Qt application, I will the Qt libraries to implement the server. That means that on the server side, the networking code is done with just three lines:

server = new QTcpServer(this);

The new_connection slot implements the client requests handler, for every client that connects to the server.

The client, on the other hand, will be implemented on Python (rulez !). First because Python is just awesome, and second because dynamic typed languages are good for general purpose data manipulation. In Isabel, the main data entities are user events, Qt objects and screenshot images. This set is too heterogeneous to even consider a static typed language.

The server networking code looks trivial, but therein lie two hidden issues. The first is that the client/server connection is absolutely insecure. Although there is error handling code, not shown in the code snipet, no checks are made to ensure that the client on the other side is indeed a legitimate Isabel client. As long as testing is done on a secure network, this will not be a problem. There is an upside though, to the lack of security. While developing the code, I used netcat as a client for some sanity checks and detecting some problems that I had not anticipated.

The other issue is a bit more subtle. The client/server pattern implies that the two entities talk the same protocol. Worse, since the client and the server are implemented in different languages, the protocol must be implemented twice. To add insult to injury, at this point I only have a vague idea of the data entities being exchanged. I have no clear view, yet, on how request look like because I have not yet thought about how to implement the testing functionalities.

Before proceeding, I should mention that I suffer from the NIH syndrome. If I didn't, I would not have started Isabel. But because I am no stranger to protocols, NIH kicked in and my first impulse was to code a protocol, tailor made for Isabel. This worked great at first, but when I began implementing the client request messages it quickly became messy. The, at the time, highly clever shortcuts that I took to implement the protocol, latter on proved to be hard to fix mistakes.

All in all, I took me two weeks before I decided to replace that mess with protobuf. Although at first protobuf seemed like an overkill for what I needed, the ability to generate glue code from a single specification file was a godsend. Another advantage is that protobuf provided a framework to reason about the protocol messages. The more limited your solution space is, the easier it is to find the optimal solution.

Tagged , ,

The best laid plans of man and mice

My previous post I ended with a question: how hard is it to write a testing automation tool for a Qt application in X11 ? In this post I will begin to awnser this question.

To begin with, I will name the tool Isabel, for no other reason than it is easier to spell than a testing automation tool for Qt applications running in X11. Then I am going to set the goals for Isabel. With it, I want to be able to:

  • read and write the properties of objects on a Qt application
  • record, replay and generate user input events on a X11 session
  • take a screenshot of the whole X11 screen
  • do all of the above from a different computer, over the local network

Because a picture is worth a thousand words, here is a schema of the test fixture where Isabel is to be used:

Isabel Fixture

The test scripts run on the test computer while the Qt application and the test server run on a second, remote computer. The testing functionalities listed above are implemented on the test server. The test scripts, through the test client, can then simulate the user input events, take screenshots and fiddle with the Qt application objects.

In a nutshell, this is Isabel. You will notice that this is a pretty conventional test fixture. The novelty is Isabel, a testing automation tool for Qt applications running in X11.

Tagged , ,

Isabel: prelude

In my current professional incarnation, I am a test engineer at a company that makes medical equipment. A few months ago, motivated by a problem I was facing at work, I became curious about automation testing tools for GUI applications. Or to be more accurate, tools for automating the testing of a Qt application running in Linux.

Now I am sure I am not the first to want to automate the testing of a Qt application in Linux. But an afternoon googling session produced very little usable results. In the open source camp, I found SikuliX, LDTP and dogtail. The first I cannot use for technical reasons, and the other two depend on accessibility being enabled on the application. That is not the case. There were also some Python tools that looked promising, see here for a comprehensive list. But either they had dependencies that I couldn't get to compile (did I mention it is an embedded Linux box ?) or they simply crashed.

And what about the closed source, comercial tools you might ask ? Well surprisingly, there is only alternative, " Squish" from Froglogic, because all the other usual suspects simply don't support Linux. I did take Squish for a spin, and it looked capable although it did not perform as smoothly as I was expecting. Not that it matters tough, as management thinks the price tag is too high.

So, one day on the train back home, I started to think how hard could it be to build my own automation testing tool. After all, Qt has introspection built-in which makes it stupidly simple to list the application objects, and to read or modify their properties. And X11 has tools to simulate user events, xdotool and Xnee probably being the most well known. Surely I can hack a usable solution in a couple of coffee fueled nights, right ?

Tagged , ,

Uber What ?

Uber is a quite interesting phenomenon. Through a simple mobile app, it has wreaked havoc in a business known for its heavy regulations and trade unions. Not so much because it allows people to call a cab form their phones, but because it allows drivers without an union card. Is this a good thing ? The question is, of course, badly posited. But for the sake of the argument, lets try to answer it.

We are no longer living in the 20's (of last century), when driving skills were not common. Today pretty much anybody can, and does, get its driver's license. As a result, only unions and city ordinances protect taxi drivers from competition. Or better said, protected since Uber allows anybody to become a taxi driver, metaphorically leaping over the legal protections.

The union drivers are not happy about this, after all the Uber drivers are playing by the same rules. Although, to be fair, those rules were meant exactly to avoid competition and it can be that some Uber drivers are just trying to make ends meet. Like many other disruptive innovations, it is difficult to evaluate its effects this early. As we say in Portuguese, a procissão ainda vai no adro.

The one thing that does worry me about Uber, is the really low entry barrier. In practice, it means that many will be Uber drivers only as a part time job. And only during the periods in which it will be very profitable to do so. The consequence is that, professional drivers can no longer subsidize their inactive hours with the above market profits they would make from the profitable working periods. Because they now face competition that varies almost instantly with demand. This automatic market regulation is every libertarian's wet dream. So, the market it better of, but what about the people ?

I fear, maybe without reason, that people in the future will draw their paycheck from multiple part-time jobs instead of a single stable job. The digital economy enables this, since consumers and producers can meet on a scale that was never attempted before. Multiple small jobs can be a good thing, or not, but it definitely takes a toll on personal life. It is no longer possible to lead a life outside work, since people do not know ahead which hours they will be working that week, or even in what job.

It will also be hard to develop and mature skills, since it takes about ten years of continuous practice to become an experienced professional. A society in which most of the workforce is composed by amateurs that never mature into experienced professionals, will be one in which innovations and breakthroughs are scarce.

Tagged ,

The right tool for the right mind

The title was going to be a little bit longer, something along the lines of: fuck you Java and the horse you rode in. Also a bit more offensive as you can see. Why do I feel so frustrated when I work with Java ? After all, Java is a great language to work with. It is battle proven and does not get much in your way. It was not always like this, but Java has aged quite nicely. And the Java Virtual Machine (JVM) does a good job abstracting from the underlying layers of hardware and software. As the saying goes, Java is written once and debugged everywhere.

However, as an embedded software engineer, my encounters with Java are best described as a battle between man and the JVM. With lots of cursing, epic failures and coffee. More often than not, at the end of the day I seriously consider a career change. The culprits are of course the JVM and the ridiculous proposition that abstracting the programmer from the surrounding environment is a good idea. Or is that a Craig supercomputer is really just the same as the latest iPhone ?

Even though there are many common points between a Craig and and iPhone, the differences between them are really the points that matter. Otherwise it would make no difference to predict the weather using an iPhone or for you to call your mom on your Craig.

It is actually interesting to note that Java tends to be used in very standard environments, typically at the server side of enterprise applications. It has seen some usage in the desktop and mobile has well, but as far as I know big business is Java's sugar dady. Not that is an issue, but it does break the argument that Java runs anywhere. So yes, Java code does run everywhere, if by everywhere you mean enterprise servers.

One of the key aspects of an iPhone is that is not a Craig supercomputer. Or an Android phone. Or an Arduino, for that matter. The iPhone, the Arduino, the Craig and the myriad of computing devices you will find in the wild, where designed for a given set of use cases. They can all be categorized as more or less generic computational devices, but only if you look at them isolated from the environments in which they are used.

The whole point of an more or less generic computational device is to assist humans in whatever task they need. It so happens that people are surprisingly inventive and the world is a very chaotic place to live in. Thus, for most cases it is absurd to write code in the assumption that it will run in a nice, little cozy more or less generic computational device where it is sheltered from the nastiness of the world. And of course, also those furry, pestering, smelly things called users. Unless you have a big business to cover your back, your code will need to face the bruteness of the world, and of course, smelly, furry users.

As an embedded developer, I am often working with different not so generic computational devices, and they all must play nice with each other. I cannot do this if the JVM keeps trying to shield me from the really of my work.

Tagged ,