straws

It's pretty easy to embed tweets nearly everywhere

That's a really good point — the lack of a common content interface is pretty tricky.

I've really like http://www.silkapp.com/ for this sort of thing. I think their API (http://developer.silkapp.com/) is great, and they have neat tools for editing structured data

In this case though, it'd really benefit from being visible — all non-editable views into public google docs should be accessible

What an oddly responsive page

This is a very nice resource — the use of Autoprefixer and the SUIT/Montage class names is welcome as well.

I see a lot of impact in flexbox for progressively enhanced designs — designs that in their most basic form have simplified or single-column layouts — where most of the layout is handled by supported browsers. Do you imagine it's better to make a clean break and just depend on pollyfills/float-base `.no-flex` backup styles though?

This is an example of one of many functional abstractions that jQuery (carefully) adds to Javascript.

There are great functional examples in Eloquent Javascript, that show you how to go from low-level loops to high-level abstractions. That's EJ's triumph: it guides you through the mental leap you have to make to go from for loops, to useful enumerations like maps and folds and the like.

Looks as if it's only the length of the article body.

A little superfluous, but I can dig it.

Codemirror reigns

http://codemirror.net/demo/vim.html

I'm surprised they didn't call it VAMP

Still no rbenv love?

So then what's the other third?

You're still mirroring the structure of HTML/XML in your json documents though, which is a pain for large templates. Still feels like you're writing Artisanal Hand-rolled JSON.

My vote for this sort of thing has always gone to Plates: https://github.com/flatiron/plates

There should be ZERO logic in your templates — Mustache doesn't count. Bind JSON to HTML through a mapping of data to IDs/class names/data attributes, and your templates will be more re-usable and render faster.

The web is still for documents. It's for a resource that lives at a URL. It's markup, not programming, and that's the very reason it has lived to be twenty years old and the main way that information is communicated. It's how we're able to hold this conversation right now — people are comfortable stitching together words in XML-ish constructs.

The people making games, applications, and lush webGL marketing demos are people who can throw lots of engineering resources at a problem until it does the thing they want it to do. Web dev has always been an insane mountain of hacks in order to get pages to render, but the attractive and democratic reasoning is that that extra effort is worth it if the maximum number of people can access the information. People on old computers, cheap smartphones, kindles, chumbys, whatever. The best computer is the one you have on you, that sort of thing. Access and ease-of-adoption are powerful things.

So that's why I see web components as something that enables people writing markup more than it empowers people writing giant javascript applications. This is so that people can add <twitter-tweet href="twitter.com/name">My Cool Tweet</twitter-tweet> tags to their wordpress blogs, and so that the people making that <twitter-tweet> tag can be confident that it will render and not look horrible on that person's blog. It's so that the complex, app-ish things can be abstracted away and added to documents with a declarative and logic-less syntax.

No amount of java applets would have ever made up for that.

Eloquent Javascript is absolutely the right starting point, I'm glad there's been a shift from recommending The Good Parts to that one.

It was linked here the other day, but Superhero JS is another great "what is the path to javascript mastery" lists:

http://superherojs.com/

No love for the Hartford Whalers?

http://en.wikipedia.org/wiki/Hartford_Whalers

If someone speaks up to tell another human being that what they are saying is offending them, they're going out of the comfort zone of a shared public space to express their opinion. It's not an easy thing to do, and it should carry some weight. If this guy continues telling sexually offensive jokes after being asked not to, it doesn't make him a misogynist, in the same way that continuing to tell uncomfortable chicken jokes in the presence of the chicken-adverse doesn't make him anti-poultry. It just makes him an _asshole_. Public spaces are about trying to find a common ground among a diverse group of people, and it's the reason we as strangers usually just fidget and talk about the weather to one another.

I see this case as two people and two companies who acted like children and both lost their jobs and look bad in the community, respectively. Some unfunny man made a joke to his co-worker because he thought it might have eased the social tension that comes from traveling, lodging, and attending a conference with another person over so many hours. An overzealous woman took offense to an overhead comment and saw it more constructive to bring attention to the public conversation that happens on twitter rather than the public conversation happening in that room because it was a more comfortable way to make sense of how she felt.

We're humans and we naturally want to surround ourselves with people who think, act, joke, argue with, and support other people like we do. It's pretty easy to never have to deal with groups we don't agree with on the internet. It's the reason swarms of misogynists got together on the internet to hate Adria and say she represented all the other women that they hate, and to call her awful names and issue a DDOS attack against her parent company.

Both of these companies looked past the human error in all of this, and enforced their zero-tolerance policies, and just fired both of them. This whole thing is a big deal because the other people we align ourselves with and allow to represent us (be it as employees, or pythonistas, or dirtbag misogynists) are making it really hard to connect on personal levels, and really easy to generalize and dehumanize issues into meaningless black or white distinctions.

CS degrees are not a catch-all. Most teach data structures, algorithms, a little AI and database theory. Few teach how to structure programs.

I'm pretty sick of the "I work with people without CS degrees" excuse. Good software design really comes down to experience, persistence, and taste.

Seconded. If you're going to have any success in converting people who write Clojure code away from Emacs, you're going to need to copy its good parts.

Nice redesign though.

Well that's just awful.

Same, and return is my BufExplorer. Lightning fast.

I'm really in love with Component, which is a sort of package manager for front end development

http://component.jit.su/

It breaks down large frameworks like jQuery, Underscore, Backbone, Twitter Bootstrap, etc into small, reusable, and composable micro libraries. There are UI elements like tool tips and modals, wonderful and tiny DOM manipulation tools, well documented AJAX libraries, and more low-level functional and control-flow related tools. It's really amazing.

It's by TJ Holowaychuk too, who is huge in the node community (Express, Jade, Mocha, Stylus, Connect, and many others).

OK, this project and that Substance editor are amazing.

Well, this thread is a new low.

People continue to love netflix.

To me, this is the smartest part of using Clojure in your projects. If you're a company with an enormous Java stack, it's trivial to add things like Clojure or Scala and use them as scripting languages. Or break out a library and rewrite it using one of the two, if that problem would be better solved more functionally.

Basically it makes it easy to convert projects without tearing down your infrastructure, ie, easy to convince your boss.