jherdman

Ajax requires long polling, this PUSHES the response to the server, thus obviating the need for long polling.

I think this is a bit of an overreaction given that Rails has always been a "batteries included" framework. The fact that Rails allows for socket-like behaviour now is not a tipping point, but simply a nice little feature that may prove useful to some.

When Rails starts including a messaging stack, job server, and more, then I'd be right behind you in your complaint.

Concentrate (OS X): Pricy, but absolutely invaluable for me http://getconcentrating.com/

And if you want to get really fancy, there's Github Pages -- http://pages.github.com/. So, you get all of the benefits of the repo approach, but your pages can be all sexy and stylish.

I like it. A VERY MINOR piece of feedback: the font is ugly as sin. I don't know why, but it kept distracting. It feels... off balance.

Homebrew doesn't handle software that updates itself. It's an opinionated piece of software.

UPDATE: More on this here http://blog.izs.me/post/3295261330/on-npm-and-homebrew

Git best practices say the first line in your commit message should be no more than 50 characters. Subsequent lines should be wrapped at 80 characters. See http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa...

If you don't like Quicksilver, Alfred is really good too (http://www.alfredapp.com/).

Sublime Text 2 is pretty great (http://www.sublimetext.com/2).

Don't bet on it. A lot of sports data is highly encumbered by copyright.

Thanks for the info! I love learning things :)

There are a few comments in this post that touch on the flaws of this API. Here's the gist:

1. HTTP methods are improperly used. The documentation states "All API calls should be sent as a GET HTTP request". GET is used to retrieve resources, and should be cacheable. It should NEVER change the state of a resource. Yet we see in that it's used to delete, create, and modify resources! Examples:

GET https://subdomain.sharefile.com/rest/folder.aspx?op=create...

GET https://subdomain.sharefile.com/rest/file.aspx?op=delete

These should be as follows:

POST https://subdomain.sharefile.com/rest/folder.aspx

DELETE https://subdomain.sharefile.com/rest/file.aspx

HTTP verbs have specific semantics that allow for intelligent, scalable architecture.

2. Individual resources are not identified by an unchangeable URI. Let's say I want a folder:

GET https://subdomain.sharefile.com/rest/folder.aspx?op=get&...

Nope. This is more RESTful:

GET https://subdomain.sharefile.com/rest/folder/123

Two things to note: 1) no 'aspx' bullshit, that's implementation and shouldn't be visible to the user, and 2) the ID is in the URI itself as opposed to the params. URIs should seldom, if ever, change. Parameter names may change, URIs shouldn't.

3. Violation of content type retrieval. Let's say I want a folder as XML:

GET https://subdomain.sharefile.com/rest/folder.aspx?op=get&...

Wrong. This is the request I should be sending as a curl:

curl https://subdomain.sharefile.com/rest/folder/123 -H 'Accept: text/xml'

Note that I'm using the Accept header. This allows for flexibility in accessing my resource. With any luck, the server will give me an XML file, and its content type should be "text/vnd.sharefile+xml" (vendor specific content types are best).

4. No link relations in the body. I'm mostly assuming this because I haven't seen sample response bodies, but almost no one does this even though is a crucial aspect of a RESTful service. RESTful services describe the relationship between resources. Suppose I have an ordered collection of files. When retrieving a file, it should describe its relationship in this ordered collection. This is done either via the LINK header, or some sort of scheme in your response body (e.g. JSON Schema describes 'link' attributes).

A pretty good RESTful API is Github's (see http://developer.github.com/). If you'd like to learn more, I highly recommend "REST in Practice" by Webber, et al (http://www.amazon.ca/REST-Practice-Hypermedia-Systems-Archit...).

Still boned. I'll try again later. I'm looking forward to it!

Sounds interesting, but... I think your site is down.

Another alternative to Pathogen is Vundle (https://github.com/gmarik/vundle). I've been using this one for a while and really enjoy it.

Though not written in Python, I'm a fan of Jekyll (https://github.com/mojombo/jekyll). You write your entries in Markdown, it converts them to HTML, sets up links and embedded content, and then publishes them to your server via Git to be served up by Apache, Nginx, etc.

I'm reading a bit into his words, yes. Here's the part of interest:

"""You don’t have this problem with chat transcripts. Forcing people to reduce their otherwise rambling thoughts into concrete sentences helps focus discussion, too.

We’ll have meetings at GitHub, but I can count the number of full “meetings” we’ve had in the last year and a half on one hand."""

The former bit implying that the focus of sentences helps, the latter bit implying to keep the membership of the meeting to only those required.

Again: siloing is far more toxic than meetings in my experience. It's far too easy for a dev to wander down a path that has no value when operating in a silo. Agile tells us that we need to exist in a state of constant communication and feedback. This necessitates meeting with people in some fashion.

I really wish the author didn't use such an inciteful title for his section on meetings. The title offers another catch phrase to avoid meetings. I'd much rather have seen Zach focus more on his actual point: holding short, focused, and tiny meetings. I fear that his title, and other catch phrases like it, encourage siloing. Siloing is far more "fucking toxic".

Alternatively https://github.com/popular/watched

What Windows text editor do you miss when on OS X?

I'm using this on a project right now and am finding a lot of successes derived from its use. We tried to build our JSON in the model using the traditional #to_json/#as_json approach in Rails, but found this was falling on its face when our data model became more complex (which, itself, is probably a code smell, but that's another story).

Good luck! I hope it brings you success.

I was really hoping for a bit more meat in this article. Perhaps some discussion on their caching strategy, or how they're building their JSON (i.e. traditional model-based #to_json approach, or something along the lines of Rabl).

Their motivations, quite simply, are different than yours.

The key differentiating factor is that the iCloud heralds an era wherein all of your data is decentralized, all of the time, and that this is the default for all users, on all Apple devices, all of the time.

I'm actually a little confused by this. Isn't one of the major benefits of Scala, Clojure, JRuby, et al, that it is hosted on the JVM?

Like hell I would! Nothing beats face-to-face communication, and the wonderful things that can arise from spontaneous interactions.

I want to believe that serious devs, OSS or otherwise, would be thinking about something along the lines of semantic versioning (http://semver.org/) as they bump version numbers.

Additionally, marketing likes to see the major number change (the "X" in the X.Y.Z). I think the public does too. They feel like they're getting more bang for their buck.

Is there something better than Viper mode for Vim folks? It just doesn't feel complete... I'm trying to give Emacs a shot as I learn Clojure.

I found this one the other day: SICP in Clojure (https://github.com/deobald/sicp-clojure). It's sadly not done, but looks promising.

I've done this on a project I worked on recently, so I'll take a moment to explain why I think this is a valid, and safer strategy than the alternative.

In said project we had a number of modifications to libraries to support some additional desired functionality. The developers at the time simply forked the library and wrote patches on top of the mainline branch. We found this significantly impeded our ability to upgrade, or take advantage of changes, down the line, as well as to track upstream's HEAD. When one forks, branches, and then patches on the branch, these problems are easily skirted. In addition, it's easy to submit your patches for integration into upstream.

In the end the gain is flexibility. One cannot discount the value of flexibility.

I can't shake the feeling that people that like CoffeeScript are those that don't "get" JavaScript (e.g. CoffeeScript's notion of a class, whereas JavaScript has none -- let go an embrace the prototypal object model). Further, most (if not all) of the examples of the problems with JavaScript are null and void. A language that combines paradigms? Most do. Sure, the name sucks, but that's hardly an issue.

I understand that syntax may be more convenient for some, but this is indirection, and is a source of complexity that may impede collaboration from other devs more familiar with JavaScript.