Refactoring GitHub's Design - <AUTHOR> http://ianstormtaylor.com/refactoring-githubs-design/ <comment><USER2> "And at the same time, we can de-emphasize the branch switcher since it's so rarely used."

WRONG. This is why designers shouldn't be "redesigning" stuff they don't use.

Branching and merging with ease is what makes distributed scm's so much better than the previous generation. Why would one want to de-emphasize this?

And let's talk about what really used. Github is great for viewing code easily and making comments. So what did they do to the code view div in the latest redesign? They made it smaller! Unbelievable!

So now I have to use a Chrome plugin to fix it: [https://github.com/sauravc/github_wideload](https://github.com/sauravc/github_wideload)

These "designers" aren't entirely to blame though. A lot of what the author suggested makes things better. Unfortunately, coders are a tough crowd to please.

<comment><USER3> Hold on.

I don't mean to pick apart your comment but since you started off with a big bold nasty "WRONG" I don't feel so bad.

First, "branch and merging with ease" has nothing to do with "distributed SCM" tools. The branching model in Git is great of course but Mercurial for instance has a far different branching strategy. Bookmarks, which mimic Git branching, were added much later.

Second, while I do a lot of branching in Git, that has nothing to do with the branch selector on the Github UI.

Now, something that DOES, is the branch selector in the Pull Request screen which wasn't mentioned by the author but IMO should've been because that's the single worst part of the Github redesign.

<comment><USER4> > First, "branch and merging with ease" has nothing to do with "distributed > SCM" tools.

Local branches tend to be a feature of distributed SCM tools, so I'd say you're wrong.

<comment><USER5> Hm you mean that's the main feature? Oh hm yeah it is.

</comment></comment></comment></comment><comment><USER6> I really like this. One of the changes not mentioned in the article was merging the file path into the repo name at the top. Since the file path ALWAYS starts with the repo name anyway, this makes a lot of sense and eliminates redundancy.

It's a shame he didn't add the language colour bar into the final comparison screenshot. I thought that was one of the best changes. It's quite jarring where it is right now.

edit: The one issue with this redesign is it clearly goes against a philosophy which GitHub has recently embraced: quickly seeing the status/overview of a repo. Moving the Commits, Branches, Tags, and Contributors from up top to the right sidebar definitely reduces some clutter, but it makes them much less of a focus. And I'm pretty sure this is something GitHub wouldn't want.

<comment><USER7> As TFAA hints, the Branches and Tags counts don't provide any useful information, they're highly dependent on the author's coding and usage style and are orthogonal to any interesting information about both the repository itself and user engagement with the repository. Consider: Django has 38 branches and 41 tags, Rails has 25 branches and 183 tags, Symphony has 6 branches and 44 tags, Play has 4 branches and 48 tags, Flask has 15 branches and 16 tags. What did that tell you about them? Nothing.

> It's a shame he didn't add the language colour bar into the final comparison > screenshot. I thought that was one of the best changes.

I thought not including it was an excellent choice: aside from providing a jarring dash of colour it is a complete waste of space, if you interact with the repository you probably know which language(s) it is coded in, and if you don't you probably don't care.

<comment><USER8> > if you interact with the repository you probably know which language(s) it > is coded in, and if you don't you probably don't care.

I don't care about language per se, but I do care about managing the operational complexity of our stack. The programming language is a relevant factor on that score. A project in a new language may require new staff expertise, a new interpreter, a relatively high number of new dependencies, a relatively high investment in new monitoring systems, etc.

That said, I don't like the language color bar so far, because I'm having trouble confidently identifying which color is which language. For example: the reddish/orangish color space has JavaScript, Ruby, and the various JVM languages. The appearance of these various reds and oranges frequently shifts due to f.lux and differences between the three monitors I commonly use at work and home. Maybe I'll learn the colors better as I get used to the new repository format, but then maybe I won't.

In practice, I look first at the project description and the beginning of the README to see how the project describes its own strengths and weaknesses. Many projects describe their major language choices and runtime requirements as a part of that description, so I never look at the language color bar unless I need to.

<comment><USER7> > In practice, I look first at the project description and the beginning of > the README to see how the project describes its own strengths and > weaknesses. Many projects describe their major language choices and runtime > requirements as a part of that description, so I never look at the language > color bar unless I need to.

And even if they don't clearly spell those out in the readme, metadata/packaging files are usually at the top level of the library.

</comment></comment></comment></comment><comment><USER9> I cannot fathom why such a visually jarring thick bar of color representing the languages used is the most prominent visual element on the page.

It makes no sense. Especially when you consider that you already likely know the primary language the project you're looking at is written in.

<comment><USER10> Totally agree. The only use I see is when you're simply searching for projects/solutions and you want to quickly ascertain popularity and language. That said, I'm not sure I'll remember the color-language relationships without a lot of work that I'm not interested in performing.

<comment><USER11> I think there's a disconnect in the use case of you and the OP compared to some other people (like me). 90% of the time when I'm looking at a Github repo it's for a new project so things like language composition, number (or existence) of tags to download and clone URL are all _very_ handy. Only 10% of the time am I looking at a project that I'm already intimately familiar with.

<comment><USER7> > things like language composition, number (or existence) of tags [...] are > all very handy

Why? How? I just can't fathom what use they could be outside of pointless wankery.

</comment></comment></comment></comment><comment><USER12> As someone that uses GH enterprise more than GH proper, I'll address the changes here from that perspective.

1\. Pushing the branch changer off to be so subtle hurts. I change branches, a lot. Browsing code and changing the branch is something I frequently do on GH.

2\. Lack of clone url is annoying. If all I have to do is click Clone and that's it, then I can live with that.

3\. Clown, Download, and Watch are too far down the screen. I usually have a big screen, but not always, and I have my monitors maximized.

4\. The ordering of the links on the right are odd. I click Watch, Clone, and Download far more than Contributors. Still, the ordering is off. Pulse is at the top, but we start off with Code? With very little thought, I'd order them Code, Commits, Pull Requests, Issues, Branches & Tags, etc.

5\. The Wiki link is hidden. It really should have a better place. While the rest of the links on the right relate directly to code at some level, the Wiki does not. It's documentation mostly. Being disregarded like it is, it should be removed. Either that, or found a better home.

6\. Stars and Forks should be Star and Fork. They are labels for buttons that perform an action, not state.

7\. Code, I assume, takes up a lot more space! Yay!

8\. The top is clean, making it easy to see exactly where I'm at.

These are just initial thoughts. Overall, the design is more open. I think for me, the layout of some of the interactions need to be thought out a bit more, and need to take into consideration more than just your basic free github user.

</comment><comment><USER13> This, like the iOS icon teardown post before it, are excellent. Tons of content. Well written.

I have a question for Ian: How do you find time to do such in depth teardowns and UI refactors of other people's apps? Actually let me re-phrase that: How do you justify spending time on these blog posts instead of focusing on your own application?

Maybe it's just a calculated cost you incur to get traffic? Even so, how did you determine this to be the highest value activity as a start up cofounder?

<comment><AUTHOR> Doing the actual refactor was probably 25% of the time investment here. When I saw the GitHub launch post about the new UI I started having a few ideas about how it could be improved, so I started hacking on it in Photoshop. Usually these kinds of things just end up in a trash folder somewhere, but I was digging where it was going so I kept at it.

As for writing the article, we actually like to encourage each other to write interesting articles on our personal blogs. One thing to keep in mind is that you'll be most productive when you're inspired to write, so if I get inspired to write something mid-day, unless there's a super important Segment.io deadline I'll just take a detour for an hour and write down my thoughts. And we try to remain open to each other doing that, instead of seeing it as "wasted" time. @calvinfo did the same with his recent article on Node's new streams too: [http://calv.info/an-introduction-to-nodes-new- streams/](http://calv.info/an-introduction-to-nodes-new-streams/) — since they are timely topics we like to get them out as soon as possible.

It's not without personal gain either, there are definitely traffic benefits, although I haven't looked into how much traffic actually gets from my own site to our Segment.io's site, let alone signs up. There are also hiring benefits I assume (we're only just starting to hire Javascript folks) from putting yourself out in the community.

Mostly I just enjoy it, so I do it ;) I usually write these after 8pm or so when I switch from working on Segment.io to doing whatever else I want (half the time it's still working on Segment.io haha).

I also wish more designers would write about this kind of stuff, so I like to do it myself too. I'd love to get more process information about how other startup designers think.

I wouldn't worry too much about keeping it fresh... I had a long period of silence from October to March while I was head down on product. Although I did feel guilty about it the whole time...

<comment><USER13> Great response. Thank you.

I think the "after 8pm" part is the secret sauce of not feeling guilty about how you're allocating your time. You've found a chunk of time that you really shouldn't be working on your startup anymore...and it's a time slot where most people are wasting time watching TV, drinking, etc. Keeping productive at that time is awesome.

I like this so much, I might give 8pm blogging a try.

<comment><USER14> Just make sure to jot down every thought and elaboration of those thoughts as they come to you, no matter what time of day they come. Save post-8pm for going back and hashing them out into a full-on blog post.

<comment><AUTHOR> Extremely important. The pieces will all come to you in little bits over time, until you have enough thoughts that you can form a longer story.

To manage it, I keep a _drafts folder in my Jekyll [1] repo which I quickly switch to and from using the project switcher in Sublime. And I use Squarespace Note [2] to jot down ideas from my phone if I have one while I'm going to sleep.

[1]: [http://jekyllrb.com/](http://jekyllrb.com/)

[2]: [http://www.squarespace.com/apps/](http://www.squarespace.com/apps/)

</comment></comment></comment></comment></comment><comment><USER15> Nice article and a very slightly opportunity for a couple of minor Github annoyances to come out of me. All of which I think apply both to the old and new design.

Does it bug anyone else that the Github commit count tops out at 1000+ commits making it completely useless after that point? A repo last updated date would be more useful (I know I only have to scan the directory modified dates but a consolidated one would be nice).

It would also be great if they could show the unmerged branches at the top of the branch selector and allow branches to be kept but marked as obselete so they weren't offered with the other unmerged branches but could be kept rather than completely deleted.

My final wish would be for a couple of things bitbucket has in its diff views, namely side by side diffs and the option to show additional lines around the diff to give greater context. Bitbucket is sorely missing Githubs great network view though.

<comment><USER16> YES. 1000+ commits is so useless. Also I wanted to look at the commit history and it was entirely unobvious that you can click "1000+ commits".

</comment></comment><comment><USER17> I like most of the ideas, but:

      Cloning a repository happens rarely, but in the old interface
      it was one of the first things on the page.

Is it really happening so rarely? It's one of my primary interactions with a foreign repository. Am I atypical?

<comment><USER18> No, you're not atypical. If I want to look into some project closer (and that's why I'm searching or visiting particular github page in the first place, well, more often than not), then I copy git:// URL and download git repo. Real fiddling happens locally later.

<comment><USER19> GitHub's answer to this is "just copy the URL from your browser." It means using http(s) cloning which may or may not be desired, but from a UX perspective I think that it is neat.

</comment></comment></comment><comment><USER20> It's worth noting a lot of the design decisions in the article are based on assertions about what is/isn't used.

Which is fine - it makes reading through the design process more interesting and insightful.

It would be interesting to compare that with actual usage statistics that one assumes github have (to one degree or another) and see if some of the differences in the design are due to flawed assumptions in the article.

<comment><AUTHOR> Absolutely. I actually had a section about that but had to cut it since it was getting rambly :) There are even other business concerns that go beyond just usage statistics. For example, GitHub might see the Mac app as their future, for bringing git to people who aren't familiar with the command line, in which case it would make more sense to make the Clone in Mac button prominent.

The other piece I cut was talking about how not only do advanced users only need certain features, but there are also features that only _new_ users need, like walkthroughs and things. It gets really hard to visualize all of those decisions in a flat mockup.

But yup I totally agree, trying to redesign an interface that you don't own is always going to be very hard and error-prone. Although GitHub is probably one the interfaces that most of us would have the most success with based on how heavily we use it.

</comment></comment><comment><USER21> Minor nitpick, it was Path who first started using the cover photo. Facebook did the same only a few months later, and then many other services followed.

<comment><AUTHOR> Good call. Completely forgot Path started that... but that makes sense since they've got a lot of nice interface touches.

</comment></comment><comment><USER22> Is cloning a repo that rare? Isn't that kind of the point of GitHub?

<comment><USER23> The point being that you do it once for a repo, and then never again (in most cases).

<comment><USER7> It is however one of the first thing you want to do, and an important part of using github.

Much more so, as far as I'm concerned, than the ratio of various languages within the repository whose level of uselessness is only overtaken by the number of tags in the repo.

<comment><USER24> 99% of the time you'll just type `git clone gh:user/repo.git`, or copy from the URL bar.

<comment><USER11> > 99% of the time you'll just type `git clone gh:user/repo.git`, or copy from > the URL bar.

No, that's what YOU do 99% of the time. Do you think that accurately reflects 99% of GitHub's users? I know it doesn't reflect what I do (and I am a developer).

</comment></comment></comment></comment></comment><comment><USER25> In this discussion he makes several assumptions like "we can de-emphasize the branch switcher since it's so rarely used" and "The Clone in Mac button was a perfect example of an under-used feature" and "Cloning a repository happens rarely" all of which do not chime with my personal experience.

Our disagreement is to be expected - no two people completely agree about an interface - but it is extremely disappointing that he makes no mention of testing on real users (or at the very least, speaking to them) in order to gauge whether these features really are unimportant. If you want to know the reason why so many site redesigns are unpopular with users, here it is: you didn't test them.

I'm not trying to take this to absurd conclusions like "every change has to be tested" but the central idea of this guy is faulty: design of the user interface, like design of software, is NOT to be done by anyone in isolation. You need to involve real users in major changes before they happen.

I hope Github ran user testing before they released these changes.

</comment><comment><USER10> These are good notes. You can quibble over some of the specific details and their assigned importance, but generally they show great logical enhancements.

To add to the language bar discussion - I rarely care about the languages in my own repositories (or repositories I'm watching or have starred). This is one of the new features that I enjoy for repository review, but if I'm in a repo I actually use, I rarely care about any of the data here (including commit numbers, tags, branches, contr.) Rather than moving this data about the page, I'd like to be able to remove it entirely based on circumstance or settings.

</comment><comment><USER26> Thanks for blogging this. I like the overall changes of your refactor, but there are a few minor nitpicks:

\- Why did you change "Star" and "Fork" to "Stars" and "Forks"? The before and after have different meanings.

\- The colour bar is missing from your final design. You mentioned in a comment that you forgot to add it and then added it, but I still don't see it :).

\- The right side navigation section is prematurely cut off at "Settings".

\- Your "Clone" and "Download" buttons could use some more whitespace between the text and icon.

<comment><AUTHOR> 1\. Ah yup that's true. The part of the "star" button that I was focused on was removing the "unstar" word since I find it really confusing. I'd rather use a depressed button to signify that I've starred something. But yup, removing the s's would be good.

2\. Nope didn't forget it. My final design isn't "final", it's just at a point in the refactoring. The next step would be to figure out how to add in more of an identity to each repo. I tried to mention this towards the end of the article when talking about the background image idea.

3\. It's hard to show in a flat mockup, but the idea for that would be that hovering it would have an animation that slightly dropped the divider down, and clicking would open it all the way. But it could totally be an over- optimization, in which case the 3-4 extra list items could just always be visible.

4\. Ah, I just took the same style as GitHub. (Actually one of the cool parts of the refactor process was that GitHub's markup is so self-evident that lots of the pieces were made by just changing class names and then re- screenshotting the GitHub interface itself.)

</comment></comment><comment> w-m Here are the two sidebars (new github vs. Ians design) side by side: [http://i.imgur.com/e2w6TkT.png](http://i.imgur.com/e2w6TkT.png)

Ians:

\- got rid of the color indicator

\- got rid of the separation lines

\- is truncating the list

\- has three identical buttons where there were two

\- has more indirection. Cloning is autofocused for me, it takes one click+cmd-c. Also, when I'm scanning the page for a way to clone by URL, I'll find the actual URL much faster than the button that says "Clone".

I like the general idea of the redesign, but I think it would make the sidebar much worse.

<comment><USER27> Agree, hiding clone URLs arn't good. Links are already in scroll area. And "copy to clipboard" doesn't help, it requires Flash, which isn't good at all on Linux

</comment></comment><comment><USER28> Well got automatically switched to the new Github layout. I tried switch the Git URL to git protocol but was unable to do so.

When I first saw github, the option of choosing ssh or git protocol, as well as http, helped to establish it's credentials as a company that "gets it" when it comes to technology. As developers that tends to be important to us because it suggests that other features are going to work the way we expect.

I think the new design is lacking in a number of areas that the old design got exactly right. The git log tells you quickly when the last update was made, but without hiding the tree view too deeply.

My preference would be for the features of the old design to be restored as best as possible, even keeping the new design as a whole. I would also like to see something like the Android application's interface, including the "news feed" like view added to the web interface.

</comment><comment><USER29> I really like the refactoring done here. Congratulations to the author. He did an excellent job, IMHO.

There's one thing missing that I always wanted to have: put the contents of the README file _above_ the file listing. The truth is, many people in Github don't use the Pages feature and rely instead on the README being the main project page containing the description, instructions, etc. And sometimes you have to scroll a bit to get to that information. If the README was on top, the main project page at github.com would be given the importance many projects give it.

Variations of this idea: let the code be on top but only after a single click to expand the repo contents, unless the project lacks a README file. In that case expand the repo contents directly.

<comment><USER7> That's what Bitbucket does (after a fashion, the default home page is actually called Overview and displays the readme at the repository root and below it a recent activity history for the repo)

</comment></comment><comment><USER30> I really don't like the trend of simplified interfaces. I have absolutely no problem with interfaces with options and buttons all over the place. Is there any real productive purpose to changing interfaces when users are used to the old one and fine with it? I see it like forcing users to switch to dvorak. Anyone who spends a reasonably amount of typing can probably get a fine 100wps on qwerty, they might get slightly more if they spent a long time learning dvorak, but the marginal return wouldn't offset the benefit, because most of the time you're not typing at your full speed anyway - you're pausing between shorter bursts of typing to think of what to type, use your mouse, or something else.

<comment><USER31> I think having fewer elements _when they are unnecessary_ is a great idea, if it makes the interface easier to use. However, in this case, though I don't _dislike_ GitHub's new interface, but the big colored line showing the percentage of different kinds of code in the project is really unnecessary and the color is distracting. But, other than a few minor things, I've not had a problem with the design changes, and I certainly didn't have the remorse that I had when I switched to the last major Facebook design overhaul early. And now I'm used to that also.

<comment><USER30> The facebook design changes all tend to feel pointless and annoying, don't they?

I've only used github for a week or so, so I'm not really attached to its interface, and I tend to only interact with it through the github client. On a bit of a tangent, the github client feels awkward and strange. For one thing, it doesn't follow the normal conventions of the OS I'm on. It doesn't even have a menu strip. I'd much rather make a new repo with file -> new repo, have push pull commit etc be in appropriate submenus on the menu strip, and so on, but this thing just throws stuff all over the place willy-nilly, sometimes I don't know if I'm even able to do something and it turns out I have to double- click, things like that. Committing and pushing with gitextensions from inside VS feels nicer.

I really think interface design for desktop apps hit its peak a while ago before everyone was obsessed with stripping things down to the bone. Every update I see menu options and configurability widdled away from applications like Firefox, which is on the track to becoming the one-size-fits-all Chrome. If you want some evidence for that, hang around some channels on irc.mozilla.org.

Another thing is that when I look at screenshots of youtube from a few years ago, it's astounding how much they got right back then that's gone now. The tracking bar has no place hovering over the video obscuring it, the five star system was great but had to be replaced with a binary yes/no, there was a button to start over instead of having to click on the start of the tracker bar, it goes on.

I've used applications from the late 90s or around that period before. They were great. Menu strips were chuck full of stuff, buttons everywhere, just great design to me.

Too many applications are being stripped of any useful feature that's not absolutely essential (or made to have the feature available only through obscure shortcuts / ini files / etc) and it's a development that I greatly disapprove of. I'd rather not have my Microsoft Word replaced with Google Docs.

</comment></comment></comment><comment><USER32> Great piece, but...

One thing bothered me. He said it took a double click and cmd+c to copy? That's not true at all. Single click auto selects. I think the hiding the of the URL is kinda lame because the URL _was the design element_ for "clone" for so long. I see the URL and I know I can click it to select, CMD+C, paste it into my terminal.

Ian certainly has some valid points, but in the end, I think he's not appreciating the full-range of use cases that everyone has. Github has a lot of different kinds of users. Enterprise development flows are a bit different than the open source ones. And those are the flows that bring in the money.

Though, I'm sure they use Github enterprise, so maybe he does appreciate that use case as well.

</comment><comment><USER33> I think it is an improvement except for the right menu. The list is harder to parse and the order is just completely wrong. The four most important links (Code, PR, Issues and Wiki) should always be on the top of the list.

</comment><comment><USER34> Really well done.

I think I was one of the few (perhaps?) who did not like the new redesign of github. I did not like the content above that red/color bar at all. It is that much real estate taken away from me to see the code/commits/documentation of the page. I often use last commit and all commits to compare and see what is going on. I also quickly switch branches on the UI to compare stuff. The current github just feels its a always one extra click or I am searching for something. Somehow it doesn't feel minimalistic at all.

Ian's redesign makes it elegantly simple and minimalistic.

</comment><comment><USER35> My opinion of GitHub's redesign from a user's point of view is that it has been difficult to adjust to the point it has made me angry and frustrated. The pull request UI change is a regression.

</comment><comment><USER5> _Reducing an interface until only the absolutely necessary elements remain is one of the most satisfying tasks in design._

Now I understand the issue with design :P

Now I think the GitHub redesign is okay - but i also think "absolutely" is too strong of a word. The "usual tasks" for "most people" should be part of the UI IMO. Many products go with "absolutely vital" and then the UI sux because you don't get the buttons u needed, in the name of simplicity.

</comment><comment><USER36> This is an interesting example of a 're-design' that isn't all about new colors, graphics, and everything else but just a combining of elements, some more uniform styling, and just doing something that makes sense. This goes to show every redesign doesn't have to be fancy new colors and layouts, just thinking logically about everything you need.

This also shows the importance of going beyond pretty colors into meaningful design.

</comment><comment><USER24> It's a nice improvement (specially with the huge language bar gone), and the header image would look great, but I still think the two-column layout is a step back. Right-hand menus are a bit weird, and it makes everything below "the fold" left-aligned, total waste of screen area.

</comment><comment><USER37> "Cloning a repository happens rarely, but in the old interface it was one of the first things on the page."

No. It does not happen rarely. I do it all the time.

(I realize that other commenters have expressed the same sentiment among other things, but for me this is the key element to emphasize.)

<comment><USER38> I suspect the statistics on feature usage are slanted toward trivial repos that are being used like SVN, or that are not being used as part of a distributed workflow. "Important" doesn't mean "used by the majority of projects."

</comment></comment><comment><USER39> I like seeing design critiques like this, especially when done from actual design experience, and with respect.

But, I came to say: Is the branch lister/switcher really one of the least-used parts of github? It's one of the parts I use the most, actually!

</comment><comment><USER40> I love to hate the "refactored design". If it's truly just "completely reorganized to emphasize the commonly used features," then it's just a theme. Let the user choose the theme, don't force it on them.

</comment><comment><USER41> As a designer that codes, i'd really like to remove most of github's grayness. They seem to do a lot of excessive bordering and gray layers. You could remove almost all of it, without making the UI harder to use.

</comment><comment><USER42> I can't even see all repositories of a user, just the "most popular" the same with gist, no quick overview anymore. I really hate the recent changes and can only laugh at this pretentious bs article.

<comment><USER43> Why is your criticism of the design changes thoughtful, but Ian's criticism of the design changes "pretentious bs"?

</comment></comment><comment><USER44> I hate that language bar so much (I work on a lot of 100% JavaScript projects) that I installed Stylebot ([http://stylebot.me](http://stylebot.me)) just to get rid of it.

</comment><comment><USER45> I like the final refactor much better, I wish they just do it :)

</comment><comment><USER46> For me, about 30% of the changes were bad choices. Its harder to navigate around now than it used to be. While the other 70% of the changes are great.

</comment><comment><USER47> Is it just because I'm on iOS or have some of these suggestions been implemented on github?

</comment><comment><USER48> Really nice insights on design. You might want to chat with the guys that make GitLab :)

</comment><comment><USER49> I'm very impressed by the result. His refactor looks great.</comment>


Funny craigslist "job": create a dating site in 4 hours - <AUTHOR> http://newyork.craigslist.org/mnh/eng/989464357.html

<comment><USER2> I think this is a result of us (developers) making claims of building whole sites in 4 hours. Doesn't surprise me in the least to see people looking for it to be done in real world scenarios. Someone somewhere will answer that ad, get hired to do it, fail miserably and that will perpetuate the myth that software can never be done right.

</comment><comment><USER3> if this post were written tongue-in-cheek, i'd call it "funny". since it seems like the poster put a lot of effort into the posting, i'd say it's more "ignorant" or "sad" or even "a perfect example of the disconnect between the stereotypical mba types and the programmers who must put up with them." personally, i read it in amazement.

eh, maybe "funny" is the right word.

<comment><USER4> This guy is not a stereotypical MBA type. If this guy has a college degree, I'd be shocked.

</comment></comment><comment><USER5> 40 hours. good luck.</comment>


What Happens When Apple Buys a Company You Depend On - <AUTHOR> http://www.wired.com/2015/03/apple-pulls-plug-tech-company-runs/ <comment><USER2> The same thing that happens when a service or product you depend on shuts its doors or gets bought out.

Why is this so exceptional? What would we do if twitter folded tomorrow? things like this happen all the time. There is nothing special about it, except Wired wants to make money taking this tack.

I mean, it'd be nice if we could depend on things to be there forever and it'd be nice if companies shuttered gracefully, but it does not happen all the time.

What are they saying in essence? Don't depend on closed source services? Don't depend on non-creative commons Wired articles for your news as they may shut down one day? People make a calculus. This option is closed source, but offers this advantage. I know, as any business, they may disappear and I'm left holding the bag, but I'm willing to take that chance, given the advantages. This is also the case for open source software, but, yes, OSS has the advantage that someone with sufficient need and resources could resurrect the project.

Fine, they have a preference for open source. That's great. We could all hope all was open source but short of that, we use the tools that are available --with the understanding they could disappear tomorrow.

<comment><USER3> > Why is this so exceptional?

Because code isn't a good that spoils. When someone shuts their door to my favorite restaurant, the presumption is that they were losing money, and needed to close the doors. When my favorite SaaS service shuts down, it's the same deal.

This is different. They're just being selfish because they got some money, giving the middle finger to everyone. That same code is still sitting in a git repo somewhere, and that's frustrating as hell to anyone that trusted them. It would be no sweat off their backs to at least scale down support over a year to let people transition.

But let's not place the blame on them. It's probably not their choice to fuck over all of their users. I guarantee this is coming from Apple, and you should all remember that when you line up to buy this new fancy 1 port macbook: Fuck Apple, they don't give a shit about open source. They're embrace/extend/extinguish just as Microsoft. They just operate on Unix so it feels like they give us more.

It's okay though. Someone inside will realize they're sitting on a goldmine of information on how to make good software, they'll leave the hellish work environment that is Apple, write an open source version, and it will be superior.

>We could all hope all was open source but short of that, we use the tools that are available --with the understanding they could disappear tomorrow.

There is no "short of that". Demand open source for everything you do. It's not unreasonable. The modern computer ecosystem IS open source.

You are very much overstating the similarities from open source developers disappearing and a closed source software company leaving you up to dry. One can live on, and one has no hope.

<comment><USER4> Angry much?

You lost me with the "code isn't a good that spoils" line. It is a great phrase, but perhaps you could re-explain?

<comment><USER5> A restaurant requires continuous inputs: fresh food, labor, electricity.

Code is a purely digital good. What was in the repo a few days ago could be released at no ongoing cost to FoundationDB/Apple and it will stay exactly how it was, forever.

<comment><USER6> I disagree. Code gains technical debt over time, bugs are found, compatibility with other libraries and the OS fray, security vulnerabilities are exposed, and what were awesome features 6 months ago become commonplace or superseded by the new awesome.

Essentially, code starts to rot after a while.

<comment><USER7> Its utility diminishes as the difference between its original environment and the current technical environment increases. However, given a replica of its original intended environment (e.g. an OS image in a VM) the code will run just as well as it always did.

So code does spoil. And it doesn't.

</comment></comment></comment></comment></comment></comment><comment><USER8> "We have made the decision to evolve our company mission and, as of today, we will no longer offer downloads." is the least respectful and most opaque phrase I've ever heard. What would have been the risk of something more honest and direct?

<comment><USER9> Seriously. This is beyond crass. Not 2 months ago, I came _this close_ to betting on and recommending FoundationDB. Today I would have been swimming in a world of shit (not to mention wasted time) had I recommended these guys.

I'm never one to begrudge exits, but they blew this. Even if financial circumstances meant they _had_ to turn down the product, there are way better ways to do that before yanking everything and disappearing.

Dave Scherer, Dave Rosenthal: I hope you're stocking up for a long cozy retirement at Apple. I honestly don't know how you expect to be trusted by a faithful early adopter ever again.

</comment></comment><comment><USER10> Maybe something more is at play here than just the founders and team cutting access to years of their work.

Could also be something to do with a certain company who doesn't like you to have access to (certain) assets of their acquisition after it went through. I mean, they did the same thing with TestFlight. janking Android support directly after the acquisition (and closing it altogether a while later) and Logic (yanking Windows support directly after the acquisition and making the product OSX exclusive).

You could say Apple really is quite ruthless and basically acts like a asshole when it comes to acquisitions, even though their CEO seems to be quite a nice and gentle person (at least after work hours)

<comment><USER11> Let's not forget Siri.

</comment></comment><comment><USER12> De rigueur comment: What happens when Apple buys a closed source company you depend on.

</comment><comment><USER13> It's odd that they imply foundation db has a strength in scalable performance that other no sql databases do not which would be handy for financial applications but then fail to mention apple pay as a potential use case.

</comment><comment><USER14> Despite the fact that this is not only happen in Apple specific case as the title suggest and probably, a quite generalization of what Apple do to the company it bought, the article raises a good point to carefully decide what technology solution you use for your company.

We have to expect that any product that we used might come to an end someday, and need to make sure that we at least have an escape plan for that.

</comment><comment><USER15> At least Apple makes puts it out of its misery quickly, unlike the likes of Google, Microsoft or Yahoo, who have been known to let products of acquired companies live on like zombies before finally "sunsetting" them.

How often haven't we read the whole fake happy "we're so excited, but nothing will change" press releases? Those have become a running joke.

<comment><USER16> I much rather have 3 years to migrate away from google's "zombies" than having the rug pulled out from under me overnight.

<comment><USER17> Uh, how is this different? These zombies most likely will also offer no support or security patches. Hence the term "zombie". The _only_ difference here would be that you could possibly still download the last version from their site which is not the case with FoundationDB.

As long as you have the latest version and you put it in your SCM or wherever you want to keep these things, you are just as able to take 3 years to migrate away from FoundationDB as you would be from one of these zombies.

At least with FoundationDB, as others have said, you actually know _now_ what will happen in the future, with the zombie you might spend additional time "sticking it out" before you realize they will stay dead. That would be time you could have used to start the migration.

</comment></comment></comment><comment><USER18> If Apple gets any bigger we're going to have to start worrying about them buying Google and then shutting it down.

<comment><USER19> I imagine it's impossible in practice, but it's fun to entertain theoretically. Right now it seems GOOG has a market cap of $383.11B and Apple has $178B on hand [1].

[1] [http://money.cnn.com/2015/01/28/investing/apple- cash-178-bil...](http://money.cnn.com/2015/01/28/investing/apple- cash-178-billion/)

<comment><USER20> Google has $60b cash. Apple can borrow $205b, buy Google for $383b, use Google's $60b cash to pay off the debt, with Apple ending up owing $145b. It's not too unreasonable for a $718.66b company to be $145b in debt.

Alternatively, use a script and cash offer. Pay $178b in cash and the rest in shares.

All of this is possible, but as Page & Brin own 56% of voting power so all Apple would be getting is Google's income, but have no say to its decision making process. I assume Page & Brin aren't selling.

Not really worth it for an extra $16b per year.

<comment><USER21> Pretty sure the FTC would not approve that merger, since it would give Apple a monopoly on mobile device operating systems, and arguably "tech" in general.

</comment></comment></comment></comment><comment><USER22> Same thing happened with the 13th Lab pointcloud SDK getting sucked into Oculus. We also see it with developers getting sucked into Google/FB etc...

</comment><comment><USER23> OPEN SOURCE, dudes. Protection from your vendor is why you need it.

This is something you learn after getting burnt by a vendor of $L33T_TOOL_OF_THE_DAY a few times.

</comment><comment><USER24> The article cites CouchDB as how this kind of thing can play out differently for open-source software. The first example that came to my mind was Oracle's acquisition of Sun Microsystems, and the subsequent MySQL forks (e.g. MariaDB). Of course, we still have MySQL today, and AFAIK it remains to be seen what will happen to FoundationDB. I doubt Apple will kill it.

</comment><comment><USER25> I'd still like to know what Apple is going to do with PrimeSense. Thanks to that purchase, I have to rely on used Kinects for all of my depth sensing needs.

</comment><comment><USER26> If this acquisition was in any way related to Apple wanting to use this product in-house -- call me massively confused. It really would be a mental sickness if Apple were so insistent on using closed-source tech across the organization, even while that is a very obscure line of thinking amongst it's competitors in the cloud space. On the other hand, if Apple is acqui-hiring these guys -- then why kill the download links instantly? So yeah, either way, seems like a poorly handled situation

<comment><USER27> Just because the tech companies we read about on hacker news rely on and contribute to open source, doesn't mean that its a 'mental sickness' to use proprietary products. There's good workloads for open source (Apple uses hadoop/hbase heavily internally), and then theres unique proprietary solutions.

<comment><USER26> The mental sickness wouldn't be using any proprietary software. The mental sickness would be acquiring a closed source database and keeping the tech closed source. Databases specifically seem to have a huge mindshare and usage share around open source. And when conventional stores haven't fulfilled a need, solutions like Cassandra, CouchBase, and Mongodb have been released as open source software. I don't really think Apple has some unique data persistence needs to require such an obscure path, if that is really what they were doing

</comment></comment></comment><comment><USER28> The website doesn't even mention anything relating to the purchase from what I can see [https://foundationdb.com/](https://foundationdb.com/)

Edit: Ah.. its on the community page: [http://community.foundationdb.com/](http://community.foundationdb.com/)

</comment><comment><USER29> Were these people paying customers? If not what did they expect would happen.

<comment><USER30> To combine this with another comment, free and closed source means that at some point, many of those users will be massively disappointed. I can think of very few exceptions.

<comment><USER20> Google search engine is free and closed source?

Sure, some of us are disappointed with how our search data is treated, but the disappointment for most generally ends at incognito mode, not that close to 'massive'.

That's quite a big exception.

<comment><USER29> Everyone know how Google makes money though, through ads. A database company doesn't have that option.

</comment></comment></comment></comment><comment><USER31> > Like other NoSQL databases, FoundationDB offered a way to build databases > that spanned hundreds or thousands of different servers, often housed in > geographically distant data centers.

What?

> FoundationDB promised a way to provide scalability without sacrificing > performance

Wait, what?

<comment><USER32> I understand that FoundationDB's main point of differentiation from other NoSQL document DBs was support for transactional integrity across documents. Others (i.e. all open-source options, AFAIK) support atomic transactions only on a single document.

Sounds like the author had been told this, didn't quite get it, and mumbled this stuff instead.

</comment></comment><comment><USER33> "That leaves companies that depended on that software out of luck. And when startups suffer, so does innovation."

Uhhh except that their existence outright is in itself innovation. Removing their existence cannot reduce innovation since their initial existence furthered it.

cliffs: article is dumb and author is an idiot. at least i think, i had to stop reading the article.

<comment><USER34> ... it reduces _future_ innovation, it doesn't undo past innovation.</comment></comment>


S&P U.S. Preferred Stock Index - 7-8% yield, what's the catch? - <AUTHOR> http://us.ishares.com/product_info/fund/overview/PFF.htm <comment><USER2> One major risk is heavy concentration in the financial sector, presumably because banks use preferred stock much more frequently and at higher yields than other companies. Bank of America (disclaimer: shareholder) has something like a dozen or more share classes. Some of them had very attractive yields a few years ago -- and still have attractive yields, but lost 80%+ of the value over the interim. (Note there is a risk of non-payment of the dividend, and in some cases it will never be payed.)

<comment><AUTHOR> So the market must think it's very risky then. I wonder if there are any other risks.

</comment></comment><comment><AUTHOR> How can a fund made up of S&P 500 stocks have this high of a yield? It's higher than BP's yield.

Are there risks with preferred stocks or this index that I'm not aware of? I can't seem to find much information online.

<comment><USER3> [http://www2.standardandpoors.com/spf/pdf/index/SP_US_Preferr...](http://www2.standardandpoors.com/spf/pdf/index/SP_US_Preferred_Stock_Index_Methodology_Web.pdf)

The S&P U.S. Preferred Stock Index is designed to serve the investment community's need for an investable benchmark representing the U.S. preferred stock market. Highlights The index is comprised of U.S. traded preferred stocks that meet criteria relating to minimum size, liquidity, exchange listing and time to maturity. The index is calculated with a modified capitalization weighted scheme, with modifications being made to index shares to prevent single stock concentration and improve index liquidity. The index is rebalanced once a year, in September, when index shares and constituents are reviewed. Corporate actions such as maturity, conversion, calls and delistings are treated according to a set of rules further defined in this document.</comment></comment>


How Software Can Heal the Mental Health System - <AUTHOR> http://a16z.com/2016/12/07/mental-health-tech/ <comment><USER2> The mental health system is broken because psychiatry was captured by the pharmaceutical industry in the 1980's. Robert Whitaker's book _Anatomy of an Epidemic_ [1] examines how commonly-used drug treatments actually worsen patients' mental health, and chronicles the capture of the American Psychiatric Association.

[1] [http://robertwhitaker.org/robertwhitaker.org/Anatomy%20of%20...](http://robertwhitaker.org/robertwhitaker.org/Anatomy%20of%20an%20Epidemic.html)

In spite of everything, science is making a little bit of progress in understanding why people have various mental conditions. For the most part, patients are 'exhausted', because of poor metabolism, malnourishment, etc. Inflammation is a huge factor, as is cortisol deficiency.

I've posted some links before - see my comment history.</comment>


Fortress is released - <AUTHOR> http://projectfortress.sun.com/Projects/Community

<comment><USER2> Is this interesting? I tried to find out on the fortress project page linked above, but all I could _quickly_ glean was that it requires Java, and it's intended specifically for HPC, with support for some concurrency primitives.

Same song, nth verse, waste of time and no better than the first?

<comment><USER3> One reason it's interesting is that Guy Steele designed it and has been working on it for years.

Edit: For anyone who finds this insufficient, Guy Steele's "claim to fame" is that he "co-wrote the specification of the Java programming language". So there.

<http://research.sun.com/minds/2005-0302/>

<comment><USER4> He already had a claim to fame by the time he worked on Java - as someone who did a ton of the Common Lisp standardization work.

<comment><USER3> Bah. He _co-wrote_ the Java specification. Co-wrote!

</comment></comment></comment></comment><comment><USER5> Anyone who wants to play with some modern linguistic support for concurrency and not having bugs should check out Fortress, it has some pretty slick ideas for both

</comment><comment><USER6> It is a strange language, but I've been wanting to study it for a long time. Thanks.</comment>


After 5 years as lead dev small startup, what now?  - <AUTHOR>

I wanted to know your thoughts on what I should do at this point in my career. I've worked for the same startup for 4 years now. I am not a cofounder but I have been with the company from the start as the head of development/technology. We are a very small shop, and I don't foresee the company growing more than 10% a year from here on out. I'm also a bit unhappy with my manager's tendency to micro-manage. He is non-technical, and I feel he has little appreciation for how good of a developer I am (something like this: http://xkcd.com/664/).
I have some stock options but I doubt they will ever be worth anything as we will likely never IPO, and acquisition is possible but I don't have any reason to believe we are moving in that direction. The company is profitable.
I make ~100K, + 15%-20% bonus, but I want my base pay to be at least ~125K + bonus. I'm unhappy with the personal and career growth opportunities at this company. I have to go way out of my way to keep current with even relatively recent tech (most of the first 4 years was spent on legacy systems with 8+ year old tech, the past year was the 1st greenfield project and I knocked it out of the park with new stuff).
I'm looking around to see what the opportunities are, but I also have a performance review coming up in early Feb, so I wanted to know what I should be aiming for in case I decide to stay. What's the normal next step for a director level lead developer at a small, profitable startup after the first 4-5 years? Besides a salary increase is there anything else I should be asking for? <comment><USER2> Instead of pushing harder for a higher salary push the company towards more adventurous things such as the last week of each month being a "hackathon" week in the company.

If the founders have a problem justifying the cost make the "hackathon" week around using any new technology but it must provide some feature/fix/optimization to the current products.

I feel like you're not totally filling the shoes of your title because what you're complaining about is the tech stack which is what you should be making the decisions for...

If you want new technologies, you, as the lead have to push the company towards it and instead of debating jumping ship you need to ask yourself, "How do I get us away from legacy code and move towards a more robust newer stack".

<comment><AUTHOR> Right, I agree with you that I am not filling the shoes of what I should be doing, and that is one of the reasons I'm not happy here, but that's not due to lack of awareness or effort on my part. I have never had issues communicating to non-technical people before. My previous managers have always commended me on my communication skills. In the past I consistently raised issues and potential areas of for improvement, explained the significance, and came to agreements with the product and project managers on a reasonable balance between continually improving our systems, maintenance, and adding new features. There is also another huge factor that complicates things, that is out of my control -- our systems are tied to a partner company and to a large extent they have determined our technology because our apps run in their servers, on their datacenter. So we've been stuck on Windows 2000, SQL Server 2000, running COM+ stuff, because those guys never upgrade their crap.

However, some projects to improve systems and to finally start looking at decoupling from the external partner are _FINALLY_ showing up on the roadmap for 2013. I spent all of 2012 on a brand new project where I enforced my vision of how things should work (totally modern tech stack, automated builds, cloud deployments, etc). That project was a big success.

So if I were to stay one of the things I want to know is how I can convince my manager to get out of the way more, and let me handle a bigger role in planning and executing the projects. Because even though the projects are coming up, he is already starting to try to "mentor" the jr dev's by trying to get them to "own" specific new projects and feature areas for things that we'll do in 2013. I strongly disagree with this approach; I want team ownership, but with his hub and spoke approach (my +1 being the hub) to managing, there is no real development team. The Jr. dev's practically never increase their skills because they spend so much time on legacy code and tedious operational stuff that can be handled by interns (i've recommended this before, buy my manager doesn't agree).

Your point is well taken though, and it's something I've been thinking about. I would welcome any advice on how to arrange a better environment for myself at the company, that would allow me more autonomy in leading the developers. How do other lead developers at small startups handle this kind of situation? Who assigns tasks directly to developers? My manager micro-manages, and assigns individual tasks to individual developers. I know that if I got to lead the team myself I'd have been able to incrementally upgrade parts of the system to free up the Jr. developers' time, and by today they'd have a lot more free time to work on even more new features. How do I discuss this kind of thing with my manager without offending his clear need to maintain strong control over the Jr. developers?

<comment><USER2> A lot of the questions you raise are specific to the situation, feel free to hit me up with some contact info: firstname.lastname@example.com</comment></comment></comment>


Most Tweets Produce Zero Replies or Retweets - <AUTHOR> http://mashable.com/2010/09/29/twitter-replies-retweets/

<comment><USER2> I'm frankly surprised that 29% of tweets DO produce replies or retweets. This really changes my perception of how the average user uses Twitter - people are interacting with each other a lot more frequently than I thought.

I guess this might be a result of Twitter hiding replies to your followees' tweets if you don't also follow the repliers.</comment>


EU court says crops obtained by mutagenesis are GMOs - <AUTHOR> https://www.feednavigator.com/Article/2018/07/25/EU-court-says-crops-obtained-by-mutagenesis-are-GMOs <comment><USER2> Interestingly, the EU court seems to accept "older mutagenesis techniques that have a long safety record" and I gather that this includes the old process of irradiating seeds or budwood of existing varieties in the hope of producing a desirable new variety.

e.g. [http://ucanr.edu/blogs/blogcore/postdetail.cfm?postnum=4000](http://ucanr.edu/blogs/blogcore/postdetail.cfm?postnum=4000)</comment>


Reason India does not have enough developers - <AUTHOR> https://www.hackerearth.com/blog/community/reason-india-doesnt-awesome-developers/ <comment><USER2> I'll explain it all much much easier. In India, there are very few jobs that pay money. Coding is usually the only thing one who becomes a coder, could do. Alternative is back to work in the fields for food at best. So it doesn't attract people who would be best coders, but just most greedy and socially competitive ones (and in any Indian collective office politics are super complicated and elaborate, any Westerner gets pushed out quickly because we are simply no match for them in politics).

That should be the case in any poor country. If you want 'coders by passion', people should have a choice of passions, each of them making comparable money. Otherwise complaining is like complaining that arranged marriage where you either marry who you told to marry to or go f..k yourself, lacks love and passion. It was simply never meant to be otherwise.

This is why coders from rich countries tend to be better. And even in Russia, coders from Moscow are better than provincial ones, for the same reason: working on Upwork from a poor provincial town is your only way out of poverty so if you stand any chance, you grind your way up there whatever it takes, and doing same from Moscow is one of the many options to make comparable money so you do it only if you love coding.</comment>


Gut Microbes Combine to Cause Colon Cancer, Study Suggests - <AUTHOR> https://www.nytimes.com/2018/02/01/health/colon-cancer-bacteria.html <comment><USER2> Tangentially related, when implants are placed there is a so called "race to surface" where bacteria try to form a biofilm before the immune system can react properly.

Quote _:

After adhering to the surface, the bacterium starts to divide and encapsulate itself for protection against the host organism's immune response. This layer of protective matrix, mostly consisting out of polysaccharides, also shields the bacteria from effective antibiotic treatment. The first stage of the biofilm formation is complete and subsequently the present bacteria start to form colonies increasing the internal pressure in the biofilm, which starts to expand.

_ [https://www.researchgate.net/figure/259382333_Figure-1-A-sch...](https://www.researchgate.net/figure/259382333_Figure-1-A-schematic- representation-of-the-race-for-the-surface-between-the-bacterial-biofilm-co)

</comment><comment> huy-nguyen This is very interesting. It looks like a few subtypes of colon cancers may join the list of cancers caused by bacteria (H. pylori in stomach cancer) or virus (HPV in cervical cancer, Hepatitis in liver cancer). Every bit of preventive care against cancer helps and hopefully a vaccine against these bacteria can save many lives in the future.

<comment><USER3> Is there such a thing as a vaccine against a bacteria? I thought vaccines were for viral infections.

<comment><USER4> There very much are! For example, Diptheria, Pertussis, and Tetanus are all caused by bacteria, and we have vaccines for all three

<comment><USER5> The interesting things about diptheria and tetanus is that the vaccine is not targeted against the bacteria, but rather the toxin they produce.

If you've been vaccination against both of these diseases and are exposed, your immune system will eventually mount an attack against the bacteria, but already has antibodies floating around that inactivate the toxin, which is what is responsible for the severity of the diseases.

</comment></comment></comment></comment><comment><USER6> It is kind of scary to see some of the "old guards" of the medical advice I grew up with getting basically tossed. In an exciting way, I should add.

Ulcers, in particular, was huge. So much of previous advice for dealing with them was just flat out wrong.

If this pans out, I'm very interested to see where it goes next.

<comment><USER7> Could you point out some of the updated advice on ulcers?

<comment><USER8> [https://www.nobelprize.org/nobel_prizes/medicine/laureates/2...](https://www.nobelprize.org/nobel_prizes/medicine/laureates/2005/press.html)

<comment><USER6> Thanks for giving that link. Highly recommend reading it for anyone. And, honestly, this makes me think I should be reading the announcements of all Nobel prizes now. Did a really good job summarizing the reasons.

<comment><USER9> Is there any cure for it apart from the restricted use of antibiotics?

<comment><USER6> I don't actually know. :(

My understanding would think diet change could work. But only if you manage to starve the bacteria. Anti biotics are much more straight forward and effective here. Obviously finish your dose.

That said, I've never had an ulcer, so have not actually read much. Other than finding it was none of the root causes I heard growing up.

<comment><USER9> Thanks :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> It's scary that Bacteroides fragilis is being seen as some kind of "autism cure" [1], and some people actively seek out probiotics _with_ it.

[1] [https://www.nature.com/news/bacterium-can-reverse-autism- lik...](https://www.nature.com/news/bacterium-can-reverse-autism-like- behaviour-in-mice-1.14308)

<comment><USER11> Huh. The wikipedia page of bacteriodes fragilis says that it's an obligate anaerobe[1]. I thought that our bodies were filled circulating oxygen-rich fluids. How can obligate anaerobes surivive in our bodies?

[1] [https://en.wikipedia.org/wiki/Bacteroides_fragilis](https://en.wikipedia.org/wiki/Bacteroides_fragilis)

<comment><USER12> [https://www.ncbi.nlm.nih.gov/pubmed/3568965](https://www.ncbi.nlm.nih.gov/pubmed/3568965)

Gangrene can be treated in part by using a hyperbaric chamber to increase oxygen content of the body. Presumably, if our tissues were all oxygenated, gangrene would never happen.

</comment></comment></comment><comment><USER13> If anyone is interested about the topic, there is an introductory MOOC from Wageningen University about the intestinal microbiome and it's effects on health.

[https://www.edx.org/course/nutrition-health-human- microbiome...](https://www.edx.org/course/nutrition-health-human-microbiome- wageningenx-nutr104x)

</comment><comment><USER14> What I'd like to know is which types of diets either inhibit/promote the growth of these bad bacteria. The types of bacteria in your gut being linked to parents or young age, might just be a symptom of learning your diet from your parents.

<comment><USER15> Anecdotal evidence from someone who's been through some of the worst digestive issues possible (stops in involuntary peristalsis/motility, food not digesting) due to "bad" bacteria being continuously introduced from infection elsewhere: yogurt.

Specifically kefir/filmjölk. Buy a bottle, take a serving in the morning, and at night if you like/can afford.

I've turned my life around. Friends have stopped proton pump inhibitors/antacids like Prilosec/Omeprezole, etc, because of this simple lifestyle switch (one serving per day). I take many more.

<comment><USER15> Also, foods with digestive fiber feed good bacteria, and stop them from munching on YOU, aka, gut inflammation, which is also a big thing we're somehow just learning about now, with relation to how it can ruin your entire life (no exaggeration) with stuff like cancers, Alzheimer's, Parkinson's most likely, etc.

<comment><USER9> Would like to hear more about how the change in your lifestyle and food habits made a difference. If you don't mind sharing, you can email me, my email id's in my profile.

</comment></comment></comment></comment><comment><USER16> Since this study found biofilms in colon cancer, I'd like to point out this recent discovery on the involvement of bacterial phage in biofilm formation:

[https://biox.stanford.edu/highlight/dangerous-liaison- bacter...](https://biox.stanford.edu/highlight/dangerous-liaison-bacteria- viruses-league)

</comment><comment><USER12> _Two types of bacteria, Bacteroides fragilis and a strain of E. coli, can pierce a mucus shield that lines the colon and normally blocks invaders from entering_

The above text in the article contains a link to an abstract. The abstract does not talk about piercing the mucus lining. It talks about biofilm.

Biofilm is essentially a large colony of bacteria, so large it begins terraforming the body in order to create conditions conducive to self preservation. I have seen a number of articles over the years on how to successfully break up biofilm and thereby reverse antibiotic resistance. They generally boil down to finding some means to make the environment less acidic. There is generally a strong correlation between inflammation, acidity and infection.

This is probably not a simple relationship. The terraforming activities of biofilm suggests bacteria will foster acidity to promote inflammation etc. So the relationship is interactive. It is not as simple as "acidity causes antibiotic resistance".

I don't have these studies at my fingertips. I have no plans to try to dig them up. I am leaving the comment so that other people can look into that if they are interested.

I wasn't reading this stuff in order to support debate points in an online forum. I have a genetic disorder that predisposes me to developing antibiotic resistant infections and I was trying to suffer less.

So, you can take this comment as testimony that these studies exist and may have bearing on the topic of discussion here.

But I am not going to debate this with people who are inevitably monstrously disrespectful towards me and who act like the last 17 years of my life did not happen because I can't link you to a study. The reality is they don't get any less monstrously disrespectful when I do link to studies and supporting articles and explain my thinking etc. So I don't plan to play that game today.

TLDR: If you are interested, you might go looking up studies on how to break up biofilm. They do exist and they contain potentially useful clues to how to stop this kind of colonization of the gut by hostile invaders.

<comment><USER17> I have always been taught that antibiotic resistance came from bacterial mutation. Are you suggesting that this biofilm is contributing to this resistance as well or instead of mutation?

<comment><USER12> My dad fought in WW2. He used to tell this story:

First, invaders would toss a grenade into a room, stunning all occupants, then promptly rush in and capture them at gun point.

Then people began creating a safety zone in the corner with sand bags. When the grenade hit the floor, you dive for cover. After it goes off, you stand up with your weapon, getting the upper hand on the soldiers entering the room.

Then they began tossing the grenade without pulling the pin. People dove for cover and waited for the grenade to go off. Meanwhile, you promptly enter and now you have the jump on them.

So then people would hear the grenade hit the floor and look to see if the pin had been pulled before deciding how to react.

When antibiotics were introduced, the world announced the end of disease. Now, we have antibiotic resistant _super bugs._

Antibiotic resistance is an arms race. It is probably not one dimensional. If infectious process were one dimensional, then the initial prediction that antibiotics heralded the ended of disease should have been accurate.

But the only thing I am trying to suggest is that studies exist and people who are interested can look them up for themselves, read them and draw their own conclusions. I am sick to death of trying to discuss what I think about such things. It is never a positive experience.

<comment><USER17> Sorry that you haven't had a productive discussion with others regarding this.

I just remembered that I have indeed heard about biofilms and their ability to prevent antibiotic activity. However, I have only heard about them in the context of secretions by specific kinda of bacteria (e.g. pseudomonas aeruginosa) that form this wall around foreign objects preventing the efficacy of antibiotics. It is why we have to change out certain catheters after a specified amount of time.

</comment></comment></comment></comment><comment><USER18> I am wondering if the type of bacteria they mention is the one that can be found in probiotics. I think I suffer from intestinal candida (I have many of the symptoms) and medical exams of my intestine did not reveal anything (Helicobacter Pylori had been tested but not candida). Thus I have reduced drastically my carbs consumption and also take some probiotics to well balance the yeast/bacteria ratio in my gut.

<comment><USER19> Probiotics are typically various strains of lactobacillus. Although E. coli and B. fragilis are "commensal flora," they can be extraordinarily pathogenic.

I don't think any company wants to take on the liability of feeding you a bacteria with a ~20% mortality rate (the BF) and trying to ensure their cultures never get contaminated with a more toxogenic strain -and- that no one takes it the wrong way (oh, did you bite that capsule open and get the B. fragilis into your peptic ulcer...?).

</comment></comment><comment><USER20> If you do develop colon cancer and are treated with certain chemo drugs some types of bacteria may be eating the drug.

[http://science.sciencemag.org/content/357/6356/1156](http://science.sciencemag.org/content/357/6356/1156)

</comment><comment><USER21> What do these microbes feed on?

<comment><USER22> They eat certain carbohydrates (such as fiber) [0] that we consume and aren't able to digest by ourselves. This is why it's recommended to eat fiber [1], which many people do not eat enough of. [2]

[0] [https://en.wikipedia.org/wiki/Gut_flora#Metabolism](https://en.wikipedia.org/wiki/Gut_flora#Metabolism)

[1] [https://www.sciencedaily.com/releases/2016/11/161117134626.h...](https://www.sciencedaily.com/releases/2016/11/161117134626.htm)

[2] [https://www.webmd.com/diet/guide/fiber-how-much-do-you- need#...](https://www.webmd.com/diet/guide/fiber-how-much-do-you-need#1)

</comment></comment><comment><USER23> Kind of related: [https://www.youtube.com/watch?v=VzPD009qTN4](https://www.youtube.com/watch?v=VzPD009qTN4)

</comment><comment><USER24> Maybe the interesting question is what allows for the mucus lining of the intestines walls to deteriorate that much, that those strain of bacteria settle in.</comment>


Tinychart – simple, ready-to-go charts - <AUTHOR> http://tinychart.co/ <comment><USER2> If you're in the market for "simple" solutions like this, do yourself a favor and spend one afternoon with d3.js.

Pre-packaged chart solutions will never achieve 100% of what you're trying to do because the options for customization of charts are endless.

Learning the basics of d3.js will liberate and empower you.

This is a fantastic place to start: [http://chimera.labs.oreilly.com/books/1230000000345/index.ht...](http://chimera.labs.oreilly.com/books/1230000000345/index.html)

If you're a web developer you can start at chapter 6 and stop as soon as you know enough to do your thing.

<comment><USER3> +1 for d3

</comment></comment><comment><USER4> [http://tinychart.co/dist/browser- bundle-d447cd2a4a298091b268...](http://tinychart.co/dist/browser- bundle-d447cd2a4a298091b268.js)

I don't really know how this can be considered "tiny" at all. Dependencies on react, brace and another charting library ([http://www.chartjs.org/](http://www.chartjs.org/)) seems a little much.

<comment><USER5> Chartjs already is too much. Even with d3 could not be called tiny, just small xD

</comment></comment><comment><USER6> Today: [https://news.ycombinator.com/item?id=9043305](https://news.ycombinator.com/item?id=9043305) => [http://tinychart.co/](http://tinychart.co/)

Two days ago: [https://news.ycombinator.com/item?id=9031894](https://news.ycombinator.com/item?id=9031894) => [http://tinychart.co/](http://tinychart.co/)

Three days ago: [https://news.ycombinator.com/item?id=9027084](https://news.ycombinator.com/item?id=9027084) => [http://tinychart.co/](http://tinychart.co/)

Is the duplicate detector broken?

<comment><USER7> I guess the visibility of the other two was pretty low, is it really that annoying? I didn't see it before I'd have to be here all day to notice the two other posts.

<comment><USER8> Maybe if the implementation wasn't utter garbage on mobile, and if it didn't totally break upon entering new data (at least in Chrome), that wouldn't be the case.

I bit my tongue last time, but seriously, this is one of the most garbage demos I've ever seen. Granted, maybe this is my fault somehow, a plugin, or who knows; at first glance 1/10.

<comment><USER7> Well that's not what he's complaining about.

</comment></comment></comment></comment><comment><USER9> In terms of design, it is a project that victordg can be proud of, but I notice a lack of domain knowledge [1] with respect to what charts portray and how they portray them; in very few situations could one infer bezier curves (or splines, or anything) from a set of data points. The result is more an "artist's conception of a chart" than a chart than an actual useful chart.

I do quite like the mouseover data points, I realize these are pretty standard on online charts, but I think he did a good job on them.

However, his chart's constraint on the time series -- really only a logistic progression is supported -- means that it essentially can only produce bar charts. I notice that it simply fails when data is missing from any table cell, which is probably an issue for any potential user; how does one then represent the absence of data?

[1] Disclosure/DK-filter: I do not work with charts or tables of figures, and I don't know a great deal about the topic: I mention it because my understanding is that that false implication of continuity is a serious flaw in chart design.

</comment><comment><USER10> This is my first project in React.js and it was really nice to work with.

The only part I struggled with was while building the table editor. I'm using contentEditable there and apparently React doesn't play well with it. The virtual DOM gets out of sync after user input and you have to manage it manually.

I really enjoyed making this and I'm happy to hear any feedback about ways to improve it! :)

<comment><USER11> I browse with cookies and localStorage disabled by default (I whitelist sites I need to log into). Your site just comes up blank for me... maybe it requires localStorage for some reason? Not sure why it would, but at least you might want to display a message indicating such.

<comment><USER10> oh, it uses localStorage to store your chart data so that you can refresh the page and you won't lose your changes.

But you are totally right that it should not be requirement. I will fix that today. Thanks for letting me know!

</comment></comment></comment><comment><USER12> Nice work in reactJS.

Github repository of the project [https://github.com/vdel26/tinychart](https://github.com/vdel26/tinychart) (From comments of [http://www.producthunt.com/posts/tinychart](http://www.producthunt.com/posts/tinychart))

</comment><comment><USER13> Just a heads up, the font there renders to me as an ugly times new roman, you should probably use something like Google Fonts to load the custom fonts you are using on demand.

</comment><comment><USER14> Two bits of feedback about 1st time experience of a non-developer:

1\. It took me a moment to find where the save option is located. I guess that some less motivated people won't dig that deep. You could make it more visible as it's the most important part.

2\. While entering the data I _automaticaly_ actred like in Excel - I typed the number and pressed the enter, assuming that it will move me to the row below. You could use the power of user's habit :)

</comment><comment><USER15> I think they went too tiny. There is almost no info about possible chart types or what you can do. The download feature is nice but that's all I can see right now. Havn't looked at the source code. I think Plottable looked like a better solution. [http://plottablejs.org/](http://plottablejs.org/)

</comment><comment><USER16> Does anyone know of a (free) JS graph library that allows for data at irregular intervals?

I'm looking for something like this, but with a more permissive license: [http://www.highcharts.com/demo/spline-irregular- time](http://www.highcharts.com/demo/spline-irregular-time)

<comment><USER17> Maybe [http://metricsgraphicsjs.org/](http://metricsgraphicsjs.org/) could help you with this.

<comment><USER16> Hrm, one of the requirements that I forgot to mention (but might be implied by the example?) is that the are 4 different data sets on the graph, all with different different intervals.

</comment></comment></comment><comment><USER18> Nice idea. A few possible improvements:

1\. Import data from csv, excel etc, from file or textarea.

2\. The chart should be resizable.

3\. Color schemes would be nice to have.

<comment><USER19> ...and that's why something "simple" hardly ever works in real-life! :P

</comment></comment><comment><USER20> FYI: Adding data to the demo chart spikes my memory usage heavily in Mozilla Firefox on Linux.

</comment><comment><USER21> Why don't you zero the y axis?

</comment><comment><USER22> looks nice! I noticed some issues on retina screen using safari. Initial render is fine, but it breaks when you update some numbers

<comment><USER10> thanks for the feedback! I will take a look at that.

</comment></comment><comment><USER23> 90 what? Bananas? Watts? Degrees? Never ever publish chart without axis descriptions. Not even as demo. (Or maybe I'm just grumpy)

</comment><comment><USER24> I really like this. Good work.</comment>


On Being a Woman in America While Trying to Avoid Being Assaulted - <AUTHOR> https://www.theparisreview.org/blog/2019/01/07/on-being-a-woman-in-america-while-trying-to-avoid-being-assaulted/ <comment><USER2> As I man I have been assaulted and battered many times.

Back when I was in college I mocked some students who were about to throw a can of shaving cream into a gay rights meeting. That put me on the "enemies" list of the anti-gay terrorists who seemed to particularly target straight people who they perceived as supporting gay rights.

The reign of terror continued until they hit a man (also straight, a residence hall assistant) with a rock in the face with a catapult. The inability or unwillingness of the school to deal with the ongoing assaults led a gay man and lesbian woman to commit double suicide.

(Two doors down I had a friend who was trans; people didn't mess with that person because that person was a gun fanatic.)

In life in general men are frequently the target of violence, get shot by the cops, etc.

For instance one time I was in a group of two men and two women and we were drinking at a bar and things started to go south and I was acutely aware that if things went any further I would be the first person to get hit because (1) I was male and (2) I was sitting on the outside.</comment>


The Inside Story of How the iPhone Crippled BlackBerry - <AUTHOR> http://www.wsj.com/articles/behind-the-rise-and-fall-of-blackberry-1432311912 <comment><AUTHOR> This is behind the paywall but very worth a read.

To quote some of the excerpts

"RIM's chiefs didn't give much additional thought to Apple's iPhone for months."

"It wasn't a threat to RIM's core business," says Mr. Lazaridis's top lieutenant, Larry Conlee.

"It wasn't secure. It had rapid battery drain and a lousy [digital] keyboard."</comment>


Ask HN: Why does not HN have a mobile friendly site? - <AUTHOR> It seems to be pretty easy to make. A work for one or two days for simplest styles for mobile. Currently, I visit the site from android mobile phone and I really like it. But the site looks very unfriendly on my phone: tiny fonts, desktop layout, everything is small. Make it guys :) please. P.s. I know about apps for HN and android. <comment><USER2> We're working on it. A recent comment about this: [https://news.ycombinator.com/item?id=10012910](https://news.ycombinator.com/item?id=10012910).

<comment><AUTHOR> Thanks :)

</comment></comment><comment><USER3> What's wrong with me? I use HN over Opera or Dolphin all the time.

The problem with so many commercial "mobile-friendly" sites is that they are just dumbed-down abonimations.

Worse yet is when a site dumbs down its _desktop_ site to limit it to the "feature" set of its mobile offering, like Stubhub recently did. They actually stripped out the ability to search for 5/6/7/8/9 seats; search by SRO or non- SRO; search by handicapped accessibility (!); search by aisle seating; search by listings which include parking, etc... all criteria that were baked into the desktop site for _years_.

</comment><comment><USER4> I never figured out how to make mobile Firefox render HN nicely. Mobile Chrome can be configured to make HN _easier_ to use, but it still has its charming warts.

</comment><comment><USER5> the shoe maker wears the worst shoes</comment>


Ask HN: What are good practical programming books? - <AUTHOR> I am looking for practical programming books.
Think "Practical Common Lisp", "Automate the Boring Stuff with Python" or "Ruby on Rails Tutorial". These examples happen to be freely available online, but I am looking for free or paid options for the following languages/frameworks: Clojure, Go, Rust, C#, React, Flask, Django, Swift.<p>Any others that you may know of and care to share would be welcome. <comment><USER2> Check out Real Python @ [https://realpython.com/](https://realpython.com/) to learn Python and web development (including Flask and Django) through hands- on, interesting examples that are useful and fun! (I am the co-founder/author)

On the fence? Check out these free resources, developed by the Real Python team-

1\. Free tutorials and resources >> [https://realpython.com/resources/](https://realpython.com/resources/)

2\. DiscoverFlask >> [http://discoverflask.com](http://discoverflask.com) \- Full Stack Web Development with Flask

3\. Flaskr >> [https://github.com/mjhea0/flaskr- tdd](https://github.com/mjhea0/flaskr-tdd) \- Intro to Flask, Test Driven Development (TDD), and jQuery

<comment><AUTHOR> Nice suggestions! Thanks!

</comment></comment><comment><USER3> I really liked the "Go Programming Language" book [http://www.gopl.io/](http://www.gopl.io/) Even though it's a book about learning the language and not about some framework or doing particular projects in it - the examples in the book are not just toy examples but very practical examples. Most introductory language books remain in the realm of toy examples for too many chapters before one gets a taste of solving practical problems with it.

</comment><comment><USER4> The Little Schemer

[http://www.ccs.neu.edu/home/matthias/BTLS/](http://www.ccs.neu.edu/home/matthias/BTLS/)</comment>


Hackathons: A life changing experience - <AUTHOR> http://news.mlh.io/second-hackathon-changed-my-life-02-12-2015

<comment><USER2> How many hackathons has JMG been to since his first one?</comment>


Ask HN: I'm being asked to be a team lead with no additional salary. Accept it? - <AUTHOR> I'm in my 20s working at a medium size tech coming I really love. The company has a very flat structure and doesn't do compensation changes, even for team leads<p>I was asked recently if I want to be one. Obviously I'm flattered as I've never been in a leadership position before. Is it worth taking on more leadership responsibilities (and probably more bullshit) for no additional pay? Thanks <comment><USER2> Hard to tell without knowing more. However generally NO!

It's similar to accepting a pay reduction.

You accept more responsibilities for no additional expense to the company. Rewarding them for bad behaviour.

It also signals a lack of commitment to the role and title.

There will be an undertone of "whatever .. that's just a title". And that will go both ways, you will feel like a "fake" team lead and they will treat you as "the developer with the fancy title that we blame when needed".

</comment><comment><USER3> I guess the question should be. Do we get paid for our current replacement cost or the amount of work we do each day? Salaried jobs are treated differently than hourly jobs.

If we should get paid for value, your value arguably hasn't changed yet as you take on this new responsibility. After you've done it for a while, yeah, you are now more valuable because of your new experience, skills, confidence gained, etc. But you don't have those yet. So, maybe they are giving you an opportunity to build up equity in yourself and the cost to you is more work.

That's one angle. But the other is that you are doing more work and maybe working more hours. If this is truly just more hours each day and not a slight shift in priority, then maybe it makes sense to at least have the conversation with them.

If I were you, I'd probably do the job first, do it well for 6 months and then have the discussion. Asking for money up front may be a little aggressive. But others may do differently and that is very important. Do what is comfortable for you. My sister is aggressive and talks to boss about salary all the time and she's now making a lot of money.

</comment><comment><USER4> In my experience being offered team lead with no increase in pay translated directly into additional exposure to blame when things went wrong with insufficient additional authority to change things to avert predictable problems.

I personally wouldn't accept it (assuming no pay increase), with the full understanding upfront that such an offer probably wouldn't come again and if I wanted a better opportunity in the future I'd have to leave the company to find it.

</comment><comment><USER5> Probably in the long run and it depends on the lead duties. Do you have actual HR responsibility or is it leading a project or deliverables team?

The difference I'd draw is that HR is harder. People are complex and not always rational - HR reporting responsibilities requires extra of you. Also deciding compensation can be hard depending on the comp structure and team - that's extra as well.

When given new leadership opportunities you should generally not go into it expecting to have your palm greased but you'd be right to expect marginal increases in your competition on your annual cycle.</comment>


UAW Files Complaint Against Tesla, Claims Workers Were Fired for Being Pro-Union - <AUTHOR> https://www.fastcompany.com/40487783/uaw-files-complaint-against-tesla-claims-workers-were-fired-for-being-pro-union?utm_source=feedly&utm_medium=webfeeds <comment><USER2> Strange to hear that some of those fired workers complained about higher wages in other auto companies - if they are so good, why not apply there? The actions of the UAW over the past 50 years have indeed increased wages, but at the cost of the number of UAW jobs. Google the decline. A bad balance. They need to increase the base, and cap the top so that all workers can afford the products of the union few. That is why there is a used car market. Tesla is going to upend the traditional car market.

Get Musk angry and he will build a plant in a right to work state and close Fremont if he gets strangled by high wages, and more importantly the union work rules.</comment>


Report: 20M coronavirus tests per day needed to fully open economy - <AUTHOR> https://abcnews.go.com/US/road-map-recovery-report-20-million-coronavirus-tests/story?id=70230097 <comment><USER2> You don't need to test everybody every 14 days.

There is no purpose whatsoever to doing that.</comment>


Show HN:Jobboard to find companies hiring during covid19-Looking for suggestions - <AUTHOR> https://www.openjobs.live/joblist <comment><AUTHOR> Hey all, I built a jobboard to find out companies actively hiring during covid19. It is built using python django, mysql and bootstrap. Python based crawlers collect data from different sites. I am planning to rewrite in UI in react if this is useful and site gets traction.</comment>