So here are the various technologies I used in the creation of my app.

YQL

To get the data for this project I used a simple Python script and YQL to get a list of locations in each Zip code in Georgia with the term “Church” in them. This yielded approximately 10,000 results, including a few from South Carolina.

MongoDB

I stored the data I got from YQL in MongoDB. Specifically, I used MongoLab’s to host the data because they have a generous free storage limit (256Meg) and can be accessed from a RackSpace server without incurring an additional bandwidth charge.

MongoDB is a JavaScript-based NoSQL solution used by sites like Foursquare. It has built-in support for Geo queries and is built to scale.

node.js

For the application layer I decided to try out node.js. Node is also JavaScript-based, based on WebKit, the engine behind Google’s Chrome and Apple’s Safari browsers. Node is event-based which means it has the potential to be lightning fast.

Canvas

The biggest factor in how well a heatmap solution performs is the graphics package that’s used. After searching around I found a pretty decent PHP heatmap solution, but it used GD and was very slow. I also found a JavaScript solution that used the new HTML5 Canvas element, but it choked when given a significant amount of datapoints to render all at once. So I decided to refactor some of the utility functions from the PHP solution and combine them with the Canvas function.

The great thing about the resulting solution is that it has the ability to run on either the client-side or the server-side. And in the end the heatmap application I built uses both. If the number of data points in a tile is less than a preset threshold defined per browser¹ the raw data is sent back to the browser which renders the tiles client-side rather than consuming precious server resources.

Web Sockets

The usual way to serve tiles is by serving images to overlay the map. And while the heatmap solution I developed does serve static PNG files from cache, I decided to use the new HTML5 Web Sockets to make things a bit more interesting. What is great about web sockets is that it allows me to pass events between the server and client very easily. Socket.io made it easy to forget where the server ended and where the client began.

ZeroMQ

As applications scale to multiple threads, processes, and eventually across servers and networks, they need to have a way for each component to communicate with other components in an efficient manner. So add a bit of future-proofing to my solution I decided to use ZeroMQ to pass messages between the front-end web server component and the back-end tile generator component. This allows me to tune the performance of the application in both directions, up or down².

Raphaël

To add some extra pizzazz to the app I decided to add in the ability to display each individual data point along with some additional detailed information. I found that Google’s native Marker system was a bit slow when it came to displaying over 2,000 markers at a time so I decided to give the Raphaël graphics library a try. The results were impressive. Raphael was not only able to draw thousands of data points on the map seamlessly, but was able to do it with smooth animations. Look for gRaphaël to be employed in future renditions of this heatmap solution.

Conclusion

Every now and then I run across a programming challenge that reminds me why I love doing what I do. These technologies and this project have done that for me. Being able to throw together a large, complex project like this in a relatively quick manner reminded me of Fred Brooks’s comment on why programming is fun.

1. 1000 for WebKit-based browsers, 250 for Mozilla-based browsers, and 0 for IE because IE still sucks.
2. Tuning performance down comes in handy when you are on a shared server with limited resources.

Share/Save

One view of object-oriented programming is that it is a discipline that enforces modularity and clean interfaces. A second view emphasizes encapsulation, the fact that one cannot see, much less design, the inner structure of the pieces. Another view emphasizes inheritance, with its concomitant hierarchical structure of classes, with virtual functions. Yet another view emphasizes strong abstract data-typing, with its assurance that a particular data-type will be manipulated only by operations proper to it.

Now any of these disciplines can be had without taking the whole Smalltalk or C++ package—many of them predated object-oriented technology. The attractiveness of object-oriented approach is that of a multivitamin pill: in one fell swoop (that is, programmer retraining), one gets them all. It is a very promising concept.

Why has object-oriented technique grown slowly? In the nine years since “NSB,” the expectancy has steadily grown. Why has growth been slow? Theories abound. James Coggins, author for four years of the column, “The Best of comp.lang.c++ ” in The C++ Report, offers this explanation:

The problem is that programmers in O-O have been experimenting in incestuous applications and aiming low in abstraction, instead of high. For example, they have been building classes such as linked-list or set instead of classes such as user-interface or radiation beam or finite-element model. Unfortunately the self-same strong type checking in C++ that helps programmers to avoid errors also makes it hard to build big things out of little ones.

He goes back to the basic software problem, and argues that one way to address unmet software needs is to increase the size of the intelligent workforce by enabling and coopting our clients. This argues for top-down design:

we design large-grained classes that address concepts our clients are already working with, they can understand and question the design as it grows, and they can cooperate in the design of test cases. My ophthalmology collaborators don’t care about stacks; they do care about Legendre polynomial shape descriptions of corneas. Small encapsulations yield small benefits.

David Parnas, whose paper was one of the origins of object-oriented concepts, sees the matter differently. He writes me:

The answer is simple. It is because [O-O] has been tied to a variety of complex languages. Instead of teaching people that O-O is a type of design, and giving them design principles, people have taught that O-O is the use of a particular tool. We can write good or bad programs with any tool. Unless we teach people how to design, the languages matter very little. The result is that people do bad designs with these languages and get very little value from them. If the value is small, it won’t catch on.

-Fred Brooks, The Mythical Man-Month, pg. 220

Share/Save

Here is the video of the initial announcement along with some juicy technical details:

If you are interested in seeing how your PHP project fares when run through HipHop, check out the official HipHop project page.

With tools like HipHop, scripting languages like PHP are no longer subject to the charges of gross computational inefficiency. In short, it’s a great day to be a web developer.

Share/Save

After doing some digging on the web I found out that Troy over at Crosswire had already begun a project named “bishop” whose aim was to provide a Java native interface to the sword library. Just what I was looking for!

While the process of building the library and corresponding java source files is more than what I want to get into here (though I may later on as I hopefully help contribute to the maturity of the project) I wanted to share my findings with anyone else who, like me, is interested in bringing more open-source Bible applications to the Android platform.

So without further ado; Here is a jar file and corresponding JNI library you can use in your own Android project to harness the power of Sword in your own Bible-related apps.

1. Sword is an excellent suite of libraries for accessing a large array of Bibles and Bible-related modules stored in an open format.
2. The fault here was not with the JSword project per-se, the fault really lies with the limited Java environment provided by the Dalvik JVM.

Share/Save