Nobody said "quarter" means multiply by 4. They said "quater" means multiply by 4, which it essentially does [1]. In addition to being a real word, it's also a prefix, e.g. "quaternary" means fourth in order.
You made a typo (quater) in correcting someone's else's typo (forth). Several people have pointed out the irony and have patiently tried to teach you a new word, but you seem to keep reading past all of them without comprehending ¯\_(ツ)_/¯
Does the trademark office just rubber stamp anything they get and let the lawyers fight it out? IANAL, but these look pretty similar:
85632326 (Instructure):
IC 042. US 100 101. G & S: Application service provider (ASP) featuring software to enable uploading, posting, showing, displaying, tagging, blogging, sharing or otherwise providing electronic media or information over the Internet or other communications network
86642511 (Canvas Labs):
IC 042. US 100 101. G & S: software as a service (SaaS) services featuring software used to allow collaboration between users for sharing information; software as a service (SaaS) services featuring software to create, structure, edit, access, integrate, manage, interpret and synchronize documents, content and data between users
The API is pretty comprehensive, and is growing daily. With the exception of some legacy features, all of the web app's UI is built on top of it, as are the mobile apps.
Even a text column would be preferable IMO ... you wouldn't need to worry about remapping if a value got removed, it's more easily queryable, and it's certainly more legible if you're looking at raw data (say, via psql). Plus you probably won't really save much (any?) space with an (64-bit) int.
This approach works well when you want to cache data from an existing integration database and don't have the luxury of rearchitecting the whole thing.
At my previous job, we had a bunch of systems talking to a single database. Some were rails, some were not. We wanted to add memcached to the rails apps via cache-money[1]. That'll handle read-through/write-through caching for vanilla rails stuff, but we had to somehow invalidate the cache for updates that happen outside of ActiveRecord::Base#save (e.g. update_all, or a write from a non-rails system). In the end, we settled upon the same approach[2] as in the article.
The trigger-backed cache invalidator was also written in ruby, and knew from rails/cache-money what key(s) needed to be invalidated when it got a notification. IIRC you didn't need to do anything special when you added a new cache key (e.g. cache user lookups by username), since the invalidator would just know what to do.
[2] This was actually on 8.4, so unfortunately there was no NOTIFY. Instead, a plpython trigger would send a message to invalidator (persistent tcp conn per pg process), but this had the unfortunate consequences of 1. firing before the commit and 2. firing even in the event of a rollback
UTC offset is well and good if you are talking about today, but as soon as you start displaying past or future datetimes, DST will bludgeon you over the head.
And depending on your app, users might want control over the timezone. When a teacher creates an assignment in canvas-lms, the due date defaults to midnight of the selected day. It would be surprising if it set it to 2am, just because the teacher happened to be traveling when the assignment was created.
We did a two-day hackfest at work recently, and this was my project. As canvas-lms has grown, we've seen our GC runs get slower and slower, and this seemed like some good low hanging fruit (especially as we keep adding more languages).
I moved the translations out of the ruby heap, so as to speed up GC runs, and there were some other enhancements in both ruby and C to speed up lookups a bit.
It's still pretty new, so as I continue to refine I hope to bring those benchmarks even further.
There were several factors, but the two big categories were:
1. Familiarity. The original decision to use MySQL was arbitrary, and as the team grew, we just so happened to hire lots of postgres-philes.
2. Death by a million paper cuts. Locking/slowdowns as load increased. Useless EXPLAINs and naive query planning. Truncation (rather than rejection) of VARCHARSs and INTs that exceed length constraints. Having to rewrite queries in weird ways and/or use MySQL-specific syntax to work around performance issues. Lack of partial and expression indexes. No transactional DDL support.
Additionally, the stars aligned. We had a very large customer -- about as big as our other customers combined (up to that point) -- that wanted an on-premise Postgres install, so we added support for it. Eventually the customer opted to move it into our cloud. We didn't want to have to maintain multiple types of database clusters, so we just moved everything to Postgres.
This looks promising. The MySQL -> Postgres replication possibilities are particularly interesting for people looking to switch over a huge database with (almost) zero downtime.
At Instructure we essentially did this last year when we made the switch. We loaded in the initial dataset using pygmy (https://github.com/instructure/pygmy ... basically a wrapper around COPY and friends) and then used a kodama-like script to keep it in sync until we pulled the trigger. We haven't open sourced the replicator yet, as it's a shameful hack ... we were doing statement-based replication, which makes query translation super brittle (yay regexes!) if you do much beyond basic ORM stuff, due to differences between the two dbs.
No matter how you go about it, there are lots of little gotchas like updating your sequences, converting tinyints to booleans, etc. Should be interesting to see where this project goes, since MySQL -> Postgres is the current trend.
I guess the real lessons there for users is "don't do anything sensitive on a device that's not yours. or on one you just acquired, unless you trust every hop between you and the server". But users generally don't know/care/think about these things :)
I should clarify, I was referring to the first visit to the site. So yes, I can see how this greatly reduces the vulnerability, though it doesn't completely remove it.
As an example, a rogue Apple Store employee could insert him self as a MITM between the access point and the internet connection. Anyone testing out a new laptop in the store (or logging in to their bank from a just-activated iphone) would be vulnerable, without the attacker ever having touched any of those devices.
The author seems to gloss over the importance of browser built-in HSTS lists. If you're just relying on a response header to tell the browser to use HTTPS, aren't you still vulnerable? Isn't that the same fundamental problem with redirecting to HTTPS via Location headers?
In other words, a MITM could downgrade any HTTPS traffic and simply remove that STS header. The browser would be none the wiser.
to put it simply, browsers are really good (these days) at executing javascript, thus the biggest factor in this test seems to be the large(r) HTML payload.
though to make this a better test, I think you should serve both the JSON and HTML as static assets. after all, we're not interested in benchmarking ERB/to_json/ActiveRecord here, we care about the client side. server-side templating and JSON generation could both be quicker with optimizations and/or different backends.
You made a typo (quater) in correcting someone's else's typo (forth). Several people have pointed out the irony and have patiently tried to teach you a new word, but you seem to keep reading past all of them without comprehending ¯\_(ツ)_/¯
[1] https://www.dictionary.com/browse/quater