[merge]
ff = no1,088 karma · joined November 8, 2010
https://github.com/fphilipe
[ my public key: https://keybase.io/philipe; my proof: https://keybase.io/philipe/sigs/182uf1x4SUnMvtmLchInbgTL0X0b0qcRGe_g2T0KLDo ]
[merge]
ff = noMy workaround has been to use email notifications exclusively. I have a Gmail filter that applies a label to all notifications and skips the inbox. Then in my mail client I have a smart mailbox that only shows me unread notifications with that label (or that folder, from an IMAP perspective). The smart mailbox then shows me a counter of unread notifications. This way I don't oversee comments when multiple ones are made in a PR.
Problem 1: No context in these notifications. It would be nice if these emails could show the code in question for diff comments or the entire comments thread.
Problem 2: Now what is really bad with these notification emails is that the link "view it on GitHub" sometimes no longer links to the comment I'm being notified of. This happens when the comment was made on a PR on a line of the diff that no longer exists, as sometimes is the case when new commits are pushed. I then have to go to the main PR page, expand all collapsed "foo commented on an outdated diff" comments and manually search for the comment in order to get the context and be able to reply.
By fixing problem 1, problem 2 would be automatically fixed with it and make my workflow much more productive. Is there anyone else annoyed by this?
Pros:
- When you enter a psql session, you `SET search_path TO customer;` and that's it. No customer_id column in any table you have to remember setting in your WHERE clause.
- Same thing for rails console. At the beginning of the session you choose which customer you want to operate on.
- Similar for web requests. You just activate the right customer (e.g. based on subdomain) and that's it. Instead of `current_customer.posts.find(params[:id])` you can now simply do `Post.find(params[:id])`.
- Data is completely separated. It's almost impossible to have a bug causing data to spill from one customer to the other, which is quite high chance when you always have to remember to load data through the current customer.
Cons:
- Number of objects (tables, indexes, sequences) is multiplied by number of customers.
- Adding a new customer requires `pg_dump` to be present as it dumps the public schema (the blueprint), creates a new schema, and loads the dump into that schema.
- Migrations take longer as there are more objects to touch.
In our case, the pros outweigh the cons. One further advantage of the separate schemas is that, in theory, we could at any time start using completely separate databases, one for each customer or just one additional for a much larger customer that's eating up all resources on the DB.
- it can't list schemas with \dn
- it can't list materialized views with \dm
- \dt <star>.users doesn't work as it does in psql, i.e. it just lists all tables due to the * instead of listing users tables in all schemas
- it can't use your editor with \e
- it can't input existing files with \i
- it can't redirect the output with \o
- it can't extract data with \copy
2. C-e and C-y as long as the cursor position doesn't move out of the visible area
Maybe in the US, but where I live, and I guess that's going to be the case in most countries, no one would ever think that this "suitcase" could be a bomb, regardless of the person's appearance. It's saddens me to see a country becoming more and more paranoid and living in fear.
As an example, we used to chase each other in school with BB-guns (here they don't have the orange marker distinguishing them from real guns). When a teacher saw us I'm sure the thought that these could be real never ever crossed their mind.
.+@.+
Should do the trick best = 0
i = 0
while true
i += 1
count = 0
face = 1
while face == 1
face = rand(0:1)
count += face
end
if count > best
best = count
println("new record: $best in iteration $i")
end
end