This holds problems we've seen in the course of our work that have non-obvious answers.
Log in with the prod-read account. Select the module and version you're interested in. If you can't see what you're looking for, it might be collapsed.
this question's been asked a bunch of times, and komalo wonderfully commented in review #K106871:
But here is the background with camelCasing JSON items as they are returned from the server:
1. the objects, on the server, have underscored variable names
2. our JS style guide uses camelCase (as is consistent with almost every other 3rd party JS library we use)
3. likewise, we use Backbone, whose models sync directly with attributes as returned from JSON from the server
Combine these 3 points, and you have a world of pain. Since if you don't translate the JSON objects to camel case, then your Backbone views will have underscored properties if returned from the server, and camelCased properties otherwise.
My ideal world would be this:
- *always* return camelCased JSON from the server, and *always* translate from camelCase to underscore when accepting JSON to the server
Unfortunately, we had a lot of legacy code when we started to use Backbone/JSON based API's in our main app, so I made jsonify accept a parameter. So now we have a world where some endpoints return underscores and some return camelCase.
There is no good solution now. The way I see it, there are two options to deal with what we have:
- continue trying to eliminate all legacy code that uses underscore JSON objects, and translate using camel_cased=True in all future places
- give up on camel_cased=True, and make explicit all JSON sources from the server by using under_score. Unfortunately, in order to do this, we would also have to make all Backbone Model and View properties use underscores, because it would be a disaster if they were mixed. Likewise, it would propagate out to handlebars files.
I still believe Option A is the cleanest, but I could be convinced otherwise. I didn't do a good job communicating this to the team, though, and am happy to work with anyone who wants to help me fix this situation. :)
Visit /devadmin/content?refresh_caches=1&version=default to refresh the PublishedContentCache with the latest and greatest. The exact stack trace will depend on what page you're trying to load, of course. See https://sites.google.com/a/khanacademy.org/forge/for-developers/cachemisserror-and-the-publishedcontentcache!
I'm getting this error on startup:
It means you didn't start the appserver with
As of June 2014, these instructions are inspired by the gist at https://gist.github.com/goldsmith/7262122. Tested by Andy.
OS X 10.8
As of April 2013 on 10.8.3, while numpy installation works following the OS X 10.7 instructions below, SciPy needs extra work. It can be installed via homebrew. Tested by Chris.
This is how I fixed this problem:
Based on the information I found under the 10.7 installation instructions here: http://www.scipy.org/Installing_SciPy/Mac_OS_X
This worked for me:
"Simply remove (or rename) the file
pyobjc-framework-FSEvents fails to install with "AttributeError: 'module' object has no attribute ‘_install_lib’"
We're still working through this one, but in the meantime, Dylan notes: "Your dev server will still work fine, but it won't be as fast as it could be. When the FSEvents wrapper isn't available it will fall back to polling the files' mtimes to detect changes and reload the code."
You can override this limit by running