I’m looking for advice on developing a standalone web app for Windows. That is, the server side would be running locally.

So far I’ve got notes on Perl and necessary modules.

  • Strawberry Perl
  • DBI and DBD::SQLite
  • Plack and Mojolicious or Dancer
  • AnyEvent and Twiggy ?

I’m planning to remove MinGW / and the compiler to make the final package smaller.

Here is the list of installation software.

At the moment I’m leaning towards NSIS for no particular reason.

What I’m thinking is that the installation script will check for the existence of C:\Strawberry. Then it will run the Perl it finds there.

  • If it can’t find the directory, it can install it.
  • If the directory exists and the Perl is good, use it.
  • If the directory exists and the Perl is not good, abort with an error message.

Any input welcome.



(This is just a note for myself).

IPC::ConcurrencyLimit is a handy module for implementing a number of concurrency patterns.

Steffan Mueller mentioned it in a comment on my blog back in 2011. Since then, there have been a couple of articles about it on the Booking.com dev blog

Growing Perl

Chris Wellons has an interesting comment on Guy Steele’s classic Growing a Language which made me think of Perl:

  • The point about a more mature version of a language failing vs an earlier version can’t be right. For example, if Perl 4 and Perl 5 were released at the same time, which would people choose?
  • On the other hand, obviously Perl 5 would not exist, because of the lack of evolution, if it hadn’t been for Perl 4. I think I saw a speech by Larry where he said he had tried to lay grass down (e.g. symbol table hacking) for others to turn into sidewalks (e.g object orientation).
  • Perl 5 is nicely designed for evolution. Take the Try::Tiny module for example. How many commercially acceptable languages could you add Try/Catch/Finally too if it wasn’t already baked into the language?

Interesting discussion at lunch today. The Javarians asserted “Yes” (although I’m certain they didn’t think through the implications).

A good counterfactual would consider the result of the void left in 1996 without Java.

Smalltalk may have flourished. C# wouldn’t have been created and instead we would have seen VB7, VB8, etc. C++ would have been pressed into more unsuitable domains. Would there have been space for D… ?

However, this is not that article. We assumed the existence of C#, .NET and Mono. Clearly Java 1.0 would not survive if introduced into a 2013 world without Java

What about Java 7 or 8?

Without developers, even a great language is useless. You can’t hire developers for it. You don’t get third party libraries or people blogging (or writing on Stack Overflow) about how to solve various problems.

Enterprise developers from C++ would have migrated to .NET or Mono already depending on whether they were on Windows or Linux. Java wouldn’t be the great leap forward (for typical enterprise teams) that Java 1.2 was in 1998.

No, even Java 7 would not succeed if released today. A big part of what makes it successful is the huge number of talented and experienced Java developers.

What do you think? Do you agree or disagree?

In the future, apparently we’ll only have one computer – a smartphone that plugs into a docking station. If a docking station is needed to work, and I need to work on the move then I still need more than a smartphone.

I prefer the future laid out by Ben Thompson:
multiple devices linked by the cloud.

…what is the smallest screen size Apple could make and still run iPad apps?

Twitter discussion on a smaller iPad

The conclusion was that a smaller iPad would need a different resolution. It would still be tough to do fine-grained work.

A reasonably sized smart phone is fine for surfing the net, watching movies and replying to email (although I’m still sad when the keyboard takes over half my screen). For working, although you can make do with one in extremis, either a larger device or a completely new interface is required.

Android Memory Scavenging

Free Space

What are we looking at here? This is the free space of the various mount points of the phone. System is the OS (Android 4.0.4 in this case) and SD should be fairly self-explanatory.

The 147MB data segment is the space for storing apps. It’s supposed to be 512MB, but HTC did something funky… and a lot of the default apps take up space here, so there is really not a lot of space for third party apps. The first thing you do when installing a new ROM on the Desire is to create a new Ext partition, and start linking parts of your data mount to it.

As with all things Android, there’s a choice of what to move off to your partition: Apps, Data and Dalvik Cache. Moving Apps to Ext is essential, but at the same time, doesn’t help much. After four or five apps, I’m still out of space on my Apps partition.


I decide to move Data but it doesn’t help much. This screenshot shows the result after moving data – and data still has 128MB used of 147MB. Surprise surprise – Dalvik Cache is also stored in “Data”.

Post Data Move

Unfortunately, moving Dalvik Cache pretty much hoses your performance. It contains pre-compiled byte code and loading that off SD card takes a long time. Apps start taking between 10 seconds and a minute to start-up.

I’m caught between a rock and a hard place. Truly awful performance, but plenty of space for apps. Or moderately poor performance and no space for apps.

Honed Android Set-up

My android set-up has been tweaked and honed over more than three years. It is really a bit more than the original HTC Desire is capable of coping with.

Home Screen

The focus of my home screen is communication. Two email apps – Yahoo and Gmail, Viber (messenging), Facebook Messenger and LinkedIn. My phone calls, SMS and a shared calendar are a fifth, sixth and seventh way of communicating respectively.

Screen 3

Primary Widgets

Screen 2

This is primarily for enabling and disabling WiFi and 3G to conserve the battery. It’s one swipe to the left and then one button press. It’s not quite as convenient in Windows Phone, even using Quick Settings.


Screen 4