Build Your Own Facebook - Part 1

Here's a billion mythical dollars - let's design the next popular mobile/social application.  I don't know how long this series (!) of posts will last but I'll at least start with this one.  We're not actually going to build a Facebook, but maybe we'll design some of a similar application, and see how big a problem can get just starting from a small acorn of an idea.

The huge question
A while ago I saw a question on Stack Overflow about building a "basic social application."  I'm summarizing a lot, but essentially the original poster had spent some months (or more) learning programming and has an idea for a mobile+social application and wants to know "what next?"   Original question here if you want to read it: How to Create a Basic Android Social Service.  The question got closed, probably for a variety of reasons, but mainly because it's a huge spectrum of a topic and the answer would not be well-suited for the Stack Overflow format.  I don't know the original poster, but I'm going to assume based on some of his or her statements that the poster is somewhere in the novice category. So a bunch of this article is going to remain high level.

So let's start
What is the application going to do?  (I'll reread the question again...)

• user signup and login (personalization!)
• user profile (so we can get to know them just like FB)
• make posts (what did you have for breakfast?)
• view posts (everything is public for now)
• special sauce (we'll come up with this later)
• use "standard practices"

This list by itself is the basics. This list is also potentially huge. Where do we even begin?  Just based on this list we know a few things.  It's going to be some kind of client-server application.  Although it might be fun to come up with a peer-to-peer social-network application... that might get kind of weird and non-traditional.  So before we get too far, we need to pick a client and a server.  I know you might not care about that and just want to start building the application, but we're building this mythical company from the ground up and somebody needs to decide.

Client platform
Android. That's what the question was tagged as so that's what we'll use.  We could just make this a web application that renders superbly on mobile, but true client applications still (as of this writing) seem to have a quicker, more natural response.

Server platform
This could be anything really but we have to narrow it down somehow.  Since I'm most familiar with Java, we'll stick with that (yes, .Net is a great platform, but we have to narrow the field somehow).  Even after we've selected Java there are still several choice we have to make as we'll soon see.  First, are we going the "traditional" Java EE route using the Java language or when I said "Java" above did you read that as "anything-that-runs-on-the-Java-JVM"?  If the latter, then there are even more choices of language: Groovy/Grails, JRuby, Scala, etc.  For now let's stick with standard JavaEE.

Hosting
Are we going to host this on our own servers (either in-house or remote)?  If not, we can host this in the cloud on  Google App Engine, Amazon EC2, VMware vCloud, Rackspace Cloud, Red Hat Cloud, or probably a dozen others. Most of the choices here will be compatible enough with how we're going to build this application that it almost doesn't matter. Note: Google App Engine is going to be the most different from the rest listed above, but for argument's sake we'll design our application such that it will work almost the same there.  There will no doubt be some economic impact, but we have a lot of mythical dollars so we'll ignore cost.  For now let's just say we'll use some generic cloud provider simply because I don't want to buy the hardware myself.

Application Server
What Java EE application server are we going to use?  I know you probably have your favorite, and for very good reasons. I have a favorite also. Just pick one out of the following list (they're listed in alphabetical order to avoid personal bias): Geronimo, GlassFish, JBoss, Jetty, Tomcat, WebSphere, probably a bunch of others, too.  There are a lot of choices here but just like the hosting, it almost doesn't matter.  Sure, one of them is going to perform better than another one, but if we write our application correctly we won't be tied to any particular app server (maybe just one or two config files different.)  Another note: if you picked Google App Engine from the previous paragraph, you don't need to select which Java EE app server.

Database
What database are we going to use?  The original poster tagged the question with "mysqlite" but may have conflated SQLite (for Android) and mysql into one.  For on-device storage for the Android client portion of our app, we'll of course use SQLite, but on the server we could use anything.  MySQL, Oracle, SQLServer, Postgress, DB2, HSQLDB, CouchDB, MongoDB, Amazon SimpleDB, etc.  Seriously the list is too huge and there are a lot I'm leaving out unintentionally, except for Sybase which I'm leaving out intentionally, but don't ask me why, it's personal.  A big choice here is whether to use a "traditional" relational database, or a non-relational one.

What's next?

We've barely scratched the surface and haven't actually designed the application yet!  Where do you want to go in the next installment?  Probably the server side.  Stay tuned.  Also, please leave comments if you have suggestions on things I left out or other topics I should cover.

See Also
For additional reading: Teach Yourself Programming in Ten Years

Immortalized in the Commit Logs

My name is now logged forever in the commit comments of a pretty Awesome Project!

Have a look at the commit log for yourself (look for my name next to "NPE").

Here's how it happened: One quiet evening in June I was looking at some code diffs of that Awesome Project (don't ask why) and saw something that didn't look quite right. Keep in mind all I was viewing was the diff so I didn't see the full context of the code. Here's the snippet I noticed:

if (varTable == null) {
    if (DEBUG) System.out.println("resizing from " + varTable.length + " to " +  getMetaClass(). getRealClass(). getVariableTableSizeWithObjectId());
    // lots more code...
}

Do you see the NullPointerException? The code just checked if varTable was null, then proceeds to dereference it. That just can't be right. I double-checked it and then finally looked at the whole file. Then I saw it, the DEBUG flag is set to false way up at the top of the file. That's why the lurking NPE never causes a problem. So what's your opinion? Is it a real bug? The code will never get executed so it's not really a problem. Is a NullPointerException still a bug if it's located in a block of unreachable code?

In any case, I thought I should at least alert @Headius, the guy who wrote it. The fix went in the next commit and he put my name in the comments! If I ever see @Headius speak at a conference I'll see if he'll autograph the commit log.

a reasonable implementation of prime number checking

Once again prime numbers on my mind, but this time I won't write the program in BASIC like I did 20+ years ago...

So here we go, a quick implementation in Java, and yes, I'm assuming non-negative input:

public static boolean isPrime(int n) {
    if (n==0 || n==1) return false;  // careful!
    for (int i=2; i<(n/2)+1; i++) {
        if (n % i == 0)
            return false;
    }
    return true;
}

Originally I ran the for loop all the way up to n, but half-n will suffice. There's another efficiency improvement that can be made to the algorithm, I didn't have it in my head until reading it on StackOverflow. Also there's some interesting reading material on Wolfram MathWorld.

Reading for Inspiration and Motivation

I just finished the book Rework by Jason Fried and David Heinemeier Hansson (see also 37signals). It's really inspirational. One of my favorite parts of the book is from page 38.

"What you do is what matters, not what you think or say or plan."

This is the year to release whatever you're working on in your spare time. Even if it's small. Even if you're not sure anyone will use it. Release it. Get it out there now.

Also on the same page

"The original pitch idea is such a small part of a business that it's almost negligible."

That sentence seems even more relevant if you've seen The Social Network.

The book isn't very long. I'm sure there will be some parts of Rework that will hit home for you. When I read this book again next year there will probably be some different parts that speak to me.

What book(s) have you read recently that inspired or motivated you?

Using Javadoc to stay healthy

Do you Javadoc ™ ? IDEs make it easy enough to create skeletal Javadoc comments in your code, so you probably (hopefully) have at least some Javadoc documentation. But when was the last time you actually ran the javadoc tool on your code to look at what it creates? It's been a while since I've run it on the codebase at work so I thought I'd give it a try. In doing so I found a couple nice gems.

Javadoc Gem #1 - Finding Stale Code
I found some stale code thanks to the {@inheritDoc} tag. The output from running javadoc alerted me to the fact that a few implementation classes had the {@inheritDoc} tag but didn't have a corresponding method in their parent (either interface or abstract class.) Since we (almost) never go straight to the implementation class, a quick search through the code found that those methods weren't being used anywhere except in a JUnit test. (So even though we aren't actually using the code at least it's well tested!)

BlahBlahBlahImpl.java:41: warning - @inheritDoc used but 
staleMethod() does not override or implement any method.

Javadoc Gem #2 - Nonstandard Copyright
I learned that the @copyright really isn't a valid javadoc tag. Yes, I actually looked it up in the javadoc reference and it's just not there. I don't remember who the first person on the team was that started the trend of using that, but apparently it's not right. Another quick search of the code showed that we used it 343 times. Hmm, should I just do a global search and replace? Better yet, maybe we can just redefine reality. There's a way to declare a custom javadoc tag and was easy enough to declare the custom javadoc tag in the maven config too.

BlahBlahBlah.java:11: warning - @copyright is an unknown tag.

Lessons Learned
I'm not one to shy away from stating the obvious, so I'll list out some lessons learned from this experience:

1. Tools are more useful when they're used more than once every 3 years. Yeah, it's probably been that long since I generated and looked at javadoc.
2. Comment the code as I go. It would be kinda painful to go back now and figure out what all these uncommented methods are doing. Sure, I can probably guess what a method does from the name, but it would be nicer to have some context to go along with it. Apparently at one point we found this to be useful: Set<Long> toLongSet(Collection<? extends Number> numbers)
3. Find a better way to detect unused code. I'm sure there's some tool out there for this. Got any ideas?

Java 7 Features, the Future can't come soon enough.

If you're like me, perhaps you wish the future was here already. A flying car would be nice and all, but I'll settle for the next version of Java.

For anyone who hasn't seen it yet, here's the planned list of Java 7 features.

The official JSR #336 for Java 7 is worth a read, though it's easy to get distracted by the Fork/Join Framework and veer off to read more about that. And since we're on the topic, if you've never heard about Parallel Arrays, you should learn something about that. (Okay, now I'm just talking to myself).

So even though the future isn't here yet, we can make it arrive sooner by downloading a current binary snapshot release of JDK 7 to kick the tires and try it out.

Let's get started.

Time to Reminisce - Computing Prime Numbers

Set the WABAC Machine for the late 1980s...

What's the first long running program you remember writing? One summer at the high school computing lab I saw the room full of PCs were sitting idle and thought it would be fun to write a program that would run for a long time.

Two math problems came to mind: 1. find prime numbers less than a bazillion, 2. compute pi to a bazillion digits. I chose the first one mainly because it would be relatively easy to verify. After all, if I found the 904th digit of pi was a 2, how was I going to verify it?

The only language I had available to me at the time was BASIC. Don't judge - that's what the school had and that's all I knew at the time. I didn't have much of an algorithm for finding primes, but I had a trusty For Loop and a lot of time. I don't think I have the code any longer, kinda wish I still did so I could try it now. My method was pretty simple: Increment a counter to the next number, start a loop up to 1/2 of that number and see if it divided evenly (quick, tell me what the big O notation of that would be). I'm sure there are better ways than just a loop inside a loop but this was a long time ago... You kids these days with your Google could probably find me a better algorithm.

I knew this program was going to run for days and could be subject to interruption (such as being unplugged by a janitor) but wanted to keep a good record of my results. My immediate choices were to periodically save to a file or send a line to the printer. Saving to the 5.25" floppy would have been fine I suppose, but I chose to use the printer because the progress would be more visible and permanent. After finding 10 prime numbers, my program would send one line to the printer listing them.

It ran for days (maybe a couple weeks) before it finally was interrupted. Every so often the printer sprang to life and added one line of prime numbers. Obviously it was quicker with the smaller numbers because it had smaller numbers. Eventually my program filled about 6 or 7 pages. I don't really remember how far it got, but I do remember being rather proud of the result. I taped the output up on the wall in my bedroom - I should call my mom and see if it's still there.

On the next episode of "Time to Reminisce" maybe I'll talk about the first program I wrote for somebody else.