has_many :thoughts

Just got this question and thought I'd make a blog post out of it.

why would someone want me to pull his changes into MY fork of this project?

This happens all the time, and usually for popular projects. There are a few reasons which lead themselves nicely into a discussion on Git[hub] distributed workflows.

The Short Answer

Git's distributed architecture can ensure that no single entity is the "central repository". Thus when someone feels they have important changes that all the forks and mirrors should utilize, they send out a global pull request to all or some of the forks on Github.

An Even Shorter Answer

It's a personal preference, one of Git's many available workflows.

Hardcore Forking

Personally, I have never worked that way on Github. I have done two things in maintaining forks.

• Fork fork; my fork is an entirely separate entity with a separate development cycle and process (or even end result)

• Support fork; my fork is a fork of the "sanctioned" main repo, and I am doing support work for the main project I will pull request to the "gate keeper" of that project (the main author or project maintainer).

Now if I really felt something was of urgency to all the forks I might do a global pull request if the main repo author didn't like my commit, he's gone AWOL and/or I still felt it was important (security, etc).

Otherwise, fork maintainers should have a local branch for tracking every other remote repository of other fork maintainer's. This is what I do to track only people I think have good commits that I can pull and include into my fork repo. Branches in this respect provide the links to other "node" repositories in the distributed glory which is Git.

Git suggests in their man pages and docs that you make the development decision to only pull in new commits, and never pushing out. Tracking remote repos demonstrates the beauty of following this workflow of "pull only".

Just Pull It

For shits and giggles lets build an example to demonstrate why "pull only" might be such a great idea for distributed project development.

I can think of no better example than Roy Fielding and the IETF's HTTP standard.

The Hypertext Transfer Protocol (HTTP) is an application-level protocol for distributed, collaborative, hypermedia information systems. It is a generic, stateless, protocol which can be used for many tasks beyond its use for hypertext...

We are going to map the following HTTP technologies to git fetching commands.

• git-push maps to Comet, a neologism to describe a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it.

• git-pull maps to Ajax, an acronym which describes a web browser technology capable of requesting only the content that needs to be updated, thus drastically reducing bandwidth usage and load time.

Comet, in general, uses the web server to push updates to the browser when they are available. Handy at times but breaks the HTTP protocol. It requires the server-side to maintain a connection and known state as the server needs to know whom the client is and where to send the new data. As we all know that's not very efficient in the grand scheme of HTTP. State is tough to keep synchronized. It limits the ease of going on and offline, as well as the client moving around across the internet (changing IPs, etc).

In contrast Ajax requests are much lighter. The client maintains when to request new content. Thus making a decision of how to handle the content, what it is and where it's coming from. When you are only doing git-pull you are choosing what to add and where to add it. There is more control over your own repository.

Summing it all Up

In a distributed environment everyone becomes the gate keeper to their own repository.

This is great for open source projects because the code is always kept free from central dictatorship.

Power is gained through this autonomous workflow when you allow anyone, at any moment, to add changes and bug fixes to the project or pull down someone else's updates for review and merging.

Last Friday, a good chunk of our team spent a while debugging a problem afflicting some sites on one of our shared hosting machines.

After a bunch of red herrings, some TCP dumps determined that the sites in question were all hung up on numerous DNS requests. That led us to the call to a web service we use on the sites in question. As it turns out, the IP geocode service being called, HostIP.info, was completely down. (It’s free; you get what you pay for.)

We assumed this couldn’t be the case, since those calls are wrapped in a Ruby Timeout calls with a maximum of 2 seconds each (Timeout.timeout(2)). Well, apparently, Ruby Timeout just doesn’t work sometimes.

Big props to Andy for sleuthing that down. And bigger props to Philippe Hanrigou for writing that very detailed article where he says, specifically:

“In particular, initiating network connections and/or a broken or slow DNS server will typically block the whole Ruby process while the call completes.”

Bingo! We’re going to try Philippe’s library on these projects and others in the future when we need guaranteed timeouts.

We’re still kicking the Ruby hardcore. We’ve just been massively busy locked in the Kinetic Barn HQ this winter. Anyway, here is a list of the latest things we’ve found interesting about the first stable 1.9.x release of MRI Ruby.

Note: Some of these have been in the 1.9 branch for awhile, I’m just taking the moment to get you all acquainted.

Newlines allowed before ternary colon operator (:) and method call dot operator (.)

Before this you might note that you could do this in Ruby, and it was valid.

Person.
  set_first_name('Ben').
  capitalize.
  to_a

# or...

dog = Person.first_name == 'Ben' ? 
'Cookie' : 
'pookie'

You won’t see the former very often, but you can do it if you keep to coding standards of 80-100 columns of text in your source.

I’ve seen and used the latter numerous times, however I usually don’t put a newline after the colon. Eithercase, Ruby makes things a bit more clearer in 1.9 (though these are bad examples of their use cases).

Person
  .set_first_name('Ben')
  .capitalize
  .to_a

# or...

dog = Person.first_name == 'Ben' ? 
'Cookie'
: 'pookie'

Kernel#methods and #singleton_methods used to return an array of strings but now they return an array of symbols.

I use this daily within Irb to see what methods are in my objects. You used to receive an Array of Strings, of all the methods on the object you ran this against. Now you will get this.

>> String.methods.sort
=> [:, :, :=>, :, :, :, :, :, :__id__, :__send__, :allocate, :ancestors, :autoload,
 :autoload?, :class, :class_eval, :class_variable_defined?, :class_variables, :clone, 
:const_defined?, :const_get, :const_missing, :const_set, :constants, :display, 
:dup, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :id, :include?, 
:included_modules, :inspect, :instance_eval, :instance_method, 
:instance_methods, :instance_of?, :instance_variable_defined?, 
:instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, 
:kind_of?, :method, :method_defined?, :methods, :module_eval, :name, :new, 
:nil?, :object_id, :po, :poc, :pretty_inspect, :pretty_print, :pretty_print_cycle, 
...]

If you know anything about Ruby low level you might guess someone got smart and decided it was better to utilize the Symbol table instead of building these lists of anonymous String instances.

Hash; preserving item insertion order

Yes, Hashes are now ordered… which is pretty odd if you’ve been writing Ruby for awhile now. We all used to utilize Arrays, and I hope we still do. But Hashes are now ordered by the pattern in which you insert keys/values into them.

[1,2,3,4,5].inject({}) { |hash, value| hash["name_#{value}"] = value; hash }

# Ruby 1.8
=> {"name_4"=>4, "name_5"=>5, "name_1"=>1, "name_2"=>2, "name_3"=>3}

# Ruby 1.9
=> {"name_1"=>1, "name_2"=>2, "name_3"=>3, "name_4"=>4, "name_5"=>5}

As a community, let’s not go nuts and start replacing our usage of Array’s with Hashes when we needed to persist order. I’m fairly certain the speed of an Array will always trump a Hash.

Named/Coroutine style Regexp

Dave Thomas can give you a better description than I can…

sentence = %r{ 
    (?<subject>   cat   | dog   | gerbil    ){0} 
    (?<verb>      eats  | drinks| generates ){0} 
    (?<object>    water | bones | PDFs      ){0} 
    (?<adjective> big   | small | smelly    ){0} 

    (?<opt_adj>   (\g<adjective>\s)?     ){0} 

    The\s\g<opt_adj>\g<subject>\s\g<verb>\s\g<opt_adj>\g<object> 
}x

md = sentence.match("The cat drinks water") 
puts "The subject is #{md[:subject]} and the verb is #{md[:verb]}"

Dir.exists?/.exist?

This one annoyed quite a few people, because before you had to do File.exists?(”/tmp”) to test the existance of a directory. Odd, but fixed.

Negative operators such as ”!”, ”!=” and ”!~” are now overloadable

OOOHHH… more fun for the DSL writers out there! dm-core, I’m looking at you! :)

Rake and RubyGems Made Core

Both Rake and Rubygems are now included in the core library. Hopefully it’s still as easy to upgrade them both!

Thats Not All

Of course this isn’t it, and the entire list is a great read. If anyone else has anything feel free to post… like the difference between proc and lambda now, new Hash key syntax {apple: 1, pear: 2} or anything else… feel free to comment.

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.