It's getting pretty easy to see that I should start finishing some entries for this blog if it's going to be at all relevant or useful, but I'll take a moment to introduce another "thing".

This past weekend, while working on a web project in Ambition, I started wishing I could control logging in a better way than what was already provided. Specifically, I wanted to be able to amp up logging in one controller while keeping another one quiet. In a horrific turn of events, I found myself longing for something like log4j/log4perl/log4net so I could use a configuration file to handle that.

A few days go by, and here we are.

Introducing Log4Vala, available on GitHub. Available as a shared library to integrate into your Vala application or library, Log4Vala provides most of the core concepts available in the other logging frameworks, without a lot of overhead. Yes, there are still a few method calls for each logging pass, but it's quiet a bit tighter than a VM environment. I'm pretty happy with the result.

I'm pleased to announce that there is a reasonable Couchbase library coming along for Vala, and it is semi-functional at this point. Sure, an announcement seems weird at "semi-functional", but considering the absence of a library up to this point, I'm calling it good.

GCouchbase is a combination of a fully functional vapi wrapper around the C libcouchbase library and a pleasant GObject layer on top of it. The libcouchbase functionality is available to the end user via GCouchbase or on its own, but GCouchbase makes the library work more like how one would expect out of a higher level language. The structure is loosely based off of the .NET library, but does not rely on libmemcached or any other proxy layer.

For those who may not be aware of what Couchbase is, it is (in my humble opinion) NoSQL done right. While similar in functionality to other offerings like MongoDB or CouchDB, Couchbase combines a persistence layer with a memory layer to provide fast, scalable JSON blob storage and retrieval that scales evenly with memory and CPU. In other words, you don't need to have a cache layer, a data layer, and a replication layer, Couchbase handles it for you. The built in view functionality is powerful, but can directly connect to an ElasticSearch instance for advanced queries.

It's very neat, and blends in nicely with the speed of Vala.
Nick,
2014-01-01 at 22:46:31

I will be presenting the Ambition MVC Framework at TCCC15. Twin Cities Code Camp is a free event that occurs twice a year at the University of Minnesota in Minneapolis, MN, and it caters to novice to advanced developers using multiple languages and devices. TCCC15 will be held on October 19th, 2013, starting at 8:00am, and you can register here.

The synopsis of my talk:

There are tons of great MVC web frameworks out in the wild, for most major compiled and dynamic languages. They're great tools to get projects prototyped and quickly into production. The Ambition MVC framework is a hobby that turned into a reasonable web framework. Written using Vala, the Ambition framework allows a developer or team of developers to create web applications or RESTful services using a static-typed object oriented language without relying on a VM or a garbage collection cycle. Plus, being compiled, it allows cloud deployment to be easy and inexpensive, as memory and CPU requirements can be a fraction of PHP, Ruby, Python, or Perl sites. While it's not "officially" released, it's available on GitHub, and being actively developed. Patches, help, and end users are very welcome, and I'd like to show you more.
Nick,
2013-10-08 at 18:49:28

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".
Nick,
2013-08-22 at 08:21:49

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.
Nick,
2012-07-18 at 15:49:21

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.

Lame.

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.

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.

Tangent.

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. :P 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.

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.