I'd definitely say that seeing libraries like this reminds me of what it was like to be a Rails developer in the early days. It's awesome to see concepts ported over to what Ruby does so well, providing clean and beautiful alternatives to what's been around for awhile.
I was trying to develop a similar library, but realized that I would need migrations pretty quickly. Do you have any ideas about the best way to do database migrations?
That's not necessarily a bad thing: if you're like me (seasoned Objective-C developer, and only the briefest exposure to Ruby) it's quite informative.
A lot of talk about RubyMotion has been about how Ruby developers and those who aren't familiar or comfortable with Objective-C can develop for iOS. I don't see why it can't work in the other direction as well: a nice entry point for people familiar with Objective-C looking for an easy-in for Ruby.
Sure, that could be a pro of RubyMotion, but then that's not the goal.
I develop in Objective-C as well, and I am very interested in what RubyMotion will bring to the table. So far, what I've seen is typical Objective-C code translated to Ruby. That doesn't offer me any advantage. What I want to see is something that will significantly boost productivity. REPL seems like one of them, but I want to see something on the code level.
I don't think diving into RubyMotion without knowing iOS API is that overwhelming; my only first hand experience with Objective-C was when I tried to submit a very small patch (2 lines) to open source project, yet I still found RubyMotion to be very easy to work with.
There are few things I wish it was simpler (e.g. Core Data) but I guess this will be fixed over time with RubyMotion wrappers and some kind of DSL.
This is RubyMotion's biggest problem right now. All of the examples are nearly 1:1 of ObjC code, and they require you to already know the iOS SDK. For someone who already knows Ruby and iOS programming, it might save a few keystrokes here or there.
This specific example saves some code over building the app from scratch in straight ObjC. But, you could get the same savings with a regular ObjC library that does the same thing, too.
20 comments
[ 3.5 ms ] story [ 49.6 ms ] threadIt's an Active Record(ish) syntax layer for the Parse iOS SDK.
I'm developing an education app and would love for it to be in Rails. Know where to find a good Rails coder comfortable with RubyMotion and iOS?
The thing is, when you create a table view in iOS apps, most of the work is for design and interaction like swiping to show a set of controls.
But you're right, there's a lot of work to do to support the concerns in a real app. I'm looking forward to it.
A lot of talk about RubyMotion has been about how Ruby developers and those who aren't familiar or comfortable with Objective-C can develop for iOS. I don't see why it can't work in the other direction as well: a nice entry point for people familiar with Objective-C looking for an easy-in for Ruby.
I develop in Objective-C as well, and I am very interested in what RubyMotion will bring to the table. So far, what I've seen is typical Objective-C code translated to Ruby. That doesn't offer me any advantage. What I want to see is something that will significantly boost productivity. REPL seems like one of them, but I want to see something on the code level.
There are few things I wish it was simpler (e.g. Core Data) but I guess this will be fixed over time with RubyMotion wrappers and some kind of DSL.
This specific example saves some code over building the app from scratch in straight ObjC. But, you could get the same savings with a regular ObjC library that does the same thing, too.
Why are we OK with this conflation of language for marketing gimmicks?