Why would they mention smalltalk? The article is framed from the writer's specific experience with both languages, not as a historical deep dive into the progenitors of Objective-C.

Granted these historical details are super interesting, but feels far from the intent of the article.

Because that is in essence why Obj-C works the way it does -- e.g., has all the square brackets. Obj-C is the child of smalltalk and C. It wasn't created in a vacuum.

> As a simple solution, one could pass a signed auth-hash of the fields generated by form_for, and the server could re-hash the fields submitted to ensure the form data you asked for is what you get (this solves the primary issue with attr_accessible).

It does not solve the issue of javascript generated forms.

If you turn it off then you're back to square one security-wise. Apps that have neither APIs nor JS are an increasingly small share these days. Also consider what is possible to sign. In most cases there will be some non-enumerable data in the field, leaving you with only being able to verify the field names, but there could be nested data and it seems like a 50/50 shot that whatever unforeseen vulnerability would not need to change the top-level params anyway. I don't think this would afford much of a security guarantee.

The only way to fix this by "more of a focus on security" would have been not to do clever things with parameters in the first place, but the clever things provide a lot of value, so the next best thing is security auditing and be on top of patching any vulnerabilities.

A better solution would be to just use Observers. One for email, one for twitter. The user shouldn't care about how to talk with these services.

Observers are one of the worst possible solutions because they lie outside the purview of, well, everything in the system. You don't ever see them in the code. You don't know they are there. They are pieces of unicorn code that have side effects that you won't know about or see because they aren't "in the code". Horrible solution.

Code should be simple and easy to understand. Observers add significant complexity and make your code vulnerable to unnecessary bugs because the code that acts on your objects is invisible to the normal control flow of the program and those who write or maintain it.

They add (at least in Ruby) a few lines of code to a program; and take things like Email out of the User model and put them in a more appropriate place.

And you'd never know that they existed if you look at the user model...

My stance is that things like sending email should be explicit calls so they are obvious. Sending email when registering a new user, for example, should be in the if user.save branch in your controllers or, if you have a more SOAish app, in the service that creates users.

def create user = User.create(params[:user])

  if user.save
    Emailer.new_user_email.deliver
    render 'welcome'
  else
    render 'oh shit'
  end

end

Or, refactor that out a bit (ONLY IF NECESSARY!)

def create user = UserService.create_user_from(params[:user])

  if user
    render 'welcome'
  else 
    render 'oh shit'
  end

end

+1 don't worry I'm patting myself on the back right now.

Swing and a miss

Am I missing something? Just install gitosis and save yourself the $600/user/year

Because developer time costs between $1k - $2k a week. This isn't targeted at companies getting to ramen profitability.

Opportunity cost. If a developer has to stop his work and spend the next week wrestling to get a sub-standard system up and running, then deal with maintenance and security fixes, $600/user/year starts to look cheap.

You have a lot to learn about enterprise software.

What's gitosis? I was thinking of installing Gitorious, but from the sounds of it, it's quite complicated. Yes, it's a Rails app, but there are lots of background queued activities, cron jobs, daemons, whatever to setup alongside it for things to function right. If GitHub:FI is really as easy to install as they say it is, then it might be worth the cost for a whole lot of people (something they're counting on no doubt).

Edit: Here's the blog post I was using to judge the install complexity of Gitorious: http://erikonrails.wordpress.com/2008/05/11/how-to-get-gitor... And after all that, several things still aren't finished:

  What’s left to do:
    * I haven’t configured ultrasphinx, so search doesn’t work.
    * I haven’t set up script/graph_generator, so there are no graphs.
    * I have no idea what script/fixup_hooks does. It might be important.

gitosis != gitorious.

gitosis is a really simple collection of scripts that basically allows you to do the same thing with git that you were able to do with SVN by hosting a repository on some server and provide SSH access to it.

Merge requests, merge notifications, easy cloning but also peripheral stuff like bug tracking, wiki and whatnot will all have to come from other places.

Gitorious on the other hand is much closer to github but it is, als you pointed out, a real pain in the butt to install and also has some really nasty assumptions about URLs and SSL in the code that make it even more painful than what it is anyways.

Combine that with no real release schedule, no integration what so ever into any eventually existing authentication infrastructure and very lacking documentation and you'll notice that Gitorious just isn't at a point where it's worth investing time into just yet.

I do think though, that the prices for GitHub:FI as they are revealed now are not really reasonable: You are paying much more than what the most expensive hosted plan costs even if you don't use their support, but you are left with the maintenance of the machine and its backups.

So you are paying more and are left with more work.

And all this because you cannot or do not want to upload your intellectual property onto a third party server (which, in my case, is even located in a foreign country with legislation not properly known to me).

So you are paying more for more work.

When you see this, you will just have to ask yourself, whether the benefits of github will justify the cost.

Installing gitorious is (at least right now) out of the question, but I had really good success with gitosis and redmine.

It's still lacking some web-based way to request (and apply) merges and stuff, but at least it's easy to set up, works and doesn't cost ~$4500/y (that about the price I would pay GitHub:FI for my 6 developers - and this one is way higher than what it cost me to install and even customize gitosis and redmine - and I had to do that once)

OK, I feel dumb. I hadn't heard of gitosis and just assumed (bad idea) that halogen64 was talking about gitorious. But really, gitosis doesn't seem like any real comparison to GitHub or Gitorious as far as features, am I right? Hosting Git repos is already pretty easy with SSH in my experience, but I'm sure I'm missing something or just making more bad assumptions. It's the online visualization and collaboration that GitHub brings that might be worth the cost.

You are right - it's no real comparison.

But still, using gitosis to host the repositories has some advantages over plain ssh:

    * you only need to create one git user
    * people don't need shell access to the machine
    * you have fine-grained control over who has push access and who doesn't.

As it's really easy to set up, it's always worth to go the gitosis route if you just need SSH repository access.

But yeah, the visualization and collaboration you don't get. For that you need to decide between Gitorious (doesn't look as nice, real pain to install, but open source and no associated cost aside of your own resources) and GitHub (really good-looking, (probably) easy to install, proprietary and quite expensive).

Judging from Gitorious' current state, I'd say GitHub is, for a non-ruby/rails programmer, less expensive to install and use than Gitorious, but it's still too expensive for what it provides, especially when you compare it to the hosted plans which are cheaper while not leaving you with backup and machine maintenance.

we use redmine+gitosis at the moment, and man would I love to get my hands on github:fi. Redmine completely fails to be anything other than a bug tracker when you start dealing with public branches, of which it has no concept.

We definitely don't want to host our source on somebody else's machine, and there's no open source solution comparable to github.

It's too expensive for us at the moment, but I can imagine a time when it won't be, and I'll push to get it then.

What do you mean by public branches? Can you clarify a little bit since we're trying to evaluate Redmine and see if it will work on a fairly large sized team of Rails hackers (15+)

Redmine IME is fine as a bugtracker, but it's not built to handle a DVCS.

So, basically, git works by blessing a branch on some server as "master". Since many of us are working on new stuff at the same time, and we don't want to work in master where our work could conflict, but we do want to see each other's changes. Thus, we make branches on that same server which we all track - these are what I mean by public branches.

So, basically this is how I'll work:

* Pick a bug out of the bug tracker

* make a public branch of the current master and call it [name]-fix-[bug #] or [name]-[new feature]

* push fixes/development to that public branch

* ask a coworker to review the branch for merge (this is easy, since it's a public branch they're tracking already)

* make any changes they recommend, rinse and repeat

* merge the public branch into master and push it to the remote repository

The problem with redmine is that it only tracks the master branch, not any of those feature branches that me and my coworkers are working on, whereas github shows them admirably, e.g.: http://github.com/rails/rails/network .

I love git, but redmine is basically unable to cope with the way we work.

Oh and if you want to work this way, this script is invaluable: http://git-wt-commit.rubyforge.org/git-publish-branch

With gitosis you just get repos + auth, with this you get github.