Tag Archive: The project


hurdleA happy new year to all! May we all join in peace with the shared knowledge that for the next month we shall all be writing “20134″

The reason I put “Vacation” in quotes like that, is that when you are the sole coder on a project of your own devising for your own release for your own product for your own (intended) revenue. The only think that delays said revenue is said sole coder. So you find yourself working even when you say you won’t.

This week was predominantly learning Java and Servlets. I would be a fool to say that I’ve learnt it all. But, I seem to now have enough under my belt that I am successfully using Eclipse, making a minimal number of Syntax Errors per revision, pushing the class to the Tomcat server, and seeing the fruits of my work.

And what are said fruits?

Originally my client was pulling data from a JSON file that I belched out from a program that made the data than I entered by hand. This JSON file was a static resource that had to be kept up and verified with each data modification. This was a painful process.

Google-r Bruno Oliveira puts this very well: (click for a larger version)geeks-vs-nongeeks-repetitive-tasks

 

When left to our own devices, we will try to simplify long and annoying process. We may do so through some even more annoying process, but the payoff is ginourmous.

Last week I had a monolithic JSON file with every bit of data in one place. This week, I now have a MySQL database with the data broken into different tables and a Tomcat Servlet, making the necessary calls to create only enough JSON data  populate the view on the client. This is reduce some major overhead and going forwards will allow far better expandability, data management, and communications scaling.

Ain’t net tech awesome in the 2010s? This is so much better than trying to compress user level data into a few bits in a byte because you only had 400K to store your data and your BBS.

Important Java tip:

In a try-catch-finally block, finally is always called.

Do not assume that you are in finally because your try threw an exception. Cleaning up resources that you built in try during finally will really make your program fail.

300px-Tomcat-logo.svgWith the holidays, the usual entertainment segment of the blog has been on holiday. We do promise not one, but two post Sing Off wrap-ups. I’m pleased to announce that many of you really seemed to enjoy the Armchair Judge; so we’ll be bringing her on as permanently as she wishes to participate.

But onto the project. Code in the project itself was fairly quiet. I put in some analytics and testing libraries to allow me to start getting the alpha into people’s hands to abuse and give feedback. In doing so there’s been a lot of Product Management and Software Management going on. As always, read the following “We’s” as the pre-corporate “I” 😉

We’re now running Jenkins, Bugzilla and Tomcat on our internal servers for the purpose of building, running, and monitoring our software. We’ve added in hooks for Flurry and TestFlight to make it easy to track usage, take feedback, and distribute alphas. I have been re-doing the company’s NDA so we can send out the alphas to people. Also, we’ve put dual 1TB RAID’ed drives in place for data security as well as system backups. We’ve been running gitolite for SCM. All of this is running on OS X 10.8 + Server on a Mac Mini. So updating that to 10.9 will be an experience.

I’ve also given the app to our first Alpha tester. In the first evening we got two bug reports (S, You rock!) as well as a few unanswered feature questions. I’m more than happy to get more testers like this! Further, I did do some coding to create a data entry front end application to let me enter and validate data more easily.

So, currently I am looking for Java folks who’ve done Tomcat, general hobbyist programmers who might like to do some pre-financing work, and testers. Feel free to drop a line on this. 🙂

Well, it’s back to Tomcat for Dummies for me.

More soon!

progressThis is going to be short and sweet. But after a few days of being utterly distracted with other things on the blog and endless phone calls today; I got the live data from the server to show up in the app. It formats correctly and even sorts on the fly.

Now we’re cooking!

confused cat huhWell, it was bound to happen working on all the backend stuff today. Once I knew that I was reading the data in; today it was all about putting the data in a commonly accessible area; formatting the data for different calls; and then letting those calls bask in the glory of real data.

At least that was the plan. (Hang on kids, it gets technical now)

Originally, the data was pulled in at app startup using the call:

sendAsynchronousRequest:queue:completionHandler:

Then I moved that out of the startup system and into its own data management class. All was going along well, but I couldn’t get the shared data where I wanted it. So I decided to pull out the big guns. We call that “Gang of 4.” This is the bible of software design patterns. I reached into the tome (well, not actually; as I don’t really need the book as much anymore) and called on one of my favourite (albeit most overly used and accursed) patterns: The Singleton.

The singleton, is muchly like building a cookie cutter for a one of a kind cookie. You take great care in making a cookie cutter, which could make lots of cookies; but this one is specially crafted so that people will simply have to share the one (and only one) cookie it will ever cut out.

That’s when life got weird. Suddenly the call above stopped working. It didn’t cause an error; it didn’t complain; it didn’t throw a wild exception and crash the device… It just blithely skipped over it.

I tried wiping the object files and compiling fresh. That didn’t work. I tried changing and maintaining the queue. That didn’t work. I changed how the singleton was instantiated… Nope. Just weirdness all around. Sadly; I got to this point about 30 minutes before I had to leave to pick up my boy from school. (My spouse got the flu). I figured, Okay… I guess I’ll spend 3-4 hours fixing it more tonight.

This also would not come to pass because I also am deeply invested in the show “The Sing Off” and have been writing reviews and analysis…es…(plural?!?!). Granted, if you read this blog… which you are at the moment (take my word on it) , then you probably have noticed a few of those posts.

So tomorrow: I have to write my Sing Off review from tonight, spend about 5 hours figuring out why the API took a hike, and then gearing up for the penultimate episode of the Sing Off. Oh what a hard life I lead at the moment. Honestly, I’m hoping that it’s 1 hour of fix and 4 hours continuing to get the real data in the app.

Oh, and to those who said they’d be interested in testing once I get to the iPad; Please remember that iPhone apps run just fine on the iPad and you can test them early. (Yes, S… I’m looking at you first and foremost 😉

We’ll figure out what went kerschlump tomorrow. I’m going to actually try to get some sleep tonight.