This looks really excellent, I'm excited to try it out.

A similar and very powerful narrative can be found in _The Half Has Never Been Told: Slavery and the Making of American Capitalism_, by Edward E. Baptist. The book is slightly problematic in some of its methods, but overall I would highly recommend it to anyone who was taught the public school version of US history.

https://www.goodreads.com/book/show/14894629-the-half-has-ne...

Sounds great, what are the problems with its methods?

Cool!

I once wrote a much hackier version of complex arithmetic in JavaScript [0]. It was to support a visualization of the complex derivative [1].

I found it useful to think of a complex number as a point in R^2 that operates under some different rules. I used Mathematica's `ComplexExpand` to translate from traditional notation for complex numbers [2].

[0]: https://github.com/chnn/multivariable-derivative-viz/blob/ma...

[1]: http://people.reed.edu/~ormsbyk/projectproject/assets/posts/...

[2]: https://reference.wolfram.com/language/ref/ComplexExpand.htm...

This is rad! I wish it had MathSciNet as well.

https://mathscinet.ams.org/mathscinet/index.html

MSN isn't free, but MRef (https://mathscinet.ams.org/mref) is up to the task of finding an article given enough information about it.

Good ol' Socrates :)

This resonates with me very strongly. But it seems all too easy to extend this sentiment towards others and remind them that they don't know what they're doing, which creates a pretty toxic environment.

The violin plots are cool and look like a great alternative to box plots, I had not seen those before. Sweet!

It is nice as it shows distributions, not only - a few statistics. However, some shapes of violin plots can be... distracting. ;)

I've been working with Ember over the past few months and am still impressed with how simple and productive it makes every day tasks. Basic CRUD stuff, especially render code, is a lot less drudge work. I'm even more excited for where the community is leading the framework, through projects like ember-cli and htmlbars.

Ember is conceptually pretty massive though. A tutorial like Michael Hartl's Rails tutorial would be a huge benefit, it looks like that's what this is aiming for. Thanks!

On the other hand, I've found many things lacking in Ember.js, though most of my gripes are with ember-data, so I don't know if you're thinking of that as part of Ember.js.

A couple of examples of Ember.js-specific gripes though:

- We have a table with one of the filters just stops working after changing the value 4 ~ 5 times. I've dug into this, but I can't really figure it out without going into the Ember.js internals (which I have done before, but the time sink isn't currently worth it). I've boiled it down to the fact that at some point Ember.js stops responding to changes on a particular attribute. Computed properties stop working sooner, but even a .observes('attribute') stops triggering after 5 or 6 changes.

I get that software is not bug-free, but how am I supposed to even debug something like that? It would be fairly difficult (and time-consuming) to boil it down to a simple test case, as this is the only place we're seeing this happen and it's in a large Ember.js application.

- There is no case/switch statement in Handlebars. I'm left with deeply nested if/unless blocks, or tons of computed properties on controllers/views that generate this stuff. E.g.:

  {{#if valueLoading}}
    Loading...
  {{else}}
    {{#if valueLoadingFailed}}
      Error!
    {{else}}
      {{#if value.length}}
        <ul>
        {{#each item in value}}
          <li> {{item}} </li>
        {{/each}}
        </ul>
      {{else}}
        No Items.
      {{/if}}
    {{/if}}
  {{/if}}

vs.

  {{#if value.length}}
    <ul>
    {{#each item in value}}
      <li> {{item}} </li>
    {{/each}}
    </ul>
  {{else}}
    {{stateMessage}}
  {{/if}}

  ... and on the controller ...

  stateMessage: function () {
    return this.get('valueLoading') ? 'Loading...'
         : this.get('valueLoadingFailed') ? 'Error!'
         : this.get('value.length') === 0 ? 'No Items.'
         : '';
  }.property('valueLoading', 'valueLoadingFailed', 'value.length'),

1. Are you using Ember.computed's array methods? I tend to go with intermediately calculated arrays which I then union/diff/whatever is necessary for filters. It is also significantly faster than function-defined computed properties. The only bug I know of for this functionality was fixed in the 1.5 branch by @hjdivad.

2. The typical pattern is lots of computed properties. They're lazily calculated, so that makes them pretty cheap.

> 1. Are you using Ember.computed's array methods? I tend to go with intermediately calculated arrays which I then union/diff/whatever is necessary for filters. It is also significantly faster than function-defined computed properties. The only bug I know of for this functionality was fixed in the 1.5 branch by @hjdivad.

This was a single value (e.g. 'selectedItem') populated by a Ember.Select view/component. After changing the selection a number of times, all things watching 'selectedItem' completely stop firing off (until a page refresh). No idea why.

There is going to be some future work on some of the form elements. They're really not quite where they need to be.

I hope it works out for you but that's just about exactly how I felt immediately before I realized it was not going to work for a very large project, switched to Angular and haven't looked back since. There was no comparison at all for me between Ember and Angular but everyone's needs are different.

What's weird is that I constantly hear the opposite. Angular's free flowing structure allows for spaghetti code in scale, while Ember might be overkill for smaller projects.

Ember's examples on their site are always the simplest use-case. For example, find me an example on their site of saving a complex relationship that was newly created by your application. Let's take the example of an invoice. Let's say you have an Invoice model, and an InvoiceLineItem model in a one-to-many relationship.

How do I save the creation of a new invoice (with line items) as a single transaction? As far as I can tell, you can't without breaking from Ember Data's very strict 'this is the way things should be done' model.

You have to create a new Invoice, then create the InvoiceLineItems doing something like this:

  var self = this;
  self.get('store').createRecord('invoice', {
    .. attributes ..
  }).save().then(function (invoice) {
    return Ember.RSVP.all(self.get('lineItems').map(function (item) {
       return self.get('store').createRecord('invoiceLineItem', {
           invoice: invoice,
           .. attributes ..
       }).save();
    });
  }).then(function (invoiceLineItems) {
    // do something
  }).then(null, function (error) {
    console.error(error);
  });

Note that this isn't even taking into account how to rollback INSERTs if, for instance a single invoiceLineItem fails to be created.

The 'other' way to do it is to create just an Invoice model, and have a lineItems attribute of type 'raw' and just create a RawTransform that's just as pass-through of whatever the JSON has for that attribute. It works, but at the same time, feels like it's going against the Ember Data Way, especially if you have a need for an InvoiceLineItem to be its own model (i.e. to be able to maintain relationships to other things and look one up by ID via the API).

Then you might have something like:

- Invoice and InvoiceLineItem models

- A RawTransform:

  App.RawTransform = DS.Transform.extend({
      deserialize: function (data) { return data; },
      serialize:   function (data) { return data; },
  });

- An attribute like so (on Invoice model):

  lineItems: DS.attr('raw'),

- Code that looks like this:

  var self = this;
  self.get('store').find('invoice', invoiceId).then(function (invoice) {
    self.get('store').pushPayload('invoiceLineItem', { invoiceLineItems: invoice.get('lineItems') });
  });

I really wish there was some thorough examples of using Ember + Ember-Data. Ideally it would be backend agnostic (mocked client side xmlhttprequest) and go from doing simple things like saving a model all the way to doing more complex things like you showed.

Drupal for instance has a /really/ great project that maintains a bunch of thorough examples (https://drupal.org/project/examples) which were indispensable when I did Drupal a while back.

It's kind of funny, but I don't even remember simple things being spelled out. For example, in their use cases all of the models and routes are single words like: post, comment, todo, etc.

In some places, you see 'Post' and others 'post', but there is nothing explicitly spelling out how that works for multi-word items (e.g. MultiWord => multiWord). Same with underscores in route names (e.g. route name 'multi_word.item.index' => MultiWordItemIndexRoute).

Yeah, the magic rejiggering of names everywhere with no clear documentation of what mapped to what† killed my interest in Ember the first time I tried to actually use it for even a fairly simple app.

† Plus the enforced snakeCase/CamelCase everywhere, but that's more to do with me far preferring names_with_underscores in general.

http://emberjs.com/guides/concepts/naming-conventions/ ?

That's a good generic overview but doesn't hit how the code handles the edge-cases.

This is one of the reasons that Ember.js + Rails seems like the preferred setup. Ember.js + Python gets you into converting underscored names to camelcase names.

Maybe to clear some confussion, snake case is exactly naming_things_with_underscores.

And SCREAMING_SNAKE_CASE, one of my favourite names for a convention ever, is when snake case is in all caps ;)

Replying to the sibling. There was documentation of how the names changed - you just need to know where to look:

https://github.com/emberjs/data/blob/master/TRANSITION.md

I'm not talking about transitioning from 'old' Ember Data to 'new' Ember Data. I'm talking about someone completely new to Ember looking through the examples and documentation. Even if they were looking through the repository, it would be easy to overload a file called "TRANSITION.md" if you don't need to transition from an older Ember Data version.

There really should be better examples. In the mean time, you should check out the Balanced Dashboard, I've learned a good amount from it

https://github.com/balanced/balanced-dashboard

> Ember's examples on their site are always the simplest use-case.

This is really key. Even extremely common patterns that will be present in virtually every web app have no examples that I can find anywhere on the web. A great example is simple nested resources, where the URL is something like `/tv_shows/555/seasons/3/episodes/2`. Obviously, this is the page that displays info about episode 2 of season 3 of the TV show with id 555. So how do I reference the tv_show model (which I will almost certainly need to do) from the `EpisodesIndexController` or the `episodes/index` template? Do I really have to specify `needs` [0] on every controller nested under `TvShowsController`, and perhaps add a `setupController` hook to make the property easily accessible like in this tutorial [1]?

Granted, I'm pretty new to this, so maybe I'm just missing the obvious way to do this sort of thing clearly.

[0] http://emberjs.com/guides/controllers/dependencies-between-c...

[1] http://balinterdi.com/2014/02/26/a-common-resource-route-pat...

> Even extremely common patterns that will be present in virtually every web app have no examples that I can find anywhere on the web. A great example is simple nested resources, where the URL is something like `/tv_shows/555/seasons/3/episodes/2`.

http://emberjs.com/guides/routing/defining-your-routes/#toc_... ?

See also http://hashrocket.com/blog/posts/ember-routing-the-when-and-... and http://ember101.com/videos/007-nested-routes/

These are the first three results for "Ember nested routes" on Google. They're all pretty simple and straightforward. Hope that helps!

Perhaps my wording wasn't great, but I'm talking about the specific issue that I explain later in the paragraph.

Ah, my apologies! I am also learning Ember, so I am not entirely sure. Hopefully someone else can come along and enlighten both of us.

I have a large, complex Ember.js + Ember-Data + Flask API app, and I don't think that I use `needs` anywhere in the codebase, so I don't think it's absolutely necessary. IIRC, the documentation says that `needs` only applies to singleton controllers. If you have a controller associated with a model (vs. a view + controller + route combo), I would assume that it's not a singleton (i.e. controllers associated with a view are singletons in that Controller.init() is only called once, even when switching away and back to a view).

To use my example of an app with URLs like "/tv_shows/555/seasons/3/episodes/2", if you're in the episodes/index controller (or template or view), how do you reference the particular season and tv_show that episode is part of?

If your API supports it you can use the EmbeddedRecordsMixin[0]. In general though, what would be a sane default for handling multiple REST API calls to single-model endpoints?

[0]: http://emberjs.com/api/data/classes/DS.EmbeddedRecordsMixin....

One pain point I've really felt recently with Python is in the deploy step. pip installing dependencies with a requirements.txt file seems to be the recommended way, but it's far from easy. Many dependencies (such as PyTables) don't install their own dependencies automatically, so you are left with a fragile one-by-one process for getting library code in place.

It was all fine once I got it worked out but it would so much nicer to provide a requirements.txt file and have pip figure out the ordering and dependency stuff. That and being able to install binary packages in a simple way from pip would make me much happier with python (no more waiting 10 minutes for numpy or whatever to compile).

As far as actual language features go however, I still find python a joy to work in.

If a package doesn't get all its dependencies installed via pip its because of missing information in the package itself. That's neither a flaw of pip or Python but will cause problems for any package manager.

I find the combination of virtual environments and pip very convenient to work with. When I run into trouble with missing dependencies I often find the project on GitHub and can send a pull request.

Regarding Numpy and the scientific Python stack, check out Anaconda https://store.continuum.io/cshop/anaconda/ it makes managing environments where you need these packages a lot less painful.

Not necessarily. pip cannot resolve all dependencies. For example, if a package specifies both numpy and pandas as a requirement, installation will fail. This is because pandas in turn requires numpy, and pip does not resolve the dependencies in a single step, you need to install numpy first and then go on with pandas.

In that case, couldn't you just specify Pandas as a dependency and Numpy would automatically be installed?

I think not, I think the problem is that it is a build-time dependency and pip wants to resolve all dependencies before installation begins.

See https://github.com/pypa/pip/issues/1386 (oddly, the issue is closed, while the problem is acknowledged).

I see, thanks for pointing to that issue. The other issue referred https://github.com/pypa/pip/issues/988 is still open, so I guess they work on sorting this out.

I recently tried to deploy a desktop app written in Python. It was a nightmare. I recently taught scientific Python to prospective switchers. The installation step was a nightmare.

We really need pip wheels or conda to become mainstream. Pip alone doesn't cut it on platforms without compilers (Windows / OSX). Standalone installers are fine, but they don't resolve dependencies and they are only available for Windows.

I totally agree that the installation and deployment story should be a top priority. Once done, it would be another very compelling point on Python 3's feature list.

wheels are pretty mainstream and are getting better fast. Forking the package management ecosystem again, just after we got over the last round of headaches there, is only going to make things worse

One of the reasons I've come to do most of my early stage prototyping in node is that managing npm packages has thus proven much easier than finagling with pip or gem.

Ruby installs are especially difficult to manage. Despite the numerous tutorials out there, I still don't know what, if there even is one, the canonically best way to install ruby and necessary gems is. RVM? Install through Brew? Add path to ~/.bashrc?

I say this as someone who likes using command line so much that I've written Caskfiles to automate my deployment to fresh OS X Machines.

> Despite the numerous tutorials out there, I still don't know what, if there even is one, the canonically best way to install ruby and necessary gems is.

Wait, what? On production, install the exact ruby you need from your favorite package manager. On your dev box, install any rubies you need through rbenv [1]. Put all your gem dependencies into a Gemfile [2]. On either end, bundle install [--deployment] and call it a day.

[1]: https://github.com/sstephenson/rbenv

[2]: http://bundler.io/v1.6/gemfile.html

I install rvm on my production boxes as explained at https://rvm.io/ then I put .ruby-version and .ruby-gemset files in the application directory to select the interpreter and the gemset (I might need to have different applications running - especially on staging machines). Finally I use bundle and a Gemfile. It's pretty easy. You got another answer suggesting rbenv which is also fine.

At my company we build with Jenkins, tarball it and deploy from that. I haven't had experience another way but I think it ends up being more efficient and less error-prone than doing actual pip installs during deployment.

That's basically what the company I used to work for did as well with our large python application. Build using a build script, pulling in dependencies from local build server, test, package up the result and deploy. Pip was used for pulling in libraries to the build machine and never used during deployment.

You should avoid using normal requirements.txt files in production. If you want to use pip, it's better to "pip freeze" your test environment, and use that requirements file to specify the production environment.

Otherwise you are just asking for nasty surprises when packages upgrade.

Just a note so people don't get confused, while specifying packages with >=1.1,<1.2 seems to be similar to the tilde in npm, in practice it isn't.

Basically, when you use >=1.1,<1.2 it will install the best version that matches at the time of first install, and then that version will never be upgraded because it will always satisfy the requirements. So you don't actually get 1.1.x release updates unless you install them manually.

We do, however, use this syntax in development when testing new versions to make sure any subsequent runnings of pip doesn't obliterate the new versions of modules we are testing.

I'd love official pip support for ~1.1 type declarations.

Long compile times can be fixed with pre-compiled wheels, http://wheel.readthedocs.org/en/latest/ I shaved off 4 minutes of our build time of numpy/pandas with it.

(dormant) PyTables developer here, we do have a requirements.txt file but I understand our setup.py needs an update. Please open an issue on github and tell us about your experience and how we can improve it.

I will soon, thanks!

Check out devpi (http://doc.devpi.net/latest/). We build our projects as wheels with pip using devpi as a custom index, i.e.:

BUILD_DIR="/tmp/wheelhouse/$PROJECT" pip wheel --wheel-dir=$BUILD_DIR --find-links=$BUILD_DIR --index=http://$DEVPI_HOST:$DEVPI_PORT/${DEVPI_USER}/${DEVPI_INDEX} --extra-index-url=https://pypi.python.org/simple/ ../$PROJECT

This will try to get packages from your devpi index, but will fall back to pypi if you don't have them.

Then upload this to devpi. It can later be installed by pip with:

pip install --use-wheel --index=http://$DEVPI_HOST:$DEVPI_PORT/${DEVPI_USER}/${DEVPI_INDEX} $PROJECT

This makes deployments super fast because you're deploying pre-built wheels instead of downloading and compiling from pypi. It also gives you resiliance by storing copies of the dependencies you need in devpi, so if they vanish from pypi (or it's unavailable) you can still deploy your software with all the dependencies you developed against.

There is work going on in the python packaging SIG to make installing better. One of the big additions for pip is the ability to install pre-built wheels for those "hard to build" packages. There is also work happening on a new package metadata standard.

Unfortunately, that's all I've learned from lurking on the mailing list for a couple weeks.

As several person mentioned already, wheels (http://wheel.readthedocs.org/en/latest/) make deploying much easier (and faster), not needing to get anything from pypi.

There's nothing like a good old deb (or rpm) package. Learn fpm[1] and bundle your dependencies instead of hoping that they get there.

[1] https://github.com/jordansissel/fpm

In my experience, you can bundle the dependancies, and then add the path to your search path.

Not the best approach, but it does work.

`pip freeze`

Reed Esau creates a bunch of vim plugins for writing, I've found them to work very nice:

http://wynnnetherland.com/journal/reed-esau-s-growing-list-o...

Thank you for this link. vim-wheel is just pure gold, I needed that for a long time...

I've always wondered what coding is like for those who don't speak english, or only speak a little. I imagine it's something like working with code beatified by this tool.

Almost every codebase is filled with english verbs and nouns. They are one of the primary tools for making source code readable by humans, not just machines.

Very cool tool.

I'm not a native English speaker, and I've actually started programming way before I've become fluent in English.

It wasn't that difficult. I remember not knowing how things would translate to my own language, but from the code, I'd know what they meant.

Now that I think back, my first steps in English were probably made in programming and cartoons; before my mum realised I enjoy languages and signed me up for advanced lessons.

So, it's nothing weird. I'd like to think programmers have a higher-than-average IQ, which makes understanding and learning easier. Maybe I'm just biased! :-)

Basic stuffs are not that difficult, i mean function/for/while/var ... is easy to understand wherever one comes from.

The biggest benefit of being an english native speaker is that most resources on the web are in English(docs,articles,videos). And since being a developper is about learning new things all the time, it's easier to learn about new technologies or tools when one can read english articles or documentations.

My english (writing and speaking) is horrible but i force myself to read english docs on a regular basis,because it's just mandatory today.