rafekett

it also leads to proof by intimidation which often masks errors.

this seems to be a lost art, unfortunately.

au contraire. I have worked on what I suspect is one of the largest Rails apps out there. autoload has been off for a long time (along with many other "convenient" features) for performance reasons.

that's beside the point though, because if you're outside the Rails world you will have to type the whole name of the file if you want to do something with it.

> JSON rendering performance is a major concern for most of my Rails apps

I've always wondered why this is the case. Faster JSON libraries don't seem to help. Similar frameworks don't have this problem. It just seems the Rails serialization code is slow in and of itself, it's not what it calls out to. Maybe there's a contention issue somewhere?

I think the issue is monorails (monolithic rails apps). If you have a single domain object you're representing that's that complex, you'd done a poor issue of modeling your domain. It doesn't matter if you write the logic in the model or controller, at that point you're just pushing code around -- you need better abstractions.

it's useful in practice for denoising file names. unfortunately rails doesn't do this at all, and every controller file is something like `app/controllers/foo_controller.rb`. in Python, if you had a file `app/controllers/foo.py` you'd be able to `from app.controllers import foo`, which is more useful and does an equally good job of declaring the file is a controller without having to write `_controller.rb` every time you do anything with a file.

this, i'm not sure why it is hard to see that this is easy to implement without storing passwords in plaintext.

there are lots of problems (particularly with versioning/backwards compatibility) that using better protocols (i.e., protobufs) can solve.

2010, python (wxpython to be exact, the Python version IIRC was 2.5). pretty fun, I think the biggest development since then is the degree to which the browser has improved as a platform for development.

I think it's less important what you've done and more important how you've done it. Replace all this with a single well-written, well-documented open-source project that people actually use and your situation would be different. I'm not trying to diminish your accomplishments, but rather diminish how much the industry values this kind of stuff. The problems you typically work on in industry are much more cut-and-dry, but the important part is not getting a solution in the first place, but a maintainable, well-tested one. Without making too strong of a claim as to whether it's correct, there is a strong negative association for academic code in the industry. I think there's actually a lot of validity to this criticism, though: for each of the projects listed, did you maintain the project at all? Were there other users for the code, or was it just you (or your research group)? This is a place where the academic experience is lacking as preparation for engineering work.

hopefully all my cryptic perl5 1-liners will still work.

just because the dataset is sharded doesn't mean that one query has to hit every shard. for example, suppose you're looking for documents with `parent_id = foo` and your sharding key is `parent_id`, then an intelligent query planner would only query one shard (the one that "foo" hashes to), and then this looks a lot like a join in an RDBMS. indeed, if you wanted to do (in RDBMS terms) a self-join to load the whole tree of documents rooted at parent_id = foo, and your sharding key were the root for each document, that query would only hit one shard with a. the trick is deciding which keys to shard on (and, in many cases, what other keys to shard on in redundant datastores that serve different types of queries).

fantastic work that's long overdue. any commitment from the zend team to implement it? if not it's a specification for HHVM, not PHP.

I was a little disappointed to not see anything I don't use regularly. Some explanation of reflog might be helpful, in addition to a bit of detail on git internals that explains why things in Git are never really deleted until you run `git gc`. For instance, just yesterday I realized that a branch I had deleted erroneously (bad branch name) contained a few days of work. I looked in git reflog to find the SHA for the last time I checked it out, checked out that SHA, then made a new branch. No work lost. If I didn't know that, I'd be out a few days of effort.