mixonic

Synchronous persistence APIs should be considered dangerous. Often they solve the immediate problem, but when you eventually need to move to an async storage solution (and in JavaScript any significantly complex task eventually becomes async) you are left with code that presumes sync behavior. This makes it difficult to refactor.

Providing an API with callbacks or better yet promises forces you to write future-safe code.

If people in "node land" want to keep using JavaScript they will eventually be using ES6 modules. Or they will fork the language. I would not place money on the Node team wanting to fork JavaScript.

And while they move, they are filing issue bankruptcy.

574 open issues exist for TypeScript on Codeplex. https://typescript.codeplex.com/workitem/list/basic

"Please note: since we’re moving to a new issue tracker and a new codebase, we are not copying all issues over. If you have issues in the current CodePlex issue tracker, please try them against the new codebase and file them in the GitHub issue tracker if they still repro."

Github is back up to 117.

Managing an open source community is something that the TypeScript leadership still have yet to learn. They weren't concerned about coordinating with TC39 on module syntax (they shipped 1.0 with an arbitrary snapshot), they were never very interested in accepting code, and they don't value the time users take to document bugs and edge cases.

tl;dr the move to Github is lipstick on a pig. It is a distraction from the real changes they must make on order to collaborate well with others.

We discussed dropping Torii's simple session manager in favor of recommending Simple Auth, but after discussing it with @marcoow decided we had slightly different goals. Torii's session manager imposes structure and terminology on your code, but had no specific conventions around how to pass request authorization to API calls, how to store a session, etc.

Torii's providers are designed to be re-usable without the session manager though, and they work just great with Simple Auth. Check this out: https://github.com/Vestorly/torii/blob/master/example/simple...

Auth is always a challenge. Simplifying the design of an application's auth solution is a great way to make clear the risks and tradeoffs it presents.

Web accessibility, as we commonly use the term, pertains to creating a website that disabled users can interact with an navigate. It does not pertain to those who choose to or are forced to disable JavaScript (the RMS example). Creating an accessible site is a challenge regardless of what technologies you pick, for sure. Just as saying "just because your screenreader supports JavaScript does not mean you have no accessibility issues", just because your website uses JavaScript doesn't mean you have accessibility issues. A plain HTML website can have accessibility issues. So can a JavaScript one.

AFAIK, nothing in WCAG says you must have a non-JavaScript fallback to adhere to their standard. If you can back that up I am all ears, I would be interested to read it.

> Google making this change makes it possible to have your non-fallback JS-only application be indexed. It does not make it more attractive from an SEO or accessibility viewpoint.

The attractiveness of JS heavy development is not in an inherent SEO or accessibility benefit. Absolutely true.

The benefit is a development style that is more productive, giving me more time as a developer to focus on solving the problem at hand, be it business logic, SEO, or accessibility. You can debate this benefit, but don't imply that single-page apps cannot have SEO on par with HTML sites and good accessibility.

100% FUD.

There is no evidence that Google is going to punish my website for being rendered with JavaScript, as you imply with your first two comments.

Google is indexing the HTML generated by JavaScript, and the links in that HTML. Not some non-web custom format like SWF.

JavaScript driven sites work just fine with modern screen-readers. https://developer.mozilla.org/en-US/docs/Web/Accessibility/A... and in 2014 97.6% of screen-readers ran JavaScript http://webaim.org/projects/screenreadersurvey5/#javascript

In 2013, 92 out of 93 visitors to a UK government webpage supported JavaScript: https://gds.blog.gov.uk/2013/10/21/how-many-people-are-missi... And mixed into that 1.1% were users getting broken JS, behind firewalls, disabling JS, etc.

Google making this change does not force you to build a JavaScript-driven website, but it does make it more attractive .

I'd debate the phrase "step back". If you replace all your references to PAGE with URL, you get closer to a real meaning.

URLs for single-page applications are a serialization of application state. The fact that we now have an application platform (JavaScript/HTTP) providing sharable, mostly-human-readable state sharing (URLs) and is also indexed and searchable is nothing short of incredible.

Yes, the basic abstractions we use are the same. We will have URLs that address content in our applications. But now these are applications running on Google's own servers. Google is running my application (and hundreds of thousands more), and trying to understand what they mean to humans. This is a pretty amazing step forward.

Imagine Apple announcing it would run all iOS applications, interacting like a user to build a search index. IMO, this parallel shows what makes Google's commitment to running JavaScript apps exciting.

Neat visualization, 100 megabytes of ram consumption! Sometimes as much as 8 meg GC during a JavaScript frame, making the frame bloat to over 50ms of running time.

I bet there are some cheap wins you can find in there OP! Keep up the good work.

It is notable that TypeScript chose not to track the ES6 modules standard for the last half a year: https://typescript.codeplex.com/discussions/446695 The modules you are writing in TypeScript are not compatible with ES6.

The TypeScript language team has yet to prove that they will track the specs and implement features as spec'd. I think claiming that they will "implement ES6 features" is a bit pre-mature. So far, they have implemented a few drafts and ignored a few others. A mixed bag.

jshint is an excellent tool for static analysis.

Aptible is another young startup in the HIPAA space: https://www.aptible.com/ They support a PaaS model similar to Heroku.

Oh my man, you really need to dig into the resolver! You can avoid the App. namespace entirely if you already use modules. This is what Ember-App-Kit and Ember-App-Kit-Rails already do with ES6 modules, just transpiled to AMD internally.

And yeah, I'm unsure of that the behavior will be in HTMLBars. I really hope it doesn't touch logic inside HTML comments- that would be quite nice.

Just a nit for accuracy, but the implication that "the Ember resolver will load code when you store it in App.Foo(Controller|View|Route|...)`" eagerly is not true. I believe the author use an HTML comment to comment out his usage and not a handlebars comment, so the code was still being run (just hidden behind html comments).

But regardless, Ember will not load everything in the App. namespace blindly- it will wait until that item is required, then try to load it.

This is your helpful Ember #protip for the day. :-p

It is worth noting that Google Cloud Storage has had this functionality for well over a year (maybe since 2010), as well as proper support for CORS so you can use XHR2 for uploads. And read-after-write consistency. If you are a developer who remotely cares about this feature, my personal recommendation is to at least compare the options.

OP here! Awesome stuff @jeremymims. Thanks for the insights.

"All the surrounding conversation about copyright infringement is just so completely missing the point" <- I completely agree, and that is my point. Scrollkit made a big deal out of the copyright issue, and that wasn't needed. At best they ended up with muddling noise- I think they could have taken their demo, pitched it to a few high-profile newsrooms, then made a big deal about changing the way XXX company delivers news. Instead, they had a very public spat with someone they should have been announcing a partnership with. If I had to pick one, I'd pick the former.

If this mess has landed Scrollkit a few customers, great. I suspect they could land more if they work with media companies instead of trashing their legal departments on a blog post :-p

I've also seen a speedup in Rails app boot time (the require optimizations):

1.9.3-p194: 11.8s

1.9.3-p385: 9.9s

2.0.0-rc2: 6.1s!

Tests were done with `time bundle exec rake environment` 5 times, dropping the highest and lowest and getting the mean of the rest (lazy snow day benchmarking). Very exciting!

I really wish Rubinius has become Ruby 2.0. Making Ruby more Ruby and less C opens lots of doors.

There are not 200 million gun owners, but there are ~270,000,000 privately owned guns in the US (http://www.gunpolicy.org/firearms/region/united-states). That's a gun for 8.5 out of 10 Americans. Or 3.4 guns for every legal gun owner.

I think this is a fact gun rights folks miss. We can clear people when they purchase guns, but a gun is a lethal weapon for years. You can't guarantee it won't fall into other hands in 30 years.

Some people argue we should give up, and embrace the number privately owned weapons in the US: http://www.theatlantic.com/magazine/archive/2012/12/the-case...

Others argue that registration of weapons is a better solution: http://swampland.time.com/2013/01/24/fact-check-the-gun-regi...

But the sheer number of these things is amazing. FWIW, the country with the second highest number of guns per capital is YEMEN. With a gun for only 5.4 out of 10 citizens. http://en.wikipedia.org/wiki/Number_of_guns_per_capita_by_co...

(IMHO, gun registration and improving our mental health system would go a long way toward addressing gun violence)

This has definitely changed. In the pre-1.0 phase, Ember was supposed to move quickly, to iterate and figure out what the right abstractions were. Since the pre.4 release and the PeepCode (https://peepcode.com/products/emberjs), the core team has committed to keeping the APIs stable.

From this point forward, master is committed to having all the examples in the PeepCode working until 1.0. It's been a long and wild ride mck, but the turbulence has stepped down a notch for sure.

I'm using Ember-Rails every day, and hundreds of others must be as well. If it's broken for you, please create an issue! I think I'm on master as of two weeks ago and sailing smoothly.

Thanks Jeff!

I've been messing with S3 for a new project involving the HTML5 canvas- So lots of CORS and canvas security concerns, PUTing objects from the browser, and desire for low-latency changes.

S3 has not been delivering. Here's a few reasons:

* S3 only provides read-after-write consistency for non-standard regions: http://aws.amazon.com/s3/faqs/#What_data_consistency_model_d... Since moving to US-West-1, we've had noticeably more latency. Working without read-after-write just isn't an option, users get old data for the first few seconds after data is pushed.

* CORS support is basically broken. S3 doesn't return the proper headers for browsers to understand how objects should be cached: https://forums.aws.amazon.com/thread.jspa?threadID=112772

* Oh, and the editor for CORS data introduces newlines into your config around the AllowedHost that BREAK the configuration. So you need to manually delete them when you make a change. Don't forget!

* 304 responses strip out cache headers: https://forums.aws.amazon.com/thread.jspa?threadID=104930... Not breaking spec right now, but quite non-standard.

* I swear, I get 403s and other errors at a higher rate than I have from any custom store in the past. But this is purely subjective.

Based on all this- I really need to agree with saurik that the folks at S3 aren't taking their role as an HTTP API seriously enough. They built an API on HTTP, but not an API that browsers can successfully work with. Things are broken in very tricky ways, and I'd caution anybody working with S3 on the front-end of their application to consider the alternatives.

I'm moving some things to Google Cloud Storage right now, and it is blazing fast, supports CORS properly, and has read-after-write consistency for the whole service. Rackspace is going to get back to me, but I expect they could do the same (and they have real support).

"One objective reality is that our government doesn’t work, not because we have dysfunctional politicians, but because we have dysfunctional voters."

We have a dysfunctional political system that provides voters with leaders who are compromised. Who then pander, rabble-rouse, and pick narrow issues to speak loudly about to raise money. Who then lose our trust and respect, corrupting the institution. Voters are not too "dysfunctional" or ill-informed to make reasonable decisions. Approval of the US Congress was at %10 in August, the lowest in 38 years. The electorate isn't smiling through the failures of government.

The People are not the problem. I think Tyson would have answered different after a few hours with Lessig. Blaming governement's failures on a ill-informed electorate is second-rate at best.

Upvoted for comic genius. I appreciate you stcredzero.

SEEKING WORK - NYC, remote

Myself and a friend are both experienced, senior web developers (Rails & Ruby, Ember, Coffee, Backbone, Scala for starters). We're looking for a project we can knock right out of the park. We've both been founders and early employees at several startups in NYC and elsewhere, but never worked together.

Some things we've been interested in lately: iOS development, Ember.js and thick-client apps, mobile optimized web dev, git integrations, ways to interact with the physical world, ways to build better teams and culture.

Our ideal project is probably remote, about 20-30 hours a week each, has a clear finished state, and involves solving a new problem. We're open to project rate, hourly rate, or equity compensation. Basically, we're flexible about all this stuff and just looking for smart people who would like to work with us. So get in touch. matt.beale@madhatted.com

Finally, something New Yorkers are happy to be #2 at.

SEEKING WORK - NYC or Remote

http://madhatted.com matt.beale@madhatted.com

Fullstack web developer with a background in startups, eager to work with the smart people on your team to build something great. I've been working with Rails since 2006, but I'm comfortable with everything from Linux command-lines to writing tested Javascript libraries.

If you're doing something with Ember.js or an ambitious client-side app, let's talk!

Harvest, Balance Media, Disrupto, Pivotal (I know 6 months ago they were starting to get serious about Tracker as a product), and that's only off the top of my head. I think turning to product dev is a pretty common aspiration for consulting companies.

I'm required by bootstrapper law to mention a project I'm working to get out of beta now:

http://spintoapp.com

Spinto is Git-based, like Heroku, and uses Jekyll with pre-processors for Sass/Scss (and Compass, Bourbon), Less & CoffeeScript. I agree with Brandon that FTP is hopelessly out of date and frustrating. Even more than that, I think there is madness in the idea that you need a database backend for your website to let somebody else change a comma, or an image (sometimes you need full-blown-CMS, but not always).

I'm trying to make a static websites easier for us to create, deploy, and collaborate on. Feedback _always_ appreciated.