arthurschreiber · HackerTrans

arthurschreiber

no profile record

Submissions

Javascript Game Development - The Game Loop

nokarma.org

1 pointsby arthurschreiber15 yıl önce0 comments

comments

arthurschreiber

5 yıl öncediscuss

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.

arthurschreiber

5 yıl öncediscuss

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.

arthurschreiber

5 yıl öncediscuss

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.

arthurschreiber

10 yıl öncediscuss

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

arthurschreiber

12 yıl öncediscuss

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

arthurschreiber

13 yıl öncediscuss

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.

arthurschreiber

13 yıl öncediscuss

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.

arthurschreiber

14 yıl öncediscuss

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

arthurschreiber

14 yıl öncediscuss

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.

arthurschreiber

14 yıl öncediscuss

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!

arthurschreiber

14 yıl öncediscuss

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

arthurschreiber

14 yıl öncediscuss

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".

arthurschreiber

14 yıl öncediscuss

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.

arthurschreiber

14 yıl öncediscuss

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

arthurschreiber

14 yıl öncediscuss

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.

arthurschreiber

14 yıl öncediscuss

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.

arthurschreiber

14 yıl öncediscuss

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.

arthurschreiber

14 yıl öncediscuss

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

arthurschreiber

14 yıl öncediscuss

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...).

arthurschreiber

14 yıl öncediscuss

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.