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

this seems to be a lost art, unfortunately.

> 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?

There have been some historical issues that should have been sorted out in more recent releases. The TL;DR is that Rails wouldn't actually use your faster gems, even if you thought it was. See https://github.com/rails/rails/pull/12183 for the work that was done to improve this. There was another issue too that detailed the specific problem, but I can't find it right now.

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.

as much as I don't want to quote dhh about anything: http://david.heinemeierhansson.com/2012/rails-is-omakase.htm...

in short, since Rails 3 there is no "Rails Way"

That's just PR.

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.

Or you would just use the class because it's already in the autoload paths. Seeing a lot of opinions from people who don't actually seem to use rails.

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.

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.

Totally agree. The browser improvements really have changed development a ton.

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.