bhuga

I wrote an electron app to inject javascript and CSS into slack in an attempt to turn off a lot of distraction and, more importantly, easily differentiate between bots and people. I feel the author's pain, but the great part about being a programmer is that if it's bad enough to write about, it's bad enough to fix.

It allows per-team customizations, and if anyone cares to mess with it, there's a link at https://github.com/bhuga/hackable-slack-client. OSX only, but it's electron, so porting it would probably be easy.

Changing other people's applications' behavior is challenging but rewarding. The hacks required make great stories for certain kinds of parties. I always point people to https://news.ycombinator.com/item?id=11805380 for a better introduction than I could give.

There's plenty of agreement with you, so I'll offer a counterpoint.

When a company is small--less than 10 or 20 people--it really can feel like a 'family' in that everyone would rather see the company fail than break apart. "Layoffs" aren't realistic in such an environment; the company is either working or it isn't.

As a company grows, these rules necessarily change. It's just a fact of having more people, as the momentum of the company becomes bigger than any individual. It's part of how a company grows. I've watched it happen; it's a strange thing and it feels like something has been lost, no matter how necessary it is.

The change from a tight-knit team, battling for success against all odds, to a sizable company with growth curves, finances, lawyers, outlooks, audits and EBITDA can sneak up on you. I think it would especially surprise early employees and founders, who remember the days when it didn't feel like a company at all.

Employment is never quite 'family'. But there's reasons to be empathetic to these founders' mistakes and choice of words, rather than a blanket "anyone who thinks that way has another thing coming."

Fun article! I appreciate the author taking the time to go through the details, like formatting the source of the javascript, and figuring out the module system. Hacking on other peoples' websites is great fun. Everyone should try it, and I hope this article encourages a few people to!

I hack on Slack, which is complex enough that even small UI changes require hideous hacks. And since the javascript and CSS changes out from under you constantly, nothing ever works for long. I'm reverse engineering something to create an opportunity to produce code that runs against an API that will change without notice. But I get big, visible improvements I see every day, and the feeling of changing something that wasn't meant to be changed is just so unreasonably satisfying!

It's bad enough that the VEP was bypassed, but the high-profile, 7-figure payout for the security researchers who had their hands on the bug is a problem too. Plenty of bug bounty programs have remote code execution at $10k, but the FBI paid _100 times_ that. That's an amount of money that some bug hunters might find very challenging to turn down. And this is "above board", with no shady bitcoin payments from dingy IRC channels.

Slack does a good job overall, but I'm glad to see articles like this one challenging the enthusiasm that they've seen of late. I'm starting to share the article's opinion that Slack encourages unthoughtful communication. I do wish the author had spent a little time pointing out some specific product decisions that lead to the kinds of problematic communication they were seeing.

For example, basic product choices like "every message highlights a room for attention" creates, for me, a feeling of "farmville for corporate communications." There's always another channel to click, another few sentences to read. This makes Slack very engaging at first, and makes it highly successful at lodging itself into organizations. And that's great, because Slack's a far sight better than email. But this rapid-fire feel encourages synchronous communications, and everyone quickly learns that @-mentions and DMs get quicker responses. That in turn leads to communicating with individuals instead of teams (or instead of searching issues, or Jira, or a wiki, or whatever). I don't think chat has to be this way; product decisions can encourage a more thoughtful question and answer flow.

I think that Chat may be like product management: the product opinions matter quite a bit, and teams have varying styles, so there's room in the market for several different products. Slack does a great job for a certain communication style, but it's not the only style out there. I hope some competing products with different opinions gain enough traction to keep them honest.

I've found message retention to be a "checkmark feature:" It's technically there, but it's not really achieving the goals you'd hope for message retention to help with. You'd want to be able to say "Don't retain messages more than 90 days old except for the rooms I, the admin, specify." But:

* There's no API to set retention settings or defaults

* There's no API to audit retention settings for private channels

* Non-admin users can change retention settings for DMs and private rooms

* There's no way to enforce that private rooms and DMs get a maximum retention setting

> and a lot of process just to ship out one migration.

I would have agreed with you before working at GitHub, but the end result is that deploying is so easy that 3 deploys does not feel like "a lot of process." On most of our applications I can do this in 15 minutes or less.

GitHub now has a build (we have about 12 builds per github push) that runs all the tests with all feature flags enabled. This doesn't hit problems that only appear in the matrix of some enabled, some disabled, but in practice has worked pretty well and found a few minor issues.

It's quite a bit more hassle than normal American tax paperwork.

Every foreign bank account or financial instrument over some trivial amount ($500?) must be reported. Foreign banks must report your holdings and gains using forms more burdensome than the usual American ones. Good luck owning a company: if Americans have controlling interest in a foreign corporation, their books must be open to the US or the corporation's income will be included in your own. The last time I saw one, the form to describe your foreign corporate holdings had a Paperwork Reduction Act notice declaring it expects it will take 2 weeks to fill out.

I think the absolute simplest case would be a 1040 (not 1040-EZ), along with the extra form for the FEIE. The FEIE has a 'bona fide resident' determination section which is up for interpretation. Two examples are given in the instructions, but the IRS will not tell you if you count as a bona-fide resident in advance (I have tried to get a determination here, and they just won't make one). There is, thankfully, a 330/365 days out of the country exclusion; just carefully fill out the form that lists all of your travel days to any country for the year.

If you live abroad, your 16 year old kid is responsible for serious fines if they don't do this for their first McJob (in theory; I've never heard of it prosecuted that way).

This was all a few years ago; some details may be inaccurate. But it's a serious amount of work, and it's enough hassle that a lot of foreign banks and financial institutions simply won't do business with Americans (which is yet another hassle).

Interesting piece. It will take some time to digest.

I wonder about the arrow of causation for conformity back in the 40's. This essay describes WWII as a spark of a generation of conformity (preceded by the New Deal for some). But it's really hard to imagine modern society signing on to a world war. What's to stop parents afraid of vaccinations from taking their draft-age children to New Zealand?

Was there something else that was already more conformist? Or was there another proximate cause, maybe even one as simple as a perceived global threat (communism, fascism) combined with a lack of individual physical mobility?

The essay is good and makes a strong point in and of itself, but I wonder if there's other variables it (and I) are missing.

If pg is reading, one piece of concrete feedback:

> the LBO wave?

LBO wasn't defined in the text previously and I had to google it (it's leveraged buy-out).

I was taken aback by this as well. The Ruby community lets opinions be strong, and tends to converge on 'standards,' so I expected 2 spaces to be a strong winner. But beating out go, which ships with `go fmt`, is a pretty impressive community-wide commitment.

Does anyone know if this comes with an initiative to fill in the gaps in Slack's administrative API so addons can be created around that, too? I'm working with SlimerJS to audit message retention and a few other settings.

Slack has a great core experience and I understand why it's doing so well. But it's weird to see an $80m fund to invest particularly in Slack addons when a lot of existing features don't yet have API support.

If you've ever worked in residential construction, there's one constant truth: everything you make will be redesigned away before it fails. Our desire for novelty is strong, and cheap construction lets us reconfigure houses affordably in ways that old, stronger construction didn't. Someone will want a new countertop because it looks pretty long before the old one will break, and the same goes for closet space and windows.

That's no explanation for situation in the article, of course. One would expect that structural elements of large, dramatic investments of that sort would take proper care to last. But drywall-on-sticks is an economic reality that makes sense.

I suspect setting up the free LFS reference/test server[1] that GitHub provides would have taken less time than writing this post complaining that GitHub isn't free enough.

1: https://github.com/github/lfs-test-server

In that case, I might prefer an authenticator to a keyfob that requires insertion too. The yubikey is slightly more secure since it's actually signing a message from the server rather than sending a password that can be (briefly) intercepted and replayed. But it's probably not 'better enough' to encourage someone not to use 2FA at all if U2F isn't convenient.

If user security has taught us anything in the last 20 years, it's that security features have to be convenient or may as well not exist. I think we'll be seeing a lot more 2FA options in the next few years. In this segment, user choice is a huge improvement in and of itself. I've also been testing Duo push for some internal stuff, which is a phone-based experience that's as smooth as silk. To each their own!

Your point is valid, but this may be a bad example. Construction margins are so thin, and construction businesses so sensitive to it, and Lowe's and Home Depot are so fungible. Even among retailers, there's no room for margin. Especially on easily-compared items like tools; construction workers know what they're buying.

Yubikey has a "always available" form factor if you're already bringing your laptop to work in the neo-n: http://www.amazon.com/Yubico-Y-110-YubiKey-NEO-n/dp/B00O8ST7.... It just lives in your USB port.

The user experience is also better with U2F than previous 2FA systems. When GitHub prompts you for U2F, you press the yubikey and are instantly logged in. No typing random numbers with n seconds, no fake keyboard.

YMMV of course, but if you've tried U2F, it feels incredibly slick.

I was going to come comment that there must be a good way to solve this, since the Ruby community has such a rich ecosystem of tools.

Heroku, for example, has a nice one-click deploy button for Rails (and many more languages/frameworks). It works straight from the source code, such as with this open-source rails app, and it's really quite impressive:

https://github.com/heroku/starboard#deploy-the-app

The author also calls out error reporting as being terrible. And there's also great tools for managing that, such as newrelic and airbrake.

So surely this author was just unused to the tool ecosystem, I thought. What a perfect opportunity for a constructive yet snarky comment! But lo and behold, discourse has deprecated all non-docker installs:

https://github.com/discourse/discourse/blob/master/docs/inst...

I was, and am, completely baffled at that decision. And I learned a valuable lesson about trying to out-snark snarky blog posts.

The API was originally about SHAs, rather than refs, but for protecting branches trees make sense. (You can retrieve statuses by ref, but are required to set them by SHA). Since a SHA can be uniquely resolved to a tree, we're doing this under the hood rather than make a breaking API change. It also just makes more sense; nobody thinks in terms of trees day-to-day.

Thanks for you comments about per-commit linting. We'll give them some thought.

> Does the "required status check" thing apply to `git push`, or just to the merge button on the website?

It applies to all ways of updating git: push, the web UI, merging, and the API.

> how do you trigger a status check to run on your actual merge/rebase as made in your local client, which will almost certainly differ in SHA1 and may differ in content from the merge made in the PR?

If they differ in SHA1 but not content, things will work fine. A protected branch cannot be updated to a git tree that has not been tested.

If your PR differs in content, clicking the 'update branch' button on a PR will make the merge commit and your PR's content the same, so a new CI run will apply to the correct content.

I still live here, and I'm sick of the "Crime is part of the character" narrative. The Quarter, Marigny, Bywater, and Treme can have plenty of character without the risk of getting mugged biking home from work.

Some popular GitHub CI integrators already do this:

http://docs.travis-ci.com/user/deployment/releases/

http://www.appveyor.com/docs/deployment/github

The "lab" environments have enough capacity to allow plenty of parallel testing. When deploying to production, it's expected that you already know your branch does what it's supposed to do. A production deploy is when one makes sure a branch has not introduced regressions, so holding it for more than 15 minutes is rare.

The deployment system automatically merges master into the branch being tested on deployment, and will not deploy any branch that does not contain master. In fact, there is a check that nags the main app team if master is not deployed to production for some reason (usually someone merging docs changes while someone is testing a "real" branch). It's considered an abnormal state, and I will often block all deployments until we figure out why master hasn't gone out.

Even forced deployments (which ignore CI and a few other checks for emergencies or maintenance mode) won't deploy a branch that's 24 hours behind master.

"Bugs on onboard Wi-Fi, entertainment systems or avionics" are not eligible for bounties.

It's very strange to see website timing attacks as worth rewarding, but not avionics. Perhaps they'd rather not incentivize people to attack airplanes in flight?

The tutorial took a long time to write and is a great tongue-in-cheek read. Thanks for that, @pyos!

> Q: F# is better than Haskell.

> In that case, use <| or |> instead.

> Objects and types

> Wait, no. Gotta show you something else first.

That's a better, faster response than I have ever seen to this topic. I wish HN let me post a happy animated GIF to celebrate your choice!

The pattern of "Oh, sure, we're associated with that project" is a very dark one. "Contribute to something on GitHub off of GitHub" has been used by a number of hard-to-verify bitcoin tip sites, recruiter schemes, and shadier characters. I hope featurehub goes opt-in very soon so it can avoid a noisy argument like this one that made it to HN last October:

https://github.com/tip4commit/tip4commit/issues/127

You're right, the protocol is also required. I didn't link to it in my comment, but it is also open and well-defined. I've updated my comment. Thanks!

> tied to GitHub.

The protocol is open (https://github.com/github/git-lfs/blob/master/docs/api.md) and the client additions are open source. There is a reference server implementation at https://github.com/github/lfs-test-server.

edit: added protocol spec