Do you rely on Time Machine? Drop to the shell right now and try "tmutil compare -n" to see which files are not making it onto your backups. For me, Time Machine randomly ignores certain files, for no discernible reason. Files that have sat on my disk literally for years will never get backed up. It's happened to me on two different Macs, and I've lost data because of it.
I ran into the same issue. After a restore from my time machine backup, I discovered that some files where missing (with no apparent pattern). Fortunately, I had a non time machine backup, but pheew that was a close one...
I discovered it when visiting an old project after a whole OS wipe-and-restore from TM. A week later I found that 'git' wouldn't recognize a project dir due to some missing pieces. I had a 2nd TM drive, and was able to manually restore files.
For my other machine, no such luck. I had a 2nd backup offsite (Backblaze) but it was months before I noticed the damage, and so the old files were no longer available via the offsite. I think the worst part is not knowing what you've lost. I have thousands of music and photos on that machine, and every once in a while I come across something that's gone.
I'm trying so hard to love Clojure, but I keep running into examples of code like this in the world: http://imgur.com/79FlpTL. I don't write dense Lisp code like that, but unfortunately a lot of other people do. And I spend far more time reading code than writing it.
Think of this code as taking a built-in data structure and repeatedly refining it by transforming it into a different data structure. With only a little more practice, you'll find reading (and writing!) code like this becomes second nature.
I find it much simpler to deal with this style than with the equivalent in other languages, which would scatter the details across a half-dozen files, a dozen classes, and two dozen methods.
I meant that in general, we as programmers will spend more time reading (our, others') code than writing it. Nature of the business. Did not mean to imply this was a bad thing.
When I consider adopting a language, part of that consideration is how well I can read others' idiomatic code. It's so important for understanding libraries. I'm still just having a hard time with Clojure. I know it clicks for a lot of people though.
Amen to that. I try to write mostly functional Python, but I use a lot of temporary variables to make such things as f(g(args) more readable where each arg is in itself a non-trivial computation that must be passed along to another function.
The problem with your let strategy is this can also impair readability if you use too many as the code becomes too far indented to the right (lets inside of lets inside of lets).
But I guess in these situations you can just use transients that are first defined to nil. Some people will probably yell at you for this.
It's a page from the O'Reilly Clojure Programming book. I hate to point fingers at the authors, because it's generally a really great book. Just that some of the examples are rather dense, and I get the feeling that this is not at all unusual in the community.
This article prompted me to dust off Firefox to try it out again. Right away I notice a nice improvement over Safari- Firefox seems willing to cache a page for "back button" behavior longer than Safari. I always hate when sites fail to set their cache-control to something reasonable (Reddit is especially bad about this). So you click a link, read it for 5 seconds then go back- bam, full (slow) page reload. Firefox instantly fetches the page from local cache without hitting the server again. I really like this.
I am pretty sure my dad didn't like them to begin with but the question at the time was 'do I give the cops a hard time and spend even more time out here or let them take a look and get on my way'.
Drunk driving is a serious problem, no doubt about it, but stopping everyone on an interstate to talk with them is insane overreach.
I am surprised no one's figured out the problem of analyzing traffic camera data to flag people who are driving erratically so enforcement can be both more comprehensive and targeted. I'd be wary of that solution, too, but it is far better than stopping everyone.
>but stopping everyone on an interstate to talk with them is insane overreach.
Especially when they aren't really looking for drunks, but people like your father to victimize as police fundraiser.
Anything that monetizes police action will lead to massive abuse. It blows my mind people won't accept that. The cops and the unions aren't stupid. They want that money for salary, pensions, and toys. The politicians want that funding without having to raise taxes.
So now the electorate is literally being bullied and mugged by the police. I'm really starting to like the lame-duck version of Obama. His recent moves are very much needed: encouraging municipal fiber, workers leave rights, sanctioning Russia, immigration amnesty, etc.
Unfortunately as executive orders, rather than laws, they can easily be undone by the next executive.
I think it's overly diplomatic to call this action a police fundraiser. These were highwaymen. Note they aren't doing this to their locals, they know better and that's why they're on the interstate, they're doing it on behalf of the locals. The rot is with the town itself.
Clearly this particular instance wasn't about catching drunk drivers or apprehending drug dealers. This is blatant arrogant thievery, while also accusing both transient travelers and their local constituents of being morons for falling for this veneer of an excuse: oh it's for drunks N drugs, OK! At the very least the police could have restricted this to race and class as subterfuge, but no this was absolutely brazen: give us your fucking money grandpa! That's what really happened.
I will bet they had a lot more resources for doing searches than they did sobriety checks for those who refused the search. The search would therefore seem fast, while you probably had an insane line waiting for a sobriety test. This is a town with significant corruption and nepotism problems, and is operating like a cartel itself.
I read so many reports of Yosemite being faster that I was beginning to think I was the only one who was disappointed.
I have an older machine (2010 Mac Pro tower), but it's been upgraded to 16GB RAM and an SSD over the years. I experienced an initial degradation in UI performance with Mavericks, but after the first OS update it was as fast as ever. Yosemite comes out, and now it takes over second to switch between Safari tabs on an otherwise idle machine. I had hoped that like Mavericks, this would be resolved in the first OS update, but no such luck. I enabled the "reduce transparency" option (this was recommended to speed up the UI) but it didn't help.
My mid-2012 MBr doesn't seem to suffer from this. I wonder if Apple just didn't consider video cards in older hardware. Not an unreasonable thing to do, but I'd have preferred a "sorry, this machine can't run the latest OS" message instead.
The new security in iOS 8 protects information stored on
the device itself, but not data stored on iCloud, Apple’s
cloud service. So Apple will still be able to obtain some
customer information stored on iCloud in response to
Some? I think the importance of this qualification has been overlooked everywhere it's been reported.
The message seems to be that Apple are 'locking out the NSA' which is nonsense of course, but both may be counting on the fact that a typical consumer won't really look too closely at the claim. Their takeaway is that Apple's phones are perceived to be safer.
Apple gets to sell more phones due to this perception, the FBI get to continue hoovering (no pun intended) up iPhone user's data, and everyone goes home happy. It seems to be a manufactured controversy, with Apple & the FBI both playing their parts and knowing full well the rules of the game haven't changed one bit.
The most famous example is the DES S-boxes, where the NSA made a change that nobody else understood - until years later, when it was discovered that they had made the algorithm more secure against cryptanalysis techniques that had just been "discovered", but which had evidently been known to NSA long before.
To expand on the DES example, the S-boxes are essentially large 'random' lookup tables. The NSA took the S-boxes, and replaced them with their own tables. At the time, it was not clear if this was to protect against an unknown attack, or to introduce an unknown attack (which may involve knowing some secret key used to generate the S-boxes).
The -1 in SHA-1 isn't because it was first. It was meant to be just "SHA", but NSA discovered a flaw in their own standardized hash algorithm soon after they published it and issued SHA-1 as a fixed version.