Risk/Reward 1.2 Out
Risk/Reward is now available on the App Store. The new version has been updated as follows:
With version 1.2, Buy Price has been changed to Share Price, as share price is more accurate, especially when short selling. Thank you to a very loyal Risk/Reward user for suggesting this change!
Also new in 1.2, the app now remembers the last value for Cost To Trade, as this cost is most likely to stay the same from trade to trade. This way you do not have to enter this value each time you use the application. Once you enter a value in Cost To Trade, it stays at that value until it is changed.
Version 1.3 will be out in the next few weeks, and this version will allow you to shake the phone (if you have an iPhone) to clear the input screen.
Why not LDAP?
I just read Evan Weaver’s blog post about Improving Running Components at Twitter and I just have to ask: “Why not LDAP?”
Let me start by saying that I do not work at twitter, so I really have no idea how they put things together there. Reading a bunch of articles on the web is not going to give me the full picture, either, so I might just be completely off-base with this post. However, I do know LDAP (very well actually), and it seems to me like a lot of the performance problems twitter is constantly trying to solve could be best handled using LDAP.
LDAP not just a fancy white page system. If it was, I don’t think Verison would stake the business of its entire 75 million wireless subscribers on it. LDAP is designed to scale, and it seems perfect for what twitter is doing (at least for 1/2 of what twitter is doing, as messaging is probably appropriate for the other 1/2).
So, from a “backseat driver” perspective, I would suggest that twitter consider doing the following:
- Put all users in LDAP. So, this means that I have one LDAP record like, uid=lucasrockwell,ou=twetters,dc=twitter,dc=com
- Put the people each user is following into groups — one group per user. So, now I have a group: uid=lucasrockwell,ou=groups,dc=twitter,dc=com, which is made up of hundreds to thousands of “uniqueMember” attributes, each pointing to the DN of another user.
- Do queries against the groups to figure out who I am following, and who is following me.
- Break out the ou=groups and ou=tweeters containers into smaller containers based on username if you have too many to fit on one server. (LDAP was designed for this.)
- Use LDAP proxy servers to figure out where the user is located, and send the traffic directly to that server (or cluster of servers).
- Of course, run it all in memory. (Again, LDAP was designed to do this. Or, should I say, modern LDAP servers were designed to do this.)
Of course, this does not address the actual tweeting, but for that, I would think they would want to use a messaging system. Tweets do not need go in LDAP. They could, but that is a lot of writing to a system that is designed for fast reads. But, given the flexibility of LDAP, its ability to do fractional replication, multi-master replication, and logical separation of data into different physical servers, all while making it look like one monolithic system from the outside, I think they could probably solve most of their design needs with LDAP.
If any twitter people read this: If you have looked at LDAP and it was deemed not appropriate, I would love to know why.
My iPhone App Experience
After having Risk/Reward on the App Store for a little over 2 months now, I thought I would share my iPhone development and App Store experience. I know a lot of people have already done this, but perhaps this post can add something new (but you can be the judge of that).
What to make?
Like a lot of geeks, I really wanted to make an iPhone app. However, not having any gaming or advanced graphics experience, I was really at a loss for what to make. A lot of the useful things I could think of had already been done, and done well. I finally came up with the idea for Risk/Reward when I actually wasn’t thinking about making an iPhone app! I was closing in on the end of Van K. Tharp’s book Trade Your Way to Financial Freedom when I decided to apply some of the principals in the book to a few of the trades I had done in the past month or so. So, I took out a piece of paper and started doing the calculations. About 5 minutes later I said, “iPhone App!!!” And with that, I started on my iPhone app development journey.
Getting Started
The first thing I did was get the SDK from Apple. I have been a long-time member of the Apple Developer Connection, so I just logged into the iPhone Dev Center, and downloaded it. Once I did this, it was tutorial and sample code time.
As great as the Apple samples are, they only get you so far, so I searched for iPhone App tutorials online. At this time — back in September 2008 — the iPhone/Apple Developer agreement restricted what could be said/written publicly about the SDK, which meant examples on the internet were scarce. I was fortunate, however, to come across iCodeBlog (which I highly recommend) which had some pretty good tutorials that allowed me to really understand how an iPhone app is supposed to work. Although I had no ObjectiveC experience at this point, I did have a leg-up on the total newbie because of my WebObjects (WO) experience. Even though I have only used WO in its Java incarnation, Apple actually ported the entire ObjectiveC framework to Java, NSMutableArray and all. This meant a lot of objects and collections were familiar to me, and I knew how to work with a fair number of them already. So, I basically only had to learn the syntax of ObjectiveC, which is pretty simple (I happen to love the syntax, so that made it easy for me to absorb it). Oh, and when I did use WO, the developer tools for doing “interface building” were very similar to Interface Builder, so the concept of “click-dragging a line to make a connection” was not at all foreign to me, and I was actually happy to finally be using these cool tools again.
Taking the Plunge
Once I got going, I wanted to test out my app on my iPod Touch (I didn’t actually have an iPhone at the time). To do this, I had to pay my $100 to apple to officially join the iPhone developers program. (The only way to get a “provisioning profile” from Apple so that you can load your app onto your phone or iPod for testing is to join the program.) I really had to be committed at this point, and I thought I was. I mean, why not, how hard could it be?
With all that said, it took me a fair amount of time to write the app. I worked on it after work, on weekends, and on BART while traveling to and from work. Then, when it was done, I just sat on it. Even though I had paid my $100 to join the program, I still sat on it for about 2 months, and for three reasons:
- I knew the next process of dealing with Apple and the iPhone Portal was going to take a lot of time and effort for a newbie
- I wasn’t sure if I would have time to deal with supporting it long-term
- I didn’t know how I would react if no one bought it
Then, on the week between Christmas and New Years, I took the plunge. I spent several hours navigating the Program Portal, getting my distribution provisioning profile, and then getting the app compiled properly and ready to go for the store. This also involved taking screenshots of the app (which have to be to the pixel or Apple won’t except them) and writing up what the app was about. I then set up a website (this site) as the public face for the app, in an effort to let potential purchasers of the app know that I was serious about development and support.
I did all of this and got the app submitted to the App Store on the 30th of Devember and said it should be available on the 31st…then…waited. Everyone who has ever submitted an app to the App Store knows about “the wait”. For some, this is very painful time. A lot of people have spent serious money developing their application, only to have weeks or a month go by before Apple approves it (or even denies it). My app was finally approved and ready for sale on January 7th. Of course, this was partly my fault. Why? Well, I had some paperwork to do that I didn’t realize. In the iTunes Connect application there is an area for financial stuff, and Apple will not release the app until you have all of that stuff (like bank account, agreements, etc.) completed. Of course, once I discovered this was part of the hold-up, it still took me several days to complete all of the items (like making calls to my bank during lunch to get the Swift Code, etc.).
Then, at 10:36 AM I got an email from Apple saying that the status of my app was “Ready for Sale”. I was ecstatic! I went to the App Store and…couldn’t find my app! Yes, the search feature take quite a while to catch up with the submissions, and, because I had put my app for sale as of December 31st, that’s the date it had when it was released. Now, if you pay attention to the dates of apps on the App Store, you will notice that a lot of apps (for any given category) are released in 8 days. So, one release day, my app ended up on the 3rd or 4th page of the Business section. Not quite the impact I was hoping for.
Updating the App
Once the app was out I started telling friends about it. Of course, it’s not like Risk/Reward is a cool game that anyone might be interested in. So, the number of friends who were interested in the app was quite small. One of my good friends, Russ, was eagerly awaiting my app as I had consulted with him about the concept of the app, as he was once a trading software programmer. Soon after he downloaded the app he sent me an ominous email, “Dude, I think your calculations are wrong.” I was completely freaked out. After about 20 emails back and forth, it turned out that the calculations were correct, but the terminology I used was misleading at best. So, I set out to update the app.
It took me several weeks to find time to get the app updated. In this time, purchases of the app had pretty much dropped to 1-2, or even 0 per day. However, those 2-3 purchases a day add up, and by the time I submitted the update, over 60 people had purchased the app. I was pretty thrilled, and it was extra motivation to do the update in the first place. Initially, my only goal was to recoup the $100 I spent getting into the program, so, for a $.99 app, that is 143 apps. So, I quite a ways to go.
I had a freak-out when submitting the update because nowhere on the iTunes Connect site does it say that updates to an existing application are automatically free (I mean, I didn’t people to have to pay again for an update that only changed some wording!). The information in the update section made it sound like people where going to have to pay for the update, and I sent off a rather hasty letter to Apple. Surprisingly, I got a response! Of course, the response was after the update was released (and by this time I had already learned that the update was free).
When the updated version came out (again several days after I said, “Make it for sale on this date”), it landed on the front page of the Business section! It was already half way down because of the date issue, but I was thrilled. And…the next day when I checked the sales report I learned that 18 people had purchased the app the day before! Wow, visibility means something with an iPhone App! The numbers stayed high while the app was on the front page, then started to trail off after the app moved to the second page. By the 3rd page, they had fallen to the 3-5 range…then…I did another update!
Updates
I just now submitted my 3rd update. I hope Apple only takes a day to approve this one and it winds up on the front page of the Business section again (my second update did, too). I already have ideas for the 4th and 5th updates. My goal is to do an update at least once per month, if not once every 3 weeks. I think there are plenty of things to add to my app, and I can easily spread these out over numerous updates.
Of course, doing an update is not just fixing code, especially when you modify the interface! With each update, I have had to take new screenshots and get them uploaded to the store. I also sweat it out because there is a pretty big lag between when you modify something in iTunes Connect, and when it shows up on the App Store. I don’t want to submit my new images before the update comes out, but then I don’t want it to be hours after the update is released, either. The last time Apple told me that the status of my application was “Read for Sale”, it was 1:13 AM, and I was sleeping. Of course, people in the rest of the world are not necessarily sleeping at 1:13 AM Pacific time, and now my screenshots and general description are out-of-date.
I am still working on getting this timing correct, but it remains elusive. For instance, with the last update I thought, “Oh, well, I know it takes Apple 2-4 days to approve an app, so I will say it should be ready for sale 3 days from now.” An hour later I went to check on my app and the App Store said, “This application is currently not available in the US iTunes Store.” Excuse me? So, I had to quickly go in and set the date back to that day’s date!
Summary
In general, I have to say, I have had a lot of fun working on this app, getting feedback from people, updating it, etc., etc. It has been really rewarding, and right now, I am working on my next milestone: Getting paid by Apple! You need to sell $250 worth before Apple will pay you, and for a $.99 app, that means you have to sell 358 apps. I am currently at 337. I hope this latest update carries me over 400 before the daily sales start to trickle back to 2-5/day!
Risk/Reward Listed On Yappler
Check out Risk/Reward on Yappler, which is a web-based collection of all the apps on the App Store.
Please Provide Feedback For Risk/Reward
If you have purchased Risk/Reward, first I would like to say THANK YOU! I really appreciate all of the people (well over 300 at this point) who have purchased the app!!!
Second, if you would put a comment on the App Store that would be great. Of course, positive comments are most appreciated :-), but any feedback would be welcome. I think if more people comment, the more newcomers would see that the app is actually used by other people, which would be a huge benefit to the app’s exposure.
Again, thanks!
Risk/Reward 1.1 Out, 1.2 On Its Way
Risk/Reward 1.1 is now available on the App Store, and 1.2 is on its way.
1.2 will be a minor update, but one that will eliminate a lot of frustration: The “Cost To Trade” field will remember the last value you entered. So, if you always enter $20, then whenever you open up the app, $20 will already be in that field. You don’t have to do anything to set this value, the app will just remember the last thing you put in that field.
Risk/Reward 1.1 Almost Out
Risk/Reward 1.1 is currently being reviewed by Apple and should be available by the end of the week.
This version allows you to do the calculation for a long or short purchase. The interface has been updated with two new buttons — “Calc: Short” and “Calc: Long” — which replace the one “Calculate” button. See the screenshot for the example.
You can do one calculation, then go back and do the other if you want. I debated putting the results for both on the results page, but thought it would be too cluttered, so I opted for the two button option.
The next version (1.2), which will be out in another few weeks, will have a preferences section where you can save default values for any of the fields.
Risk/Reward 1.0.1 Now Out
Apple finally published Risk/Reward 1.0.1 on Feb 4th. This is the write up for the new version:
In version 1.0.1, the term “Trailing Stop” has been changed to “Max Loss/Share” because some users of the application felt that the application is more about protecting against an initial loss than about locking in profits (which is what a Trailing Stop is really for). So, semantically, “What are you willing to lose per share traded?” is more correct when performing this calculation.
Also, in 1.0.1, Info buttons have been added to the right of each field. Just tap on the button and info about the field, including an example, will show up in an alert view.
The next version (due out around the end of Feb./beginning of March) will have two new options: 1) Calculation for when you want to short a stock, 2) Calculation for when you don’t know how much stock you want to buy, but you know how much money you want to spend, and the maximum amount of that money you are willing to loose.
Thanks to everyone who has purchased the app so far!!!
iPhone App Support
If you need help with the iPhone/iPod Touch application Risk/Reward (which was made by Lucas Rockwell) please send email to:
iphone-support@lucasrockwell.com
You can also send general comments/suggestions/praise/etc., to that address as well. And again, thanks for purchasing Risk/Reward!
Risk/Reward now in App Store on iTunes
Risk/Reward is now in the App Store on iTunes. You can download it here:
And thanks to the people who already have! Let me know what you think and what you would like to have added.
Sponsors
