748 karma · joined April 24, 2012
I'm disappointed they didn't go with «» or similar to set apart type parameters. The answer in the doc is that they "couldn't bring ourselves to require non-ascii", but there's an easy way to handle this without _requiring_ non-ascii characters: let "(type …)" and "«…»" be syntactically identical, and have gofmt change the former to the latter. Basically everyone uses gofmt all the time, so all the code everyone reads would use the more visually distinctive syntax, but it would be easy to type using ascii only.
I'm not affiliated, just a happy paying customer. I organize a pretty good chunk of my life in it.
https://github.com/gilesknap/gphotos-sync
is a command-line tool (in Python) that downloads (incrementally) your Google Photos content directly using the Photos API, not through Drive. I just set it up recently.
The two main caveats are the lack of location info and that it won't re-download photos that have been edited.
I filled up the root filesystem by accident once, which is supposed to be a very bad situation for btrfs. I was able to ssh in, diagnose stuff, delete the offending files, and then I did a minor rebalance to clean up some of the unnecessary metadata space that got allocated (not essential but I wanted to try it). No big deal and still works fine.
I haven't used any btrfs raid features. I mirror it (via daily rsync) to an ext4 filesystem on another device to guard against filesystem-related bugs and device failure.
I think the usual situation is that the candidate was on a team where some impressive work was being done by others, understood it enough to talk about it in detail, but didn't actually do any of the challenging work themselves and couldn't work at that level consistently.
I'd like to think most people aren't actively lying or bullshitting, but it's easy enough to implicitly take credit for work done by a team when you're trying to sound impressive.
Could the plays’ many connections to Bassano be explained by simply
assuming the playwright knew her well? “Shakespeare would have had
to run to her every few minutes for a musical reference or an
Italian pun,” he said.I was kind of annoyed because the initial settlement was apparently so embarrassing that the _judge_ rejected it, something like $330M on supposedly $3B in lost wages. So they went back and increased it to the $435M, still nowhere close to what it should have been. Of course at this point the lawyers' incentives and the class' incentives are not aligned at all, so that's how it ended.
For the record, I'm current using Ubuntu on an X1 carbon 4th gen and it has worked literally flawlessly since day 1, no issues with wifi, bluetooth, or sleep, and it has great battery life. My X220 before that was 98% perfect.
Thank you for reporting bugs, though!
Also Rdio.
I'd like to note that even if you're a static typing fan and don't believe that argument for code, you can still believe it for serialization and protocols, because data schemas and protocols evolve in different ways than code does (they're almost duals of each other).
The thing I realized was that even if a field is present, you almost always still want to do further checks on it before declaring the whole thing valid and good to go. "required" just tells you that it's an integer, for example, it doesn't tell you if it's in the range [0, 1000). Or that a string is a valid filesystem path. Or that two parallel arrays are the same size. You have to do those things anyway, so the has_... check is no big deal. And making everything optional is really nice when you have to make large changes to your protocol and don't want to have to carry around dummy values forever.
Protocol buffers weren't designed from scratch by Jeff Dean, they evolved from various ad-hoc ways of specifying query parameters (which, ok, were probably mostly written by Jeff), so I don't think it reflects badly on him to say that required was a mistake. Groups were a mistake in retrospect too, but no one thinks that means Jeff is an idiot.
> Google programmers living two to three to a bedroom in Bernal Heights, not even that close to BART.
Why would Google employees care about living close to BART? They take the Google shuttle to work, and Bernal has great highway access, making it a shorter commute than other parts of SF.
Besides that, the people I know who have tons of roommates in SF do it because they want the experience of living in SF (culture, nightlife, food, socializing). If they just wanted to make money and save as much as possible, they'd live on the peninsula or in the east bay and have a more comfortable, and also cheaper, housing situation.
Even for people working in SF (SOMA), commuting on BART from Oakland is often faster than many parts of SF, and almost certainly cheaper. If you choose to live in SF anyway, it's because you want to be there specifically.
I haven't used evernote so I don't know all of its features, and I'm sure dynalist is missing many of them, but it's wonderful for all those things you mentioned (notes, lists, ideas, reminders, todos). The android app is a little sluggish, but that's pretty much my only complaint, I love everything else about it.
A text file sitting next to the config file? I can't see any benefit to that arrangement over just using comments in the file.
Comments that exist in the file in the repo but get stripped out by the deploy process? Again, there seems to be no point to doing this.
Commit log messages? I agree commit logs can sometimes be valuable to see the context of a change, but 1) they're fundamentally about documenting _changes_, not the contents themselves, and 2) the UI is really clunky: git blame, find the line you want context for, then git show on that commit.
Whether documenting semantics of fields belongs in a config file or code (I say both!), it simply doesn't make any sense to say that comments about why specific values in specific files are the way they are belong in the code that parses them. (How can the parsing code have knowledge of all config files out there?)
Tip: get some rubber gloves to deal with the concentrated solution.