SL4A – scripting layer for Android

SL4A – scripting layer for Android

Scripting Layer for Android (SL4A) brings scripting languages to Android by allowing you to edit and execute scripts and interactive interpreters directly on the Android device. These scripts have access to many of the APIs available to full-fledged Android applications, but with a greatly simplified interface that makes it easy to get things done.

Scripts can be run interactively in a terminal, in the background, or via Locale. Python, Perl, JRuby, Lua, BeanShell, JavaScript, Tcl, and shell are currently supported, and we’re planning to add more.

The permanence of temporary

I came across this little story about the Gmail logo.

How many times have you been told not to leave something for the last minute, but when you did, it actually turned out better than expected? Well, Gmail’s logo was the product of this situation — it was designed by Dennis Hwang (who’s responsible for most of Google’s doodles at the time) the night before Gmail launched. Former Google designer Kevin Foxtells the story on Quora: “The logo was designed literally the night before the product launched. We were up very late and Sergey and I went down to his cube to watch him make it.”

The last minute bit reminded me of something else.  A few years ago I was involved in a project with a rather hectic release plan.  There was too much work to do, not enough organization, and the deadline appeared much sooner than expected.  The team was in the office pretty much since Friday afternoon and it was already just after 11pm on Sunday night.  Everyone was stressed and exhausted, and we thought that the painful release of the project was just about done.

It was then that we got a report from the support department that something is wrong with our outgoing emails.  And the problem was that they weren’t going out much.  Clients submitted forms and were told to expect activation / verification email with code.  And those emails weren’t coming for a while already.

It was then that we realized that in all the chaos we actually completely forgot to implement that bit functionality.  There was nothing there that was sending emails.  Oops!

I kicked everyone out of the room, locked the door and wrote a very quick Perl script.  I spent not more than 15-20 minutes.  We just needed something really quick to get the mail queue out of the way.  We would rewrite it properly next day, when the dust settles a bit and everyone is rested and thinking clearly.

Can you guess when we actually rewrote it?  One and a half years later!  That’s  right!  Something as temporary as that lasted and did the job for almost two years.  Turned out that the job I wrote it to do on the first night was pretty much the job it would be doing 24×7, and there was no need to even update it.  It supported templates, multiple languages, and pre-configured attachments based on the template and language.  And it was efficient enough, since when I was writing it we already had a few thousand messages in the queue and I wanted to send them out as quick as possible.

Even later, when the rewrite happened, it wasn’t for any new functionality, but for better integration with the rest of the project.  After all, it doesn’t make much sense to have a single standalone Perl script in the project that is completely written PHP.  It was ported almost verbatim.

Every time I tell this story, especially to my Russian friends, I keep hearing the same response: “Nothing is more permanent than temporary“.  You build something to last for years and it gets destroyed, redesigned, and rebuilt every 6 month.  You throw something together to get you through the day and that lasts a century.

The Gmail logo reminded me of that.  Designed on the night before the release, the logo is still here…

Whatever happened to programming

Via this Slashdot post I came across an excellent blog rant – Whatever happened to programming (and the follow-up).  Subject in focus – modern programming, and how boring it have become (mostly).

Today, I mostly paste libraries together.  So do you, most likely, if you work in software.  Doesn’t that seem anticlimactic?  We did all those courses on LR grammars and concurrent software and referentially transparent functional languages.  We messed about with Prolog, Lisp and APL.  We studied invariants and formal preconditions and operating system theory.  Now how much of that do we use?

Of course, when a subject like that is brought up, it’s pretty much guaranteed that the web will respond with numerous discussions on if and how much of it is true, how did we get here, and how we can get out, and anything else remotely or not at all related.  And that’s just what happened.  You can read Slashdot or Reddit comments or Google for more.  But I think, if you do programming for living, you’d probably agree with the main point of the article.  And even if you won’t, it’s still fun to read.  Like this bit for example:

Especially, I have learned that anything that has “Enterprise” in its name is so incredibly boring that the people who use it had to shove the name of the Star Trek ship into its title just to keep themselves awake.

On the serious note though, working with mainly two programming languages – Perl and PHP, I see that there is indeed a difference to the “being boring” degree.  PHP is way more boring than Perl.   Surprisingly even with Perl being so well known for its CPAN – a huge archive of modules and libraries to use.   I guess it has something to do with There Is More Than One Way To Do It – motto of Perl.