MacRuby Learning
As a former Obj-C+Cocoa developer, I can’t tell you how happy I am about MacRuby. To be quite honest, after taking a brief look at RubyCocoa, I wasn’t too excited. But after taking a careful look at MacRuby, I’m very excited. In fact, I think this is as big as Rails for Ruby.
Here’s a list of learning resources I compiled:
Pragmatic Studio Bonus Track #6 and #7 – screencasts
Mike Clark did an excellent job explaining MacRuby. I’m very stunned that he’s not charging for these two screencasts. Who know, he may come to his senses and start charging for them. Get them now!
Meet MacRuby by Peepcode – screencast
I already reviewed this. It’s $9 and well worth it.
Developing Cocoa Application Using MacRuby
Excellent tutorial from Apple. Basically similar tutorial as Mike Clark’s screencast. I wonder if he wrote this…
MacRuby.org
The official site with documentation and all the goodness.
By the way, to my delight, MacRuby is based on 1.9 version of Ruby. Have fun!
RubyMine 1.0
I just couldn’t resist the price tag of $49. That’s with 50% off coupon code I got from JetBrains when I signed up for beta. So, I got RubyMine 1.0.
I just want to make it clear that the primary reason is NOT the price. As a former Java programmer (that sounds terrible), I used IntelliJ and thought it was the perfect replacement for Visual Studio on MS side. Although in its infancy, RubyMine didn’t disappoint.
RubyMine has all the features you’d expect from an IDE; code completion, code inspection, version control integration, documentation lookup, testing helpers, and etc… The best part is that it runs on my Linux, Windows, and Mac. I only use the Linux version, which took some time to set up.
I still like Komodo Edit and will continue to use TextMate on Mac, but RubyMine really makes my life simpler. The only complain I have is that it takes way too long to start up.
I look forward to future upgrades.
Rails Plugin Directory – Now With New Design
When I saw the new design of Rails Plugin Directory, I was dying to tell everyone, but Ben made it clear that he didn’t want it announced while in development. I know, duh. Well, Ben made the announcement and it’s now live!
As I said before, I’m not a big fan of the whole plugin stuff. However, this site has plenty of information where you can make the informed decision to use a plugin or not. Go check it out for yourself.
Meet MacRuby by Peepcode
I just downloaded and and viewed “Meet MacRuby” from Peepcode, and I must say, I’m extremely impressed with the content as well as the production value. Geoffrey has gotten considerably better with each screencast over the years and I assure you that you’ll be amazed with this one. It’s worth well over its $9 price tag.
As a former Obj-C programmer, I have certain bias towards using anything other than Obj-C for Cocoa programming, but MacRuby appears to be the future. I’m somewhat sick of Ruby being used strictly for web programming and it’s about time Ruby gets used for other areas. MacRuby and Cocoa does not appear to be a small step, but a giant leap towards that goal.
I only have two words for this screencast, GET IT!
Oh No!
Sinatra 0.9.2 Released
Here’s what the changelog says. The most important thing in this release is the compatibility to Rack 1.0. Well, the confirmation of the compatibility is more like it…;)
= 0.9.2 / 2009-05-18
* This version is compatible with Rack 1.0. [Rein Henrichs]
* The development-mode unhandled exception / error page has been
greatly enhanced, functionally and aesthetically. The error
page is used when the :show_exceptions option is enabled and an
exception propagates outside of a route handler or before filter.
[Simon Rozet / Matte Noble / Ryan Tomayko]* Backtraces that move through templates now include filenames and
line numbers where possible. [#51 / S. Brent Faulkner]* All templates now have an app-level option for setting default
template options (:haml, :sass, :erb, :builder). The app-level
option value must be a Hash if set and is merged with the
template options specified to the render method (Base#haml,
Base#erb, Base#builder). [S. Brent Faulkner, Ryan Tomayko]* The method signature for all template rendering methods has
been unified: “def engine(template, options={}, locals={})”.
The options Hash now takes the generic :views, :layout, and
:locals options but also any template-specific options. The
generic options are removed before calling the template specific
render method. Locals may be specified using either the
:locals key in the options hash or a second Hash option to the
rendering method. [#191 / Ryan Tomayko]* The receiver is now passed to “configure” blocks. This
allows for the following idiom in top-level apps:
configure { |app| set :foo, app.root + ‘/foo’ }
[TJ Holowaychuck / Ryan Tomayko]* The “sinatra/test” lib is deprecated and will be removed in
Sinatra 1.0. This includes the Sinatra::Test module and
Sinatra::TestHarness class in addition to all the framework
test helpers that were deprecated in 0.9.1. The Rack::Test
lib should be used instead: http://gitrdoc.com/brynary/rack-test
[#176 / Simon Rozet]* Development mode source file reloading has been removed. The
“shotgun” (http://rtomayko.github.com/shotgun/) program can be
used to achieve the same basic functionality in most situations.
Passenger users should use the “tmp/always_restart.txt”
file (http://tinyurl.com/c67o4h). [#166 / Ryan Tomayko]* Auto-requiring template libs in the erb, builder, haml, and
sass methods is deprecated due to thread-safety issues. You must
require the template libs explicitly in your app file. [Simon Rozet]* A new Sinatra::Base#route_missing method was added. route_missing
is sent when no route matches the request or all route handlers
pass. The default implementation forwards the request to the
downstream app when running as middleware (i.e., “@app” is
non-nil), or raises a NotFound exception when no downstream app
is defined. Subclasses can override this method to perform custom
route miss logic. [Jon Crosby]* A new Sinatra::Base#route_eval method was added. The method
yields to the block and throws :halt with the result. Subclasses
can override this method to tap into the route execution logic.
[TJ Holowaychuck]* Fix the “-x” (enable request mutex / locking) command line
argument. Passing -x now properly sets the :lock option.
[S. Brent Faulkner, Ryan Tomayko]* Fix writer (“foo=”) and predicate (“foo?”) methods in extension
modules not being added to the registering class.
[#172 / Pat Nakajima]* Fix in-file templates when running alongside activesupport and
fatal errors when requiring activesupport before sinatra
[#178 / Brian Candler]* Fix various issues running on Google AppEngine.
[Samuel Goebert, Simon Rozet]* Fix in-file templates __END__ detection when __END__ exists with
other stuff on a line [Yoji Shidara]
Please Don’t Blame It on Rails
One of many reasons why I love Rails…, yes, I said it, I love Rails, okay? Let’s move on. I love the fact that Rails makes developing a web app really easy and breaks down the barrier to entry. In fact, it’s allowing the designers to develop really stylish web apps. I think everyone benefits from this.
However, in recent projects, I find that these designers never took time to really study the basics of programming. In fact, I see so many Rails apps put together with a bunch of plugins blindly thrown in that it’s getting really frustrating to work on. I can now see why people are bitching about apps written with Rails and subsequently, Ruby gets blamed as well.
My experiences through the years have taught me that you can write unscalable and poorly performing applications in any language, framework, and/or platform. There are apps out there that is running very well that’s written with Ruby and Rails. So, is it really fair to blame a language and a framework for your failure? I really suggest that everyone take a hard look at themselves before placing the blame on a framework that brought so many people into our profession.
Please don’t blame Rails for your app not scaling across multiple servers when your code takes an uploaded file and save it at a specific directory in a server where other servers can’t get to it. I didn’t even know that it was possible to do this, but apparently it’s possible.
Please don’t blame Rails for your app not performing well because you didn’t implement all known performance enhancing techniques. Being a developer means you have to be learning constantly, both from your experiences as well as others.
Please don’t blame Rails for SQL injection attack when your code takes the user’s input and put it into sql condition without escaping. Yes, I still see this.
Do not blindly use plugin. DRY is NOT Repeat Others. Investigate and document if the plugin is poorly documented. Every plugin deserves a code review, even if it’s written by a famous dude.
Please know the reason behind the techniques and convention. Ask yourself if you really need to be RESTful, because it may actually not make sense for you to be RESTful. By the way, using Rails for REST services is silly when we have Sinatra and Rack.
Don’t get me wrong, Rails does have its shortcomings, but Ruby makes it possible for you to correct it. After all, it’s open source! Isn’t that the beauty of this whole open source movement?
