HN user

wulczer

1,457 karma

Engineer at New Relic (personal email: wulczer-hn@wulczer.org)

[ my public key: https://keybase.io/wulczer; my proof: https://keybase.io/wulczer/sigs/g46dYvOOsEpYFfTEQUY4Hwj5x_gO3JSvfDNXnd4pjvI ]

Posts14
Comments229
View on HN
80x40 11 years ago

Since all of the previous states are there in the repo history, you can make that gif yourself at any moment!

Django 1.8 released 11 years ago

Postgres at least will store rows roughly in insert order. So whether you're using integers or UUIDs for primary keys won't affect on-disk layout.

When scanning the index, the database will be traversing it in btree order, anyway, so as long as the values are comparable, ints or UUIDs shouldn't matter much.

What is the epiphany here? What is the insight or enlightenment to be gained from this story?

I have my own, but I'm curious about what people believe is the moral of the story.

That's also why, when you go to the movies and it turns out tickets cost the same regardless of the film, you should go for the one with the longest running time.

One of the important reasons Postgres connections are serviced by a separate process is that if that process segfaults, you only disconnect other connections (because if might have tainted shared memory when it died), but the main database process keeps running and you can reconnect immediately.

Frequency 12 years ago

Almost two years ago the "The Pulse of Spain" was made, based on the same idea (disclaimer: the designers of this are also designers for our product (and dear friends)).

It's in Spanish, unfortunately. You have to click on the tiles to activate them and they'll start pulsating. If you have Flash, there'll be sound.

The link is:

http://img.actibva.com/pulso2/

Tor best practices 13 years ago

Logs subpoenaed from your ISP show that you were using Tor between 3:10 and 5:23 PM on 02/05/2012.

Logs from forensic analysis of a breakin to EvilCorp show that the attacker came in from Tor and was downloading secret data from 3:10 to 5:23 PM on the same day.

Not enough to prove anything, but there's definitely some circumstantial evidence there.

Why can't you use a connection that has issued LISTEN for anything else? In fact, I'm fairly sure you can use it normally.

We're using NOTIFY to broadcast database changes to services that should react to them and it's quite a nice way to separate concerns: process A just writes to the database, a trigger issues a NOTIFY, process B checks and notices there's been a change.

Edit: I see, the code in the post suggests that the connection needs to be stuck in a select() (I should know, I contributed a largre chunk of psycopg2's async code handling). You just need to use an asynchronous driver and you can happily LISTEN and do queries at the same time (of course you won't get notifies while a query is processing - the Postgres protocol has no concept of multiplexing).

We're using Twisted and happily mixing queries and NOTIFY.

Not really, the ones calling down to date_trunc should be marked as STABLE, since the underlying function is STABLE.

  psql=$ \df+ date_trunc
     Schema   |    Name    |      Result data type       |        Argument data types        |  Type  | Volatility |  Owner   | Language |    Source code    |                     Description                      
  ------------+------------+-----------------------------+-----------------------------------+--------+------------+----------+----------+-------------------+------------------------------------------------------
   pg_catalog | date_trunc | interval                    | text, interval                    | normal | immutable  | postgres | internal | interval_trunc    | truncate interval to specified units
   pg_catalog | date_trunc | timestamp without time zone | text, timestamp without time zone | normal | immutable  | postgres | internal | timestamp_trunc   | truncate timestamp to specified units
   pg_catalog | date_trunc | timestamp with time zone    | text, timestamp with time zone    | normal | stable     | postgres | internal | timestamptz_trunc | truncate timestamp with time zone to specified units

I've been thinking about switching to sup a few times, but the inability to sync changes back to the IMAP server is a deal breaker to me.

If I mark an email as read in sup, I don't want it to show up as unread on my phone. If I delete an email on the phone, I don't want it to stay in sup.

I know there's been a branch of sup that synced IMAP flags from the local repo to the server, solving at least the read status problem. But it seems the version linked here does not include that branch.

it does when using the re.U flag

  re.match(r'\d', u'੧', re.U)
  <_sre.SRE_Match at 0x3070ac0>

  sys.version
  2.7.3 (default, Mar  4 2013, 14:57:34) \n[GCC 4.7.2]

Better idea: check which of those keys are in the Debian Weak SSH Keys list and own their GitHub accounts (or find if they have any servers and start SSHing into them).

Less nefariously: send them an email asking to regenerate the key.

Yes, thank you, sorry for too big of a mental shortcut.

By bad tests I mean trivial tests (much like trivial comments that just state the obvious), or ones that work on an assumption that need not be generally true and thus changes of the code that are correct from a logic standpoint might still make them fail.