I whipped this up as a quick Sunday project. The code is based on dims’ code here.
Its translations aren’t great, but would probably do in a pinch. They’ll likely improve as Google improves its translation bots.
I also used it to to test out Google’s code hosting, which is quite nice. The code is located here:
Here’s a question that has bugged me for a while, and to which I’ve never found a satisfactory answer.
How do people handle mailing list moderation when they have spam filters active? For instance, I get a lot of spam in the moderation queues for the Apache mailing lists I moderate. Sometimes gmail flags it as spam, and I can’t quite say it’s wrong… I mean the body of the email that’s help up for moderation is often full of spam words. But the moderation message itself isn’t really spam. I’m afraid of confusing the filter if I let it through. I guess this is where an open source system might be better, as you could simply put a rule in saying “if it’s a moderation email, don’t even bother looking at the keywords”. Gmail’s awfully convenient though… anyone else out there with the same problem?
The latest component of Android Hecl that I have been working on is a simple shell server that lets you interact with Hecl remotely, in order to be able to telnet in, run commands and see what they do. In order to give it a whirl, fetch Hecl from svn:
svn co http://hecl.svn.sourceforge.net/svnroot/hecl/trunk/hecl hecl
Then install the Hecl.apk:
adb install android/bin/Hecl.apk
Select the Hecl Server demo, at the bottom of the list:
You also need to make sure that port forwarding is set up:
adb forward tcp:7405 tcp:7405
At this point, you can telnet to port 7405 on localhost, and run Hecl commands:
> puts hi
hi
> androidlog "hello world"
> java android.telephony.TelephonyManager telman
telman
> set phoneinfo [[activity] getSystemService phone]
android.telephony.TelephonyManager@435c8f80
> $phoneinfo getLine1Number
15555218135
Since this simple server runs in its own thread/interpreter, you can’t control the GUI from it. To do that, there is a ‘maineval’ function that sends code back to the main interpreter:
> maineval {set layout [linearlayout -new [activity]]}
1
> maineval {$layout setorientation VERTICAL}
1
> maineval {set layoutparams [linearlayoutparams -new {FILL_PARENT WRAP_CONTENT}]}
1
> maineval {$layout addview [textview -new [activity] -text "Hi!" -layoutparams $layoutparams]}
1
> maineval {[activity] setcontentview $layout}
1
Gets us this very, very simple screen:
Hecl’s Java reflection support is still fairly alphaish, but you can use it to query classes about their methods and constructors, and call them most of the time; errors should be sent to me or the mailing list.
I found this little server particularly useful when fiddling around with some of the undocumented android classes, as a way to experiment in a running system.
http://www.postgresql.org/about/news.918
I’ve always preferred PostgreSQL to Mysql. I think the “worse is better” compromise is ok in some cases, but it’s scary to see money being handled in transactionless MyISAM tables that are so widely used; I’ve done work for a number of places that had that kind of setup, and extrapolating from that, it’s got to be very, very common indeed. I guess they heard it was “faster”… but I’ve always likened that kind of faster to the kind of faster you get by riding a bicycle with no brakes down a hill. Mysql’s made lots of improvements over the past few years and is beginning to approach the robustness that Postgres has always had, but I’m going to stick with Postgres, and I’m glad to see they keep churning out cool new things, using the same sort of community open source approach that works so well at the Apache Software Foundation.
Yoav Shapira wonders about the “rails backlash”:
http://yoavs.blogspot.com/2008/02/railsshudder.html
I’m a big fan of Rails, and of course I realize that it has some flaws and is certainly not the optimal choice for all situations, but I don’t buy into the bashing.
Sure, Rails was hyped, but there is no way that it could have possible reached the level of popularity it has on hype alone. We’re not talking about multi-million dollar marketing budgets commanded by the likes of Sun or Microsoft, but about a video and some nice dressings by DHH and 37signals. A small group like that just doesn’t have the resources to push something like Rails as far as it’s gone without some substance to back it up.
Look at all the imitation. People realize that the basic idea is good, and even though the basic idea is nothing phenomenal, it hadn’t really been done before. What is this idea? Take a bunch of components, and good (if not always the absolute best) practices, and integrate them nicely. Database, templating, testing, a clean application structure, ajax/javascript integration, with some code generation, all done with a language that’s flexible enough to do all of the above pretty well. All those things existed, but Rails did a great job of tying them all together. And that’s been imitated far and wide. That seems to indicate that, even though the imitators may change and improve bits and pieces, they’re quite smitten with the idea itself. So much that they’ve dedicated a lot of time and effort to reproduce it. That’s quite a tribute.
Look at the adoption. Moving to a new language/platform is a big step, not one to be taken lightly, and for people with lots of existing code in some other language, perhaps simply not possible. Hype will take things only so far, but Rails has been taken up by a large number of people who certainly didn’t do so because it was the safe, easy path to take. Perhaps some of those people have found that Rails really wasn’t for them, but that’s pretty normal. No one said it was perfect. However, when you look at what it takes to make people jump ship from what they know, and are comfortable with, you realize that it really must have been that much better to make people go out on a limb.
Furthermore, it’s easy to point out the failings and drawbacks of something after the fact, but much more difficult to do creative, innovative work of your own. Compounding that is the fact that criticizing others’ work is often an easy and effective way of looking smart; there’s an interesting study referenced here http://bobsutton.typepad.com/my_weblog/2006/08/brilliant_but_c.html that talks about this effect.
It’s something I’ve come to dislike over the years. Our field is so new, so dynamic, and so immature, that it’s usually pretty easy to take a look at something and say that it “sucks”. It is much harder to write something of your own and put it out there, knowing full well that lots of people who have never done much of anything will jump on it and bemoan its “copious failings”. That’s not to say that it’s impolite to criticize, but – do it constructively please. Imagine that you were there in the same room, talking to the person who wrote the code in question. You would still say you don’t like it, but you’d probably be much more polite and helpful in your commentary. I hope so, at least.
I’m a bit tired after driving up to Munich for the Android developer meeting, hosted by Google, and being “on” all day, but it was worth it. I was a bit apprehensive that it might be too ‘introductory’ in the sense of the Google guys telling you in person things that you could have easily looked up on the web, without spending a bunch of time driving around Austria and Bavaria. Fortunately, that wasn’t the case. There was some of that, but also plenty of unstructured time to chat with Dan Morrill and Jason Chen, the two Google “Developer Advocates”, who are both very friendly, informative and informed, approachable and put a lot of energy into what they do, despite being a bit tired from flying over from the US. It was nice to get a chance to talk with them, and considering that the platform is still changing, useful as well, because they were definitely listening to what people had to say to them. My thanks to them for a job well done.
Here are some “impressions” I took away – note that they’re not what anyone said, just ideas I got about what they said:
Source code is being released when handsets ship because they want to work very closely with the hardware partners to make sure the phone experience is good (they said this). They want to “set the bar high”, and they probably run the risk of someone snatching the code and slapping together a phone if they let out the source code to early. (They definitely didn’t say this, it’s just me connecting the dots).
Despite interest for ‘other languages’, it really looks like they want everything to go through Dalvik in some way or another. Clearly, at some point in the future, there will be specs for writing Dalvik byte code.
They won’t talk about the upgrade strategy, something I asked about. I want to know that as a developer, I won’t be stuck with N combinations of things that I have to support over the years. I want to know how they’ll minimize that pain, but they’re not currently able to discuss it.
Talking with other people attending, there seemed to be some doubts about security and permissions for user data, since Android is moving away from the j2me “everything is private” model, to a model where data can be shared between apps, which opens up lots of good things, but also some potentially bad ones as well.
There’s still really a sense of Android continuing to evolve, in a true spirit of openness. I liked that, as it means there is space for people to tell Google what they want, rather than simply being given a finished product and told that that’s that… but then again, I would, being the open source guy that I am.
I didn’t get to show off Hecl quite as much as I would have liked to, but I did get to mention it a few times, so I guess I did ok.
Tomorrow (January 28th), I’ll be in Munich for this:
http://www.mobile-monday.de/web/guest/android
Unfortunately, the event filled up super fast and I barely managed to squeeze in, so there are probably no spaces left. Still, if anyone would like to meet up afterwards, send me an email soonish. If you managed to get in, and would like to see a demo of Hecl, let me know, because I’d like to have the chance to show that off some too!
Hopefully it will be a valuable experience. Android is a pretty convincing system in many ways, but of course has yet to fully come into contact with reality, so I’m curious to meet some of the people involved and hear about it from them. I really hope it doesn’t end up being a rehash of information that’s available on the web, as it’s a two hour drive from Innsbruck.
This was a pleasant surprise:
I haven’t had a chance to actually buy a copy and see if they did a good job with the article, but it was pretty cool to see that it made the cover!
Link: http://webonline.gruppoinfomedia.it/dac/index.php?form_rivista=login&form_rivistanum=65
I’ll be in Zurich doing some consulting work this coming week. If things go well I ought to be able to do drinks and/or dinner on Wednesday. Drop me an email if you’d like to join us!
If you follow online discussions of programming languages, you’ll occasionally see articles about language X “dying”. It is, however, a bad metaphor, because the “life cycle” of a programming language is different from single biological units, of which you can definitely say at some point “He’s not pining … this is an ex-parrot!”.
Once a programming language is widely deployed, it simply won’t up and disappear from one day to the next. Too many people and companies depend on it, and replacing it is difficult enough, that the “switching costs” will keep it in place for many years. The obvious example is Cobol. This effect works in favor of languages that are not “the new thing”, and means they will probably not truly cease to be used for many, many years.
On the other hand, it’s also pretty easy to tell which way the wind is blowing and get an idea of what’s hot and what’s not. Java got hyped a lot in the past, now it’s Ruby. Scala is beginning to get hyped some, so is Erlang. Careful observers can spot the rise of languages as they hit the early stages of the technology adoption lifecycle.
By paying attention to what’s going on in the wider world, it’s also possible to see when languages are used less and less for new projects, and solely kept on for the legacy systems. I think this is what most people mean by “dying”, but of course it creates confusion, because it’s clear that the language is still utilized. In some cases, I think it may be possible that a language continues to be more widely adopted, yet still seems to lag behind, simply because other languages are being adopted at a significantly higher rate.
So what it’s really about is two factors: how widely deployed is the language in any given moment, and, perhaps more importantly, the rate of adoption – is it accelerating or slowing down? Are more people jumping on the bandwagon, or is the language being used less by innovators, early adopters, and new projects?
You need both those coordinates to understand where a language is at – it may be huge but declining, small but on its way up, or a niche language that never achieved widespread usage that isn’t catching on any more. The last one is the one you’d probably want to be wary of. The first two will probably be ok as long as you understand what you’re getting, and the type of user or organization you are matches where the language is at in its lifecycle.
I think that perhaps those interested in discussing these things seriously ought to find some good terms to use. “Forth’s rate of adoption is declining” doesn’t sound as exciting as “Java is dying!” though. “Fortran’s diffusion is decelerating” doesn’t have much of a ring to it.
Any other ideas?
DedaSys Journal 