Redcar is cool, but I still can’t use Linux
With the arrival of Redcar, which is a TextMate-inspired “text-editor/IDE for Gnome in pure-Ruby”, Linux is becoming more appealing as an everyday OS. Honestly, I am almost ready to install Ubuntu in a VM just so I can try this out…
As cool as Redcar is, there isn’t one, or even a collection of applications that would make me switch to Linux. Let me put it this way, even if every application I use on OS X worked on Linux, I still couldn’t use Linux as my everyday, desktop OS. Why? Because OS X is the only OS that distinguishes between GUI editing and line editing.
Let’s start with a little background. The Mac was a GUI-based OS from the start, i.e., there was no command line. And because of this Apple, for whatever reason, created a new key on the keyboard: the Apple key (which is still in use today, but the Apple logo has been removed, and everyone refers to it as the “Command key”). There are two Apple/Command keys: one to the immediate left of the spacebar and one to the immediate right of the spacebar. (For some reason, I have never used the one to the right of the spacebar.)
So, what’s the Apple/Command key for? Well, it’s the equivalent of the Control key in Windows and Linux (but only for GUI editing in Linux, and now you can probably see where I am going with this…). If you want to “Select All” in a GUI Mac program, you use “Command A”, whereas in Windows and Linux, you would use “Control A”. Ok, so, great, what’s the difference? Well, what happens when I am writing an email and I want to go to the beginning of the line? Anyone? Anyone? … The suspense is killing me… On the Mac I would type “Control A”! How do I go to the beginning of the line in a GUI app on Linux? Please, you tell me. Oh, right, that special key, which is way out of my way, that had to be invented to do this simple task.
Now, let’s pull out the command line. How do I go to the beginning of the line? “Control A” of course (thank you emacs!). So, on Linux, if I am writing an email in Thunderbird and I want to select all, I hit “Control A”, but on the command line, “Control A” takes me to the beginning of the line… Excuse me? On OS X (and yes, this is with OS X, as (I believe) the only use for Control prior to OS X was the contextual menu support in OS 9), the Command key commands work in every app, and the Control key line editing commands work in every app.
Even in iPhoto, if I am editing the Title of a picture, I can use “Control A” to take me to the beginning of the line, and “Command A” to select all. Same is true for the Terminal (the command line) where I can use “Command F” to open the find dialog box (like on every other GUI app!) and search for something. And yes, “Command A” in the Terminal selects everything in the buffer, and then I can “Command C” to copy, switch over to another program, and “Command V” to paste.
As clean and amazing as this is, the pièce de résistance of this is that the command line “cut” — “Control K” — and “paste” — “Control Y” — both work in GUI apps, too, and uses a separate clipboard than the GUI cut and copy! So, this effectively gives me two clipboards! But, actually, it gives me n clipboards because the command line cut and paste are for that application only, whereas the the GUI cut, copy, and paste are global. So, this means I can use “Control K” in TextMate, and “Control K” in the Terminal, and when I do a “Control Y” in either of those apps, that app remembers the thing that I last “cut” in that application. This takes advantage of the fact that in OS X there are literally n clip/pasteboards.
Some Linux users have pointed out that you can switch to command line-like editing on a per-app basis — the concept is “enabling emacs key bindings” — but when you do this on Linux, you now have to use another key for doing GUI things like “select all”. So, to me, this is not a solution, in fact, it makes things worse because now you have to remember which apps have emacs key bindings enabled, and which don’t.
In closing, until Linux, or more precisely Gnome, KDE, or any other desktop environment makes a clear distinction between GUI editing and line editing, and it is implemented across all of the applications I would want to use every day, there is no way I can switch to Linux. Emacs line editing commands* are embedded in my brain, so are GUI editing commands, and it is a massive (which is an understatement) productivity killer to have them be inconsistent or just outright broken in Linux. And forget about Windows. I used Windows at work for 4 months and thought I was going to go nuts. I switched to Linux and got maybe another 4 months before I told my manager that I either get a Mac, or I’m leaving. (They gave me the Mac.)
* The GUI line editing in OS X is only a subset of the things you can do with emacs/command line. For instance, you can’t do “meta f” to skip ahead one word in the GUI, but for that, you have the “Option right arrow key”, which is universal in all GUI apps on OS X. The same goes for all word, line and page skipping, forward/back/up/down in GUI apps.
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.
Sponsors
