April 2012 - MacRuby-devel - lists.macosforge.org

Update
by Laurent Sansonetti 10 Apr '12

10 Apr '12

Hi guys, So we had a team chat, and we agreed on the following. First, we will release master as 0.12 (and just forget about 0.11). It is important since master has changes for the latest Xcode that have never been snipped yet. I will work on this. In the meantime, if you can, please do install one of the latest nightly builds and let us know of any regression. It is likely that 0.12 will be one of the last releases before 1.0. Second, we will prepare a new landing page for the project, which will be hosted on GitHub. The page will be very minimal, as we intend to use the wiki for the real content. Josh volunteered to work on this, he does not need more help. Watson has been working on the necessary Wiki pages, but we might need more. If you're interested, the Wiki is open to anyone, you can create new pages or edit existing ones: https://github.com/macruby/macruby/wiki Third, we will migrate the tickets from trac to GitHub. Jake Smith and Dan Sinclair volunteered to work on this. We will coordinate so that the process will be as smooth as possible. No more help is required here. Fourth, we will move the nightly build system to a new infrastructure. I will provide a Mac Mini that will do the builds and push them on Amazon S3 (costs will be covered by my company). This will not happen right now, but somewhere in the future. We will probably do the first 3 items at once :) Laurent

1 0

Re: [MacRuby-devel] The future of MacRuby
by Jake Smith 10 Apr '12

10 Apr '12

I have already tried importing the tickets to GitHub at http://github.com/theviolentbear/macruby-issues usinghttps://github.com/adamcik/github-trac-ticket-import. I was doing it so I could have offline access to tickets, but someone let me know that it was being discussed on the mailing list. It didn't properly escape code blocks nor did it import most of the metadata or respect the GitHub API limits, but it kind of worked as you can see. -- Jake Smith pace e bene On Sunday, April 8, 2012 at 10:00 AM, macruby-devel-request(a)lists.macosforge.org wrote: > Send MacRuby-devel mailing list submissions to > macruby-devel(a)lists.macosforge.org (mailto:macruby-devel@lists.macosforge.org) > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > or, via email, send a message with subject or body 'help' to > macruby-devel-request(a)lists.macosforge.org (mailto:macruby-devel-request@lists.macosforge.org) > > You can reach the person managing the list at > macruby-devel-owner(a)lists.macosforge.org (mailto:macruby-devel-owner@lists.macosforge.org) > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MacRuby-devel digest..." > > > Today's Topics: > > 1. Re: The future of MacRuby (Eloy Duran) > 2. Re: The future of MacRuby (dan sinclair) > 3. Re: The future of MacRuby (Eloy Duran) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 7 Apr 2012 23:40:39 +0200 > From: Eloy Duran <eloy.de.enige(a)gmail.com (mailto:eloy.de.enige@gmail.com)> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org (mailto:macruby-devel@lists.macosforge.org)> > Subject: Re: [MacRuby-devel] The future of MacRuby > Message-ID: <D23125EB-0B40-4F7B-BB6C-6D739ED4D32A(a)gmail.com (mailto:D23125EB-0B40-4F7B-BB6C-6D739ED4D32A@gmail.com)> > Content-Type: text/plain; charset=windows-1252 > > > Can we get the issues section enabled on github and move off of Trac? (Not sure how hard it would be to import all of the old trac stuff to Github). > > > > Would be nice to consolidate everything in one place. > > I think that?s an excellent idea. However, it?s probably better to first import tickets from Trac before we open it up for new tickets, because that won't leave any risk for damaging any tickets opened before the old tickets are imported and also avoids people spending time on duplicate tickets. > > Are you interested in investigating this? > > ------------------------------ > > Message: 2 > Date: Sat, 7 Apr 2012 14:53:19 -0700 > From: dan sinclair <dj2(a)everburning.com (mailto:dj2@everburning.com)> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org (mailto:macruby-devel@lists.macosforge.org)> > Subject: Re: [MacRuby-devel] The future of MacRuby > Message-ID: > <CAB0vK_JU6iF5z1pv38z1izsJeE+qHn=Pb9k2ZpuuctS3n-G_jg(a)mail.gmail.com (mailto:Pb9k2ZpuuctS3n-G_jg@mail.gmail.com)> > Content-Type: text/plain; charset="windows-1252" > > Can you import before it's open? I just assumed it wasn't accessible at all > until enable? It looks like forgeplucker (http://home.gna.org/forgeplucker/) > has support to pull tickets out of trac and dump to JSON. Should be pretty > easy to go from JSON to GitHub API I'd expect. > > I can take a look and see what's involved. > > dan > > > > > On Sat, Apr 7, 2012 at 2:40 PM, Eloy Duran <eloy.de.enige(a)gmail.com (mailto:eloy.de.enige@gmail.com)> wrote: > > > > Can we get the issues section enabled on github and move off of Trac? > > (Not sure how hard it would be to import all of the old trac stuff to > > Github). > > > > > > Would be nice to consolidate everything in one place. > > > > I think that?s an excellent idea. However, it?s probably better to first > > import tickets from Trac before we open it up for new tickets, because that > > won't leave any risk for damaging any tickets opened before the old tickets > > are imported and also avoids people spending time on duplicate tickets. > > > > Are you interested in investigating this? > > _______________________________________________ > > MacRuby-devel mailing list > > MacRuby-devel(a)lists.macosforge.org (mailto:MacRuby-devel@lists.macosforge.org) > > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > > > >

5 6

Re: [MacRuby-devel] The Future of MacRuby
by Andrew Havens 09 Apr '12

09 Apr '12

I've been a lurker in this mailing list for a while now. Sad to hear we've lost a project lead but glad to hear Matt has identified many of the issues I've been feeling myself. I'm a self-taught web developer. I never had any interest in learning native app development until I heard about MacRuby. Now I've written a few sample apps and one "production" app. I think MacRuby is a great resource to the Ruby community and I think web developers are MacRuby's target audience. All of my MacRuby apps are GUIs for other Ruby libraries or gems. The biggest thing that I feel is lacking at this point (which Matt mentioned) are adequate "getting started" and reference guides. I had a heck of a time trying to create my first app. I had to scrounge together blog posts, StackOverflow questions, and Objective-C docs. I think some good guides (like Rails guides) would go a long way towards increasing adoption. Also moving this mailing list to Google Groups and splitting it into MacRuby-core and MacRuby-help would provide a place for newbies to get help. In fact I started a Google group for just that purpose since I was frustrated that there was no mailing list for people starting out (but never told anyone so I'm the only one who ever used it). But I would love to see an official one. All the open source projects I know of have a Google group since they are easy to use and subscribe to. I also feel like XCode is a major hurdle. If you're already familiar with XCode, that's great, but as a web developer, I spend most of my day in TextMate (or command line). I would love to see some code samples of a REAL app created from scratch (not using XCode, multiple files/object oriented) because that's how I would like to work with MacRuby (from the text editor of my choice, rather than be forced into using Apple's IDE, regardless of whether or not it's better). I installed MacRuby from the command line via RVM so I want to generate a .app from the command line too. I think Ruby on Rails is seen as a productive programming environment. I think a big part of that is due to its many command line generators. A lot of people learned how to use Rails by looking at the code generated by the scaffolding created. If there was more emphasis towards using MacRuby from the command line, I could see more people writing MacRuby app scaffolding generators. I also think that there's a big movement towards writing native apps using web technologies (write once, run everywhere mobile apps using JavaScript, i.e. Titanium Mobile, PhoneGap). I think this is huge since nobody wants to learn a language that's proprietary to a single device/company. However, I don't want to write JavaScript unless it looks more like Ruby (thanks CoffeeScript). If I could write an iOS app in MacRuby I would. I'm not sure how this would work though. I included MacRuby in my Snow Leopard app and it increased the app file size tremendously. File size is important when it comes to mobile. Those are my thoughts. Again, I think MacRuby is great and mostly complete. More code samples and documentation are a high priority at this point in my opinion. --Andrew Havens P.S. If you're interested, I'm working on an open source version of HipChat that I call Mad Chatter. I used MacRuby to create the native Mac client. https://github.com/andrewhavens/mad_chatter Contributors more than welcome!

7 13

Re: [MacRuby-devel] The Future of MacRuby
by Colin Thomas-Arnold 09 Apr '12

09 Apr '12

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

5 4

The future of MacRuby
by Matt Aimonetti 09 Apr '12

09 Apr '12

*Many of you have been wondering what is going on with the MacRuby project given the lack of up-to-date releases and overall communication. I feel we owe you some explanation. As a lot of you have noticed, our de-facto project leader Laurent Sansonetti has been M.I.A since October 2011, his last post to this mailing list being http://lists.macosforge.org/pipermail/macruby-devel/2011-October/008168.htm… MacRuby 0.11 really soon. His last commit was a change of license back in October: https://github.com/MacRuby/MacRuby/commit/ac2a7a8e678d19e44d3c64a9508a8370d… <https://github.com/MacRuby/MacRuby/commit/ac2a7a8e678d19e44d3c64a9508a8370d…> Laurent is fine. As described on his twitter http://twitter.com/lrz and LinkedIn http://www.linkedin.com/in/sansonetti accounts, Laurent is no longer with Apple and is clearly also no longer directly involved with the MacRuby project on a day-to-day basis. Laurent is currently busy with another project and and hopes to someday be able to contribute to the MacRuby project again. While no one on this list can speak for Apple, and Apple as a company does not tend to comment on its future plans or intentions, I think it's reasonable to imagine that Apple would be more than happy to have the MacRuby project decide for itself what its destiny is and how to achieve it. If they did not want the community to be involved or drive such a process, they would not have released MacRuby as open source or created the project infrastructure to facilitate it. It is time for us to stop looking to Apple to provide guidance, leadership and coding for the project, in other words, and take on those challenges for ourselves! MacRuby is already very powerful and comparatively stable as a development platform, now it's time for us to take things to the next level. I personally think it will finally allow us to communicate and collaborate on the actual process of development as it occurs, rather than the previous practice of simply seeing code appear from some hidden, internal branch which was driven almost exclusively by a single person Doing all of this in the open should lead to far more people being interested in the project, not just as users but as developers and leaders. No one rushes to fill a position that is occupied by someone else, but now we have a vacuum to fill, and that can be a good thing in terms of encouraging more people to step forward. Here is how I see things and I would love to hear more about what you guys think. MacRuby is a great project, but: - the target audience & projects aren't clear - the target platform (OS X) isn't the one we all really want to target (iOS) - Cocoa's API is awesome but not user friendly/easy to grasp What I'd like to suggest is the following: 1. Define clear goals for MacRuby that we can easily evaluate: - Focus primarily on making MacRuby the tool to use for quickly prototyping OS X and iOS applications. - Remove dependency on libauto so MacRuby can run post Mountain Lion and on iOS. 2. Increase the number of contributors: - Define areas of contribution: - implementation itself (mainly requires C, C++ knowledge) - prototyping focus (templates, wrapper APIs, modules, tools: a full ecosystem aimed at being more productive) - documentation (getting started, guides, FAQs, wiki, demos, hacker guides) - support - empower contributors: - move the website to github for easier contribution - better release process and roadmap - better process to review pull requests & give commit rights 3. Improve communication: - start an active and official chat room (IRC, campfire like or something else) - open discussions about plans for the project and progress made - better collaboration with other Ruby implementation teams (Rubinius, JRuby, MagLev and of course Matz/C Ruby) Let's not forget that MacRuby is and will remain a free Open Source project and that means we need your help and support. Without you, this project doesn't mean much so please voice your opinion and if you decide to do so, become an active participant to MacRuby's success. I would like to thank Apple for their historical support and Laurent for starting this project and all his work so far. Without those contributions, MacRuby would never have existed and the project will more than welcome any future participation by either Apple or Laurent. At the same time, I don't think the future of this project can or should rest on the shoulders of a single corporate entity, or that of a single individual. That does not encourage the kind of broad participation, or the kind of overall longevity (in the form of future generations of contributors) that Open Source projects really need to survive over the long term. Finally, I'd like to make clear that I see myself more in a role of a facilitator than a technical leader on the order of what Laurent was. This role has been left vacant for more than 6 months now and needs to be filled by a group of people with greater technical skills than mine. Additional contributors are therefore more than welcome to join the team, and their support will be as much appreciated as it is needed. Finally, in addition to the already numerous great MacRuby contributors and soon to become contributors, Evan Phoenix (Rubinius) agreed to act as an advisor for the project. So, MacRuby community what do you think?* * * *- Matt*

14 17

Future of MacRuby
by Laurent Sansonetti 07 Apr '12

07 Apr '12

Hi guys, Yes, I'm still alive :) As you may have noticed, I have been absent here for a few months. Last year we got a baby, then we moved back to Europe. I decided to leave Apple a few months ago to achieve one of my dreams: work on a startup, in part so that I would be flexible in my time and be able to keep hacking on MacRuby. Believe it or not, in the near future I should have less pressure on myself and therefore I should have the time to hack on MacRuby again. I will happily resume maintaining MacRuby, like I did for the last 5 years. MacRuby is quite stable right now so the maintenance burden is less significant than before. Also, during my absence, Watson did a great job of smashing all sorts of incoming bugs, if he keeps up he will likely become the #1 committer of the project :). Mark Rada spent a lot of time triaging bugs and writing patches. And Josh Ballanco kept the IRC channel in activity. It's like the project never slept. BTW, the 0.11 release actually does exist, you can find it on the GitHub page. The release notes are still missing, but I will take care of this (we need to automate the whole process). One thing that people are worried about is that the Objective-C GC is being deprecated in Mountain Lion. That's not a surprise given that the emphasis is on ARC now. As Apple generally (but not always) removes deprecated APIs in the next release cycle, MacRuby needs to be changed this year to not depend on the GC anymore. I have been experimenting with different alternate memory models for MacRuby on my spare time, and one of them seems to work well, modulo a few leaks. It's similar to ARC in design (but it has a different implementation). I have been working on a MacRuby app with friends using the new code, so far so good. I will merge my branch with GitHub as soon as it's stable, with a few other improvements. That should happen before Mountain Lion ships, so no worries, we should be fine. What can you do to help? Well, keep using MacRuby :) Report bugs. Write cool samples and submit them on GitHub. Write tutorials covering a feature of OSX that was challenging to program in MacRuby. For the more technically-inclined, you can check the tickets, try creating patches, etc. Laurent

6 6

Re: [MacRuby-devel] The future of MacRuby
by Seth Willits 07 Apr '12

07 Apr '12

> What I'd like to suggest is the following: > > 1. Define clear goals for MacRuby that we can easily evaluate: > > - Focus primarily on making MacRuby the tool to use for quickly > prototyping OS X and iOS applications. This is the wrong thing for "MacRuby" to focus on, in my opinion. I've been watching MacRuby be developed over the years, and liked everything I saw on the blog post updates for new releases, but I never understood the focus on trying to build complete applications with it, and trying to simplify the Cocoa frameworks by including wrappers. These are two separate (but related) projects. MacRuby should be a *foundation* for which those kinds of projects can be built upon, but it shouldn't be a main goal of the MacRuby project itself. Creating a bulletproof Ruby which is completely compatible with the official version (when using plain Ruby code), where you can use Obj-C<--->Ruby as needed, with leanings towards increasing performance where possible, is a challenge in itself, and a very worthy goal. I'm a full time Cocoa developer and have done many Mac and iOS apps. If anything, the thing that makes it "difficult" to prototype Mac/iOS apps is not Objective-C, it's the structure and learning curve of the Cocoa frameworks. Particularly on iOS, the view controllers are specialized with specific purposes and usage patterns and you need to know about and understand those to use them properly. Objective-C doesn't get in the way of that. Connecting some view controllers together, dropping in images, hooking up buttons to transition between the view controllers etc, all of that involves a trivial amount of code. If you already know Objective-C then there's zero benefit to using Ruby to prototype instead. If you *only* know Ruby, then sure, using Ruby might make it possible for you to prototype an app, but the more significant barrier is still the frameworks. I should preface this by saying I'm also a Rubyist so it's not just a blindly biased opinion. I use Rails, have complex Ruby-only code for massaging and dealing with a lot of data, and have written code bundles in C and Obj-C to connect with Ruby via C bindings to do performance-critical code. Now, personally, I don't want to write a Cocoa app in Ruby. The tools Apple ships (Xcode, Instruments, etc) all work great with Obj-C and help me stable and performant code. Using Ruby as the main language of development in my application only makes it more difficult for me to debug and keep performance up when it matters. Sure, simple applications can be written in Ruby and all the power to those who want to do that, but to me it's not what MacRuby is for. MacRuby may be a *part* of that solution, but if it's for a prototyping, that would be best served by a separate MacRuby-based framework and GUI application. What MacRuby is to me: MacRuby to me, is interesting in a few ways: 1) Performance — Using llvm to JIT Ruby to native code, plus libauto was supposed to yield a notable performance increase over the standard Ruby. Now, Ruby has come a long way since <= 1.8 in performance, so how significant these potential gains are now, I am unsure, but in the applications we have, performance matters. 2) In the Mac applications I do write, there are several possibilities for me to use Ruby. Let's say for example, I want to allow my user to be able to use Ruby to write "plugins" for my application. This capability would be for any user to implement a custom process, using Ruby to directly work with Cocoa objects that get used in the application. This would require no compiling on the user's part, I wouldn't have to write a ton of C bindings glue to connect Cocoa and Ruby — it would just work. 3) Sometimes in our Ruby projects, it would be oh-so-convenient to be able to use Obj-C frameworks to get something done — Again, with no need to write C bindings. Say I need to get at the stuff in the address book, want to use methods available to NSString/NSCharacterSet/etc because it's faster, or better yet use Quartz to do graphics rendering from my Ruby code. 4) Another thing that interested me, is shipping an actual binary. Say I have some proprietary code written in Ruby and I want to ship this to clients (specifically running on Mac OS X). I obviously don't want to be passing out my source code. With MacRuby, I want to be able to effectively compile my Ruby code and have a binary I can ship out. It's mainly the performance and interoperability between Ruby and Obj-C the makes up what MacRuby is to me. Not using it for prototyping or building entire Mac/iOS applications. My two cents. -- Seth Willits

1 0

Re The Future of MacRuby
by Dan Farrand 06 Apr '12

06 Apr '12

I am not a a contributor to MacRuby, but I have been interested in using it. Without Apple sponsorship, I have very little interest in MacRuby. Without commitment and support from Apple, it will be a never ending scramble to just keep up with niggling changes to xcode, cocoa and the build process. Every new release of anything by Apple will break stuff. By offering no comment and no hook into the apple labyrinth the message from Apple is that, "it is not strategic to us". The broader message may also be that computing in general is less and less strategic to Apple. So sad to say, I think it is goodby MacRuby. Very sad, because if Apple does care about the computing side of the business, they are going to need to provide an alternative to ObjectiveC and the aging development approach they have been living off of for the last 10 years. I had hopped that MacRuby might have pointed the way, but apparently not. danf

3 2

Re The Future of MacRuby
by Tim Rand 06 Apr '12

06 Apr '12

I am surprised to hear Laurent has left Apple. I don't know what motivated the change, but I am sure that he is working on something great. Good luck Laurent!!! While I have a lot of faith in the open source community and think growing a larger pool of contributors is critical for the long-term viability of macruby, the libauto issue is a simple example of how internal decisions at Apple can have profound effects on macruby's future. That worries me. Without anyone promoting macruby from inside Apple, they can shut compatibility with x-code off with an update, add months of work to remove libauto-dependency because they decide to deprecate GC or otherwise alter the programming universe in some unforeseen way. Since Apple is an unapologetic, iron-curtain of secrecy, with a propensity to stop short and change direction (remember when it seemed like macruby would be on iOS?), I can only imagine how many hacker years the macruby community will burn while trying to hit an ever-moving target. Apple, think different--don't be evil! --Tim On Thu, Apr 5, 2012 at 9:02 PM, <macruby-devel-request(a)lists.macosforge.org>wrote: > Send MacRuby-devel mailing list submissions to > macruby-devel(a)lists.macosforge.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > or, via email, send a message with subject or body 'help' to > macruby-devel-request(a)lists.macosforge.org > > You can reach the person managing the list at > macruby-devel-owner(a)lists.macosforge.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MacRuby-devel digest..." > > > Today's Topics: > > 1. Re: Re The Future of MacRuby (Jordan K. Hubbard) > 2. Re: The future of MacRuby (Chong Francis) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Thu, 05 Apr 2012 17:45:48 -0700 > From: "Jordan K. Hubbard" <jkh(a)apple.com> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org> > Subject: Re: [MacRuby-devel] Re The Future of MacRuby > Message-ID: <F0B5203E-88F8-4897-A68B-DF292DAF428D(a)apple.com> > Content-Type: text/plain; charset="us-ascii" > > > On Apr 5, 2012, at 3:34 PM, Dan Farrand <danf(a)greenRiverComputing.com> > wrote: > > > I am not a a contributor to MacRuby, but I have been interested in using > it. Without Apple sponsorship, I have very little interest in MacRuby. > > I think Matt has already said all that needs to be said on that subject. > There are many application environments, both commercial (like Unity3D) > and open source (like Mono), that have enjoyed a healthy and robust > existence without Apple's help. Apple is a wonderful company that makes > many fine things (and I'm obviously biased), but it would be frankly silly > to suggest or even imagine that no one else is capable of making fine > things on their own. One also need look no further than the MacPorts > project to see one that was started by Apple but became FAR more successful > and motivated once the community became seriously involved with and took > over the development process, so there's a counter-point to your somewhat > pessimistic viewpoint right there. > > I personally wish Matt and anyone who wishes to join him in charting > MacRuby's future course the very best of luck. As he notes, it's already a > fairly stable platform and a lot of good work has already gone into it: > It's hardly starting from scratch with just a few gossamer dreams and > ill-defined notions to hang its future on! You have some great stuff to > start with. > > Even better, it's open source and the doors are therefore open to anyone > who wishes to participate. No hosting situation is perfect, of course, and > should there be any impediments to such participation then I'm sure they > will rapidly resolve themselves given the plethora of alternatives for > hosting the bits, the bug reports, the community discussion portals, and so > on. Those are mere implementation details, however, and it's far more > important that the project have some clearly defined goals and people > willing to drive those goals since, as I can personally attest, the heart > and soul of any open source project is the people involved with it on a day > to day basis! Not the source code. Not where the sources are hosted. The > people. > > There simply has to be some collection of people who constitute an actual > community since it is communities, and the essential need that humans have > for creating them, that binds any project together and leads to its > longer-term success. Individuals themselves may come and go, just as I > left the FreeBSD project after many years of involvement with it, but as > long as there is a strong community of like-minded individuals remaining > then the project will live on and continue to prosper (I like to think that > FreeBSD is far more successful today than it was when I left it). > Focusing on the past merely leads to pointless navel-gazing. Think about > the future you want to create, as Matt says, and you'll be on the right > track. > > > Finally, I also think that integration with Xcode, while certainly not a > bad thing to maintain going forward, should also not be held up as such a > holy grail that it proves an impediment to thinking up new and even more > exciting ways to rapidly prototype applications in an interactive, > interpreted development environment. > > MacRuby is not Objective-C. It can be compiled, and that's great, but it > also lends itself particularly well to Smalltalk-style interactive > development environments that, I believe at least, have been sadly lost in > time as IDEs like Visual Studio and Eclipse rose to prominence and became > the new norm. What about seeing software more as connectable ICs, with > lines and arrows denoting control flow, for example? What about dragging > and dropping stuff from palettes of code templates rather than writing > endless amounts of boilerplate? These are the sorts of concepts that a > project like MacRuby could easily explore, should it choose to do so, > rather than simply trying to clone or track existing development metaphors. > > The Rails developers certainly proved the notion, and proved it with > rather spectacular success, that you could start with a flexible and easily > learned language like Ruby and then create a de-facto DSL on top of it, > making things that were formerly somewhat complex almost absurdly simple. > Whether you like Rails or hate it, you cannot argue the fact that this > essential idea struck a strongly responsive chord with a lot of web > developers, so why not seek to create something similar for app developers? > Both individually and collectively, the readers of this list are in > charge of where MacRuby goes next. If you like the vision that Matt is > proposing, by all means follow him. If you don't, github also supports any > number of possible forks, the word "fork" no longer having the somewhat > pejorative meaning it once had, either, but rather representing the > opportunity for one or more individuals to demonstrate another possible > vision of the future the old fashioned way - by creat > ing it! > > - Jordan > > > >

2 1

Rails.app done by the MacRuby community
by Matt Aimonetti 03 Apr '12

03 Apr '12

Today a mini drama was started after Yehuda Katz announced his kickstarter project to build a ".app" for Rails. He's trying to raise $25k to work on the project, see more there: http://news.ycombinator.com/item?id=3768339 Putting the money raising question aside, I think this is a good project but I think that as a community we can do it together, learn a lot in the process and create an awesome product helping the community. My suggestion is that people interested get together and hack together in an open and public way. Yehuda might get funded and decide to contribute or do his own thing in JS, that's totally besides the point since our motivations would be different so we shouldn't worry about that. So, what do you say? - Matt P.S: Two years ago, I ported couchdbx to MacRuby and extracted some code you can see here: https://github.com/mattetti/mrstuff The couchdbx app is also available in my github repo. -m Sent from my iPhone

3 9