Wasn't worth keeping it around after that.
735 karma · joined March 28, 2012
Wasn't worth keeping it around after that.
We've found that this will beat a 'better' parallelism even if we need to do a lot of extra or redundant work due to the lack of IPC or reduction due to the no-overhead approach, although this will of course be highly dependent on the problem at hand.
Unless we're already there, but some short internet searches found nothing but misleading blog post titles.
Even geeks can’t handle folders in folders
Hierarchical file systems weren't invented because it was ancient times and they were the easiest thing to produce. Hierarchical file systems were invented because they are a really, really good paradigm for storing and retrieving hierarchical data - which I strongly believe is still the case for the majority of files.I didn't read further in to the article so perhaps I missed where this same idea was discussed, but I think a useful idea going forward would be meta-tagging of data. Something very basic like the ability to flag a file and later search or sort by those flags. Do it for specific folders, like the Documents folders. Done.
Now the 'non-geek's can deal with flat file structures and us 'geek's can do smarter things.
There is no content in this post, no useful points, no specific examples of what is wrong (although there is an example of how to do it right - thanks for that). No call to action other than "Do it better!".
I'm not saying it isn't worth talking about, I'm just honestly curious how the HN algorithm works that this has made it to the top. Is freshness so highly weighted?
Let me try to articulate my point, but I could probably use some help:
I suspect that the sort of developers who were writing apps and using SQLite locally but deploying with Postgres were the sort of developers whom will still use shaky and poor development and deployment practices regardless of whether or not Postgres is available to them locally.
Orthogonally, I think that the kinds of developers who will actually take the time to follow best development and deployment practices probably wouldn't want to use an app like this - not because it isn't a nice and helpful app, but because they probably want to install the full always-on server bundle via 'brew'.
That's my guess anyway. Does this mean the app was a bad idea? No, definitely not. But I don't personally expect a huge uptick in Heroku deployment quality because of it. At least it definitely won't be for lack of trying!
I use bloom filters in an application at work and was very interested to hear about this, wondering if some sort of hybrid might be useful. But when I saw that the hash map was storing the actual objects, I immediately dismissed the idea for my use case - we can't afford to store anything more than a handful of bits. (Our bloom filters set between 9 and 11 bits per signature.)
The key advantage to bloom filters is that the represent set identity lookups (albeit in an adjustable lossy false-positive way). They do not, however, store actual sets of data. They must be coupled with a storage mechanism (traditionally with a several-order-of-magnitude slower lookup speed than the bloom filter) to actually store the items contained within the set - the bloom filter is just a way of definitively answering the question "Could this set possibly contain this item?"
The best part was that this was in Javascript (and obviously he was not using a timeout). The entire page would lock up while it waited for the second to elapse. He never even figured out the obvious usability concern because he was so confounded by the fact that the procedure wasn't getting called after a second had passed.
Ok, to be fair, it was a freshman year programming class - not an unexpected or even unusual mistake. But it gave me a chuckle just now remembering it.
1: https://chrome.google.com/webstore/detail/cljcgchbnolheggdga...
Working on someone else's project is something that eats a LOT of time. Even small projects inevitably end up taking weeks, months, or years.
If you're getting paid or if it's a personal passion then it tends to get done very quickly. Anything else tends to be regulated to release-date-pushing hell.
If anyone is interested, here is the URI: http://eblume.github.com/gmail_safe/
Note that this is my first Node app. It needs a lot of polish. It is published under the MIT license, though, which some people here might enjoy.
I was told that this is because such a policy allows the company to respond to subpoena requests by simply saying "our policy is to discard all emails after two months, so we cannot comply with this request."
The long-winded answer goes in to a huge amount of details on really interesting pattern matching problems... but not really the specific problem mentioned by the question asker.
I'm glad for a world with Stack Overflow and other similar resources, because I find the long answer fascinating but if I were asking the question I'd much prefer also having access to the shorter, succinct, and also-correct answer beneath it.
It's really a fantastic idea and something I fully intend to use in every capacity that makes sense going forward. It doesn't make much sense as part of the software design flow, but it absolutely could (and probably should) be a tool in any deployment protocol.
My AARs usually read pretty much like this blog post, more or less to the T, although we emphasized what we would do differently in the future more.
A name by itself, you are quite right, is not PHI. Thanks for the reminder!
Often, names alone wouldn't necessarily constitute a violation as names are generally not sufficient to count as personally identifiable information... but a name like 'Bobby Null' is, I think, quite unique.
When I was being trained on HIPAA compliance I was told that sole first names are generally perfectly fine, and sole last names can often be fine but should be avoided for very common names. But I should also say that I am not an expert on HIPAA compliance.