turaw | 9 years ago | on: Scaling Mercurial at Facebook
turaw's comments
turaw | 9 years ago | on: Comparing Git Workflows
turaw | 9 years ago | on: Comparing Git Workflows
> ... how can you tell which one of the parents is the previous commit in the master ...
You can use --first-parent [1] to disambiguate that. In a nutshell, the master branch in your example would be the first parent, letting you disambiguate (and there's support for this in a lot of other git tools!)
[1]: https://git-blame.blogspot.ca/2012/03/fun-with-first-parent....
turaw | 9 years ago | on: Am I really a developer or just a good Googler?
"The creative application of scientific principles to design or develop structures, machines, apparatus, or manufacturing processes, or works utilizing them singly or in combination; or to construct or operate the same with full cognizance of their design; or to forecast their behavior under specific operating conditions; all as respects an intended function, economics of operation or safety to life and property."
In my ideal world, every developer would do what you're describing as engineering, and the software engineers would be those who far exceed those requirements.
turaw | 10 years ago | on: Never trust the client
turaw | 10 years ago | on: Never trust the client
Or, identify that your business need is just to provide 'some' sort of ranking and compare the user against their Facebook/G+/Twitter friends, who are probably less likely to cheat.
turaw | 10 years ago | on: Have Software Developers Given Up?
[1]: https://en.wikipedia.org/wiki/Pareto_principle In case you didn't know this but srs you're on hn
turaw | 10 years ago | on: Have Software Developers Given Up?
:'|
Could you take a look at how they're receiving offers and perhaps put some suggestions together on how to duplicate that effect? Most programmers I know have had extreme difficulty getting a job, especially one that would pay at-or-above the average rate (per Glassdoor).
turaw | 10 years ago | on: Organize Your Closet Like a Computer Organizes Memory
I do think that analogies should be less, for want of a better term, leaky than those presented in the article: if they hadn't dragged CS topics into the discussion, I would've upvoted a reasonable productivity article and left it at that.
turaw | 10 years ago | on: Ask HN: How do you deal with so many project management systems?
[1]: https://sameroom.io
turaw | 10 years ago | on: Organize Your Closet Like a Computer Organizes Memory
In sum, it felt like I was being advertised to in an native format, so I called it native advertising.
turaw | 10 years ago | on: Organize Your Closet Like a Computer Organizes Memory
"Most people have several stores for clothes..." I'd argue that most of those are acting like FILO queues anyways, since you typically don't need random access to clothes in a washing machine/from the to-be-washed pile.
"On days that I need to be out of the house particularly early, I will "cache" my next day's clothes..." you're still spending the same time overall ((sum over all day's clothes(time(access clothes)) + time(get dressed)) to get your next day's clothes, so preloading them just reduces the time spent when in the mornings when deadlines are tight. That's a totally valid technique, but it isn't caching as described in the article, which is described as a technique for mitigating the cost of frequently accessing high latency resources, since you (probably) only infrequently access clothes to wear. In that case, the time spent overall is (probably) dominated by the lookup times for single articles of clothing, so excellent organization is (probably) the best way to cut down on overall time. You'd need to profile to determine whether it could be of use, though.
"I've got a cache of stuff that I need on a daily basis..." that's actually quite valid! I had mentioned b-trees ]1] jokingly, but they can be analogized to what you're describing (feel free to skip the next section if you're already familiar with them). Idea in a nutshell: since hard drives are slow and return data in blocks (you can think of it as retrieving shelves of data at a time instead of individual items), it makes sense to pack as much relevant information as possible (spatial locality) [2] into each block (which b-trees do by having a large branching factor and including data inside of nodes). The relationship to placing items in discrete groups around the house is quite similar: physically moving (following a pointer) is quite slow, so once you're somewhere (a block), you want everything of import to be nearby (high locality, no need to follow more pointers). This is _still_ not caching, since you weren't going to sit down and perform some access intensive operations on your wallet and keys in the morning, but it does have some distant relationship to a CS data structure :)
Or, at least, that's my take on it.
edit: I'd just like to mention that I don't follow any of that advice and just use a roughly sorted laundry bin to keep most of my clothes in a single place, if not in any particular order.
[1]: https://en.wikipedia.org/wiki/B-tree
[2]: https://en.wikipedia.org/wiki/Locality_of_reference#Types_of...
turaw | 10 years ago | on: Organize Your Closet Like a Computer Organizes Memory
As the article states, caching is useful when you have memory stores with different access speeds. This is (frequently, in my experience, caveat caveat etc.) not the case in reality, where you only have the one storage area that has a fixed, fairly low access speed. People are mostly bottlenecked by scanning rate, so it'd make more sense to use an indexing mechanism. Maybe b-trees for closets? B-trees, perhaps, if you store things in boxes?
turaw | 10 years ago | on: Pinterest Reinvents Itself to Prove It’s Really Worth Billions
... all judgment aside, I hope the people working there are doing alright. Hinging your self worth on your work ethic in a company can be exhausting.
turaw | 10 years ago | on: EU hits Google with second antitrust charge
Licensing of Google’s proprietary apps:
The Commission seeks to ensure that manufacturers are free to choose which apps they pre-install on their devices.
Anti-fragmentation:
The Commission has found evidence that Google's conduct prevented manufacturers from selling smart mobile devices based on a competing Android fork ... In doing so, Google has also closed off an important way for its competitors to introduce apps and services, in particular general search services, which could be pre-installed on Android forks.
Exclusivity:
The Commission takes issue not with [financial incentives to ... smartphone and tablet manufacturers ... on condition that they exclusively pre-install Google Search] in general but with the conditions associated with Google's financial incentives, in particular with the condition that the financial incentive is not paid if any other search provider than Google Search is pre-installed on smart mobile devices.
[1]: http://europa.eu/rapid/press-release_MEMO-16-1484_en.htm
turaw | 10 years ago | on: Iceland's Water Cure
edit: Ah! Also cool is dental cement [2] which is, as the name would imply, used in dentistry (but without any aggregate equivalent!).
turaw | 10 years ago | on: Iceland's Water Cure
"There are ramshackle _cement_ rectangles squatting under rain clouds..."
It's concrete [1] not cement. Even the word cementing can mean "settle or establish firmly", which is what happens to the aggregate in concrete. Augh.
[1]: http://www.todayifoundout.com/index.php/2011/12/the-differen...
turaw | 10 years ago | on: Facebook is worried about users sharing less – but it only has itself to blame
turaw | 10 years ago | on: The Real Story of How Amazon Built the Echo
edit: Except, apparently, on that site.
[1]: https://chrome.google.com/webstore/detail/animation-policy/n...
turaw | 10 years ago | on: On Let's Plays – That Dragon, Cancer
"Razer Inc., who acquired the Ouya platform and property in 2015, stated that all revenue from sales of That Dragon, Cancer on Ouya would be donated to the Morgan Adams Foundation and Family House SF, two charities that had assisted the Greens' during Joel's treatment in San Francisco."
There's also this ever-present feeling of dread whenever I invoke any p4 command -- if I absentmindedly submit something with unshelving the change that I had shelved after making a previous change but reverted when trying out a new change, I can wipe my old data and lose work. Or some issue comes up in a deployed environment, so I have to grab a new workspace (or dance through shelving/unshelving all my open CLs), have a 10 minute coffee break while it syncs, sync up to the release line and work on that one. Also my IDE doesn't like being switched rapidly between repositories all the time. Also it's difficult to just _commit_ some code after making a change and wanting to save progress. Every operation is just so stress inducing; how do you handle it :/