The good: Lovely and simple design. The person that designed the transition animation deserves a very cold beer.
The can be better:
1. I was disappointed that I would be required to have my partner beside me to take her own part. I would rather have her download the app and answer her questions after I have sent her the link which would have only the questions I answered.
(In that case only the person who buys the app can initiate questions)
2. You should be able to skip questions for later.
I am sure you are planning to have much more questions. I am sure you could use the same code to make a version for friends you want to ask some questions.
Hey! An idea just poped into my mind. maybe a version for potential co founder with questions like: If you got a million dollars would you wan to sell the startup? :)
1. Yep, we'd love to do this, and is on our to-do. You could sneak in a cheeky game during work - 5pm may not come fast enough :)
2. Didn't even think of this, thanks!
Re-branding the game to do other things in a related field is definitely on our to-do as well, and yes you are right the code (plus some minor changes!) would suite well for other question content.
We cut several features we would have ideally liked in there (like your first suggestion), but though we should get it out the door ASAP.
I read a post on this site ages ago about someone spending a month working on billing code for a site that never got a customer (I've been there...!) so wanted to try and avoid that first. I suppose that's something you learn when you make the mistake yourself though heh :)
I'd love to hear what you think about the write-up, and whether you can offer any of your own tips on any of the topics covered - did I miss something?
Any feedback on your thoughts as well on any of the points mentioned or what you would have done differently would be appreciated, I'd love to learn more.
Great write up! I really appreciate the clear structure you provided in detailing the various components of your project, as well as the detail in describing the choices you faced and your rationale for the choices you made. I will be using this as a template for my own project :) Good luck!
As a C# developer myself it's also comforting to see you successfully used C#/MVC3 for your back-end, though I'm curious why you didn't use something like MonoTouch for the front-end? Was it to avoid exceeding the 20MB 3G limit (I'm not sure how large MonoTouch apps end up being)? What about PhoneGap or Appcelerator?
Before we started coding, we considered the (pretty cool!) PhoneGap system, but not Appcelerator (which we just reasoned as being similar to PhoneGap) or MonoTouch for that matter.
PhoneGap was considered initially because of course it would be cross platform (write the mobile game once, let it work on both Android and iPhone, plus Windows phone, etc), but we didn't want a less-than-optimal game play experience from a UI perspective.
We felt that it would be less than ideal to play due to the transition animations between screens not performing perfectly (like native apps do) on iPhone, and Android at the time seemed similar (not every phone we tried had perfect HTML5 CSS support etc for animations/rotations).
We then thought that you could tell (from little things like scrolling the window) that the app wasn't native, and it distracted slightly from the game play experience.
It's probably a silly reason, but I'm glad we decided to just write the game native on both platforms after-all, because I got to learn Objective-C and write an iPhone app (and play with Android development), while my friend got to hone his Android app skills.
Considering the game play logic was in the web server, a lot of the heavy lifting was done for us.
Had we decided to put the game play code on the mobile client itself, I'm sure we would have had to re-visit PhoneGap (and implement the game in JavaScript), as we'd certainly not want to write the game play logic twice.
Thanks for the detailed answer :) I had similar concerns about performance and compatibility. I'm not too keen on learning and maintaining code for two separate platforms, though, so I may end up just sucking up the differences so that I can get something launched!
I didn't want to spend too much time with a product name, we were thinking up idea's and Cherry Pop was suggested and it just sounded good at the time.
It had the hint to sex that we wanted, (plus, you're popping your cherry asking some provoking questions I guess!) but also wasn't too generic, so that we could do a brand around it.
A product name is definitely hard, and we're having to tackle the problem of people not realising they should search for 'Cherry Pop' when they want a game like ours - so it's a work in progress.
Well, when I hear the term "cherry popper" it's a similarly titled episode of The Shield that springs to mind. And that episode was all about pre-teen sex while pervy middle aged guys in a seedy club watched. So, even after knowing what the product is, I'd maintain that it's not a well thought out name.
I'd suggest you allow people to answer basic questions for free and ask them to pay to unlock certain questions (more explicit ones). They can may more to create their own questions.
Great documentation. Checking out the Real Time Google analytics feature.
> Unit testing is also made easier by using an SQLite in memory database for several unit tests.
That doesn't sound like a good idea. You haven't tested the code that actually interacts with your PostgreSQL database. It seems that you're placing your trust in nHibernate to act exactly the same when working with SQLite or PostgreSQL.
If I were you, I'd run my integration tests against an actual PostgreSQL database and run my unit-tests against a mock repository. That way, your unit-tests test the actual logic of your app without being slowed down by trips to a database and your integration tests actually tests if your database calls work as expected.
How many tests have you currently got and how long do they take to run?
> That doesn't sound like a good idea. You haven't tested the code that actually interacts with your PostgreSQL database. It seems that you're placing your trust in nHibernate to act exactly the same when working with SQLite or PostgreSQL.
Integration testing is definitely something I do, there's some code there to do a pretend game that runs through the motions as a final sanity check.
I've used a wrapper transaction around the unit test to do integration testing on the real database before (and a rollback after the test ends allows the schema to be left clean for the next test) but this time opted to try SQLite to see if it sped anything up.
In my experience so far, SQLite has been good at being a "mock repository" (it knows its schema from FluentNHibernate mappings), I don't need to hand-feed it what objects should be returned for some tests.
The caution you have about not using the exact database is a valid concern though; but one I don't mind right now, as the core logic I am really testing is responding as expected.
Various tests use no repository at all and are just using mock objects, it depends what's under test.
I currently have 105 tests, 20 second total runtime.
Once again, I haven't used SQLite in a very long time nor do I know anything about what your code looks like but there's a possibility that if you remove your calls to SQLite from your unit tests and use a mock repository, you could reduce that total run-time of your tests from 20 seconds to a second.
One of my current asp.net mvc projects has about 192 unit tests and has a total run-time around 2.3 seconds. Most of the time, the code I'm changing and working on doesn't interact with the database and so I can keep running all my unit-tests after every change to make sure I haven't broken anything. I wouldn't be running my unit-tests as regularly as I do now if I knew I'd have to wait 20 seconds each time.
Give trying using a mock for the test that involve SQLite when you find some free time. You may find the time saved to be worth it. I'd also suggest looking into dan_b's suggestion below; a one-line code change to go from in-memory to integration tests sounds interesting and if it works like I imagine it does, I think I'll be giving nHibernate another chance since my last disappointing attempt at using it.
Appreciate it, thanks. I definitely have tests that run instantly because they just use a mocked database, and ideally all of my tests would do that because I agree having them run instantly is so much better than waiting around.
I'm going to be more attentive to how long tests take from now on, and try and avoid a backed DB when possible. Thanks!
This caught my eye "After pushing through a handful of the excellent 193P Stanford iTunes tutorials, I got a bit frustrated from not working directly on my product, so I just fired up xcode and began to develop it and worked out how to do things along the way."
I tend to pick up a book on subject X from time to time and getting bored after a while just repeating code. Fear of jumping in and doing things "the wrong way" is probably the reason. I tell myself that im going to come back to it; and never do.
Do anyone else have any experience on the subject? I have a nagging feeling that this is how most people actually ship product and would love some input.
(Now if this is to much off-topic, let's just downvote this)
It's better to do things the wrong way rather than not doing them at all.
Jump into it. If whatever you build is successful (under whatever metrics that may apply), you can always consider some refactoring once you know better.
> Jump into it. If whatever you build is successful (under whatever metrics that may apply), you can always consider some refactoring once you know better.
Definitely, and that's what I meant by getting frustrated and just wanting to get started.
I've got a product out the door now, this wouldn't be the case if I didn't start sooner.
I've been a developer for a while, I've learned to push through and realise that it wont always be the best the first time around (especially with new software). I've already learned a lot just building the iOS version, so the next app I decide to make would be better. Rinse repeat :)
When you finish one thing, a hundred more things are left to do. I think an important step that I don't see in this blog is your future vision. What are the additional features you'd like to add? How will this impact users day to day? How could this impact users day to day?
Random thoughts I have that may or may not be too creepy: ability to invite phone book contacts? Location based info to see who's nearby and has the app? Ability to post a message such as, "Hey lets meet up?"
> When you finish one thing, a hundred more things are left to do.
Tell me about it! A good skill I've been improving on over time is the ability to say No and cut stuff out :)
As for a future vision, we have a few general plans (some we can't discuss!) but we wanted to also take a break afterwards and see where to go from here.
We want to add some viral features, but its a pretty tough market to advertise in and seek approval as something someone would like to try.
We see this as a game you'd play and laugh at with your partner, but then learn a little something along the way. It's supposed to be playful and ridiculous at times, with an element of seriousness at the end.
It's exhausting marketing :)
Adding social stuff like invite phone contacts, or send messages etc may not fly with our users (I'd be concerned about what an app like this would want with my phonebook!) but its good to think about ideas like that, we may change in the future.
As a solo technical founder building everything by himself (2-3 months now) from the backend (rest api), the mobile apps (both Android and iOS), this is beautiful to read! I hope to have a similar blog post once I launch! Meanwhile, nice work!
Thanks, appreciate the response and good luck with your project. Would love to read your experience too.
I've developed the iPhone application, the entire website you're reading (and back-end REST JSON API), sorted out business registration, large amounts of research on how to do each step (how do I do marketing? How do I test iPhone apps? What laws do I need to comply with?), server setup and management, I helped write some of the Android game as well, plus other things I'm sure I am forgetting.
My partner worked entirely on the Android development, and of course we collaborated with each other on fleshing out the game idea and helped out in other areas too.
I spoke with a designer friend of mine and asked whether she would be interested in working with us - I wanted to make sure she was paid, as we've all worked on projects before :) and so she was contracted to come up with those designs. We really liked how she also helped figure out the "tone" of the interface.
This is probably project #4 I've worked on in 2011, 2 I cut after getting half done (too much work), 1 I launched and made about $100 then stopped it because I didn't market it enough, this is #4.
I'm learning every iteration, I'm looking forward to #5 :)
The good: Lovely and simple design. The person that designed the transition animation deserves a very cold beer.
The can be better:
1. I was disappointed that I would be required to have my partner beside me to take her own part. I would rather have her download the app and answer her questions after I have sent her the link which would have only the questions I answered.
(In that case only the person who buys the app can initiate questions)
2. You should be able to skip questions for later.
I am sure you are planning to have much more questions. I am sure you could use the same code to make a version for friends you want to ask some questions.
Hey! An idea just poped into my mind. maybe a version for potential co founder with questions like: If you got a million dollars would you wan to sell the startup? :)
cheers man!