I posted this because it is one of the first games to get me excited since FTL. I really love what indie game devs are doing now days. You would never see this from a big design shop, but I would play this as is.
I am in the exact same situation. I know Ruby, as my first language, but keep running into scientific applications where Python or R is used. The languages are so similar, it is pretty easy to move between the two at a superficial level, but does take away some bandwidth trying to stay current in them both. It seems that if you are going to do web based work, Ruby is a good choice, but it you are going to be actively involved in non-weby stuff, Python is a better choice. I say this as a dedicated Ruby guy, who would rather stay with it, but am being pushed into more and more Python....
Does anyone know if a similar API exists for patient billing records? I see the OP API provides information on claims, but those are not necessarily detailed bills. I would assume that the answer is no, due to the many forms such bills could take. I am hoping they are required to have/provide an electronic bill in a set format, perhaps for medicare reimbursement purposes? Thanks......
Nation States that employ offensive cyber operations will NOT stop at only targeting computer infrastructure. Many technologists/hackers naturaly like to separate the world into two spheres (the so called "real world" and the "online" world), somehow thinking that they are above the physical fray. The truth is that hackers and security professionals on all sides will increasingly expose themselves to physical attacks like this. Any militarily sound employment of cyber warfare will include a physical attack component, whether covert or overt, depending on the current stage of the conflict.
I completely understand and agree with your comment re: the importance of the APIs, but I think the big win is going to be the Ruby DSLs built on top of the tool kit to make the APIs easier to use - for RubyMotion's intended audience (existing Ruby/Rails Devs). This is just the first step.....look six to twelve months out with an active developer community and think where this project could be.
In my opinion lot of these threads completely miss the point of a tool like RubyMotion. It isn't about which solution is "better"...it is about ease of use for the large number of people that already know Ruby, and want to leverage that knowledge into exploring IOS development. Not everyone has the time or inclination to learn Objective-C right now, even though we can all agree that learning other languages is a good thing. This clearly scratches a market itch, will be supported by a great community that will layer tons of syntactic sugar and cleaverness over any verbosity/UI tool problems, and will likely grow into something truly great for the market it seeks to serve. I think it makes for one hell of a 1.0 MVP release.