HN user

betamike

117 karma

[ my public key: https://keybase.io/betamike; my proof: https://keybase.io/betamike/sigs/WH6jjvgJ6iRtAKwkayMdwMGpLxjvEQtb2os6yJavgWA ]

Posts1
Comments13
View on HN

This is what my last, 6 person, startup used, and it was really helpful. It lowered the barrier to having a quick discussion, since you could see if someone was at their "desk" or busy in a meeting.

Also you can see if other teammates are having a discussion or co-working in a common area, which made for some ad-hoc co-working sessions.

Author here, and yep! We eventually want to offer those kinds of enterprise features (SCIM, syncing group membership from Okta/other IdPs), so I kept that in mind throughout the process.

While I haven't gone too deep on that yet, I was thinking we'd take inspiration from how GitHub maps IdP groups to native GitHub teams. So first step here would be adding user groups/teams natively in the product.

I skimmed the paper, and it looks like they are looking for swearing _anywhere_ in the repos' code, not just comments.

I would be curious to see the ratio of swearing in comments vs code identifiers. I'd also be curious to see if the repos with swearing in their comments just have more comments in total. Perhaps the correlation is, "code with more comments is more likely to be higher quality".

IBM's Asshole Test 4 years ago

Hah! This reminded me of a similar story:

"In 1951, David A. Huffman and his MIT information theory classmates were given the choice of a term paper or a final exam. The professor, Robert M. Fano, assigned a term paper on the problem of finding the most efficient binary code. Huffman, unable to prove any codes were the most efficient, was about to give up and start studying for the final when he hit upon the idea of using a frequency-sorted binary tree and quickly proved this method the most efficient.[5]

In doing so, Huffman outdid Fano, who had worked with Claude Shannon to develop a similar code. Building the tree from the bottom up guaranteed optimality, unlike the top-down approach of Shannon–Fano coding."

https://en.wikipedia.org/wiki/Huffman_coding#History

Very cool. If you have a recent enough version of Redis, you may want to move away from doing the lookup using KEYS and move to SCAN (http://redis.io/commands/scan). KEYS will work for a while, but with a large enough DB it can become a very slow operation so it's not typically recommended for a production system.

Also, just curious, I see that the original url is encoded in the key, so the key is "<short>||<original>". Since the key is already a hash, it seems that you could eliminate having to scan over every key in Redis by making each key be only "<short>" and having an additional field in the hash for "original". Then a lookup becomes simply an HGETALL (if you need to get the "count" field, otherwise just an HGET for the "original" field). I might be missing something though! </armchair programming>

You can define a category within your implementation file (.m) and redeclare the property like this:

@interface MyClass (PrivateMethods)

@property(readwrite, retain) NSObject *myProperty;

@end

@implementation MyClass ...

Now only your implementation knows about the generated setter methods, and you don't have to implement them yourself.