I love it when people implement the stuff I haven't had the time to do myself. Well done.
One suggestion: Your use case is well defined. Don't get thrown off by people in here suggesting millions of features.
HN user
I love it when people implement the stuff I haven't had the time to do myself. Well done.
One suggestion: Your use case is well defined. Don't get thrown off by people in here suggesting millions of features.
He would indeed benefit greatly from reading a bit of Polanyi.
Interesting, and potentially useful. However:
"All stores support key expiration, but only memcache supports it natively. All other stores emulate expiration." Redis doesn't support volatile keys??
Also, does it allow access to a DB's tuning parameters? It makes a great difference whether to use Tokyo's B+ tree database or its hash database ...
QED
I had an ATI 3870 which was supported in 10.5 but ceased to be in 10.6 - a shame, since it outperformed the nvidia cards in core graphics by a large margin.
As someone who ran a hackintosh for over a year, here's the summary:
CON - even if things work now, they can and will break in the future (removed hardware support etc)
- every update takes time and work
- don't even think about running it on the hardware you already have - only use specifically built systems (such as those linked)
- backups aren't as nice as on a mac (disk cloning, time machine)
PRO - you get a lot of harddisks (internal, cheap and fast ones)
- it's almost stupid not to use a raid setup (such as 10)
- serious GPU power is affordable, but OSX is picky
- repairs are really really cheap
Most people are not pissed at BP - they just want them to fall. It's reality entertainment.
(This obviously excludes anyone who's really affected by the spill.)
De-referencing short urls is a pain.
http://www.longurlplease.com/ is quite nice.
Bookmarklet, FF extension, and a JSON API. I've used the API, and it was a pleasant experience.
Most important: Folic acid (B9).
Apparently has strong correlation with IQ. Makes me wake up instantly in the morning. Less tired. Better concentration.
Don't take more than ~400mg /day.
If you can, get the new sigma 50mm 1.4 instead of the Canon. The sigma has USM, better bokeh, is faster, has better build quality and seems a bit sharper. Both go for around the same price (~300 euros).
Doing the math roughly is actually easy. Every tweet that doesn't come from search endpoints has the user details inline. The user details include the number of followers.
So just consume the filter streaming api with your chosen hashtag. You will get all the tweets, or at least some and a measure of how many you missed (limit notices).
For every new user in said stream, add the number of her followers.
It's so easy you could write the code in the length of this comment. Of course, if you want to avoid counting duplicate followers, you'd have to do an average of 1-2 additional calls per user.
Twitter clients on the desktop suck.
yorufukurou does regex and is generally tolerable (OS X) http://sites.google.com/site/yorufukurou/home-en
Apart from that, it's easy to roll your own stuff - for example using the tweepy python library.
A very valid point.
I'm not entirely sure what kind of analysis you are thinking about. Statistics in R for me entail a lot of human intuition, interpretation and decisions. You probably don't want a script building your models for a confirmative factor analysis, for example.
The arguments are good and sound, but could be simpler:
If you can "grasp" your data by looking at it, use excel. If your data is too much to look at, use R.
Excel lends itself more to shallow exploratory approaches, while with R, you have to think first (or rather: always).
Although the 160GB has a slight write advantage over my 80GB G2, it appears those last 15% make quite a difference. That wouldn't be totally out of line from how regular HDs behave once they approach 100% utilized capacity. SSDs (the intel ones at least) have a buffer of cells that are inaccessible to the OS (that buffer is larger on e models), maybe that's double for the 160?
Back when I tried that I simply used xbench - the 4k block writes went below 10MB/s. I don't have the exact numbers, but I do remember that mac os took > 30 seconds of spinning wheel to boot, compared to 1-2 usually. BTW, filling the disk is as easy as performing "erase free space" with Disk Utility.
SSDs do degrade by around factor ten (!) in write performance when full, although not in read performance. (Tested this with an x25-m).
Sadly, recovering from a fragmented SSD on OSX right now involves opening the machine and booting linux. (I tried that, and it works: http://forums.macrumors.com/showthread.php?t=841182)
As long as you leave plenty of free space, SSDs work great out of the box. Don't ever fill them (something beyond 80% capacity), or you will crush performance. The tweaks in the article are attempts to optimize for the last 2%, but in no way necessary.
Another way to save (the oh so precious) space on SSDs is to apply HFS+ compression to files.You can use ditto(1) or this GUI: http://latenitesoft.com/squeeze/
Note, however, that files are decompressed on writes, so don't try it on anything large and frequently written to.