Netflix and Amazon instant indie films: my top picks

I keep stumbling on great indie films on Netflix and Amazon's video on demand services, and though I've mentioned a few of them here before, I think it's worth recapping the best of the last few years:

Monsters
Netflix: Instant Queue
Amazon: VoD Rent, Buy

Monsters is hard to pin down, and it's definitely the sort of film which many will be disappointed with because they walk in with the wrong expectations. Let's clear it up right away: there are giant, alien monsters in this movie, but it's not a giant monster movie. Ultimately, it's closer to a wartime travelogue than anything else. Our heroes are trapped in Central America some time after Mexico and parts of Central America are overrun by an alien infestation, accidentally returned from space by a NASA probe. The aliens appear briefly from time to time, but for the most part are just there to provide the motive force that keeps our heroes moving. The question the film silently asks is: who are the monsters and to whom? An excellent movie I'm happy to recommend.

(more after the break)

Building an Android App Development Workstation

I've recently started doing Android App development. It's actually not trivial to get started, and I hit a number of difficult roadblocks along the way. I started off by thinking long and hard about OS. I'm a Linux guy at heart, and Android is Linux-based, so a Linux system seemed the right choice, but I didn't want to have to have two desktops, and in my spare time I also play Windows-based games, so in the end I decided on Windows with a Linux virtual machine.

Next up was my choice of hardware. I already have a good keyboard, mouse and display, so I only needed the box. Along the left, I've linked the Titanium Gamer AMTI7013 which is roughly the same hardware that I bought (though I got mine at MicroCenter). This has the Sandy Bridge-based i5 2500K. The system I picked up had more RAM, so you might want to explore picking up some extra if you buy that box.

My primary performance concern was the Android emulator. It's slow and greedy, so I wanted plenty of RAM and at least 2 if not 4 cores so that it would be guaranteed plenty of dedicated instruction pipeline.

Having picked the hardware, I needed software. It's amazing how much software you have to install to get going. I started with the Android Development Tools (ADT) installation guide. But in the end, I had to install all of this (I'll describe this for the Windows setup, since I'm not running the emulator under Linux):

• Chrome browser (you could go with Firefox if you wanted)
• Java SE
• Eclipse Helios for Java
• Android SDK starter package
• Then I followed the ADT installation guide
• I had to make sure to install the USB plugin and all of the API levels I will be developing for

Optional components that I found useful included:

• Google Plugin for Eclipse - Useful for many purposes, but especially key if you have an app that uses Google App Engine (GAE) on the back-end; see the recent Google I/O talk/announcement and get:
• The Google Web Toolkit (GWT) 2.4 beta or later.
• Google App Engine SDK (make sure to get the Java version if you want to develop the back-end in Eclipse)
• Gimp for image/icon/logo creation and manipulation.
• VirtualBox for installing Ubuntu Linux
• Vim if you like having a quick-and-dirty editor around for opening random files (much lighter weight than opening files with Eclipse, but much more capable than notepad)

A few tips on getting things installed: make sure that you create a new directory that's separate from everything else (I made it C:\Dev) to put all of the downloaded items in. It's important that you not place Eclipse into existing system areas, since it doesn't always play nicely with the Windows file protection model.

Some notes about your app. You're going to need to sign it eventually, so you might as well get that out of the way when you're still in the "hello world" stage of development. To save a signed APK, just right-click on the top-level project name under the "Package Explorer" in Eclipse and select "Android Tools -> Export signed application package..." Once you've done this, you can use that key that you created for lots of useful purposes, not the least of which is to interact with Google APIs for services like Calendar and Maps. For example, there's a document that Goolge provides on extracting the md5 signature of the key and using it for access to the Maps API. To do that, you'll need the keytool program that came with Java SE, and can be found in that package's "bin" directory.

I'll continue to post more as I learn and get my first application up on the app market. Enjoy!

ASUS Wireless-N Router and Repeater

I just bought this handy little device, and I couldn't be happier. I've bought D-Link and Linksys in the past, and they've always managed to introduce some annoying complexity that I shouldn't have to deal with. But the ASUS was plug-and-play. I'm using it as a repeater and as a bridged physical switch. I plugged it in, turned it on, pressed the red button on the back and the corresponding button on my primary router, and then plugged my TiVo into the back. Boom, all set.

My signal strength on my Droid is now much better when I'm on the second floor, and Netflix has stopped stuttering. All is well with the world.

A shout-out to the Micro Center sales guy that pointed me at this device. You made my day.

Toward an Open Source television studio

In the software world, Open Source software has won. The last holdouts are still fighting the good fight, but the idea that you develop software in the open, while building a business model around local extensions, support and professional services takes such a myriad of forms that it's now hard to imagine a world without Open Source. Apple, Google, IBM, Red Hat, Oracle, VMware... they all make heavy use of and contribute to Open Source software.

Many have tried to apply this model to other areas. Wikipedia is probably the best known example of a non-software Open Source project, but there are many others. In Japan there's even a virtual pop star whose music and videos are essentially a gigantic Open Source project. Today, I got to thinking about what Open Source television would be like, and I think it would be very interesting. Here's how I'd see it working:

A studio or consortium of studios develop a setting and some central players. Let's say you want to set a comedy in a business (like The Office). You develop a "bible," as the industry calls it, that describes the business in some detail; its important players, background and the elements of the world that it's in that differ from the real world, if any. Then, you write a second bible that describes the show in terms of main characters, the shape of any given episode and some of the stylistic signatures. You release the first part as Open Source (say, under CC-By-SA), but the second half is proprietary.

Each time you release and episode, the show itself is licensed as normal, but you revise the setting with any new details that you've developed in your show.

Legal concerns: Television is a complicated world, and there's certainly much more scrutiny of where ideas come from and who owns them than in other industries. Because of this, it might be necessary to build some protections into the licensing of the open source piece That's a hurdle, to be sure, but I don't think it's a very high one.

As time goes on, the creator studio can continue to build new open or proprietary content in this world, licensing it as they see fit. Others can publish open source shows, books or other media set in the same world, but they cannot re-use the specific characters or details from the proprietary shows.

This gives the broadest number of options to the original creators of the show, but if a vibrant ecosystem forms around this nucleus then it probably makes sense to start publishing new content as open source. After all, television makes its money on advertising, and there is still going to be a demand for seeing episodes when they first air, which drives the audience numbers, which yields ad revenue.

In terms of secondary revenue such as DVD sales, proprietary shows will still have control. Open source shows will not, but there are ways around that. Special boxed sets, signed by the cast, for example, could drive sales of the original (this brings up a point: it may also be necessary to modify the licensing such that open source shows can produce proprietary packaging for media sales).

Anyway, the idea is simple: by building a community around the development of your core intellectual property, you give up some control while gaining massive productivity multipliers. This is how Google and Apple are able to innovate so fast. It's why Oracle was able to step into the business of distributing their own operating system, literally overnight. This isn't an idea, it's a proven business model, and frankly, I believe it's one that every industry is going to have to adopt or find a way to compete with.

Clamchowder (ne Perl 6) to offer shell migration package

This was an April Fools post.


The rich history of Unix shell scripting is often overlooked by the community of "real programmers" who work in languages like C, C++, C#, Cobol, COMTRAN, CPL, Common Lisp, CLOS, CLIPS, Clojure, and even some lesser known languages which start with other letters. But this has left decades of important infrastructure tools unavailable to the average programmer without using an external command like "system" which is often considered a security risk due to the existence of "." in everyone's path.

As a result, the Perl 6 community has announced a new suite of tools that aid in converting old shell scripts into this modern language with all of the features one might expect, and all of the other ones also. This conversion is quite difficult, which is why most languages do not provide such a tool suite. The reason for this is that shell scripts inherently rely on external programs, so the language isn't just a set of syntax, but a semantic pallet that includes the entire operating system. Perl 6 resolves this problem by providing a unique module for every existing operating system revision.

For example, if your shells script was written to run under BSD 4.2 Unix variant, Ultrix, then you would run the conversion tool like so:

  shell6 --system=unix.bsd.ultrix bofh.sh

Which would produce an output script called "bofh.pl". This script maintains a close compatibility with the legacy system by providing an execution environment that mirrors the expectations of the script. It will first boot a Perl 6 version of the 4.2 BSD kernel. This kernel is actually hand-written in Parrot Byte Code (PBC) giving it the blazing speed of an interpreted byte code, far out-performing the original Ultrix VAX-based systems, when run on modern hardware.

Next, Perl attempts to simulate the expected idiosyncrasies of these legacy systems. Because the 1980s pre-dated the development of the World Wide Web, there was a far greater dependency on communications protocols like UUCP, Usenet and FTP which are not nearly as widely used today. Thus, the shell6 translator also creates a "news spool" and establishes a "bang path" connection to other users of the service over which to communicate and share observations about the latest episode of Automan, Star Trek: The Next Generation or Babylon 5 with the simulated sense of urgency that only Perl 6's hyper operators can bring.


There are, however, some problems. There are still a number of simulated environments in which scripts do not behave as expected. In most of these cases, it is believed that the legacy scripts in question may depend on the ability to compile and run code in programming languages that start with the letter "C". For those cases, the next revision of shell6 intends to have a full parser (written in Perl 6 rules) for each of the common versions of these languages, but don't expect that to be released just yet, as there may be some concerns about embedded assembly that will require a more robust approach which simulates the entire hardware platform.

As the title of this article implied, there is also a team investigating the value of moving Perl 6 from the "P" namespace (let's face it, no real language has ever had a name that started with "P") to the more prestigious  "C" namespace as "Clamchowder", so you may wish to begin using that name in all of your Perl 6 communications with colleagues. Final debate has already begun, but stalled on the options of "Clamchowder," "ClamChowder," "Clam-Chowder," or "Clam_Chowder." There is a small contingent of "clmchdr" advocates who claim that Perl's name should be golfed for great justice, but nobody is taking them seriously.

Yes, today is April 1.

Perl 6 for finding non trivial powers less than 2 ^ 20

I recently noticed Terry Jones's blog post, "The eighty six non-trivial powers ≤ 2^20." I was immediately struck by how well this lent itself to being implemented in Perl 6, so I grabbed a handy Rakudo interpreter and translated it rather literally and then played with some slightly more idiomatic approaches. I still think I'm missing something with respect to the main loop, but I like what I came up with. The code is on github in my scripts repo.

In comparing the two (Terry's Python and my Perl), I really felt like this summed up the reason I want to code in Perl 6 more often. I work in Python for work, these days, and while it's a fine language with some very nice tools (django is especially nice), I frequently find myself wishing Rakudo were just a bit more production-ready.

So, without further ado, some thoughts about the two versions...

Code length is ignorable. Sure, the Perl is shorter in some areas and longer in others, but if that's interesting to you in terms of a mathematical problem, then there may be a problem.

However, in terms of clarity, I find two distinguishing features. One is strongly in Perl's favor, and one is mildly in Python's favor:

Pro Perl:

The largest thing I notice is that last block. It's much clearer to me that were'e concatenating the key with the value, after both are transformed in some way.

This reads a bit like, "print the formatted number in the key, followed by an equal followed by the values, joined internally with "^" and externally with commas."

Meanwhile the Python is something like, "print a formatted number, and equal and a formatted string where the number is in n and the formatted string is a comma joining a formatted pair of numbers joined with a "^" where the numbers are a and b where a and b are the tuples in powers indexed by n."

It's not that the code is *longer* that's the problem, but that it's far more disjoint. Even the indentation has to be complicated to suit the way they're mixing infix, functional and postfix grammatical elements.

Pro Python:

The declaration and use of powers is far cleaner in Python due to the handy defaultdict concept. This bypasses the defaulting that we do in Perl:

    (%powers{+$n} //= []).push([$a,$b]);

Beyond being punctuation-heavy, this is exactly the same underlying behavior as the Python. We default the bucket at $n to an empty list and then append the new item. The difference is that in Python the defaulting behavior is taken care of behind the scenes.

I say that this is minor because I understand this to be functionality that Rakudo Perl 6 has simply not implemented yet. You will eventually write:

    my Array %powers;
    ...
    %powers{$n}.push([$a, $b]);

very much like its Python counterpart.

Update: I'm told by the good folks on #perl6 that the right way to push onto a hash entry with a default empty array is:

    %powers.push: $n => [$a, $b];

Which is certainly cleaner than all of the  above, so woot!

Two free albums worth paying for

As readers of my essays know, I've been listening to free music recently. That's not to say that I participate in file sharing of otherwise for-pay music. Rather, I enjoy music which artists choose to share for free. I've even donated a bit or bought for-pay albums as a result.

This month, I've found two new items that really tickle my fancy. The first is Commence, the second free album from Paul Lisak & After the Ice, the first being It Happens All the Time.That album's clear and nearly hypnotic rifs and commanding vocals were my first taste of free music that I could actually love. Commence doesn't live up to this standard, but it's a solid rock/pop/alternative album which far surpasses the bulk of the free music I've been listening to of late. It's a bit bluesier than Happens which can definitely be nice if that's what you're in the mood for.

The second is the instrumental/ambient album, Shedneryan by Roger Subirana Mata whose work was covered in 2008 on Free Albums Galore (I've also linked to one of his CDs on Amazon, to the left, if you're not ad-blocking), an excellent blog for finding free music. This new album was released last month and I'm not sure that I agree with one poster to Jamendo who said that it was on-par with Tubular Bells, but it's an excellent atmospheric piece that I'd compare favorably with Tangerine Dream (especially the first track), Vas (the second track) and many of my other favorites. There's even what I think is a little bit of dark soundtrack ala Danny Elfman and John Massari thrown in for good measure.