How the Heck Do I Use GitHub? - <AUTHOR> http://lifehacker.com/5983680/how-the-heck-do-i-use-github <comment><USER2> "The site is based around how git works, and git is pretty old. It runs via the command line and has no fancy graphical user interface."

Wait, we're using software first released in 2005? Holy crap, we may as well be using quill pens.

<comment><USER3> Lifehacker saying such things does not surprise me as their quality of writing and target audience is much less hacker news in 2013 and much more mainstream. It would almost be more suitable to just relink the article to help.github.com as some others have mentioned.

<comment><USER4> Gawker now exists as a network that posts articles designed to get that advertising revenue in, the whole Reddit witch-hunt a while back serves a point.

If you're learning Git from a Lifehacker post, you're not going to learn much.

Massive shame, it used to be a great site for productivity tools. Kotaku too, now that's reduced to the low hanging fruit of gaming news, and don't get me started on Gizmodo.

<comment><USER5> "witch-hunt".

Here's the thing: unlike witch-hunts of old, modern day witch-hunts do actually sometimes find witches.

</comment></comment></comment></comment><comment><USER6> This post is so apropos for me (at least the title is) -- I'm perfectly fine with the Git part of github, but was struggling with the other parts of it. For example, trying to figure out how to make a versioned release. The download link they provide gets you the latest version from the repository. Took me a bit of searching and looking at other projects to realize that if you tag a release, it can make that available too.

But now trying to get that to show up in the project page (using their auto page generator) -- I ended up having to hand edit the html code, because I wanted the web page to have a list of specific releases. But even their source download link isn't fully intuitive. For example, mine shows up as "<https://github.com/derekp7/snebu/archive/1.0.tar.gz>, but it downloads a file called "snebu-1.0.tar.gz".

Oh, and to get the readme file to utilize their markdown, you have to call it reamde.md, instead of readme.txt. And I'm looking for where my users can leave feedback or discuss things, other then opening an issue in the issue tracker. But they don't have any mailing lists or forums (I guess most projects set up a separate forum, and link to it from the readme.md file or the gh-pages page).

What I'd like to see is a document going over the entire lifecycle of all the features offered through github, including documenting the standard practices for items that they don't provide (such as the forums thing). Anyone got any pointers?

<comment><USER7> Re: releases; GiHub used to have a cool feature that was removed* (and I deeply miss): they removed the file uploads.

* <https://github.com/blog/1302-goodbye-uploads>

You know, the code distribution can be different to the code you have in the repo (git archive != python setup.py sdist).

The uploads functionality wasn't perfect (I had to make the dist package, upload it), but it did work for me.

<comment><USER6> One alternative for the uploads is to make an orphan branch similar to gh- pages, populate it with your tar.gz file contents, tag it, then delete the branch. It will show up like a normal tagged download without having extra messy branches in your repo.

</comment></comment></comment><comment><USER8> Back when I first started using git, I found Github's own getting started bootcamp pages to be a good starting point. <https://help.github.com/categories/54/articles>

</comment><comment><USER9> For how popular github is, it does have a surprisingly frictional client set up process, for Windows users at least (although this is partly due to git itself). I can talk a non-technical person through setting up an SVN repo using Tortoise no problem. With git it's something I just have to do for them.

I think it speaks to how amazing a service github is that the more complicated set up process doesn't put anyone off.

<comment><USER10> Have you checked out _Github For Windows_? I like how it hides some of the complexeties of Git, _and_ gives you a Git Shell with Git in the current path.

<comment><USER9> Ha, I just looked and it came out immediately after the last time I set up git/github on a windows machine the old-fashioned way. So it looks like my comment is probably invalid now. The next time I use git for a project I'll be sure to check it out. Thanks.

</comment></comment></comment><comment><USER11> GitHub is fantastic if you have an UNIX/Linux background. I can understand the scary felling of someone that uses Windows on daily bases (for example) and suddenly have to work with SSH, GIT, Markdown, etc. I love GitHub but I don't think it is made for ordinary people. One day maybe it will be.

<comment><USER12> What's the relation between Git and Markdown on the one hand and Windows on the other? SSH, yes, but the others? And there's nothing about Unix that limits its use to extraordinary people — I use it, as well as Git, Markdown, ssh, and even Emacs.

<comment><USER11> I just cited markdown as complement to git. Git is a command line tool as is SSH (don't talk about GUIS for Git, that is not the case). I never said Unix is used exclusively by extraordinary people only (Ubuntu and others are an example), but the majority of people still use Windows.

Have an Unix/Linux background makes it easier to get started because you already know what they are talking about.

My personal opinion? Windows sucks (just to be clear, that is me).

</comment></comment></comment><comment><USER13> This is a really good article. Personally, I don't use Github for the same reasons - the over-whelming complexity of GIT and its terminologies. I currently use an SVN (Tortoise SVN) to keep my work in sync.

<comment><USER14> You might like mercurial and bitbucket. There is also TortoiseHG and though I find it a tad clunkier it's not too bad.

<comment><USER13> Thanks :)

</comment></comment></comment><comment><USER15> Kudos to lifehacker for writing "how to use git with github" and not just instructing people to install the github Mac client and calling it a day.

</comment><comment><USER16> I've gotten as far as creating repos, branching, merging and pushing them to github. Oh, and not publishing my livejournal passwords in my repo. Anymore.

But yeah, not the most beginner-friendly thing in the world, and most of what's on github i'll probably never even touch. I forked a repository but i still don't know how to submit a pull request. I don't even know how to delete it. Feh.

<comment><USER17> There's a lot of documentation on the web for Git, but the Git/Github integration can get a little hairy if you get out of sync.

The pull request workflow depends on what you're working on (Personal project? Company project? Massive open source project?), but Red Hat has a pretty good overview of a fairly standard system that most people should be familiar with:

[https://openshift.redhat.com/community/wiki/github- workflow-...](https://openshift.redhat.com/community/wiki/github-workflow-for- submitting-pull-requests)

If you have any more questions, feel free to shoot me an email, I'd love to help you out.

<comment><USER18> Thanks, this is one of the best one-page workflow examples I have seen for Git and Github. Sometimes all the docs are so focused on the power of each command, that they neglect the big picture of how to apply them in real world workflows.

</comment></comment></comment><comment><USER19> To me, the hardest part of using GitHub was using Git.

Once I wrapped my head around Git HEAD, remotes, branching, merging and all that jazz, using GitHub was fairly trivial.

<comment><USER20> All you need to know to get started:

       git init
       git add .
       git commit -m "some message"
       git remote add origin email@example.com:username/project
       git push -u origin master (the first time)
       git push

<comment><USER19> The very first thing I needed to know was

        git pull

because I initialized a Git repo from GitHub, with a README.md file.

</comment></comment></comment><comment><USER21> Why would anybody who doesn't know how Git works would want to use GitHub?

<comment><USER22> Because they want to share their code and participate in open source projects?

</comment></comment><comment><USER23> > and git is pretty old.

No, it's not! It's released in 2005.

</comment><comment><USER24> <https://help.github.com/>

Am I missing something? All of those things are covered in one of the articles on help.github, especially under "Setup" and "Bootcamp".

<comment><USER25> To be fair, if you're going to lifehacker to help you set up github, you're probably not motivated enough to go tearing through github's faq. Quite frankly, you're probably not motivated enough to finish the lengthy tutorial they posted.

<comment><USER26> Agree completely. I'd extend that to say that if you're relying on Lifehacker to help you set up Git/Github, this statement is probably false:

"Nevertheless, it's good to learn the old-fashioned way otherwise your options in the simplified software won't make sense."

The Github app goes to great lengths to make the interaction with Github more intuitive than the CLI Git client. Yes, your options are more limited, but I work with several pseudo-technical users who use solely the Github app. You can switch branches, checkout, publish, delete, and merge through the Github app. The Github app even stashes automagically if you switch branches with uncommitted changes. The only area that gets sketchy are conflicts, but many of the people at whom this article is targeted will never encounter a conflict, because they're the sole developer.

In any case, I can see absolutely no reason that a casual developer should move past the Github client to the Git CLI client if they have no specific need.

<comment><USER27> I sort of regard lifehacker as a web site for teenagers and hobbyists nowadays, so I'm not particularly surprised at the quality and tone of their technical work.</comment></comment></comment></comment>


Ask HN: Entrepreneurs, what do you think of my web-based startup idea? - <AUTHOR>

Hi all,
Doing some early stage research for a startup I have in mind and I'd love to get some insight from other entrepreneurs.
It is basically an odesk-type platform for connecting small businesses to MBA students. The idea is that MBA students have valuable skills (many are former financiers and strategy consultants) and small businesses/startups in need of professional business advice for things like project valuation or corporate strategy may lack the resources to hire top-tier talent for these problems, or just lack the bandwidth to do it themselves. Essentially, you'd be getting McKinsey level talent for a fraction of the cost, maybe $100 per hour.
Is this a service your business might be interested in? Thanks in advance. <comment><USER2> You shouldn't be asking startups this. Call small businesses and ask them.

Regardless, I worked for a small business while I was getting my BS in Business Admin. One thing I realized from this experience was that a lot of what I learned in business school was focused on the corporate world and not small business. A small business is much different than a corporation and I could argue that advice from an MBA would not be that helpful to a small businesses (to an extent of course).

Also, while this is only one data point, I can tell you that the small business I worked for would not use this service. This is because the owner would not seek out such help because he believed that running a business was something that couldn't be taught and that an MBA (who has never actually had a business) was not qualified to give any advice.

Edit: I reread your post and I think you might be considering startups and small businesses the same. I think you need to pick one of the two because they are significantly different.

</comment><comment><USER3> This sounds awesome!

</comment><comment><USER4> Great idea. I don't know if I'd be blabbing this on HN though. The MVP should be your "research".</comment>


Show HN: Flash is dead? Here is a stab at a replacement - 100-xyz https://its-near.me/flash2/editor <comment><AUTHOR> It seems like you missed a // here: <script src="https:its- near.me/js/svgjs/svg.min.js"></script> to <script src="https//:its- near.me/js/svgjs/svg.min.js"></script>

<comment> 100-xyz Thanks a lot. Corrected. Its actually [https://...](https://...). :-)

</comment></comment><comment><USER2> For a real flash alternative checkout: [https://tumult.com/hype/](https://tumult.com/hype/)

It boggles my mind that Tumult hasn't been acquired by Adobe yet!

<comment> 100-xyz Tumult has been around for a while. Its not web based but an Apple application.

</comment></comment><comment> 100-xyz I am also looking for advisors - those who can advise me on what features to build out first. Previous experience with Flash desirable but not necessary. Thanks.

</comment><comment> 100-xyz This is at a proof of concept stage.

FEATURES

Web-Based Motion Graphics Editor

Export / Import Files

Exported Files can be played in a Player

Exported Files can be added to your web page

Bugs, suggestions etc welcome</comment>


What Google Taught Me About Scaling Engineering Teams - <AUTHOR> http://www.theeffectiveengineer.com/blog/what-i-learned-from-googles-engineering-culture/ <comment><USER2> While I cannot judge how those practices work at Google, I have seen similar practices fail miserably when applied in smaller companies.

Opinionated best practices stop being useful when the emphasis is on opinionated and not on best. If the cabal that has political influence is not the strongest there is, standardization just increases how much technical debt can be built in a short period of time.

I have seen expenses on tools teams that went nowhere, for two reasons. The first is that tools teams are attractive to people that do not want to deal with customers, so they can attract the opinionated and antisocial. The other problem is that the generic tools really have to solve the problem very well: Lack the engineering quality in said tools team, and you are spending a bunch of money on infrastructure that will both fail to evolve at the speed of OSS, and get entrenched everywhere in your codebase.

Automated testing will only get you far if it is pragmatic. I have seen millions of dollars spent on test automation that was extremely fragile and never paid for itself, because it had an extremely short shelf life. Picking the wrong tools for it makes it even worse.

Code reviews can be great, or can be terrible. A code review searching for real problems in the code, or that really considers alternative solutions, will be very valuable. But code reviews can quickly become pissing contests used by people to impose their preferences on others: A passive aggressive way of asserting dominance on a team. You can see a lot of that in proponents of the 5 minute code review: No actual analysis of the code is done, but 5 minutes is plenty to use it as a tool for abuse.

So while the techniques described in the article can be very helpful, the wrong implementation of them will just help you standardize on a monoculture of bad engineering. So before implementing such things think about how good your engineering really is, and whether you really are better off making sure people bend to your standards, or you are better off learning from the experience of new people. Chances are you are not Google.

<comment><USER3> You have to be careful about who you hire. If you do that well, then opinions, code reviews, one shared repository, and so on, work great. If you hire a bunch of assholes, then they won't work.

I do about 20 code reviews a week; there is never bullying and they are only rarely rubber stamped.

(My favorite code review of my own code this week was where I updated a counter to use atomic.AddInt64 instead of sync.Mutex. But where I was reading the counter, I just read the integer value directly instead of using atomic.LoadInt64. 30 seconds of the reviewers time, and we avoided a potentially difficult-to-track-down bug. No pissing match, no bullying. Just better programs.)

<comment><USER4> 20 code reviews a week? How many lines of code for each review?

<comment><USER3> I looked in more detail and if I average it out over 2.5 years and only include actual code I care about (not importing OSS packages, which I also review), it's more like one a day.

I was too lazy to calculate a histogram, but let's go with ~100 lines a day.

<comment><USER4> Thanks for the reply.

</comment></comment></comment></comment></comment><comment><USER5> Speaking from my experience as an intern at Microsoft, I really wish there was more focus on training. I've heard from a lot of praise about the quality of codelabs from friends at Google and never received anything like that when I was working. I was basically just given a project and expected to pick up things by asking people or reading some half-outdated sharepoint pages.

From speaking with other interns it seems their experiences varied entirely based on their teams. The impression I got was that it was really fragmented across teams and that each team felt like it had its own way of doing things.

I'm not exactly sure how it is at Google but I've heard from a friend that the entire company works on a single shared codebase. The project I was working on had 3 different forks of the framework I was developing (that I knew of), each maintained by different teams. Basically, the impression I got was that everything just felt really fragmented and that I was only working with my team rather than with an entire company.

I should mention that this was my 2nd software development job ever so maybe this is normal for lots of companies and that Google is one of the few companies doing it right, but the experience didn't really leave me with lots of confidence in the engineering environment/culture of the company.

I've heard tons of good things about the engineering culture at Google so I'm considering if I should try applying there.

<comment><USER6> Ex-Google engineer here. The way Google does things is indeed very rare, your experience at Microsoft is more typical.

Note that the path Google chose isn't easy! As the codebase got larger and larger they had to basically design and build their own build system, a distributed unit testing engine, custom code refactoring and hyperlinking tools, do major IDE modifications to Eclipse to make projects even loadable, eventually even build their own version control system because no other VCS scaled to the sizes and speeds they needed. They invested a TON of time and gold into allowing a single codebase to scale like that; it's practical if you're sitting on a hosepipe of money and you can hire brilliant engineers then assign them to build tools, but it's probably not practical for most companies despite that the resulting environment was quite pleasant.

That said, although the codebase was remarkably consistent, there were still variations. The most notorious was the split between the C++ and Java codebase. Some frameworks were written in c++ and bound into Java using things like SWIG. Others were bound using cross-process RPCs. A lot of smaller libraries were simply written and maintained twice. The culture was different too. Some Java codebases were way over the top of excessive abstraction and use of dependency injection, making them an absolute nightmare to understand or debug for newcomers. Others were simpler and more understandable (typically the older ones). The C++ side felt much more light weight, but on the other hand, it was largely stuck in the 90s, with memory management being entirely manual even in cases where conservative GC could probably have helped avoid mistakes. When I left C++11 was in the process of being whitelisted one feature at a time.

The biggest problem with the culture I had at the time I left (and was one reason I decided to pack my bags after 7.5 years there), was that basic tasks were becoming more and more bureaucratic. Often this was due to poorly designed processes put in place in a panic after some PR disaster around privacy or data handling, like Street View or Buzz. Sometimes it was just because some engineer needed to redesign a widely used system in order to prove they were being "impactful" and get promoted even though it wasn't really broken. There was a running joke there that there were two versions of every tool, the deprecated one and the one that didn't work yet. It started out as a lighthearted take on the companies rapid progress and by the end unfortunately just reflected a sad reality.

As an illustrative example, around the time I started to step back, one member of my team had spent on the order of 6-8 weeks attempting to simply download a file via HTTP in production, from our own servers (was a self test). This task involved filling out forms, arguing with the owners of the HTTP download service (the old one didn't require this process but was deprecated), discovering that the new version was hopelessly buggy and was breaking random products for end users without anyone on those teams noticing, etc. This is a task that could be accomplished in two minutes with a random Linux VPS and "wget" but turned into an epic struggle against a Kafkaesque corporate disaster zone. The problem was not that one team was poorly performing though: the problem was the company had lost the ability to pre-emptively catch this or even recognise that there was a problem. Most team members were happy to just collect a paycheque each day; if they got paid for filling out forms justifying why they needed the "fast reliable" HTTP download service instead of the "slow unreliable" service, why worry? Best not to rock the boat.

</comment></comment><comment><USER7> > One reason I was able to quickly become productive within Google was because > the company had invested so many resources into training documents called > codelabs.

Counter perspective here. The on-boarding training at Google for SWEs is indeed very extensive, spanning several weeks with tons of material. For example, the first code lab alone covers how all of Google's source is in a single repository, how to check it out, how it gets built on a server, how to do code reviews, what the coding style is, etc.

I threw it all out the window after my first two weaks. I was joining an Android team, and as it turns out, Android works completely differently. Different source repo, different SCM tooling, different build system, different development workflow, different deployment mechanisms, even different workstations.

And the company culture was different as well. For example, in the Life of an Engineer class, they impressed upon us Google's culture of openness by poking around the source tree for search, and showing how we already have access to its code! But the Android source tree is tightly controlled, and my access request required two weeks and VP approval. (It's still the case that the majority of Google SWEs do not have access to Android source, or the Android café menu.)

I eventually came up to speed the old fashioned way: poking around outdated documentation, trial and error, and lots of bugging my neighbors. So in my case, the Google on-boarding process was mostly useless and partially misleading. This illustrates one way that "reusable training materials" can go wrong, especially with a larger organization.

<comment><USER8> From your experience, it just seems like the android team was lacking those "training material". I think your case shows it would have been a good idea for them to have some as well, doesn't it ?

<comment><USER3> More like: when company A acquires company B, company B does not instantly replace its culture with company A's. Especially if company B is quite successful.

</comment></comment></comment><comment><AUTHOR> > _One reason I was able to quickly become productive within Google was > because the company had invested so many resources into training documents > called codelabs. Codelabs covered the core abstractions at the company, > explained why they were designed, highlighted relevant snippets of the > codebase, and then validated understanding through a few implementation > exercises. Without them, it would've taken me much longer to learn about the > multitude of technologies that I needed to know to be effective_

Any Googler care to share what a "codelab" looks like? Always interested in seeing innovations in documentation/onboarding (and I'm guessing it has nothing to do with the now retired "Code Labs"? [https://code.google.com/labs/](https://code.google.com/labs/))

<comment><USER3> We have some public codelabs; the Dart ones come to mind first:

[https://www.dartlang.org/codelabs/darrrt/](https://www.dartlang.org/codelabs/darrrt/)

Basically, a tutorial. The internal codelabs have some logic to substitute your username throughout the text (good for things like "create a test directory"), but are otherwise very similar to the public ones.

</comment></comment><comment><USER9> It is very difficult for me to translate lessons learned at google to anything except google. I have read a lot of blogs from googlers and formers who write from a perspective of, I guess, a luxury I have literally never seen, even at MS during its golden age. For example, the idea of code reviews and whitespace. I have never worked in an environment where we had that kind of money to spend.

<comment><USER10> _" code reviews and whitespace. I have never worked in an environment where we had that kind of money to spend."_

Also my experience with google coding practices. Code reviews process can be excruciatingly long and painful (especially when you're starting out). Lots of back and forth over things like whitespace between operator/operand and whether to put the stream operator at the end of a continuing line or at the beginning of the continued line etc.

Someone else said that the google practices are optimized for code maintainability rather than developer efficiency. Absolutely true. Reading code (at least C++ which I have experience with) at google is a joy while writing (and submitting) code is at best a chore. At it's worst it's bad enough that I've seen a new hire (senior engineer, known for delivering at a high level from his previous company) go back to his old company after a quarter or so of frustrations with the process.

</comment></comment><comment><USER11> "Invest in reusable training materials to onboard new engineers."

So important! Doing this really helps keep people on page and limits the amount of time spent arguing about semantics or why we came to a certain decision.</comment>


Can an Economy Feel Joy? - <AUTHOR> https://www.camerongordon.site/post/can-an-economy-feel-joy <comment><USER2> In _Echopraxia_ , Peter Watts argued that group minds invariably become psychotic, if inter-node latency is too great. Which makes sense to me. So arguably no.

And yeah, TFA does considerable bullshit in order to display text. I mean, what is "parastorage.com"?

[https://parastorage.com](https://parastorage.com)

> Error ConnectYourDomain occurred

<comment><USER3> Looks like Cameron used Wix for his site. `parastorage` only shows up in the context of Wix as far as I can see.

ed: [https://www.wix.com/corvid/forum/search/parastorage](https://www.wix.com/corvid/forum/search/parastorage)

"That is a part of Wix CDN network to deliver images and stuff like that faster." by word of a "Wix Code Evangelist"

</comment></comment><comment><USER4> I think the question suggests another question:

Can an economy feel "irrational exuberance"?

</comment><comment><USER5> Site doesn't load content w/o JS enabled (or some other BS.)

ORT (Only Read Title)

No: economy doesn't have glands.

However, consider, can _cells_ feel joy? Everything we do is done by cells: we see because the cells in our eyes can see, we digest because our cells digest, we move because our cells move, we think because our cells think, and so on...

If we allow a an analogy (however imperfect) between cells and the body, and between people and their civ/society/economy, then it seems to me that, yes, you can measure or quantify a given civ by the joy of its members.

Bhutan actually formally collects and analyzes data to form a Gross National Happiness index (as contrasted with the GNP metric), and attempts to use this as feedback for their government.

<comment><USER6> Well, yes, given that economies aren't organic individuals, their "feelings" will be something different. I also do no think it's useful to separate "economies" to study as if they were entire beings, they are a part of "societies" \- this reads a lot like asking if our arms feel joy.

<comment><USER5> > Well, yes, given that economies aren't organic individuals, their "feelings" > will be something different.

Yeah, that's kind of what I'm trying to say. The analogy between a human organism and human society is imperfect, so I think the closest you could come to saying a society is joyous would be if the humans in the society are joyous.

As for what would constitute the subjective experience of a society, you could call that the _extrinsic_ Hard Problem of Consciousness, eh?

> I also do no think it's useful to separate "economies" to study as if they > were entire beings, they are a part of "societies" \- this reads a lot like > asking if our arms feel joy.

I agree with that too. FWIW I would maybe identify money with oxygen and the economic system with the circulatory system, and maybe (parts of) some others (I'm an expert neither on economics nor physiology.)

<comment><USER7> If you start from philosophical questions of mind and identity (e.g., substance dualism vs physicalism, etc.), it's not hard to get to an argument that qualia are neither substances nor physical identities but instead properties of systems (cf Whitehead), so you can ask not only "what is it like to be a bat," but also "what is it like to be _any_ system capable of qualia?" It's possible that such systems could include societies, economies, corporations, and so on, depending on what you assume the criteria are for a qualia-capable system. (This is also how you get to the Gaia hypothesis, which sounds utterly crazy taken on its own, but almost axiomatic if you build it up from a systems approach to mental states with loose enough coupling and coherence restrictions).

The kicker of this approach is that the modes of qualia or consciousness at different system levels are likely to be so completely alien and the causal mechanisms so hard to discern that you could never definitively answer the question of "what is it like to be an economy;" it's as impossible as a neuron wondering what it's like to be Proust eating his madeline.

Scientifically, it's virtually unfalsifiable but, if correct, it does have the delightful side-effect of turning social sciences such as economics from attempts to formulate natural "laws" to something more like efforts to psychoanalyze alien gods.

<comment><USER5> In re: Gaia, if the basis of qualia involves something cells do then (IMO) there's no inherent difficulty in assigning "mind" or subjective experience to the global ecosystem. We can "fold in" that question with the problem of human subjective experience.

Gregory Bateson speculated that evolution and thought are two aspects of the same process. ("Steps to an Ecology of Mind", "Mind and Nature: a Necessary Unity")

Michael Levin's lab's work on the self-regulation of living forms points to _ambient_ intelligence. The cellular machinery that neurons use to think is common to all cells. It's concentrated and accelerated in neurons but the clear implication (IMO) is that all life thinks.

"What Bodies Think About: Bioelectric Computation Outside the Nervous System" (youtube.com) [https://news.ycombinator.com/item?id=18736698](https://news.ycombinator.com/item?id=18736698)

</comment></comment></comment></comment></comment><comment><USER8> Ask the 1920's or 1990's.

</comment><comment><USER9> Can we get a "Betteridge" filter for headlines that ask stupid questions?</comment>


UWSGI is a fast (pure C), self-healing, developer-friendly WSGI server - <AUTHOR> http://projects.unbit.it/uwsgi/

<comment><USER2> From the linked page:

      Why ? There are already mod_wsgi, flup and lot of protocols (fastcgi, scgi...).
      Is this faster or simpler to configure ?

      Stop acting as a Rails user ! Deploy of python web applications is not a problem.

      No need of ultra-hypeous next-fu*king-useless almost-working deploy technology.

      The challenge in the python-world is now "features", uWSGI is a feature rich
      application, developer (and administrator/security paranoid/business environments)
      friendly. Stop.

      Other deploy systems, works very well, this one does only more things.

<comment><USER3> Why do some programmers feel the need to piss on other people's projects?

</comment></comment><comment><USER4> Much needed. We pythonistas are still waiting for a deployment option as slick as ruby passenger.

I'd prefer to see this wrapped up as an nginx-module and seems they have that on their todo-list - awesome!

<comment> old-gregg Slick? Passenger spawns additional processes that require maintenance. I was always envy of Python's mod_wsgi - can it get even better? What don't you like about mod_wsgi?

<comment><USER4> As far as I know (correct me if I'm wrong) passenger is maintenance free. Anything else wouldn't make much sense anyways. It maintains a pool of workers and distributes load over them, just as it should be.

mod_wsgi for apache seems to do the same so I should have been more specific: I'm still waiting for a proper mod_wsgi for _nginx_. The nginx mod_wsgi is not the same as the apache version. It has some very unfortunate problems which effectively rule it out for production use:

[http://blog.dscpl.com.au/2009/05/blocking-requests-and- nginx...](http://blog.dscpl.com.au/2009/05/blocking-requests-and-nginx- version-of.html)

<comment><USER5> I was actually talking to a developer awhile back, the conversation resulted in him actually updating the Ubuntu repository for Nginx's mod_wsgi to be updated to mod_wsgi 2.5 (as opposed to 1.0) and making it have choices of using Python 2.4 thru 2.6 via variants. But even then it was barely stable on Nginx 0.7.* and un-buildable on Nginx 0.8.*.

At the moment the most stable version of Nginx to run mod_wsgi with is the legacy 0.6.+, the original author ported it during the 0.5 release.

Performance and integration wise, Passenger excelled over trying to hack the mod_wsgi plugin into working. And as you said there are too many bugs to be effectively used in a production environment.

Once Passenger is compiled, it only requires two lines in the Nginx configuration to enable a Python WSGI application, and its no more heavy on resources than Nginx itself. You do of course have to restart Nginx (which in effect restarts Passenger) if you change or add a web application, but thats about the only hard part. Passenger even builds and installs Nginx for you, so not sure where the high maintenance is at.

<comment><USER4> _You do of course have to restart Nginx (which in effect restarts Passenger) if you change or add a web application_

Actually depending on your web framework you don't even have to do that. Werkzeug and others support code-reloading.

By the way I had a talk with a passenger developer yesterday and the WSGI support seems to be stabilizing. I was told that dreamhost is already using it in production - so it's undocumented but functional.

</comment></comment></comment></comment></comment><comment><USER6> they claims to be fast. do they provide bench compare with alternatives ?

</comment><comment><USER7> Looks interesting. I like that at least one real ISP is using it... it gives me hope that one day it will spread to be a good solution for python apps on cheap web hosts.

Also it is good to have a couple of different python extensions for apache. It keeps them all on their toes.

I'm not sure the GPL licence makes sense for this project though. It means that to use it, people have to use the GPL for their web apps... or pay/negotiate a different licence. Well, maybe getting people to pay for it is their intention.

The protocol uses a 16bit length headers... meaning it will fail for big payloads. That turned me off investigating it out any further. However it is likely not a problem.

<comment><USER8> Even though uWSGI's source is GPL, that doesn't mean your web apps need to be GPL, that would make this completely useless (same way your editor is GPL but the code you write with it does not need to be). This would apply if you decide somehow bundle the uWSGI's source within your application for whatever reason.

<comment><USER7> hi,

If your app links to a GPL app, then your app is most likely covered by the GPL.

There are not copyright notices in all the files... but it looks like you are supposed to import a GPL module into your python program... thus the GPL is in effect. The uwsgi.c python module has a GPL copyright notice.

If your python web app talks to the server over a socket... then that is a different thing, and the GPL does not apply.

So I'm not sure how it applies in this case where your app talks to it over a socket. Note the README in the project is empty... and there is not much other documentation which I could find that explains exactly how this is to be used.

<comment><USER9> The regular GPL contains a distribution loophole which excludes your use case. That case is covered by AGPL: <http://en.wikipedia.org/wiki/Affero_General_Public_License>

</comment></comment></comment></comment><comment><USER10> Anyone had a go with this?</comment>


Ask HN: Advice for Team Lead - <AUTHOR> I have been recently promoted to team lead. I have no prior experience handling team.<p>Please guide me on handling team, managing day to day tasks, time management, and handling toxic employees. <comment><USER2> Team leader should not work anything but to delegate any upcoming work to team members and follow up/control it's execution and status In extreme cases he should be able to get any sloppy/overdue task and execute by himself in perfect way as showcase for dedication and quality of work and as an example to others

</comment><comment><USER3> Rule number one, be honest.

Rule number two, don't wait to have difficult conversations, do it as soon as something arises.

Rule three, delegate organisation tasks to your team.

I still struggle with time management personally, I'd be interested in others opinions on this as well.

You will have to balance delivery over care, or going fast over doing top quality work.

Solicit feedback from your team about how you can help them.

Also, work hard to prevent burnout.

The best way to gain trust is to show you are working for your team and not for your manager.

And don't ever listen when someone suggests one on one meetings with your team members could be a waste of time.</comment>


'Post-Truth' Beats 'chatbot' to Word of the Year Crown - <AUTHOR> http://www.theregister.co.uk/2016/11/17/posttruth_beats_chatbot_to_word_of_the_year_crown/ <comment><USER2> I like 'post-truth' seems to imply a different past, one of truth and objectivity and noble deeds. I don't believe that actually ever existed or that things are better or worse now. You might say Watergate, I could reply Snowden.

I do believe we're making it easy for people to get only the 'news' they agree with, read only the op-ed that spells out their thoughts.

But it's just as easy to tap into voices of dissent, to find views that are radically foreign to one's own. Maybe even easier and less stressful than it was in other ages.

I think blaming the media or age for intellectual laziness and corporate/political disinformation is neither fair nor productive.

<comment><AUTHOR> Ha, quite right. As if there were some verdant past lush with truth.

People want to point the finger. At whom should we point it? At the figure in the mirror? Maybe these things go in cycles.

Wasn't there at post to HN a couple of months ago about a chat/forum service that connected unlike with unlike. There'd be a social good in that if it were pervasive. Not only "know thyself" but "know thy enemy".</comment></comment>


An appeal from Wikipedia founder, Jimmy Wales - <AUTHOR> http://wikimediafoundation.org/wiki/Appeal2/en?utm_medium=sitenotice&utm_campaign=jimmy_banner_testing&utm_source=2010_testing51

<comment><USER2> I'm just curious, how much does Jimmy take away from this?</comment>


HTML Nerds: Read the Distributed Extensibility Proposal from Microsoft - <AUTHOR> http://lists.w3.org/Archives/Public/public-html/2009Sep/att-1216/MicrosoftDistributedExtensibilitySubmission.htm

<comment><USER2> The problem I have with this, is that the examples provided, e.g.

 _A HTML document editor adds information about tool settings so that a subsequent editing session can continue with the same settings._

 _A JavaScript library processes custom tags in a browser and turns them into custom controls dynamically on the page._

 _A browser wants to allow custom behaviors to be defined in one module and attached automatically to custom elements._

 _An author includes processing instructions in the document that will be processed by a server before delivering the document to a user agent._

 _An author runs a tool on a document to add numbering to headings and a table of contents. Running this tool leaves custom metadata tags intact._

can already be pretty easily achieved with the technology we already have.

I don't really see the need for namespaces in HTML. If you need custom tags and attributes surely you are better off going straight to XML and then parsing your data in any number of ways that are already available (XSLT, Javascript, PHP etc. etc.)

<comment><USER3> I'd agree with this if we were designing something in a vacuum, but XML namespaces already exist, and HTML-only browsers already exist. It's a pain to have this mechanism available in XHTML only. To illustrate why, I think I have a better example than the ones from the proposal:

If you want to use just one namespace-based extension like MathML, then you have to make the whole page XHTML. That changes the way CSS and JavaScript work. It turns previously-uncaught syntax errors into site downtime. It makes legacy browser support more difficult (because, for example, the DOM API is incompatible between browsers that support XHTML and ones that don't).

This proposal would allow me to use HTML for my entire site so that I can support legacy browsers reasonably, but also add inline MathML to some pages for browsers that support it, while using the same stylesheets and scripts across all pages.

It also lets me use namespace-based extensions within content management systems where I don't control the doctype, and it generally improves the ease of moving or sharing content between XHTML and HTML web sites.

<comment><USER4> That's a pretty good example... except that HTML5 already requires that browsers support SVG and MathML elements in HTML documents without any namespacing at all.

The other problem with adding namespaces to HTML for machine metadata is that HTML5 already supports arbitrary opaque content in attributes whose names begin with "data-". Sure, it doesn't solve the extensibility problem as thoroughly as namespaces would, but it takes a good bite out of Microsoft's use-cases, and maybe the 80% solution is Good Enough.

</comment></comment></comment><comment><USER5> In the abstract, I like the idea of HTML namespacing. However, their proposed implementation gives me a nasty feeling in the pit of my stomach.

It seems that this proposal would contort HTML to better accomodate XML data, just as other interchange formats like YAML and JSON are taking the stage. Also, a lot of the scripting advantages are already taken care of with HTML 5 custom data attributes. I just don't see the need.

Plus, some of these changes would seriously break compatibility with legacy parsers. The only purpose for this proposal seems to be making life easier for Microsoft programmers.

</comment><comment><USER6> Sounds nice in theory, but then again, so do most proposals about making stuff more extensible.

There's more examples out there of how extensibility went wrong rather than right. (for example, OpenGL 1.x extensions vs. Direct3D's continually updated core API)

With this kind of proposal, I'd be more convinced if I was presented with practical arguments based on how real people and organizations would use the extensions, rather than theoretical technical advantages of slightly different approaches.

<comment><USER3> We've had several years of experience with the proposed extensibility syntax, since it's taken directly from XML 1.0 (and XHTML 1.0). Some common real-world uses include SVG and MathML on web pages, and Creative Commons license data (using RDFa) for HTML documents.

The main reason for this general approach is that it works with current (and future) XML vocabularies like SVG.

<comment><USER6> I see.

I'm under the impression that Microsoft doesn't support SVG in IE for political and competitive reasons, and that this proposal isn't going to change that, so I really don't see the point.

I guess I don't really know how proposals like this help move things forward. I'm just your average web developer frustrated by the lack of progress in compatibility between browsers.

</comment></comment></comment><comment><USER7> This seems like it could so easily be used for evil.

It literally seems like they're requesting their own custom, proprietary extensions on HTML builtin to the standard.

<comment><USER3> They're requesting the ability for _anyone_ to extend the standard without risking incompatibility with future versions—in exactly the same way that anyone can _already_ extend XHTML 1.0 and XHTML5.

It's not just Microsoft. Sam Ruby of IBM has been requesting it since 2007 when he made a very similar proposal: [http://intertwingly.net/blog/2007/08/02/HTML5-and- Distribute...](http://intertwingly.net/blog/2007/08/02/HTML5-and-Distributed- Extensibility)

Sam was appointed co-chair (with Chris Wilson of Microsoft) of the HTML working group in January 2009, and I expect he'll be a prominent supporter of some version of this proposal. But the primary editor of HTML5 (Ian Hickson of Google; his co-editor is David Baron of Apple) has so far preferred more limited additions that address specific use cases, such as the "data-" attributes in current drafts, or hard-coded support for specific W3C vocabularies like SVG. His reasons are similar to yours; he hopes that by forcing all extensions to go through the HTML working group, the W3C might prevent implementors from fragmenting HTML into mutually incompatible dialects.</comment></comment>


New Android Virus Lands on 100,000 Chinese Smartphones & 9 App Stores - <AUTHOR> http://thenextweb.com/asia/2012/07/08/new-android-virus-mmarketpay-a-found-on-100000-chinese-smartphones-and-in-9-app-stores/ <comment><USER2> I think that it is not appropriate to call this a "virus", since it doesn't replicate from one device to the next. The user has to install it from an app store. The proper term for this kind of malware is "trojan horse".</comment>


Asking an Investor to sign an NDA - Good Idea or a Bad One - <AUTHOR> http://www.yanivnizan.com/2009/08/signing-nda-with-an-investor-good-idea-or-a-bad-one.html

<comment><USER2> I half agree, half disagree with you...

When I was looking for investment, and if I was to do it again I never sent an NDA for the first one or two meetings. From my point of view I wanted to interview my potential investors as much as they wanted to interview me. If I'm going to be in bed with these people I better like them. IMO, when you are a 1 or 2 man shop, your first investors will essentially be investing in you as much as your idea. So I never gave away my secret sauce before in the first meetings. I just gave them enough to get them interested. As such, I never sent them an NDA.

Once there was interest from an investor and they want to know more, I approached them with the confidentiality question. Those that wanted to see a demo better understand our secret sauce, read the patent docs that we wrote (but didn't have $$ to file), and/or get to see an in-depth demo had to agree to keep in confidential.

There are ways to tell someone how you're going you're different or going to be better without divulging your secret sauce.</comment>


Mom, Dad, This Playground's for You  - <AUTHOR> http://www.nytimes.com/2012/07/01/nyregion/new-york-introduces-its-first-adult-playground.html?pagewanted=all&src=ISMR_AP_LO_MST_FB

<comment><USER2> For years I have seen Joggers stop, duck in to kids playgrounds and use the playground equipment to do various excercises. The fears could have been unwarranted but no doubt this made parents wary. I was going to joke that we already had fitness trails in the form or long avenues choked with cars, bikes and pedestrians to dodge but I guess giving adults some equipment to use while keeping parents happy is a good development. Wish they had swings and slides though.

</comment><comment><USER3> There were no fitness trails in NYC before this? Wow, the City really does have no conception of the rest of the world.

[https://en.wikipedia.org/wiki/Fitness_trail#United_States_of...](https://en.wikipedia.org/wiki/Fitness_trail#United_States_of_America)

<comment><USER4> Yeah, NYC's so out of touch!

/s</comment></comment>


Make the Switch. Discover something better. Pepipost 100M free emails - <AUTHOR> http://www.pepipost.com/2016/09/09/pepipost-comes-100-million-idea/?utm_source=hackernews&utm_medium=hacker&utm_campaign=1million-hacker <comment><USER2> I know the rule of thumb says you have to market your product with pictures of naked flesh, children or pets, but looking to this page was like this:

[https://www.youtube.com/watch?v=469zNXTCHdk](https://www.youtube.com/watch?v=469zNXTCHdk)

The boy is just scary.

</comment><comment><USER3> Am I missing something or does the business model look sketchy? A service that sends emails for me and wants me to pay only for emails _not_ opened. And the number of these non-opened emails is determined, monitored and reported only by that service. Why should I trust them?</comment>


The Fall of Ethereum - <AUTHOR> https://medium.com/futuresin/the-fall-of-ethereum-15c4b64467d8 <comment><USER2> Ctrl-F "Plasma", "Sharding", "Proof of Stake"... 0 Results. Not trying to be a dick but if you are writing an article on how ethereum will not succeed because it can't scale then I would mention how ethereum is at least trying to scale. I understand this blog is very much an op-ed, but it makes that opinion come off as uneducated if you aren't at least addressing the fact that ethereum is working towards scalability.

</comment><comment><USER3> Couple of points:

 _3,000 developers and entrepreneurs, largely men in their 20s and 30s, cannot save the world. Ethereum doesn't scale, and it won't be able to scale in 2019 any better than in 2018. That's a fact, let's kill the fiction and hype from crypto. Ethereum might not be the one._

This is the main theme of the article, the lack of scaling. I wish the author would go into at least somewhat more technical details into why he thinks it's absolutely hopeless "in 2019" as he puts it. 2019 hasn't even started.

 _Failures of leadership are rife in nearly every industry and system of human society in 2018. We see it in corrupt politicians, greedy tech executives, unethical engineers and, of course, crypto profiteers who especially abused the ICO system. EOS is a perfect example of this. Ethereum might be more attractive to developers, but it may not have as bright a future as blockchain-as-a-service in the Cloud does, led by the likes of Alibaba and Amazon. The market necessitates centralized blockchains before we are ever near decentralization taking place._

Here I can understand the point. I'm pretty skeptical of "open source" governance that itself isn't centralized. Centralized creation, whether it's R&D in a corporation, a university principal investigator, or a Linux kernel, MUST be centralized to some degree. However, I don't think any blockchain development is particularly decentralized.

He might be right that a successful blockchain that's centralized (a bank or an Amazon or something) might be the 'proof of concept' needed before the decentralized demand is there.

It's a shame that so much capital had to come and go before any successful projects made it to the mainstream - assuming they ever do.

</comment><comment><USER4> Wow, the arguments are just so bad, I feel dumber after having read this article. My first hint of trouble ahead was when the author wrote that Eth lost 10X it's value.

You can lose 90 percent, but not 10 times. You can GAIN 10 times.

</comment><comment><USER5> omg could ya'll get back to researching decentralized technologies instead of speculating on them?

who cares how much it costs? who cares if ethereum itself wins or it gets replaced by something new? the value to humanity is in the research</comment>


Serial over Ethernet software - <AUTHOR> https://www.eltima.com/products/serial-over-ethernet/ <comment><USER2> I've used a lot of tools like this over the years, usually when working with NMEA data.

@hollysmokes is there a particular feature in this particular product that stands out to you?

I've often found that getting the data back into serial format is useful for any 3rd party tool that expects com data. I like Moxa brand serial to Ethernet bridges a lot and have used them in many customer deployments.</comment>


Ask HN: How relevant are Master's degrees in tech today? - <AUTHOR> I ask this question with interest from both from the perspective of a person with a non-cs undergraduate degree and one with.
Personally I have a degree in economic geology and am currently studying a Master of Finance but I have been programming on and off since school. Recently I have been considering exiting my finance masters with a grad dip/cert (I am in Australia and am not sure if those quals mean anything anywhere else?) and pursuing some form of CS. For many working professionals and people who don't happen to live near quality education institutions, I think that online learning is an excellent choice.
Unfortunately this severely limits the course options to both lengthy and costly master's degrees through universities such as Georgia Tech, Penn State or Liverpool, or short specialisations through MOOC providers such as Udacity or MIT's open courseware.
[TL;DR] Getting to my actual question. Do you think it is worth the cost (both in time and money) to pursue a Masters in CS through a traditional university or are building skills by completing personal projects and taking MOOC's (such as Udacities nanodegrees) just as likely to arm you with the skills to land a job and make a meaningful contribution in the field.
Edit: Fixed my paragraph formatting. <comment><USER2> Most of the time you will hear this community downplay the importance of post- graduate work in finding success in tech. This is true. You, by no means, need a master degree to have a successful career, monetarily speaking, in tech. However, If you want to work on problems beyond consumer applications or B2B crud, working on serious technical problems (machine learning, compilers, OSes, embedded, etc), then a Masters will certainly help. Do you _need_ it? Probably not, but it isn't the resounding "No" that you hear when asking about success in startups or the middle-ware teams of the big four.

</comment><comment> a-saleh As far as I have seen, the thing that in mostly gets you a job is that you already had a similiar job somewhere else. The sentence for junior positions is "completed bachelor's degree in CS/Software Engineering or at least 2 years of work experience in field."

On the other hand, my two years of experience was "Sysadmin a server for a local church." and only reason why my local church needed sysadmins was because me and a friend of mine bought a server, collocated in a local ISP that a third friend worked at and decided "Hey, our church could use a website and we could be the sys-admins :-)"

To answer your question, I think the utility of Master in CS as well as learning through MOOC's is dwarfed by anything you can present as "Somebody already paid me money for a thing I did", if you want to primarily land a job.

When I thought about getting a master degree, I thought about these questions:

Do I see ever wanting to pursue some sort of academic career? I.e, get a phd, desire to write papers on obscure topics, e.t.c. then definitely.

Do I want to learn things that require at least somewhat well furnished lab? I.e. it is quite hard for MooC to offer a lab on side-channel attacks on security cards or hands-on with sensor-array networks.

Do I want to learn the theory more in-depth and does physical classroom help in this regard?

How does the cost compare? What do I get out of this credential-wise?

In my case I wanted to get masters in Information Security for these reasons:

1\. I already endured 2 semesters of algebra and I.S. was one of the few that both interested me and would use the theory I have learned in BC

2\. yes, one day I might go back to school to crank out few papers just for fun and the low probability of getting a proper academic title :)

3\. school did have a few nice security lab courses present

4\. having a course end with proper seated exam with lecturer present helps me focus on studying

5\. I study in Czech republic, which means I have first 3 years of tuition paid for by the state. (Even if I didn't it is under 1000E/semester).

</comment><comment><USER3> I got into an ME (Masters of Engineering) program after a non-CS degree and working in the Industrial Engineering field.

I would say it was worth it for me, as I worked on FreeBSD servers to set up a system for deploying experimental modules to test security measures. I had zero experience with anything of that sort before.

I say find a professor willing to provide work (and pay) for your time in a Master's degree and it's completely worth it.

</comment><comment><USER4> You can try the Ga Tech OMSCS. It's fully online, is the same as the on campus version, and costs about $8000.

<comment><AUTHOR> Thanks, yeah I have been looking at that option. I really like the course, the content and especially the price. I just wonder if one could simply take most of the free specialization courses on Udacity that are offered as part of that course and have the same job prospects.

</comment></comment><comment><USER5> Can you get a accepted for a MS CS without at BS CS first?</comment>


"Try Before You Buy" Job Hunt: On-Demand W2 Employment - <AUTHOR> https://www.forbes.com/sites/rachelritlop/2017/05/30/the-millennial-try-before-you-buy-job-hunt/#57b694ea1749 <comment><USER2> It's a Big Idea-- well executed. Curious to hear of any expansion plans beyond the Bay Area?</comment>


Game of Thrones Shows the Problems of Centralized Power – Foundation for Economi - <AUTHOR> https://fee.org/articles/game-of-thrones-shows-the-problems-of-centralized-power/ <comment><AUTHOR> The analasys is lacking (a bit) in a true understanding of the story, from an overall perspective of the books and show, but it does nicely tie together many aspects of modern ecconomics theory with a good foundation in understanding of human nature in regards to polotics and the use of force.</comment>


Check-ins Are Dead? Location App Life360 Adds 1 Million Users in 10 Weeks - <AUTHOR> http://www.readwriteweb.com/archives/check-ins_are_dead_location_app_life360_adds_1_mil.php?sms_ss=hackernews&at_xt=4da7a9a467e2dde2%2C1 <comment><USER2> Assuming ~2 billion internet users, that's less than 1 in 2000 users in less than 10 weeks.

If I start a business in my home town and get 5 new customers per week, do I deserve a write up?</comment>


How Microsoft Lost the API War [2004] - <AUTHOR> http://www.joelonsoftware.com/articles/APIWar.html#repost

<comment><AUTHOR> Dupe of <http://news.ycombinator.com/item?id=1438255>, but I think it is worth another look in light of a few things:

1\. Advances in web application technology like HTML5, Sproutcore, and so forth.

2\. New "platforms" like smart phones, tablets, and ebook readers where Microsoft doesn't dominate.

3\. Getting back to point #1, the possibility that nobody uses desktop applications, where by "nobody," I mean "fewer than 10,000,000 people," to borrow Joel's phrase.

<comment><USER2> I think your point #2 is the critical one and it seems to be at odds with the premise of the article. Microsoft is now trying to keep it's old API intact on a platform (tablet) that it is not suited for. If Microsoft had really got behind a new API (even if it was a OS X => iOS :: Windows 7 => ??? situation), it would have a better chance as opposed to the drumming it has taken.

<comment><USER3> I don't think it's at odds with the article. Microsoft irritated developers by pushing wave after wave of new desktop APIs on them for no good reason, and now that they have a compelling justification (new form factors) to release a redesigned API they can't afford to risk it because they've worn out the patience of developers.

<comment><USER4> This is so true, the constant churn of frameworks for desktop apps has left me very skeptical of anything they offer.

</comment></comment></comment></comment><comment><USER3> _But there's a price to pay in the smoothness of the user interface. Here are a few examples of things you can't really do well in a web application:

Create a fast drawing program

Build a real-time spell checker with wavy red underlines

Warn users that they are going to lose their work if they hit the close box of the browser

Update a small part of the display based on a change that the user makes without a full roundtrip to the server

Create a fast keyboard-driven interface that doesn't require the mouse

Let people continue working when they are not connected to the Internet

These are not all big issues. Some of them will be solved very soon by witty Javascript developers._

What's left on this list today?

<comment><USER5> None of them, though 'fast drawing program' is arguable. Especially for 3D.

</comment></comment><comment><USER6> I don't think there really was an API war. What happened to what Joel considers "Microsoft's crown strategic jewel", the Windows API, was also largely irrelevant.

Microsoft's real problem was they spent far too long pouring resources into preparing for an enemy that never really arrived. Imagine instead if they had spent the last ten years pouring resources into keeping IE, Hotmail, and internet search, as cutting edge products.

It's kinda mind-blowing to think what the world might look like today if Microsoft hadn't basically surrendered these markets at the turn of the century.

<comment><USER7> I like your analysis, but bear in mind Joel wrote this in 2004. MS did waste time and resource trying to extend Windows to the internet, or somehow wish away the internet. Exactly in what year did MS realize this? Only interesting in so far as history is interesting.

</comment></comment><comment><USER8> There's an astonishing amount of really wise and relevant stuff here six years on. Joel is correct about automatic garbage collection being the big win in the PERL / Python / PHP / Javascript / Java / Ruby / Scala / C# / VB language generation. It's still true. C and C++ were always hard to use to develop solid and secure code, and now there's no reason to.

He's also right about Microsoft's history of radical compatibility, and how it has faded away.

What about developer tools now? VS2010 for C# and Eclipse for Java are pretty equivalent IF you pay extra to augment VS with Resharper. ADO.NET and JDBC are both good now. We have to give MS credit in 2010 for keeping up with open source.

But Joel is right about the MSDN faction promoting byzantine solutions to problems.

It will be interesting to see how the HTML5 / Silverlight / Actionscript-Flash issues play out. It's going to be hard for the market to support more than two of these.

</comment><comment><USER9> Six year later, XAML didn't replace the old GUI's and is now on its deathbed...

<comment><USER10> 1\. It's not, actually, it's a big part of Silverlight and Windows Phone 7.

2\. MS has this horrible problem of not actually using their own products. No big apps came out of MS using WPF/XAML, why would anyone else use it?

<comment><USER11> Which is much the same of what could be said for WinForms, MFC, and soon even Silverlight will be thrown under the bus or at least bolted on top of HTML5 to keep it alive.

</comment></comment></comment><comment><USER12> Nice read.</comment>


Don't Comment Your Code - Write Better Code - <AUTHOR> http://sam-koblenski.blogspot.com/2013/07/dont-comment-your-code-write-better-code.html

<comment><USER2> "My code is so good it doesn't need comments" is usually untrue. Don't fall for it.

If you can name an API or framework that you use that has near-zero comments... And _benefits_ from that, I'd like to know. I can name plenty that are a pleasure to use because of clear, replete documentation.

If you're thinking your code is different from an API, you're right - it's worse. An API is designed for consumption, whereas your code is buried. It might not get look at by another human for months... or _years_.

Who will be looking at that piece of code next? You? Ok. Be your own worst enemy. More than likely it's someone else looking. And why? Maybe because it doesn't work like it should, or conditions have changed, or it needs to be extended.

Bad documentation can be just as bad as bad code, but "don't comment your code" is a road to madness.

<comment><USER3> > "My code is so good it doesn't need comments" is usually untrue.

I still don't see this as a convincing argument.

Our greatest constraint is time. So the question becomes do I spend my time writing comments or do I re-factor the code I wrote to make it more readable?

I always opt for re-factoring my code.

Have you read some of the comments most developers leave? They either explain the most obvious inane functionality or use it as their personal todo list. And sometimes they do both. That is not helpful.

In instances where I know my code will be a critical component which will be utilized by many others, I opt to write _documentation_ rather than _comments_. And there is, of course, a difference.

Comments are inline, documentation is frequently split out. Comments are frequently inane explaining the obvious, while documentation goes in-depth into not only how the code works, but what it is trying to accomplish and why. Documentation also provides examples of use, which is far more useful than anything else. When I reach for the documentation option, I almost always include a separate markdown file with the same name as the original file. There are then a ton of options in terms of software that aggregate those files into a searchable, indexed collection.

Focus on code quality and if some sort of annotation is necessary, write documentation, but don't leave comments.

<comment><USER4> Inline documentation done right is undeniably a massive time-saver though because you don't need to search a separate document at all. With the right editor, your documentation can also be folded into a single line or be hidden altogether.

Can you show us any concrete examples of high quality, comment-less codebases? The last (mostly) comment-less source that I read through last year was Node.js and I wouldn't exactly call that high quality or well documented.

<comment><USER3> > Can you show us any concrete examples of high quality, comment-less > codebases?

No.

Quite simply, there is a collective perception that if a codebase lacks inline comments, it's of poor quality. Very few would dare to publish such a work.

I have a different challenge for you.

Take a high quality codebase and delete all the inline comments. You'll find it's just as readable, if not more so. How much better would it have been if the coder had spent the time writing better code rather than adding superfluous comments?

<comment><USER2> "The coder" probably should spend time talking to customers, testing designs, interacting with their peers, reading other code, learning.

None of these contribute directly to achieving a theoretical maximum output of SLoC. If that's you're metric, I don't think it's a good one.

Aside from niche projects - A great deal of time goes into realising software. The incremental cost of comments is minuscule.

I have lots of challenges and bottlenecks. The time to type comments isn't one of them.

<comment><USER3> > a theoretical maximum output of SLoC. If that's you're metric, I don't think > it's a good one.

That's certainly not my metric and I definitely don't believe it's a good one.

My metric is readability. The ability to return to a piece of code 6 months down the road and be able to understand precisely what's happening.

> I have lots of challenges and bottlenecks. The time to type comments isn't > one of them.

Oh, I know. It's very easy to add a comment that you think will help clarify things down the road, but instead, ends up being more cryptic than your code.

By definition, a comment is something short and half-thought out. It's a comment.

As I said in the post up above, stay away from comments. If you have to annotate, write documentation instead.

<comment><USER4> That's not the definition of the word "comment" at all.

Who is the authority on whether commentless code is good or not? Could this possibly be completely subjective? Hmmm.

> Oh, I know. It's very easy to add a comment...but [it] ends up being more > cryptic than your code.

You don't know that :)

</comment></comment></comment></comment></comment></comment></comment><comment><USER5> Don't listen to this guy. Comment your code, because if its in production, your most likely not be the only hands that touch it!

Someone down the line will have to review it, change it or modify it. It saves both time and effort, if you comment the code.

Just do it.

<comment><USER6> Or they will simply change or modify the code and leave the comment? Now the comment doesn't help, it's actually detrimental.

<comment><USER7> Perhaps testable comments?

<comment><USER8> Testable documentation - or, as it's more commonly known, unit testing - is of course a very good idea, and a better replacement for comments.

<comment><USER7> Related, for sure. I think for it to be considered testable _comments_ it would have to 1) be inline, 2) be brief enough to be easily readable in the context of a comment, and 3) be aimed at documenting the kinds of things good comments are aimed at documenting. All of these are occasionally aspects of unit tests, but there are plenty of things that are unit tests and are probably a good idea that are not all three of these.

</comment></comment></comment></comment></comment><comment><USER9> Speaking from experience of a) working in a team and b) maintaining legacy code: Your code, no matter how good, will not instantly make sense to someone else.

Comments are essential. Writing good comments is as skilled a task as writing the code.

(as an aside; the most important comment is WHO. Because knowing who wrote/modified a block of code is ridiculously useful for all sorts of obvious reasons)

<comment><USER10> If you have to write who wrote a piece of code in a comment, you must not be using a decent version control system with a blame command. Which is a problem you should probably fix way before talking about comment styles.

<comment><USER9> Uh, that takes much longer.

Blame is useful in more elaborate context but... comments are instant :) And that is important.

</comment></comment></comment><comment><USER11> Personally, I like Linus's take on comments:

"Comments are good, but there is also a danger of over-commenting. NEVER try to explain HOW your code works in a comment: it's much better to write the code so that the _working_ is obvious, and it's a waste of time to explain badly written code.

Generally, you want your comments to tell WHAT your code does, not HOW. Also, try to avoid putting comments inside a function body: if the function is so complex that you need to separately comment parts of it, you should probably go back to chapter 6 for a while. You can make small comments to note or warn about something particularly clever (or ugly), but try to avoid excess. Instead, put the comments at the head of the function, telling people what it does, and possibly WHY it does it."

[https://www.kernel.org/doc/Documentation/CodingStyle](https://www.kernel.org/doc/Documentation/CodingStyle) (Chapter 8)

<comment><USER11> Hmm, maybe I'm just assuming Linus Torvalds wrote that - it could be another kernel dev.

</comment></comment><comment><USER12> "My code is so good it doesn't need comments!" says the first.

"What the hell was this guy thinking?!" says the second.

</comment><comment><USER13> "don't comment your code", as dogma, without thinking, it's just stupid.

What sometimes happens, when you work on the same code base for month and you know it inside out, it's that you get some knowledge for granted. So you shift your mental needs (and the need to comment it out) from the "how the hell do I do this" from "why the hell do I need to do this" (there can be some crazy business rules, or some infrastructure limitations or whatever).

The problem is, the knowledge of the code base is not easily transmissible from people to people. So it's still useful to leave some comment, specially on some "non intuitive" steps.

<comment><USER14>
        The problem is, the knowledge of the code base is not easily transmissible
        from people to people. So it's still useful to leave some comment,
        specially on some "non intuitive" steps.

Having just come from a team where code was well-written but poorly documented, this is important. It is the difference between it taking me 20 minutes and 4 hours to implement and test a small change. If the code is well- documented I can quickly find my way around and locate the behaviour I need to change. Again, if it is well documented it is easy to see how this relates to the rest of the system and I can make good decisions when I make my changes. If the whole process is well-documented I have a good starting point for what acceptance tests I should run to make sure it works as intended, and what kind of regression tests I should put in place or modify.

Without documentation I must read and decipher a much larger body of code, much of which ends up being unrelated to what I am working on now. Even in the best code-bases there will be code that is not clear without a pre-existing knowledge of the code-base as a whole. I am likely to make time-consuming mistakes because I do not understand some edge-conditions or complex interaction.

</comment></comment><comment><USER15> I used to argue that well-written code needed no documentation, but I read various articles about documentation anyway.

The takeaway was this: Even if my code is clear, neither I nor anyone else should have to read through a function in order to understand what it does. Reading a comment should be enough to use it.

<comment><USER16> This has the additional advantage of separating the specification from the implementation. If e.g. a javadoc comment says "@throws IllegalStateException when foo", then I know if I change the method, I have to preserve that behaviour.

</comment></comment><comment><USER17> Or better use (and develop) a good judgement on where it's better to add some comment here and there if required. It doesn't need to be black or white. There are lots of gray in between.

</comment><comment><USER18> no code will say WHY you did something the way you did it. only comments can do that.

<comment><USER19> On the contrary, an approximation of some code I've written:

        function do_search($query) {
            if($database->type == "mysql") {
                return __do_search_stupidly_because_mysql_is_shit($query);
            }
            else {
                return __do_search_sensibly($query);
            }
        }

<comment><USER20> So a comment could explain why MySQL is shit, what versions, whether it applies to MariaDB, whether there's an open defect, how your algorithm is different, etc. Presumably whoever wrote this code learned some of that metadata, so it's helpful to keep a record of it.

<comment><USER19> Those things are commented _within_ the function; but the name of it allows the casual reader to know that madness lies within and they would be happier for not looking at the innards at all :P

<comment><USER20> Ok, makes sense. By the way, switching on a type code like that is the classic use case for virtual functions.

[http://sourcemaking.com/refactoring/replace-conditional- with...](http://sourcemaking.com/refactoring/replace-conditional-with- polymorphism)

</comment></comment></comment></comment></comment><comment><USER21> Worst. Advice. Ever.

Please comment your code. First, you're probably not going to immediately remember what the code does 6 - 12 months after you write it and when you have to come back to it for an update it's going to take you too long to figure out if you actually read the code. Comments make familiarizing yourself with your old code much faster. Second, any other teammate who touches the code is going to hate you if they have to read your code to figure out what it does. There is nothing worse than looking over code written by someone else when there are no comments.

<comment><USER22> I disagree. And I'm not sure you caught the tiny part at the beginning when the author talked about how _why_ comments are good, but _what_ and _how_ comments are mostly useless. Yes, there was only a tiny mention in the post, but it was there.

I think that what and how comments are useless because they're literally the code itself. Comments like 'increment by two' are useless, because the next line literally says `x += 2`.

If that comment was expanded to be something like 'increment by two because ...', explaining why x is being incremented by two, it becomes useful, and I think the author agrees.

I think the reason these posts get as much traction as they do every time they're posted is because people tend to write bad comments. In my experience as a CS tutor at my college, most new programmers either write useless what/how comments or no comments at all.

The problem I see with these posts are that they don't talk about how there are good kinds of comments, but that everyone should just make their code cleaner and everything will be great. If more time was spent talking about how to write better, more informative, and relevant comments I'd like these posts more.

</comment></comment><comment><USER23> Comment rot is like wiki rot -- all too common, and often more confusing. There are a couple good rules of thumb I follow.

1) If you are writing a comment, make sure it is a "why" and not a "what" (why this code exists, not a description of what it is doing). Why comments often survive refactoring, you might entirely redo the login system, but the reason you do it is still so people can log in.

2) If you find yourself documenting the "what" about code -- take a moment, and think really hard about why it is confusing. If it is accidental complexity (your fault), refactor it. If it is fundamental complexity (problem domain is a bitch), don't add the documentation to the function, put that knowledge in the tests. Nothing is as harmful that a bunch of gotchas buried in comments no one will read, and will eventually rot and not even make sense after the code is refactored.

</comment><comment><USER24> Ah yes, there's nothing like wanting to use the new hot API and realizing you have to read almost all of the source code to understand how to use it because the code is so good it didn't require comments. Because I see good comments as a form of documentation. Can comments be abused and detrimental? Sure, but then so can code.

Especially in Javascript where parameters of a method are not typed, so if you want to know whether you should be passing a string or a number you have to read through the code to find out.

Or, you know, a single line comment saying what to pass might be helpful.

The problem is not the comments. The problem are the coders that follow behind to update a block of code but can't be bothered to update the comments to reflect the changes.

If your code is so good it doesn't need comments then it seems it wouldn't require git commit messages either.

</comment><comment><USER25> I read the second block of code before the first. Just reading the second blob, I had no idea what the code was actually doing. Part of this is because I only have a peephole view into what's going on. I don't know what CalculateResultPairForNextStage() does, for example. My only clue that DMA is even involved in this code is the comment about resetting the source. Perhaps you have a big beautiful block comment in the header that explains what this component does, but just looking at this example things are far from clear.

I'm also wary of the refactoring. The _csHoldoff check and decrement happens every loop in the first block, but only once at the end in the second block. Of course I have no idea what _csHoldoff is or does, nor do I know why there's a "cs" prefix on it. Hungarian notation? Some variables have it, and others, like _centerFrequency, don't.

</comment><comment><USER26> The problem with this is that he assumes the context will always be known to the reader.

I find that many assumptions about what is obvious in code have to do with the context the code is in. That context may be closely surrounding the code block, or with may extend to many lines before and after. If you have not been working on that entire section for a time, the context is not present (or only partially present), and as such all your thoughts on what is obvious may be subtly wrong.

This is analogous to program state. The farther you explore in either direction of the target code, the more of the possible state you can infer. Comments help is make these inferences without having to explore as much. Without comments we are forced to explore more of the program to build a better mental model of the possible states. Comments help us by providing hints as to the context (state).

</comment><comment><USER27> I'm a proponent of self documenting code (method names, variable names, immutable variables etc) but this only helps document the WHAT and sometimes HOW but seldom the most useful WHY or WHY NOT or what I have tried before this and what didn't work so I changed it.

</comment><comment><USER28> "Don't comment bad code -- rewrite it." \-- The Elements Of Programming Style by Brian Kernighan and P.J. Plauger. 1974.

Until your code is as good as Kernighan's you probably want to comment what you intended to do.

<comment><USER13> Kernighan does not say "don't comment _good_ code"

<comment><USER28> You can read what Kernighan wrote here: [http://books.cat-v.org/computer- science/elements-of-programm...](http://books.cat-v.org/computer- science/elements-of-programming-style/elements_of_programming_style.pdf)

Also see Software Tools and The Practice Of Programming.

<comment><USER4> He really doesn't say "don't comment good code".

Reading page 141, he generally recommends that everyone should comment their code for non-trivial programs. Also, "One thing we will _not_ do is make pronouncements about how many comments a program should have."

</comment></comment></comment></comment><comment><USER29> KISS!!

comments describe why. code describes what.

<comment><USER5> I thought this was just another stupid HN comment. Had to read it several times for it to make sense. Its solid advice.

</comment></comment><comment><USER30> "Clarity" is not a substitute for comments. The _only_ thing I've seen that really substitutes for comments is a rich, easy to understand unit test suite. But even that is problematic, as it usually covers a lot of edge and corner case situations that aren't relevant to the end user.

</comment><comment><USER31> I use comments where nescessary but what I really wish the IDE's/editors had was the ability to hide all comments (not just fold but completely hide), I don't need to see the comment now as I'm writing the code and the model is in my head but I will want to see them in 3 months.

</comment><comment><USER32> I was trying to write good code instead of document a lot. But now I feel that a few comments is necessary, given that you write the stuff that matters. Maybe we should all try to comment as concise as possible, and write it just like SEO.

</comment><comment><USER33> linkbait title. not a very good article. I think most of us here know about the dangers of stale comments, or spammy comments. I also think most of us know that writing good, descriptive, and up-to-date comments is basically essential.

</comment><comment><USER34> Its true one should FAVOUR self documenting code. Going to the absolute and never commenting your code is obviously stupid, there will always be cases when more context and information on "Why" is needed.

</comment><comment><USER35> I have been coding for over thirty years and the best reason for commenting your code is that the older you, will not remember what the younger you was thinking when he wrote the code.

</comment><comment><USER36> Please don't summarize what your functions / methods do, make me read them in their entirety to find out.

Er, what?

"Illiterate Programming" paradigm?

</comment><comment><USER37> I find it good practice to comment code for that other guy that is me-in-two- months. I just rediscovered some semi-old code and boy am I happy about the comments.

<comment><USER38> Yeah, good comments help support DRY. Not so much DRY in the code, but avoiding repeating the mental work that led _to_ the code (whether yours or somebody else's.) If the code is non-trivial, there is probably research, discussion, or analysis that went into producing it that the next person working with the code (whether you-in- _N_ -months or someone else) either won't have done or won't have as fresh in their mind when they look at the code. Summarizing or providing references for that work stops it from being redone (or, worse for the code, the lessons forgotten and the mistake that it avoided reimplemented.)

</comment></comment><comment><USER39> I wholly agree that code comments can be greatly reduced by better code, most notably with code that has well-named variables and methods as well as through reduced complexity through refactoring.

However, I think the way the OP title is phrased, " _Don 't_ Comment" makes too strong of a statement against comments, when I think the better, albeit softer statement would be: "Write Better Code and Fewer Comments"

The main argument against commenting period is that comments are inherently not part of the workflow/compilation process, so it takes an extra level of cognitive awareness and maintenance to make sure they stay up to date with the specs. Other than that (very big) hitch, there's nothing inherently wrong with comments...except that in practice, a huge number of them indicate a code smell, as well as being a maintenance liability.

This may have been outside of the OP's scope, but I think it's worth mentioning that well-written and copious tests can also serve the function of comments...unlike comments, they _do_ break when the code they document is changed, and so thus they're easier to maintain in that you _can 't_ go forward without fixing them (which introduces its own maintenance chore, and so on and so on).

<comment><USER40> Yes, I was thinking the same thing. Your title suggestion is more accurate, but would probably draw less clicks.

I prefer it when a title is bland, but the content is so astoundingly good. These are little surprises and they still find their way to the front page.

</comment></comment><comment><USER41> +1 I like to refactor just names of variables and methods, instead of writing comment what it actually does.</comment>


I'm Brianna Wu, and I'm Risking My Life Standing Up to Gamergate - <AUTHOR> http://www.marco.org/2015/02/11/brianna-wu-standing-up-to-gamergate <comment><AUTHOR> Since there seems to be a flagging campaign (based on the low placement relative to articles with similar upvotes and time submitted) against the original, I'm submitting this.

<comment><USER2> You added little to no content to something which was already being flagged, are you going to be surprised when this gets flagged too?

<comment><AUTHOR> No, but maybe the moderators will do something about the situation.

<comment><USER2> If you actually cared you would write a more moderate piece, most of the reason #GAMURG8 gets flagged is the hysteria makes it unbearable to read.

You basically blogged a "re-tweet", a poor attempt at circumventing the hackernews community...

<comment><AUTHOR> Learn how to read.</comment></comment></comment></comment></comment>