arthurschreiber

We could enable the linter in production to silently log problematic queries without actually affecting their execution.

If we used separate db users as you're suggesting, any query that we didn't catch beforehand (e.g. via our CI builds) would cause noticeable problems for our users, which is something that we want to avoid.

Additionally, switching to a separate user account would require holding open twice the amount of connections to each database server (old db user plus new db user), which probably would be fine but is still a lot of additional connections at our scale.

As described in the blog post, large paths of our database schema have grown in an organic fashion. These virtual partitions allow us to prepare our database access for splitting out groups of tables into separate clusters in the medium term, with sharding those clusters being a next step and a long term solution to handle our database growth.

We wrote our own linters that hooked into the `sql.active_record` event emitted by ActiveRecord when a query gets executed.

See https://api.rubyonrails.org/classes/ActiveSupport/Notificati... for the API to subscribe to these notifications.

Unless I'm mistaken, 97% of (24 hours) = 23.28 hours.

I really like docopt (http://docopt.org/) which also comes as a CoffeeScript / JavaScript version.

That's _exactly_ what XSS is about. One possible way to exploit things like this is if I send you a link to a website, that embeds the target page through an iframe with javascript output injected. I could then have the JS steal your cookies/session or worse.

This is similar to how the Rubinius project has been managed for a long time: After your first pull request gets merged, you'll be added to the repository as a committer.

I also created a very rspec like bdd library, called tclspec: https://github.com/arthurschreiber/tclspec

I'd even say that the biggest contributor to this difference is the non-blocking nature of Node. Using e.g. EventMachine would probably close the Gap between Node and Ruby even more.

Well, that comparison is not exactly fair, is it?

While the rails benchmark tries to compare different template engines in the same language, framework, and with blocking IO, you're comparing these results to rendering under "pure" Node.js (no framework that slows you down) with non-blocking IO.

Don't take this the wrong way, tho, I'm absolutely blown away by your numbers!

I'm confused, is this not what generally is done (and works) in open source development?

To be honest, I think both styles are good practice, but it totally depends on the context. For example, if I want to describe how the "#admin?" method is working, I'll use

    describe "#admin?" do ...

but if I'm describing a different method, that does different things depending on whether the user is an admin or not, I'll do the following:

    describe "#some_other_method" do
      describe "if the user is an admin" do
        ...

So you can mix and match both styles, depending on what exactly you're describing (and it's context).

If you're looking at the OP more closely, it even says this is only recommended for "describing methods".

Well, but Tcl blocks are nothing more than strings that you pass as arguments that then get eval'ed using uplevel. Ruby blocks are "real" language constructs, and are real closures, in difference to Tcl blocks.

Not having an aluminium bar at the bottom makes it very much look like the Apple Cinema Display, though.

Hah! Your pull request actually introduces subtle bugs into the diff view. I had already submitted _exactly_ the same change some months ago, and after having it enabled for some time in our gitlab installation at work, I ran into some issues.

I can't remember the exact preconditions, but there were cases where this change would start showing changes that were not even part of the merge request at all, which was extremely confusing.

In the end, I went ahead and did some more low-level changes to gitlab, so it would not only save the branch for a merge request, but it would save the actual commit shas of the source revision. That was much more accurate and reflects the way pull requests work on Github.

Yes. Just check this model, for example: https://github.com/gitlabhq/gitlabhq/blob/master/app/models/...

I'm pretty sure it should have it's attributes protected.

Also, prepare to have to work with pretty confusing code. I don't want to belittle the work of the Gitlab authors and contributors, but the whole codebase is ignoring many Ruby, Rails, Webdevelopment and general programming best practices.

A short list of problems, at least in my eyes, and in no specific order: * Obtrusive JavaScript inside the erb templates, inline style definitions * Non-semantic css class names. * Highly confusing controller code (filters are used to set all kinds of instance variables, which makes it very hard to easily understand where the variable is coming from and what it's value is). * "Roles": Code that has been extracted into seperate modules, but for no real reason. E.g. the SshKey module is only included into the Key class, and is highly coupled with it. * Totally brittle test suite.

Be sure to take a closer look at the Gitlab source code. The last time I did, they still were vulnerable to exactly the same attacks that were also demonstrated to work on Github some time ago.

Yes, but enumerators are (in most cases) implemented with Fibers. So you're going to get hit with at least some performance degradation.

As others have already pointed out, that has nothing to do with MVC, but is more a result of how template engines usually work.

E.g. in Rails, by default, due to the fact that you can have views provide content for your layout (using content_for), it has not been possible to start sending your rendered HTML before the rendering was completely finished.

There is an experimental Fiber based solution in Rails Core, that shipped with 3.2, that kind of fixes that issue, but only to a certain degree (see http://api.rubyonrails.org/classes/ActionController/Streamin...).

Yes, but their Model layer, in comparison with what ActiveRecord provides you with, is really not that great. One of the main aspects that I really didn't like was that the Model finder methods don't give you object instances back, but instead you get php arrays with the fetched data from the database.

I'm only guessing, but I'd say with the release of Github for Mac 1.2.

Same here. That's really creepy. :/

Wasn't there some actual recruiter offering DDH a senior rails developer position? I'm pretty sure I read about that in DHH's twitter stream some time ago.

Usually you will have another level of indentation, so class methods shouldn't be that easy to mistake for instance methods.

How often do you come across the need to type in your password? Personally, I do not have to do that too often, and when I have to it usually makes sense to re-authenticate.

I don't know the Play! framework, but the main difference probably is the use of nonblocking IO in nodejs, in contrast to blocking IO in the example you just have given. (I'm not saying either is better).

An Open Source h264 Encoder.

I'd be interested, too.

I encrypted my SSD using BitLocker, and for me, the performance hit is not really noticable in my day-to-day work (programming + running a virtual machine). Your SSD will still be A LOT faster than a regular, unencrypted HDD. But YMMV.

xpi files are "normal" renamed zip files. Try extracting the contents using your favorite unzipping application. You should then get access to the source files.