Why HN was down
261–270 of 303 posts
Re: Why HN was down
#262Earlier quoted context omitted.
I do this a lot too. In fact more often than not I end up not posting the question because either I solve the problem or I think of a possible solution I should go try first. I think we should start calling it Digital Rubber Ducking.
I am looking for an excuse to make digitalrubberduck(y/ie).com If I was a bit more clever I feel like there is a use there.
Re: Why HN was down
#263[deleted]
Re: Why HN was down
#264Appreciating the details. "Hacker News was down all last night." With the internet there is no "last night" ;-) Europe - and more so Asia I assume - had to live for many working hours without HN.
Re: Why HN was down
#265I'm not sure whether it's terrifying or relieving to realize that if all I dream of comes to pass and I achieve something akin to the legendary status of pg in the hacker community that I will still be susceptible to the inevitable facepalm moments that come with direct database access. In any case I am thankful for the detailed explanation.
he's not legendary for his IT skills.
Re: Why HN was down
#266Earlier quoted context omitted.
I've never screwed it up on a live database, but I do take about 5 mins, first reviewing the keys, the type, whether or not something can be null, checking to see if critical columns have select count(distinct column_name) having count(distinct column_name) > 1; To make sure that there isn't an underlying uniqueness assumption. Sure I could do it in 10 seconds and save myself 290 seconds (a 97% savings!) but then one…
This. Back in the day when I was in more of an analyst role, I ended up /having/ to hack on the live DB frequently (reasons for this were myriad). 1. Always, always make a backup just before the hack. 2. Write a small set queries like 3pt14159's to check uniqueness and other pertinent properties. 3. Write a SELECT query to show the data you are going to change. 4. Borrow the WHERE clause from 3, and write your UPDATE…
Re: Why HN was down
#267Earlier quoted context omitted.
> And that's how processes are born. Not necessarily. Processes are implemented by people, so they can break at any time. The correct solution is more code, or less bad code.
And how do you get less bad code? Magic dust or process? My money would be on the latter, as in http://www.fastcompany.com/28121/they-write-right-stuff .
Re: Why HN was down
#268Re: Why HN was down
#269Hacking code in the repl without testing the new behavior. We all did that. Don't lie. Once I wanted to quick fix a "gmail.ca" to "gmail.com", which I did.. but to all the users instead of just the one mistaken. Fortunately I realized by mistake really fast ;-)