binspace

I used to organize js binding based on the controller (https://github.com/pivotal/jelly), but found that it is better to base it on the template.

There are a few reasons:

1. It makes more conceptual sense. The javascript relates to html (which is generated by the template), not a controller action.

2. You will probably want to reuse templates across different controllers. Also partial templates can have reusable behavior.

3. It is easier to move between the associated javascript + template

4. Refactoring is easier, especially with html gotten via AJAX

What a load of horse shit. The place that is willing to sue open source developers is the place that gets shitty programmers.

> I wonder what happens with PHP... ;-)

Ignorance is bliss?

> Of course. Python users are happy people.

Heh, I've been using Python lately and have felt lots of urges to swear, but I can't get myself to commit it. Shoot.

Rendering members of Arrays should also be in the spec. I believe mustache.js has support for changing the iterator rendering token, however mustache.rb does not.

{ "items": ["foo", "bar"] }

# From mustache.rb

{{#items}} {{{to_s}}} {{/items}}

> {{#genes}} open table {{#rows}} row stuff {{/rows}} end table {{/genes}}

JSON templates has an interesting solution.

http://json-template.googlecode.com/svn/trunk/doc/Introducin...

{.section genes} open table {.repeated section @} row stuff {.end} end table {.end}

Got it. I guess the distinction is not that big of a deal for me, though it would be nice to have the inline {.or}-like construct (it saves one statement).

> Why would it be moot?

Because the server generates the javascript template methods. Thus the browser does not need to parse the mustache templates. It only needs to call the compiled functions. This means the browser would not need to have an implementation of mustache running on it, since the template building is contained within the compiled javascript functions.

Mustache has an equivalent to {.or}

{{^something}} {{/something}}

The draw of mustache is that it does things implicitly. I don't have to worry about .section, .repeated, .or, |html, for example. Mustache does it for me.

That being said, one thing that mustache does need to address is the difference between conditionals and repeated operations as needed (handled by .section and .repeated in JSON Template).

AFAIK, the songs template would require a boolean to be passed in of the existence of songs in mustache, since mustache would implicitly assume that {{#songs}} was a loop and create multiple tables.

http://json-template.googlecode.com/svn/trunk/doc/Introducin...

I propose we have a mustache convention at the end of November (grow a mustache month). Those without mustaches will be shunned and not taken seriously (those unable to grow naturals can wear fake stashes)!

> the client shouldn’t even be downloading a .mustache template — it should download a .js file containing a pre-generated function which can be called with the context, returning the rendered template

This would render browser-side mustache as moot. Now the server side implementations must render javascript functions. handlebars.rb, handlebars.py, handlebars.php, handlebars.cs anybody?

As a user of mustache in multiple languages, I believe the most important priority of the mustache community is to have uniform implementations, which is what the mustache spec will hopefully solve.

There are some features that do not seem to be consistent across implementations. For example, partial templates are handled differently in mustache.rb and mustache.js.

It seems like there are attempts to "embrace and extend" the mustache language (handlebars and mustache.js), which is fine, as long as the spec is adhered to and the good features get folded into the spec.

The innovations are happening despite ip restrictions. It has been historically shown that innovations increase after the ip restriction expire.

http://www.thefreemanonline.org/featured/do-patents-encourag...

Html5-based apps allow you to share (javascript) code between your web site and mobile applications.

This infographic is pretty confusing. The numbers are much more easily explained with a bullet point list or graph.

72 character lines is unnatural to read for long sentences (especially in web browsers).

Also, less has line wrapping and who develops using 80 character terminals anymore? Maybe the author has a time machine back to 1981? I want access to that!

Clicking on the "Click here" doesn't even work for me. I'm running ubuntu.

My personal experience is that tech conferences tend to encourage cliquish and hierarchal (based on popularity and tech-sphere influence) behavior which feels dehumanizing.

I think there is a common thread with my observation to sexual harassment at conferences. When people relate to each other on a human (rather than hierarchal level), people tend to respect each other more.

edit

Women also bring greater social cohesion to groups.

http://www.sciencedaily.com/releases/2010/09/100930143339.ht...

The fact that women are sexually harassed could be solved by having more women at conferences.

It will only take 35 days and 18 hours.

I get more psychological assurance by paying less overall, thus I feel better paying off the higher interest loan.

Agreed. Punishing people who make stupid comments seems like it causes resentment and anger and thus more stupid comments.

I wonder if there a parallel with the whole punishment vs rehabilitation aspect of the justice systems. In essence, a justice system is a social tool to cause people to act a certain way. Some techniques are better than others.

Also, consider the fact that Mongo is a document database, where each document has it's own schema. Postgres (and most other relational databases), has a single schema for the table.

There are tradeoffs with each approach. I've found that that migrating Mongo documents tends to require more software for easy migrations, but also tends to be more flexible.

For example, you can lazily cache data from services and since the schema is flexible, a single collection can seamlessly hold different types of records.

Replication is also more natural with Mongo.

Of course, reporting and getting aggregate data is easier with Postgres.

Good thing the US invaded Afghanistan, I suppose... Afghanistan has lot's of mineral resources. Let the exploitation begin.

http://blog.foreignpolicy.com/posts/2010/06/14/say_what_afgh...

Hopefully, Afghanistan has a functional (and non-oppressive) government that can stand on it's own soon. That will be tough, if possible, to accomplish.

I am in the wrong profession.

True, but they are still different use cases. For example, Facebook friends seem to respond more to my posts than my Twitter followers.

Twitter seems cold and impersonal. Facebook has my friends on it so it's warm and fuzzy.

I wonder how long it takes for the observation to influence the results, thereby invalidating the observation.

I'm starting to see more women in the SF ruby community. There has since been a more concerted effort by Gogaruco (among other Ruby functions) to be more female-friendly.

True, it's over HTTP and that's pretty much it. No abstraction layer (with software) that duplicates many features that HTTP already provides.

First of all, the fact that you need such a code generator for the interface is a smell, not a good thing. To consume a REST service, you just need an HTTP client, possibly some authentication hashing, a url, and parameters and a json parser. You then get a hash.

The Web services I've used tend not to be super complicated. A handful of api calls tend to be used.

There's also versioning, which is handled well with a good url structure.

Also, the schema problem is more of a JSON vs XML issue. I personally use JSON because it's simpler for flatter data graphs. I also use JSON schema btw. XML does have the advantage of xpath (or css selectors) too.

But even in the REST + XML case, the XML is simpler than the XML + SOAP case.

Which brings up Content-Type. Rest can serve pretty much any content type in a way that's readable by almost any web-enabled client. Not so with SOAP. You need to have more software.

Basically, I can add these features on an as needed basis. REST is easier to work with right now and I probably will not need all of the features of SOAP. That's the gist of why it's less popular now.

It's complicated, difficult to understand, requires large tools (expensive ide's) to be productive with, different vendors have different interpretations of SOAP anyways.

Basically, it's a bunch of extra work and requires more documentation due to the complexity of it's implementations.

Also, SOAP libraries (e.g. Soap4r) are problematic (doesn't talk to Micro$soft's version of SOAP properly).

REST is over HTTP. Just about all programming environments have a HTTP library.

> Patents remain relevant and valuable in fields beyond software, where product development and basic R&D costs a hell of a lot more than it does in our little field.

There's evidence that innovation increases without patents.

http://www.techdirt.com/articles/20100421/1451179133.shtml http://www.readwriteweb.com/archives/study_says_patents_hind... http://blog.mises.org/10217/yet-another-study-finds-patents-...

Patents are rent seeking agreements and have long since been outdated, if they ever made sense.

Basically, I think of patents in the same light as special interest groups. They promote the welfare of the few at the expense of the rest.