Welcome Back

After some thought and paging through many years of old, outdated technical advice, I have migrated my blog to a new domain with a bit of a fresh start. Because I never want to let go of what I’ve said in the past, I kept a few entries around for grins, but will start fresh and new from here on forward.

Welcome to my new blog.

The main reason I’m writing here is to share thoughts and elicit some conversation about modern development on the web and in the cloud, using old and tired technology, as well as new and busted technology. With any luck, none of the entries will end with “get off my lawn”.

Adventures in Vala: Ambition Framework

Quite some time ago, I posted about my Adventures in Objective-C, postulating that people would be willing to rapidly develop in a static-typed language if the language was easy to deal with. I created the foundation of a web framework that didn’t do too much, but was functional enough to prove that it was possible. I also gave up shortly after, as I found development on Windows and Linux to be a gigantic pain — too few libraries, not much support.

Some of the same ideals I was going for in that previous post still hold true. Java still clicks in a weird way for me, even if it’s too verbose and runs in a VM and 90% of the web frameworks for it annoy me to death. Objective-C was cute, but mostly useless for me. I don’t mind the idea of C#, except for the fact that it’s Windows-centric, and I’m still uncomfortable putting my eggs in the Mono basket.

In the meantime, I stumbled across a language called Vala. Vala’s roots are in the GNOME community, where they have a couple of great C libraries: GLib, and included in that, GObject. Using this standard library, C-based GNOME applications have had a lot of the great benefits of object oriented programming while maintaining the speed and support of the C language. Unfortunately, you got everything else that C provides: no memory management, no namespaces, and difficulty in reading it later.

I’m going to get flamed for that.

Nevertheless, other people saw some of those same things. They also saw some Mono applications creeping into the GNOME core, and felt that all the pieces were there to do something better. Vala was born as a true object oriented programming language, with a very similar design to C#. The difference is, it relies on GLib and GObject to accomplish the OO goals, and therefore, compiles into C, which is then compiled by gcc. As a result, you get significantly smaller and faster binaries than VM-hosted languages, with very minimal pain. Furthermore, you don’t need to use GTK or anything like that, it’s still a general purpose language that can be hosted on any platform that can compile GLib. That means I can code on OS X and Linux, and, while I haven’t done it in a while, Windows can join the party as well.

You see where this is going.

In the end, I took my ideas for a reasonable web framework, and started porting them to Vala. Months ago, I had a proof of concept similar to the ObjC example in my previous post. But, I kept working on it. Routing, templates, plugins, configuration, build systems, all managed to find their way in. Then, the nice things. Session, Authorization, and Form frameworks are a part of it. I’ve started on a fairly simple ORM, as well, Almanna. The result is, well, this.

This blog is the first production test of the framework. I ported the blog software from Catalyst to Ambition, launched it here on the existing database, and I’m going to see all the places it fails. It will likely do a lot of failing, but it’s a decent first effort. After a little stress testing, I’ll open this up on GitHub, and see where else it can go.

Detecting scrolls in an Android ScrollView widget

So, Android.

You would think that Google would have an event available for when someone scrolls a ScrollView widget. After all, it’s the basic way to make some view scroll. Even better, there is an event for the AbsListView and other scrollable widgets. Turns out, there is an event that gets fired in a ScrollView, but you have to subclass the widget to get at it. Then, you have to figure out how to get that message back to your controller.


So, for those of you who want to see if a scroll changed on a ScrollView, do the following:

1) Create a class, call it whatever you’d like, but subclass ScrollView. You’ll probably need to override the three existing constructors to be able to instantiate from your controller or XML layout.

public class ExampleScrollView extends ScrollView {
    public ExampleScrollView(Context context) {

    public ExampleScrollView(Context context, AttributeSet attrs) {
        super(context, attrs);

    public ExampleScrollView(Context context, AttributeSet attrs, int defStyle) {
        super(context, attrs, defStyle);

2) Add an interface within our new class to be able to set a listener. We’ll call it something different so we don’t override any existing OnScrollListeners.

public interface OnScrollViewListener {
    void onScrollChanged( ExampleScrollView v, int l, int t, int oldl, int oldt );

3) Let’s add a private attribute and a way to set that listener in the class.

private OnScrollViewListener mOnScrollViewListener;

public void setOnScrollViewListener(OnScrollViewListener l) {
    this.mOnScrollViewListener = l;

4) Now, set onScrollChanged to fire the event we provide.

protected void onScrollChanged(int l, int t, int oldl, int oldt) {
    mOnScrollViewListener.onScrollChanged( this, l, t, oldl, oldt );
    super.onScrollChanged( l, t, oldl, oldt );

You’re done! You can now set up one of these in your XML layout, or built on the fly. Set your new listener like this, provided you have one in your layout with an id of ‘example_scroll_view’:

ExampleScrollView exampleScrollView = (ExampleScrollView) findViewById( R.id.example_scroll_view);
exampleScrollView.setOnScrollViewListener( new OnScrollViewListener() {
    public void onScrollChanged( ExampleScrollView v, int l, int t, int oldl, int oldt ) {
        Log.d( “Scroller”, “I changed!” );
} );

Lifecycle of an Android Application

Every time I get a new gadget, something possesses me to try to write an application for it. It’s happened with dang near everything since the Newton, yet only a few gadgets have ever had a finished project. I tried the hardest on Symbian, but never came up with anything useful. I’d like to blame the SDK, but you should never blame your tools, no matter how much they completely sucked.

In October of 2008, a brand new T-Mobile G1 arrived via UPS, one of the first Google Android devices to hit the market. I had always owned smartphones, whether they ran Windows Mobile or Symbian (S60 or S80), but I wanted to get something that was easy to develop for, and would work well on my network. So, Symbian was out (hated the SDK), iPhone was out (Just started supporting apps, plus no one wants to be on AT&T), Blackberry was out (SDK even worse). Android seemed like a really neat, but young option. Being on the bleeding edge never scared me, it just usually screwed over other people.

So, approximately 3 days after receiving that G1, I downloaded the SDK, and started to use my extremely rusty Java skills to bang out a LiveJournal client for Android. It’s not as though I still really used LiveJournal, but I felt like it’d help me try out all of the neat APIs in Android. Web services, location tracking, image capture and manipulation, they were all there and usable. A shell of an application started to emerge around a series of mocked up layouts, and I was able to hook up login, posting, preferences, and user pictures in a short amount of time. ElJay was born, and I even wrote about it here. I’m amused at how proud I was that it was pretty complete after a few days — because it shows. Since I decided to dive right in instead of going through tutorials and example applications, it was subject to many of the first time Android developer errors. Screen rotation would lose settings, or interrupt a login, or interrupt a post. Web activity would throw exceptions that I never caught. Nothing was in a service, so switching applications or views would interrupt the same interruptables as above. Everything I did was in onCreate, so switching back to the application after Android cleaned house meant that someone would have to log in again. Sometimes, state wasn’t kept, so you’d post to no account at all. It was a barrel of laughs. I updated and updated until it was a mess of spaghetti code and generic exception catching. Android 2.0 finally broke it, and I didn’t care for a while.

I eventually pulled it from the market.

… until the screams entered my inbox.

A few weeks ago, I recommitted to ElJay, but instead of running through to try to fix it, I made the best and worst choice I could make, and started over. This time, I started it as if I were doing one of my Perl-based web applications, or writing a desktop application — I started with the back end. My first task was my XML-RPC interface, followed by my LiveJournal model. I created a unit test suite for those external interfaces. I created a suite for all of my display controllers. After a while, I got to the point where I had a decent unit test suite, and a few test accounts that passed the unit test suite. This process took a lot longer than the “few days” it took to bang out the first version, but from a system level, it worked well. It also helped me solve a long-standing bug I ran into in the first version, where the default Java XML library used by Android doesn’t handle some output from LJ very well. Hey, I could have saved myself from a rewrite! … Nah.


Only then did I start working on the user interface. This time, I could actually plan for exception handling, threading, the external service, the sync API, even basic user interaction. It also honors resolution independence properly, since I’m no longer using pixels as measurement. 😛 It’s amazing how much more confidence I feel in this application — not that I believe it’s bug free or foolproof, beta testing will prove that wrong within minutes — but that I can easily work with it, fix issues, and section pieces out for later. Things are getting really close now, and the beta rolls out in less than two weeks.

For those keeping track, the first version allowed posting with user pictures, security options, tracked your location, worked with tags and moods, and allowed you to save entries for later. The new one does all of that — and well — but also adds friends list support, attaching photos to your posts, and with any luck, manage your messages. I’m also throwing ads in, but they’re optional.

It does live.

Fun facts for hard times

When developing for Android, the default button height is 48 dip.

MooseX::Declare, TextMate, and TmCodeBrowser

Do you use TextMate?
Do you use TmCodeBrowser?
Do you use MooseX::Declare?

Must be a pain that nothing shows up the side pane when you start using it. It was for me.

Open ‘~/Library/Application Support/TextMate/PlugIns/TmCodeBrowser.tmplugin/Contents/Resources/.ctags.tmcodebrowser’ in a text editor. Add the following:

–regex-perl=/^[ t]*(class)[ t]+([^ t;]+)s*[ t]*[{;]/2/c,class,classes/
–regex-perl=/^[ t]*has[ t]+'([^ t;(]+)’/1/p,property,properties/
–regex-perl=/^[ t]*method[ t]+([^ t;(]+)/1/m,method,methods/

Reload TextMate.

Bask in the awesome.

Happy 25th Anniversary, Macintosh.

Twenty-five years ago today, January 24th, 1984, Apple offered the first Macintosh for sale to the public. Released with a huge amount of fanfare using arguably the first high-budget “Super Bowl Ad” during Super Bowl XVIII on January 22nd, Apple aimed to change the computing marketplace forever. Contemporary personal and business computers used a command line driven interface to operate, and programs written for these platforms followed the same type of functionality. IBM’s PC, Commodore’s 64 and 128, even Apple’s II series all followed the same idea, and few computers on the marketplace tried to change that at the time. The big contender, Apple’s Lisa, was a market flop, mostly because it was sold at over $10,000, 5x the amount of the average business computer at the time. Macintosh offered a 32-bit processor (on a 16-bit bus, but let’s not get caught up in the technicalities), 128k of RAM, a high resolution monochrome screen, and a mouse to control one of the friendliest user interfaces at the time. $2,499 was very steep in 1984, but it took the world by storm, and became the envy of every platform.

We got our first Macintosh in the fall of 1986, a smoke and fire damaged Macintosh 512K Enhanced, complete with an Apple HD20 (20mb hard drive!), a LaserWriter Plus printer and an Abaton Scan/300 sheet-fed scanner. My grandmother’s house had burned to the ground, and her basement tenant and friend was getting into desktop publishing — this was her machine. My dad took the machine in while she was relocating, cleaned the smoke damage out of everything, and powered it on. I remember hearing the chime the first time and watching it power up, and it was completely different than the Commodore 64 I grew up with. My dad let me play with MacPaint, and I was hooked. It wasn’t until years later that I realized my dad was letting me play on a setup that was $15,000 when purchased new in 1985.

That machine lasted me until 1993 as a full time machine. I learned Pascal, HyperCard, and MacBASIC on that machine. I did the best looking school papers and projects on that machine, using the scanner to include maps and other data, and using the laser printer to provide crisp, clean printouts. I had Aldus PageMaker and Microsoft Word to create brochures, flyers, and homework. I ran a BBS off of WWIV/Mac for a couple of years. I tried to squeeze System 6 and MultiFinder in the scant, un-upgradeable 512K of RAM. I got into the first BBSs with MacTerminal, and later, ZTerm, all with my Racal Vadic 1200 baud modem, and later, my generic Hayes-compatible 2400bps modem. I really, really used that poor machine with the warped, fire damaged vents.

To this day, that machine boots, hard drive and everything. The LaserWriter Plus and Abaton scanner were sold off by the next owner long before.

The machine taught me about typography, user experience, software development, and the appreciation of a great graphical user interface. I’ve had many PCs and Macs since, and they are exponentially better than that poor little FatMac I used to have. Without Apple’s leadership with that little machine, though, the computing world would be a far different place.

I just had to share.

Happy 25th anniversary for your crazy creation, you guys. Thank you.

For some reason, this amused me

This amused me. 🙂

Because you can’t tell a great hacker except by working with him, hackers themselves can’t tell how good they are. This is true to a degree in most fields. I’ve found that people who are great at something are not so much convinced of their own greatness as mystified at why everyone else seems so incompetent.

Rest in Peace, Mr. Butterfield

Jim Butterfield died last night at 1:30 in the morning, from complications from cancer. He inspired many a geek who hacked their way through Commodore 64’s in the old days. He certainly helped me explore the inner workings of computers, and he will be missed.

The sad thing is that he leaves with a whimper, when he was such an influential person in the 80’s, in that scene. Anyone who opened a copy of COMPUTE, COMPUTE’s Gazette, or RUN knows who he is, and how brilliant he was.

My best wishes to his family. Know that he left his mark on so many people, and he will be remembered.

The Comeback of a Language

Not sure what was going on with me this morning, but I think I was trying to pick a fight in #catalyst this morning. I was at work all of about ten minutes before I asked a simple question, amounting to: “Are there any plans to bring Catalyst to a wider audience?” Confusion followed, followed by a decent discussion. The general point I was trying to make is simple. If you ask someone who works near web development if they’ve ever heard of Ruby on Rails, chances are, they have. If you ask them about Catalyst, you’ll usually end up with a shrug. Those who are willing to listen further generally stop listening as soon as you say “framework for perl”.

There is a stigma attached to perl for various reasons — people view perl as unreadable, or slow, or hard to develop in on a large scale. Most people have a perception of perl that dates back to the late 90’s, coding against cgi-lib.pl or CGI.pm. Hell, back then, I was rolling my own CGI scripts so they were ‘lightweight’. God forbid anyone look at my code from back then. Perl was pushed as a rapid-development, but hacky language, and most people produced a lot of code that looked like line noise or otherwise, and that is what is burned into people’s minds. There is an unfortunate percentage of the current perl population that still writes kludgy one script wonders and calls it a web application, and that’s also bad for the community, in my opinion. Frankly, a language that holds contests on who can make the most unreadable code, or who can fit the most into one line, generally deserves that stigma.

The other side of the coin is Perl 6, the upcoming complete rewrite of Perl. If you Google for perl 6, you’ll find articles talking about its impending release dating back to 2001, yet we still don’t have a final revision. The bytecode interpreter is far from complete, and the closest thing there is to a working, usable interpreter is written in Haskell, another higher level language. The whole thing feels kludgy and incomplete to an outsider, and that’s probably because compared to other modern object oriented languages like Ruby and Python, Perl 6 is kludgy and incomplete.

So, disillusionment and wankery abounds when it comes to perl, and a lot of it is deserved. It’s a perception problem, and one that is almost impossible to solve. But, hell, I’m stubborn, and other people have made far inferior products rise from the ashes.

Those who remember a few years back realize that not many people were aware of or used Ruby before Rails came out, and a lot of old perl hands fell right into Ruby because of its similarities. I find Ruby to go against ‘what I mean’, so it’s a reach when I start pounding out any code. I was hoping to find an alternative when I stumbled upon Catalyst, and I’ve been hooked since. I think quite a few people would see the same thing, if they only knew what was there.

My plea to #catalyst was simple. Catalyst is a diamond in the rough, a flexible, fast, and powerful web application framework that is very easy to use once you get over the first learning curve. It is an excellent demonstration of modern OO perl development, despite any flaws or issues that still remain in the framework. The problem, however, is there is very little marketing or outreach happening, and without any kind of constant public opinion, the userbase stagnates and eventually shrinks, leaving frameworks like Catalyst to die on the vine. Someone within the Catalyst community, or even tangentally related to the Catalyst community needs to find a way to bring people back into the perl fold by making them aware of the strengths of the framework.

A few things would need to happen, in no particular order. Note that this is only my opinion, and I’d be happy to be told I was wrong.

  • They want their wiki moved from Trac to MojoMojo before they do any major wiki work. Fine, I’ll give that one.
  • Get some nice looking skeletons into the default Catalyst project template. Make it look pretty. For some reason, this actually works, and makes people want to do the same.
  • Catalyst’s primary development happens on mailing lists and on IRC. This should be outlined somehow within the wiki so creep doesn’t occur.
  • The primary focus of catalystframework.org should be marketing and outreach — a bulletproof example of the stability and scalability of an application written in the framework, with easy to deal with tutorials and a complete set of hyperlinked documentation. Links should be given to external sites who use the framework, as well as third party Catalyst tutorial sites.
  • There needs to be a third party tutorial and development site! You can toot your own horn, but it’s hard to convince people that what you have works really well unless they can see other people getting together and doing things really well. The real championing of OS X doesn’t happen on apple.com, so the real championing of Catalyst shouldn’t be on catalystframework.org. Luckily, it’s not, as the site is a bore and makes the project look dead, as it is hardly updated.
  • Along with the third party site comes some community support. Bring people together. Show people to IRC, bring people to a forum. Get a forum of a couple of hundred and hold CatalystConf or something similar. The key to getting the product into the eyes of many is to show people that there is an active following behind it. Lesser languages and frameworks do it and give people confidence to continue developing. Check out Lasso and REALbasic if you have no idea what I mean.
  • Tell people you’re using Catalyst. If you run a site that is truly great, and starting to get public attention, mention the framework. The Rails apps are doing it. The PHP people just try to hide that it’s PHP behind it.

I’m not talking about zealotry, here. I’m not talking about Catalyst being the best or brightest, or that perl is the best or the brightest. I’m not talking about how Ruby, Python, or PHP suck (this time). I’m only talking about bringing a really great language and a fantastic framework into the foreground so people are at least aware of the options before they talk some smack.

Or maybe, just maybe, I’m completely full of it.