Re: [MacRuby-devel] The Future of MacRuby
tl;dr: I propose getting tutorials and code under one structured collection, and to create classes that wrap Core Data in the same way HotCocoa wraps NSViews. I agree with the sentiments about "setting ourselves apart". How do we do that? Please allow me to pontificate. I apologize for the length. I think we have already answered this question: Cocoa is huge and hard to learn when you are getting started. Let's fix that! Let's make it easy - NAY - FUN to get started. That's what made Rails so darn popular, right? It's not because it was the fastest, or had a long history of support, or zero bugs, or stability. It was FUN. And that's what *Ruby* is about, too! I think we should also show off how "grown up" MacRuby already is. When I saw that there was already a Core Data project template, I was sold. If that *hadn't* been there, I would have balked, for sure, and maybe even walked away. Also, Matt Aimoetti's MacRuby book, and the upcoming book, MacRuby in Action, indicate that the support is out there. I think that HotCocoa is a great example of "fun" and "distinctive development cycle". It aims to be a replacement for Interface Builder. I don't think we need to stop there. We can replace *Xcode*. Hotcocoa already handles compilation, using macrake to run or deploy or embed a project. If we could go so far as to wrap up Core Data into ruby classes, hoohoo boy would we be having fun then! "HotCocoaData" anyone? For my part, I'd like to reach out to those of you that have collections of recipes and tutorials, and start creating a structured repository of these resources (jballanc/Josh recommended using the github wiki as this tutorial repository). I would *really* like it if our tutorials did the same things most do (pushing a button => prints "hello" - WOW!), but then always take that a few steps further. If it is easy to print "hello", why would you stop there? Do something useful, or at least something complicated, that provides food for thought. With help, I think we could create a project that allows us to create Core Data models using ruby code. At that point, *everything* could be done in ruby, but with full access to Cocoa, and then we'd be doing something really exciting. Not that MacRuby isn't already exciting - if it wasn't, we wouldn't be talking about this stuff! #colinta
Compare with ActiveRecord/DataMapper, i really have no love on Core Data. If MacRuby could run all those ActiveRecord/DataMapper adapters, there are few reason to use a Core Data wrapper (much like ruby dev will not ever normally use mysql/postgres gem directly). Certainly if such wrapper follow ActiveModel it would be very useful, but if we can already use AR to use sqlite db, why bother another layer of wrapper? Colin Thomas-Arnold 於 2012年4月9日 上午11:50 寫道:
tl;dr: I propose getting tutorials and code under one structured collection, and to create classes that wrap Core Data in the same way HotCocoa wraps NSViews.
I agree with the sentiments about "setting ourselves apart". How do we do that? Please allow me to pontificate. I apologize for the length.
I think we have already answered this question: Cocoa is huge and hard to learn when you are getting started. Let's fix that!
Let's make it easy - NAY - FUN to get started. That's what made Rails so darn popular, right? It's not because it was the fastest, or had a long history of support, or zero bugs, or stability. It was FUN. And that's what *Ruby* is about, too!
I think we should also show off how "grown up" MacRuby already is. When I saw that there was already a Core Data project template, I was sold. If that *hadn't* been there, I would have balked, for sure, and maybe even walked away. Also, Matt Aimoetti's MacRuby book, and the upcoming book, MacRuby in Action, indicate that the support is out there.
I think that HotCocoa is a great example of "fun" and "distinctive development cycle". It aims to be a replacement for Interface Builder. I don't think we need to stop there. We can replace *Xcode*. Hotcocoa already handles compilation, using macrake to run or deploy or embed a project. If we could go so far as to wrap up Core Data into ruby classes, hoohoo boy would we be having fun then! "HotCocoaData" anyone?
For my part, I'd like to reach out to those of you that have collections of recipes and tutorials, and start creating a structured repository of these resources (jballanc/Josh recommended using the github wiki as this tutorial repository).
I would *really* like it if our tutorials did the same things most do (pushing a button => prints "hello" - WOW!), but then always take that a few steps further. If it is easy to print "hello", why would you stop there? Do something useful, or at least something complicated, that provides food for thought.
With help, I think we could create a project that allows us to create Core Data models using ruby code. At that point, *everything* could be done in ruby, but with full access to Cocoa, and then we'd be doing something really exciting. Not that MacRuby isn't already exciting - if it wasn't, we wouldn't be talking about this stuff!
#colinta
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
When I was still at Apple, I actually started work on a library for MacRuby backed by CoreData, but I had to leave it before it was done. To address the "why" question: CoreData ties in very closely with a lot of the Cocoa UI libraries (and other libraries). It also has features that other Ruby ORMs lack (like the ability to do fuzzy searching using NSPredicates). That said, it is a bit cumbersome if you're used to Ruby ORMs. I don't have time currently to lead such a project, but I think it's an excellent idea and I will answer what questions I can. As it happens, my second Boston.rb talk covered some of working with CoreData from MacRuby… Video: http://bostonrb.org/presentations/macruby-for-fun-and-profit Slides: http://www.slideshare.net/jballanc/macruby-for-fun-and-profit - Josh On Monday, April 9, 2012 at 12:04 AM, Francis Chong wrote:
Compare with ActiveRecord/DataMapper, i really have no love on Core Data.
If MacRuby could run all those ActiveRecord/DataMapper adapters, there are few reason to use a Core Data wrapper (much like ruby dev will not ever normally use mysql/postgres gem directly). Certainly if such wrapper follow ActiveModel it would be very useful, but if we can already use AR to use sqlite db, why bother another layer of wrapper?
Colin Thomas-Arnold ©ó 2012¦~4¤ë9¤é ¤W¤È11:50 ¼g¹D¡G
tl;dr: I propose getting tutorials and code under one structured collection, and to create classes that wrap Core Data in the same way HotCocoa wraps NSViews.
I agree with the sentiments about "setting ourselves apart". How do we do that? Please allow me to pontificate. I apologize for the length.
I think we have already answered this question: Cocoa is huge and hard to learn when you are getting started. Let's fix that!
Let's make it easy - NAY - FUN to get started. That's what made Rails so darn popular, right? It's not because it was the fastest, or had a long history of support, or zero bugs, or stability. It was FUN. And that's what *Ruby* is about, too!
I think we should also show off how "grown up" MacRuby already is. When I saw that there was already a Core Data project template, I was sold. If that *hadn't* been there, I would have balked, for sure, and maybe even walked away. Also, Matt Aimoetti's MacRuby book, and the upcoming book, MacRuby in Action, indicate that the support is out there.
I think that HotCocoa is a great example of "fun" and "distinctive development cycle". It aims to be a replacement for Interface Builder. I don't think we need to stop there. We can replace *Xcode*. Hotcocoa already handles compilation, using macrake to run or deploy or embed a project. If we could go so far as to wrap up Core Data into ruby classes, hoohoo boy would we be having fun then! "HotCocoaData" anyone?
For my part, I'd like to reach out to those of you that have collections of recipes and tutorials, and start creating a structured repository of these resources (jballanc/Josh recommended using the github wiki as this tutorial repository).
I would *really* like it if our tutorials did the same things most do (pushing a button => prints "hello" - WOW!), but then always take that a few steps further. If it is easy to print "hello", why would you stop there? Do something useful, or at least something complicated, that provides food for thought.
With help, I think we could create a project that allows us to create Core Data models using ruby code. At that point, *everything* could be done in ruby, but with full access to Cocoa, and then we'd be doing something really exciting. Not that MacRuby isn't already exciting - if it wasn't, we wouldn't be talking about this stuff!
#colinta
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org (mailto:MacRuby-devel@lists.macosforge.org) http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org (mailto:MacRuby-devel@lists.macosforge.org) http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
I can start migrating the macruby-Recipes repository to the wiki section of Github, but I'd like to make the case they should be in a sub-module or repository that users can download directly, not just view on the wiki. I've started, but have largely failed -- due to a new job -- to "port" MagicalRecord core-data code to mac-ruby, giving us a "active record like" interface to core data. I have some new recipes to add to the macruby-recipes repo (https://bitbucket.org/codefriar/macruby-recipes) that I can push hopefully later today. I'd really love some suggestions on what recipes to add. you can see the ones I have in progress on that repo's wiki. Perhaps we should find consensus on style so various recipes don't look completely different? All that said, I agree with other posts discussing the bugs / missing features we need to find a way to fix/get up to speed. My C/C++/Obj-c is non-existent to rusty at best, so if there are any macruby vm coders who could offload work to me, in order to give them time to fix those, let me know offliist. I was wondering if there would be benefit to writing (a) Generator(s) ala' Rails' "rails" script for the stubbing out of apps and m,v,c ? Imagine: facet new <application name> facet g model <AwesomeModelName!> … Thoughts? -Kevin On Apr 8, 2012, at 11:50 PM, Colin Thomas-Arnold wrote:
tl;dr: I propose getting tutorials and code under one structured collection, and to create classes that wrap Core Data in the same way HotCocoa wraps NSViews.
I agree with the sentiments about "setting ourselves apart". How do we do that? Please allow me to pontificate. I apologize for the length.
I think we have already answered this question: Cocoa is huge and hard to learn when you are getting started. Let's fix that!
Let's make it easy - NAY - FUN to get started. That's what made Rails so darn popular, right? It's not because it was the fastest, or had a long history of support, or zero bugs, or stability. It was FUN. And that's what *Ruby* is about, too!
I think we should also show off how "grown up" MacRuby already is. When I saw that there was already a Core Data project template, I was sold. If that *hadn't* been there, I would have balked, for sure, and maybe even walked away. Also, Matt Aimoetti's MacRuby book, and the upcoming book, MacRuby in Action, indicate that the support is out there.
I think that HotCocoa is a great example of "fun" and "distinctive development cycle". It aims to be a replacement for Interface Builder. I don't think we need to stop there. We can replace *Xcode*. Hotcocoa already handles compilation, using macrake to run or deploy or embed a project. If we could go so far as to wrap up Core Data into ruby classes, hoohoo boy would we be having fun then! "HotCocoaData" anyone?
For my part, I'd like to reach out to those of you that have collections of recipes and tutorials, and start creating a structured repository of these resources (jballanc/Josh recommended using the github wiki as this tutorial repository).
I would *really* like it if our tutorials did the same things most do (pushing a button => prints "hello" - WOW!), but then always take that a few steps further. If it is easy to print "hello", why would you stop there? Do something useful, or at least something complicated, that provides food for thought.
With help, I think we could create a project that allows us to create Core Data models using ruby code. At that point, *everything* could be done in ruby, but with full access to Cocoa, and then we'd be doing something really exciting. Not that MacRuby isn't already exciting - if it wasn't, we wouldn't be talking about this stuff!
#colinta
_______________________________________________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
I was wondering if there would be benefit to writing (a) Generator(s) ala' Rails' "rails" script for the stubbing out of apps and m,v,c ? Imagine:
facet new <application name> facet g model <AwesomeModelName!> …
Thoughts?
I had started on rewriting my tools for that for MacRuby, actually based on the same way Rails does it (Thor). It creates applications based on the actual Xcode templates and thus the resulting project is fully Xcode compatible. I never got far enough and won't be working on it any time soon, so if anyone wants to use that as a starting point, go for it! I’d still very much would like to see this released :) https://github.com/alloy/rucola Eloy
participants (5)
-
Colin Thomas-Arnold
-
Eloy Duran
-
Francis Chong
-
Joshua Ballanco
-
Kevin Poorman