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.

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"

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.

my language was too harsh. see my edit in response to ptarjan.

really, the big problem was that the HHVM team didn't use CMake, so there was no concern with how long the build took and it was frequently broken. I had two instances where I spent hours fixing bugs that were fixed internally at FB at the same time, but hadn't been pushed. I know there was an ongoing effort to move completely into the open, but it was frustrating. I don't think these are persistent problems with HHVM, just reasons why the project wasn't really ready for primetime in the OSS world (open academy, specifically).

the fact that no one who doesn't work at FB is allowed to merge code (correct me if I'm wrong) made me feel like I was helping FB more than the OSS community. I get that HHVM is business critical to FB, but if you want it to truly get community support it needs to be spun off from FB.

edit: and I will add that my language was way too harsh. it's not hard to get in a PR provided it doesn't break anything in an FB internal test suite which I can't see (which never was a problem for me, but I could see it being one) and didn't degrade FB performance.

depends on what you define as good quality. it's efficient code, but it's sparsely commented, and a style nightmare.

you're probably interested in the downsides of HHVM, not Hack. Hack is really just a PHP frontend built on top of HHVM. HHVM is the JIT.

- it runs really well on expensive, FB hardware. there's no consideration given to anything else (performance-wise) in development. that's not to say it's slow, but it works best on 64GB servers with fat SSDs.

- it's a huge moving target when it comes to php5 compatibility -- there are a few intentional inconsistencies and a lot of unintentional ones. fixes for zend incompatibilities have a whack-a-mole effect: the typical patch fixes one inconsistency and introduces a few more.

- bad documentation and bad code quality

- it is open-source, but only in the most superficial sense. it's really an FB internal project, so good luck making any changes that help you but don't help FB

it's still better than zend PHP, and, to be fair, most of the incompatibilities are in cases where zend behaves stupidly. source: i was an HHVM contributor. (edited to space out my ascii list)

I'm curious -- what is your use case is for writing and deleting?

you shouldn't be surprised, FT and the economist have always had a deep right skew.

defaults to SF for me. closest airport to me on their list is IAD, but it is ~6 hours away.

> anything you do while employed belongs to your employer

have you ever signed a software engineering contract? surrender of IP created at work or working for the company is _very_ standard.

My intention wasn't to label anyone. Xah has been a disruptive and counterproductive presence in the emacs community, but I think it's because he needs help he's not getting. He spent his time in poverty fighting flame wars on usenet -- he needs to get his priorities straight. I buy he's a smart guy who can get a lot done, but he's not employable in his current state, and I don't think the right solution is to give him money so he can continue to live like he does.

Xah needs to seek help for his mental illness. Look at his posts on comp.lang.emacs for evidence. He's been spending all these years on $3 a day trying to figure out a more "ergonomic" keyboard for emacs, but many of his suggestions are really just based on what he wants and are less ergonomic than standard emacs.

EDIT: comp.lang.emacs doesn't exist, it's been many years. gnu.emacs.BLAH

troubling, but i can't see any way in which this is illegal on the part of Alexandria PD.

i'm incredibly reluctant to post in threads like this, but I think this attitude is actually hurting diversity in the industry: excessive "chivalry" by males gives more of an illusion of preferential treatment when women stand up to discrimination, which is just more fuel for the gender war fire. women need our support, not our defense. it's fine to be outraged, but your response should not be to go on the offensive.

maybe this has changed, but arel's documentation last time i used it was about as good as the rails documentation, so it was wildly incomplete/inaccurate.

for example, last week I wanted to a bulk INSERT. maybe arel can do this (though I highly suspect it cannot since this isn't a part of relational algebra at all), but that's kind of worthless if i can't find any evidence of how to do it without reading the arel source.

so you'd be twice as productive if you could type twice as fast?

I had to use ActiveRecord last week after a year straight of using SQLalchemy and it was downright painful. doing anything beyond simple CRUD is near-impossible without writing raw SQL. i used to like ActiveRecord more when I didn't understand relational databases, but now I don't understand how anyone who's ever used SQL directly in their life could tolerate AR.