Augh, I've been trying to like Perforce for a year and have hated it at every turn. I invariably wind up having ~3 workspaces open so as to map to different parts (or different views of the same) of the depot, constantly swapping back and forth between them whenever there's a problem that requires attention on some stream or another. Code reviews are awful; I need to balance tonnes of CLs (and their shelves) so as to save _my_ current work, grab the reviewed code, reset everything etc (or I could just make a new workspace for each review! hahahah).
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 :/
> ...this is solved by the named branches in Mercurial...
I'm not super-familiar with Mercurial (and only somewhat-familiar with git), but couldn't you get the same effect as named branches by just not deleting fully merged branches in git?
> ... 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!)
For comparison, I would normally define an 'x' developer (depending on specialty) as anyone who writes code and a software engineer as a developer whose job description involves engineering, per the American Engineers' Council for Professional Development [1]:
"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.
Recording and playing back input events, at least, shouldn't be that expensive unless you're emulating the entire stack up to the application. If the logic is written in some portable manner (Xamarin [1], etc.) you could just re-execute on the server with the same logic as the client. It requires a fair amount of discipline to keep everything deterministic, too. The real difficulty would be identifying the AI players from the humans; you'd basically have to recreate re-captcha's humanity checkbox, and that's still not a guarantee.
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.
How do you signal goodness, though? I wound up with a cushy position (largely by luck), but practically everyone else is barely scraping by. Side projects? Prestigious internships? l337 hax0r skillz? Maybe the 80/20 rule [1] applies and there are only a few, key factors that make some applicants stand out?
> most programmers I know receive several offers a month
:'|
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).
Essentially, I agree with everything you said -- the core of my complaints about this book excerpt is that it seemed to confuse the areas of responsibility for caches (and their structures) and efficient storage data structures.
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.
I guess, when it's an excerpt from a different source, I feel like it's advertising? Like, if Wired were a journal I were paying for, having excerpts makes sense -- the editors found some piece they thought would work well in that issue, so they purchased a license for it and ran with it. But Wired? Given how much they complain about adblockers, their revenue from advertisements can't be that large to begin with, let alone large enough to share. My reasoning, right or wrong, was that the excerpt was placed primarily to drive sales of the book (and perhaps to get some clicks in the process).
In sum, it felt like I was being advertised to in an native format, so I called it native advertising.
I'm going to do the thing where I quote sentences from your comment and respond to them individually, which IMO is normally pretty aggressive -- just wanted to say I'm doing that for organization's sake, not for any other reason.
"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.
By the way, that article is an advertisement for "Algorithms to Live By: The Computer Science of Human Decisions" [1] in case you're triggered by native advertising. That out of the way ...
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?
My first instinct was to post a message on HN about how yet another company is fetishizing overtime. It's not even productive to work at that pace; IIRC, most if not all people wear down too quickly for that to make sense. If anything, this proves that the management at Pinterest can neither stay on top of their own product nor set deadlines properly.
... 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.
Just digging through the fact sheet released by the European Commission [1] to gain a more concrete understanding of what the investigation is trying to turn up. Quotes are heavily edited; please read the full document before forming opinions :3
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.
Fair enough :/ it just feels like 'misusing' words is disrespectful to their source, as though a lack of effort was taken to use it 'properly' (air quotes since those are highly subjective terms). In a detached sense, I suppose seeing semantic change [1] in action is neat, but it is still just the tiniest bit depressing.
edit: Ah! Also cool is dental cement [2] which is, as the name would imply, used in dentistry (but without any aggregate equivalent!).
Don't you feel that way on most sites? I mean, conceivably, HN could be manipulating your feelings as well by fingerprinting your browser and using a different ranking algorithm.
I've been using Animation Policy [1] to only play gifs through once and it's worked pretty well so far (in contradiction to the reviews on the chrome store).
If anyone read this line: "And that is this: our studio has not yet seen a single dollar from sales." and also wondered what they're talking about, this excerpt from the Wikipedia article on their game [1] might help:
"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 :/