HTML5 Databases & Palm Pre Development

Recently I have been working on a Palm Pre project in the Obtiva Studio. A feature arose where we needed to know if the user had arrived in the application (or at a certain page with in the application) for the first time. After doing some searches we discovered that the Palm Pre supports HTML5 which allows for some pretty awesome database setups and calls.

So here is what our code looks like:



We needed to use this code at two different places on the application and so pulled it out into it's own class. The initialize function does just what you would think it would do, and the beginning of the new interesting stuff is on line 4

this.db = openDatabase("Database Name", "1.0", "Display Name", 10000);

This openDatabase command is a new HTML5 window method, so it starts to get interesting. This method takes 4 things:

1. The database name: here brillantly named, Database Name (I didn't say it had to be interesting)
2. The version of the database: 1.0
3. The display name: Display Name (again....interesting naming isn't the game)
4. The estimated size in bytes of data that will be stored in the database: 10000

Now, we move on to some more interesting things, and what to do with this now opened Database. We need to note if the user has been at that particular page in the past, and if they haven't then they need to see different information than a user that's been around the block a few times.

The two things we did were to call a transaction on the database object and then execute some SQL statements on that transaction. All the interesting happens in these lines:



In general to execute the SQL you do this:



Where the function(tx,result){} is going to hold the action of what you want to do if the SQL instructions passed and likewise the function(tx, error){} will hold the instructions of what to do if your SQL fails. In our case the error actions are just logging the error messages while the successes are dealing with figuring out if the user has been to the page before.

We didn't get any deeper into the HTML5 database things, but being able to create databases and check for users on the fly was a fun and exciting find.

Don't Mix Your Mocks!

Yesterday while pairing with Jake Scruggs we came across the strangest problem. We added in some tests for a new component that we were adding, and were going to check the new code in. And what do you do before you check in boys and girls? That's right! You run your specs. So we run the specs and all of a sudden there are two failing tests. Wait....what? Those tests aren't even near anything we changed

So we did the poor man's roll back by commenting out every line of code that we had changed, and ran the specs again. Still two failures. We did some rubber ducking with Dave Hoover, who tried to just comment out the failing specs. We ran the tests again...Now there were 8 failures. What the What? Commented those back in....and now we have a total of 10 failures. We had everyone on the project get up to date and run the specs. Every single person had a different number of failing tests.

It came down to the fact that somehow we had two different mocking frameworks in place. We had some rspec tests, and we had some mocha tests. They lived in harmony for a long time and then all of a sudden...KABOOOOM. The tests looked like they were trying to overwrite class methods and so I guess the two different fameworks started bumping heads. We moved everything to the rspec mocking model and everything was back to playing nice.

So. In short. Make sure you keep an eye on what mocking framework is being used in your project and stick with it. Strange erros indeed!

Find via Terminal

So you need to find a file quickly on your machine. If you are in the terminal do :

mdfind file_name

It's like using Spotlight but within the terminal. It's really fast and a nice way to find files that you need quickly.

Oh...You're Using RSpec and not TestUnit?!?!

Oh no.....but then when you do

script/generate controller NewController

you generate tests in the test unit folder and not the spec folder and it's a pain in the bottom as doing the generate thing is suppose to save you time and not waste it.

But it's a simple fix and because it's Friday my tip isn't going to be that awesome. But now I remember it and that's all that matters...and thus it is awesome.

script/generate rspec_controller NewController

This will then generate everything correctly for you and your bottom won't be in pain.

Git Stashes

You know you like your stash, who doesn't? But when you stash, the simple way git stash it gives you these ridiculous titles so if you had more than one when you do git stash list you would see things like:

stash@{0}: WIP on branchname: 9cb5fe9... Merge branch 'branch' of git@github.com.....

What the hell is that? What is on that stash?

If instead you did git stash save "comments describing this stash"

then when you did git stash list you would see

stash@{0}: On branchname: comments describing this stash

To get the stash off, and you do git stash apply, it pulls off those changes but it leaves the stash in place so you would still see it if you did git stash list. To get the stash off AND delete it do git stash pop instead (think of it poping off the list of stashes).

LeahC hasn't had to use mulitple stashes yet....so no word on how to take advantage of that.

Importing SQL Databases

I was working on merging in a branch to our master branch and did rake db:migrate like you do when people have added in some migrations. My pair and I realized that the branch was not ready for merging as there were still a lot of failing tests and so decided to leave it to the person working on that branch to fix.

So there's the pre-story. Now my database was all screwed up and so all the tests back in master were failing because things like "user_name" was changed to "user_firstname" and so on. So I did

rake db:migrate:reset

This is a pretty strong reset and deletes everything....so know, "With great power comes great responsibility"

To get my system back on track we did a sql dump of all the data that had been added and to add it back you do the following (one of many ways):

1. Download the sql dump file
2. Go to the folder where the file is
3. Go into mysql
4. show databases;
   
5. use database_name; (where "database_name" is the one you want to repopulate)
6. source filename.sql; (where "filename.sql" is the sql dump)
   

That's all there is to it.

Obligatory "Welcome" Post

I am a software apprentice at Obtiva.

I tend to not remember things unless I do them 800 times and thus need to keep going back to the master programmers to ask how to do the little things or spin my wheels for too long to do some little task.

Hence

"Tips From a Software Apprentice"

...more like,

"LeahC's notes to Self"