has_many :thoughts

Does anyone think there is a market for a Philadelphia area, 1 or 2-day Merb conference?

I’ll be the first to admit that my Merb cred is quite minimal. I did a talk on it months ago at Philly.rb but since then, I have barely touched it. I’m seeing great things out of Merb recently, and I feel it has a real potential to overtake Rails as our Ruby framework of choice at Kinetic.

So I’m thinking of trying to organize, or at least get behind, a regional conference all about Merb. The Philadelphia Ruby community is thriving and I wonder if there is an appetite for hearing some Merb talks and, of course, socializing with other Rubyists.

I suppose my next task should be to watch this talk from RubyConf. I skipped it in Orlando thinking I’d never want to organize a regional conference. But perhaps I do…

I’d like to start by thanking Mr. Peepcode for his article which presented a great case for learning Emacs! Without it, I would have never thought of mastering the only Unix editor I had yet to experience.

Configure With NS

GNU is NeXTstep Unix… why even bother with Aqua, Carbon, Cocoa Emacs when you can just compile “nextstep” support for GNU Emacs itself?

NOTE: I used another blog article but it seems like its always incredibly slow. Check that guy’s blog out since he’s the original author though, or buy him a beer.

So here are the regurgitated compilation steps that I used.

git clone git://repo.or.cz/emacs.git
cd emacs/
./configure --with-ns
make
make install
sudo cp -R ./nextstep/Emacs.app ~/Applications

Configuration Tips

If your a picky hacker like myself you’ll be customizing your workspace for the rest of your life… but you’ll want to definitely clone topfunky’s emacs-starter-kit. It takes some configuration to get right, but puts you on a great start. I loaded linum-mode, ruby-electric and some radical themes to get comfortable. Also, I can’t keep away from RTFM too.

One final thing to note, I read that although nxhtml looks pretty friggin awesome… its a monster to load. I patched these lines to my starter-kit-misc.el as well… to use the nxml library in which nxhtml was built upon. Its gotta be smaller, faster and cleaner then all of those features I just won’t be using in nxhtml.

(add-to-list 'auto-mode-alist '("\\.html$" . nxml-mode))
(add-to-list 'auto-mode-alist '("\\.rhtml$" . nxml-mode))

If and when I get back around to adding syntax highlighting to the Ruby lines within erb/rhtml files (which nxml modes loads into now)... I’ll need to patch those lines up again to load Rinari’s “rhtml-mode” or what have you. You can remove just the rhtml mode from Rinari by the way.

Of course I haven’t yet decided if I want to use emacs-rails, Rinari, or just stick with Yasnippets by itself ::shrug::. I’m fine typing out my code right now while I get the hang of my workflow with Emacs, but if anyone has any experience with them please comment your thoughts.

Textmate ;_;

So yeah, TextMate is now officially dead to me. I wish it wasn’t so, but with all the amazing support of Emacs, the power and fun of Lisp and the focus of staying on the keyboard the entire day… I’m pretty sure I won’t go back.

Please Note: This is bitching. I’m a nit picky kinda programmer. I pull things apart, rip out what I hate and go nuts over it so I remember to never do it again. This is a rant, your warned.

I’m not too happy with a lot of things going into Rails lately, outside of the stuff that they are learning about through other frameworks. Some additions have been made to Rails lately that are bringing it further from Ruby, into its own language.

Many people already believe that “Ruby on Rails” is a language in and of itself. I guess they believe that the “Ruby on” part is just a cool name. Frankly, some commits as of late could possibly be developing that language.

Array#second, #third, etc.

When I first learned scripting languages I learned Python, and I still love Python (despite having no current use for it). Even back to my C/C++ days I enjoyed Array indexing as Array#[] (in ruby terms). Whats so hard about an integer (0..n) being used between them? How else do you easily modify them into Ranges…. well Rails has solved all of this for us!

Array#first, plus now Array#second, #third, #fourth. Our playboy even says he’s found a way of “massive savings in overhead” for something Ruby never had a need for in the FIRST place.

Object#try

Object#try is another one. Again, something Ruby and Matz never put into the language itself. That doesn’t stop Rails from developing it into its own language.

Object#blank?

Ever try to bring a script over from Rails, and find yourself rewriting #blank?. Sure, I love blank, it saves time right? But where’s the Ruby in a method that was never originally intended to be monkey patched into the language itself?

My Point

My point is, there are other frameworks that try to keep this sort of thing to a minimum. The benefits are countless, and I think the best are…

1. Monkey patching is kept to a minimum. If you don’t understand the danger in monkey patching, please don’t ever read a blog entry I write again.
2. Lowered need of detailed attention being required when transferring code to other frameworks and platforms
3. Less lines of code within your code base, required pieces.
4. Universal code that is understandable by anyone using the original language.
5. Learning the appropriate methods the first time around
6. Not having to re-implement if you find yourself without one of these methods

Now I’m not against these sorts of things completely, and there are frameworks that implement them correctly (Merb and DataMapper’s combined ExtLib library being one of them).

I’m just not impressed by the magic tricks anymore, and tired of seeing Rails core become the bastard child of someone’s personal “good ideas”. Just because your doing it in your projects doesn’t mean it should be forced down my throat.

It’s not often I link to Microsoft but they have an insightful blog post over on the MIX Blog. Molly Holzschlag discusses the business benefits of Web Standards.

For several years, we’ve been pushing standards-compliant sites to our clients and we receive very little resistance. Many of our customers just roll with whatever recommendations we provide, especially for new sites.

But when clients have an existing site, and we try to sell them on converting it into nicely formatted, semantic XHTML and CSS, it can be a challenge. We’ve found it helpful to document clearly for them the additional cost they will incur by having our developers wade through crufty nested tables and horrendous cross-browser compatibility. When laid out in dollars and cents, the decision becomes easier.