emilam

I recently returned from a trip to Germany and had a chance to read The Art of SQL, by Stephane Faroult, while on my travels. I picked this book up a while back but ran out of time to read it. I am very glad that I took the time to read the book, and I consider it to be one of the greatest SQL resources I have stumbled upon. This book will remain on my shelf, and I will be going back to it for references for a long time.

Stephane starts from the basics of normal forms and goes onto deep topics such as tree hierarchies. The book does not cover syntax for queries, but instead helps you think about the queries you are righting. For those who have used SQL in the past, Stephane helps better explain how you can use relational theory to improve the speed of your queries. He talks constantly on how you can help the query optimizer and what problems you can cause for the optimizer if you choose to lay your queries out in a certain way.

The book covers many non academic problems that you run into with SQL, and gives you many patterns you can follow to help improve your SQL. Stephane will often show a common query someone would write and then go into detail on what is wrong the query. He then gives alternatives and reasons why the new query would be better. This anti-pattern/pattern approach is very handy because the reader is able to pick up on these patterns and apply them in many different situations. Stephane often gives more than one way to write the query because the speed of the query is not always dependent on how the tables are laid out, but on other criteria such as the amount of data, the indexes, and the filters used.

The only problem I have with the book is that it caters to Oracle, and does not always tell if you the syntax used will work in other DBMS’s. Most of the syntax is very generic and can be applied to almost any relation database.

I would recommend this book for anyone who is working with large amounts of data or just trying to write more efficient SQL. This book will help you think through your queries before you write them and help you become a proficient database user. The chapter on the different way to setup and use hierarchical data is worth the price of the book itself. The Art of SQL is a great book for anyone trying to deal with data in the real-world.

Recently I gave a talk at the Utah iPhone Developer’s Group about listening to user feedback. I’d like to just rehash the idea and summarize what I talked about. I ran a little short on time while giving my presentation and I dont remember if I left anything out. The bulk of the talk focused on different ways we can listen to users, and pros/cons of those methods.

iTunes Reviews -

In my opinion this can be some of the worst feedback you can get from customers. These reviews are focused at other people making decisions about the games. You should never ignore these because they do give a good indicator of what is going on, but do not rely on these as your main source of how you users are doing. It’s a lot of work to review in iTunes, and most users don’t take the time. You need to focus on ways that are easier to get the user to give feedback

In Game Feedback -

Build a feedback button into your iPhone app or maybe a form that submits to the server. The users do have a limited keyboard, but atleast they can give feedback while using your app. They don’t have to go through all the work to talk to you and they feel like you want the feedback. You not only have an another and easier way to get feedback, but the customer actually feels like he is important. We all like to feel like we are important sometimes. This is great way to create evangelists for your app. When you listen and improve your app you will increase customer sentiment and create some evangelist for you app.

The Web -

The web is a great way to get feedback. Yeah the user is away from the phone, and its not as centralized as iTunes, but it is so much easier. Set up a website and create a twitter account. People are probably talking about your app on twitter or are looking for you on the web. Make it easy for them to find you and go out and try to find them. I am a huge fan of Get Satisfaction and User Voice. Create an account on their and start talking to your community and listening to what they want.

Analytics -

Listening to what your user has to say is great, but listening to what they do is even more valuable. Analytics is where you are able to see how much your app is being used or if it is even being used. You can see the most used, abused, and missed features in your apps. Analytics has helped me find bugs and cheats in my game, and I believe every app should have some form of mobile analytics installed. You can easily just track app usage, but take the time to track user behavior. It takes a little bit of effort to scatter the logs around your code, but its worth seeing what the user is actually doing while using your app.

My favorite source for mobile analytics is Pinch Media. I have analytics in Green Wars, and it has helped us add many great features to our game. Like I said, it helped us find a cheat in our game that we could only see because of the way users were using the game.

Take the time to install analytics in your app. The libraries are small and you wont notice any lag in performance at all. It is worth the little effort that is required.

I am a huge fan of customer development, and this continue even after you release your product. You need to continually get feedback from your customers in order to imrpove your product. Pocket God is a great example of this. They have a great product and are staying in the top apps. Their decisions are based upon customer requests because the customers are the ones buying their product. Without the customer are products would be pretty useless. So get out there and focus on building what the customer wants, and then after you release it make it even more of what the customer needs and wants.

Back in February, I attended the CTO Breakfast hosted by Phil Windley, and I was able to learn about a hosted error management system called ErrorStack. I did not get much time to play with it at the time, but I’ve had some free time lately so I’ve been able to put it to use.

ErrorStack is hosted on the Google App Engine, and they give access to your errors through their website and their flex application. I like the layout of the errors on the website a little more than the flex app, but I usually have the flex app open to tell me when I receive errors. They also send out nightly email as a digist of errors received in the last 24 hours. I do like the idea of digest style. I have a filter in my email to filter out all my error emails. Because it gets so big, and its not in my face, I always forget to look in the folder at the emails. These nightly emails are a lot easier to handle and don’t spam my inbox.

As we release updates for our iPhone we do a lot of testing through beta testers. Ive been able to use ErrorStack in my app to help me get the real exceptions and errors that are happening. This is really helpful when I’m not able to see a crash log, or the testers don’t know exactly what they did.

I made a little class to send the errors to the ErrorStack sytem. You just make a call to ErrorStack with your error name and reason. Name and Reason are what NSExceptions use so I use those as parameters. I’ve also added the log to contain the version of the iPhone platform and the version of your software. This is great if you have different versions out with beta testers.

You can download my iPhone ErrorStack Code here.

This can handle exceptions and your own messages. Ive really only used it with my own messages because I don’t have many exceptions thrown. If you wanted to you could do something like this though.

If you saw that I would hope you knew what the problem is, but whatever. This will send the error to ErrorStack sytem which will appear in your stack. I’ve named my variables a little different than ErrorStacks, but they let you call them whatever you want.

When its on ErrorStack, anyone who you let view your stack can view this error, and when you have fixed or recognized the erorr you can clear it off of ErorrStack. This makes it a lot handier than email where you may have 3 people working on the same bug.

I am very impressed with ErrorStack and plan to use it in my future projects. They have pre-written code for Python and Javascript at this time, and I believe they are planning to add more. I recommend checking it out, and using it in your future projects. I would love if someone would write an extension for log4j. Also, If you want an invite I think I have 1 left.

Green Wars has finally been released to the app store. It took a little longer than expected. Apple says 98% of the apps that get reviewed take 4 days to be accepted. Our app took 11 days to get accepted which is not bad, but I would have liked 4.

I broke down yesterday and wrote an email to Apple asking them to please accept our app. It went like this

Hey reviewer

We got a phone call from a man named Richard asking us to change our
description. We did that a week ago, and have received no word on our
app. Could you please tell us what we should.

We waste about two hours of our day refreshing the iTunes connect page
to no avail. Sometimes we break down and cry. We don't have a
complicated app. It is a simple game. We love you, and wish the best.
Please escalate our app review.

Thank you!

Richard actually never said he would call us back or ever get in contact with us again. It seemed like a good trick to pretend we deserved to talk to someone really.

This is the response we got.

Thank you for contacting iPhone Developer Program regarding review time.  Each application submitted to Apple has different capabilities, features, and complexity, which means that individual review times vary. Once the application review process has been completed, you will receive an email notification.

Regards,

iPhone Developer Program

It does not seem as if we did get to talk to someone real so we were a bit saddened. It seems as if the “Program” emailed us back. Im not sure if thats the application or the whole iPhone Developer Program team. If its the team then I’m flattered.

Anyway, This morning our app finally appeared in the App store. Go check it out and download it for free from iTunes. You can also see some pictures and info about our apps over at OrangaTank

Thanks for your support, and please download our app.

I am currently working on an iPhone application that is pulling data from a lot of different websites and bringing them together. It seems a little tedious to parse each website and deal with changes. It is especially difficult to do with website that are changing, and do not have an API you can use instead.

To overcome the lack of uniformity in these websites I used the Mozenda web data extraction system. It does help that I work for them so I do get a free account, but it is easy to gather the data from all the different websites using their tools. They also have a generic API which makes it easy to get all your data with one simple call. Anyway, thats not the point of my post. I want to show how easy is is to access data from the Mozenda API on the iPhone.

To be able to pull data from the API you need to have your Mozenda web service key which and the ID of the view of which you wan to pull data out of. The data comes back as xml and is in a generic format for every view. I’ve created some simple classes in Cocoa to do the xml parsing , and you are free to use it whenever you want. I have been playing with it to pull down data on prices for items at different stores. It made it easy for me to compare prices on my iPhone while I was shopping.

The code is split into three different classes. The class that does all the parsing is the MozendaParser. To use this class you must first set your Mozenda API Key in the MozendaParser.h file, and then make a call to getData with your viewID. The class will also let you do dynamic calls by passing in view parameters. Look at MozendaParser.h for more details

MozendaParser.h

#import "MozendaItem.h"

#import "MozendaView.h"

#define API_KEY @"YOUR API KEY GOES HERE"

#define BASEURL @"http://api.mozenda.com/?Service=Mozenda10&WebServiceKey=%@&Operation=View.GetItems&ViewID=%d&PageNumber=%d"

#define PARAMURL @"%@&ViewParameter.%@=%@"

//	Mozenda Parser

// The parser is used to pull data from the mozenda api

// To use the parser set your api key in the API_KEY constant above and call getDataForView

// passing in a view id to get back a list of MozendaItems

// These items will correlate to the view you have set up with the mozenda system

@interface MozendaParser : NSObject {

	NSMutableArray *list;

	NSMutableString *currentElementValue;

	MozendaItem *currentItem;

	MozendaView *view;

	int parseState;

}

@property (nonatomic, retain) MozendaView *view;

- (MozendaParser *) initParser;

- (void) handleParseStateRootEnd:(NSString *) elementName with:(NSString *) elementValue;

- (void) handleParseStateViewEnd:(NSString *) elementName with:(NSString *) elementValue;

- (void) handleParseStateListEnd:(NSString *) elementName with:(NSString *) elementValue;

- (void) handleParseStateItemEnd:(NSString *) elementName with:(NSString *) elementValue;

+ (MozendaView *) parseAddress:(NSString *) urlString;

+ (MozendaView *) getDataForView:(int) viewID;

+ (MozendaView *) getDataForView:(int) viewID onPage:(int) pageNum;

+ (MozendaView *) getDataForView:(int) viewID usingParams:(NSDictionary *)params;

+ (MozendaView *) getDataForView:(int) viewID usingParams:(NSDictionary *)params onPage:(int) pageNum;

@end

MozendaParser will go through the XML and create a MozendaView which contains meta data about the view, and the data. The MozendaView class has the meta data on what page you have requested, and how many items are on that page.

MozendaView.h

@interface MozendaView : NSObject {

	NSMutableArray *Items;

	int PageNumber;

	int TotalPages;

	int ItemsOnPage;

}

@property int ItemsOnPage;

@property int TotalPages;

@property int PageNumber;

@property (nonatomic, retain) NSMutableArray *Items;

- (MozendaView *) init;

@end

Each row or item returned from the API call is in a MozendaItem which is basically an NSDictionary. The keys are the columns of your view. I’ve wrapped the dictionary and offered some basic accessor methods. I almost used the NSDictionary directly, but decided to make it slightly uniform. You can pull it out if you want to.

MozendaItem.h

@interface MozendaItem : NSObject {

	NSMutableDictionary *data;

}

@property (nonatomic, retain) NSMutableDictionary *data;

- (NSString *)getForKey:(NSString *)key;

- (void) addData:(NSString *) item forKey:(NSString *) key;

- (MozendaItem *)init;

@end

As you can see it is very simple, but it does allow access to the Mozenda API. Currently it does not have any error handling and only supports view support. I do plan on extending the classes and making it a full library to support Mozenda API calls in Cocoa.

You can download the Mozenda API for the iPhone.

I have done some testing with this, but not extensive. If you see any major flaws please leave a comment so I can fix it, and put and update out. I would like this available so people can use this great service on their iPhone apps.

What do you think? Is this helpful at all? Any ideas on what I should change?

Last night Nate, and I stayed up pretty late getting our application ready for the iPhone app store. It really is true that most of your work is in the very end of development. This is my first iPhone app, and first game that I have taken to completion.

I spent most of my day yesterday trying to find memory leaks with Instruments. My biggest problem turned out to be UITableViewCells that I was not reusing, but that the system was caching for reuse. This was eating up a ton of memory overtime because of how often I reloaded them. It took a while but it was fun. I am excited to have it release, and am working on revisions for my next release.

Now I will talk a little bit about green wars. Green wars gets its name and concept from Drug Wars(aka Dope Wars). We originally had the idea to release Drug Wars, but we saw that the other apps trying to get approval were having a hard time so we went with a different theme. The game is a Drug Wars clone for the iPhone, but without the drugs. Instead of buying and selling drugs you buy and sell green products. We have carbon credit bundles, solar panels, hybrid cars, and so on. It has the same flow as the original drug wars, and we have tried to not deviate too much from that. We will see how updates go, and where the users want to take it.

I’m too lazy to upload a lot of photos of the app, but I will upload a couple.

This first photo is the main menu in green wars. As you can guess we went with a simple green theme.

Nothing special just your new game, highscore, and resume.

This is the travel page that allows you to go to other destinations in the game.

The game takes place in the Boston area so you can ride your mass transit to get around.