Android TV is included in some modern Smart TVs, and there are also external set-top-boxes to get Android TV for any TV with HDMI input.

However, there are also some set-top-boxes which almost, but not quite, support Android TV.

With not so much extra effort, it is possible to make an Android app supporting those fake Android TV devices as well as the real ones.

In addition to the guidelines from Google for building Android TV apps, do this to support the fake TV Android TV devices as well:

If you build an app for both Android TV and mobile (smartphone/tablet), make sure to build a separate .apk for Android TV, using Gradle flavors. (This is a good idea anyway since it will keep down the .apk size.)

Do not use the televisionresource qualifier, put TV resources in unqualified resource directories instead. (When building a separate .apk for TV only, this resource qualifier is not necessary.)

A struct should allow constructors. Such constructors can have two purposes, to convert one type of data into another and to validate the input. Such constructors should take parameters and be able to throw an exception if the input is invalid, to make it impossible to create an invalid instance of a struct. Each constructor should be required to set every field of the struct, and if no constructors are defined, a default one should be generated which simply takes all fields as parameters.

It can also be useful to have derived fields, which would be parameter-less function which return a value computed from one or more fields in the struct. They should be pure functions from the current state of the struct.

There should be encapsulation so that fields can be marked as public or private. Which one should be default?

structs should be immutable by default, with an option to mark individual fields of them mutable. However, it should be required to mark the whole struct as mutable to be able to mark any field of it mutable. A mutable field cannot be private and it’s value can be set from outside (typically with assignment syntax).

structs should not have any inheritance or polymorphism, and should not have any methods.

structs should be value types without identity, like a struct in C# or a primitive type in Java.

Several popular statically typed programming languages, including C++, Java and C#, have a serious design flaw. They make no useful distinction between objects in the OOP sense and plain data structures.

A plain data structure should only be a dumb container for data. It should not have any behaviour, only simple accessors for data items in it. It should not be possible to override data accessors. It should be clear and transparent what it does.

Good old C has a working construct for plain data structures, the struct.

C++, even though trying to be compatible with C, managed to mess it up. C++ added class for OOP objects, but also extended struct to be more or less equivalent to class. Even though there seems to be a convention in C++ to use struct for plain data structures and class for OOP objects, there is no guarantee that a struct in fact is just a plain data structure without surprising behaviour.

Java made it worse by skipping struct completely and providing no other construct for plain data structures than class which is primarily made for OOP objects. In the Java community, there is no general convention for making any distinction. To make things even worse, the horribly verbose Java Beans convention is quite popular and has support in the standard library.

C# actually have a meaningful difference between struct and class, making struct more suitable for plain data structures. However, it seems like struct have too much OOP like functionality built in and that it is possible to provide surprising behaviour.

Scala has class for OOP objects, but does also provide case classes which are suitable for plain data structures. Case classes also have some bonus features like pattern matching and auto generated methods for equality, hash code and string representation. Together with Scala language features like named parameters and immutability by default, they work reasonably well as plain data structures. However, I wish they could be more restrictive and not allow OOP features like general inheritance (which does not work well for case classes anyway) and overriding accessors.

It is possible to use associative arrays as data structures, and then you get no surprising behaviour. This is popular in Javascript which have nice syntax for this. However, most other languages do not have a convenient syntax for this, and in particular it does not work well in a statically typed language. I like to declare my data structures, and it should not be possible to add arbitrary values to instances of them at runtime. Associative arrays usually also have a runtime performance overhead.

It is also possible to use tuples (which some languages have) as data structures, but I want the items in them to be named, not ordered.

In their quest to promote Reactive, Typesafe is beating up a straw man by portraying blocking I/O in a particularly stupid way which is rarely (if ever) done in practice.

In a recent webinar, I found this slide which suggests that a blocking I/O operation will waste CPU time while waiting for the I/O to complete.

If I understand it correctly, it does not actually work like this in any reasonable runtime environment / operating system. As an example, consider doing java.io.InputStream.read() on a socket in Java (or any other language on the JVM) on Linux. If there is not data available in the buffer, this call will block until some packet is received by the network interface, which may take several seconds. During that time, the JVM Thread is blocked, but the JVM and/or Linux kernel will reschedule the CPU core to another thread or process and will wait for the network interface to issue an interrupt when some packet is received. You will waste some time on thread scheduling overhead and user/kernel mode switching, but that’s typically much less than the I/O waiting time.

I am quite sure it will work the same way on other runtime environments (such as .Net) and operating systems (such as Microsoft Windows, Solaris, Mac OS X).

There are other reasons why blocking I/O can be problematic, and the Reactive principles are useful in many cases. But please be honest and don’t portray blocking I/O worse than it actually is.

I want a simple, fast and lightweight text editor for my Linux desktop. I don’t want to learn a lot of new arcane key bindings, so not Vim or Emacs. I want a real GUI desktop application, not a console based one, so not nano (even though nano is nice when you only have a text console available). I don’t want a full-blown IDE for programming (I already have that) so I don’t need syntax highlighting and similar features.

So far I have been using gedit which is bundled as default text editor with Ubuntu. But it is not lightweight and sometimes really slow. It is particularly bad at handling large files and slow at searching, searching for a word in a 5 MB text file was painfully slow on my quite fast computer.

I got fed up with gedit and went out to look for alternatives. I found Leafpad and really like it. It is available in the standard Ubuntu APT repository, so it is trivial to install. It is GTK+ based (just like gedit), so it integrates nicely with the Unity desktop, it even supports the Unity global menu bar.

Leafpad is really lightweight and much faster than gedit. Searching through a 5 MB text file is not a problem at all.

Leafpad lacks some of the features that gedit have. It doesn’t support multiple files in tabs, but since it’s lightweight you can start multiple instances of it in separate windows, and the tab support in gedit is not very good anyway. It does not support syntax highlighting, but for me gedit is not good enough for serious programming anyway, I want a real IDE with more than just syntax highlighting for that.

I regularly use Swedish keyboard layout, but I keep the English layout around in case I would like to temporary switch to it.

Ubuntu 14.04 sometimes mess this up and I suddenly get English layout when I log in. I fix this by installing dconf-editor, go to desktop/ibus/general, and make sure that the values engines-order and preload-engines are the same and in the desired order with the default layout first.

I use Adobe Lightroom 4.4 for photo editing. There is one very annoying aspect of this program, it is not available for Linux (only for Windows and Max OS X).

In order to run Lightroom on my computer, I had to use VirtualBox and install Windows 7 in it. This works, but is quite clumsy and annoying. And since Lightroom is the only reason for me to run Windows, I would like to get rid of it.

So I decided to try out Wine. The current version of Wine does not support Lightroom out of the box, but I found some patches and tricks which makes it work. This is how I did it, for Ubuntu 14.04 32-bit (might work in older versions as well).