Show HN: Celebrate the 50th Anniversary of Doug Engelbart's Great Demo - <AUTHOR> https://colab.research.google.com/drive/1k4oC2bzjgUOiU9vdadjrBpEwWGaqJWsA <comment><AUTHOR> It is very interesting that now we start to see trolling and vandalism on that page. No surprise for a public wiki. I published it here to HN instead of tweet just to limit that kind of publicity but encourage people in the community to experiment in the spirit of Doug. That is the best way to celebrate his legacy.

For those internet trolls, no big deal, they will get bored after 15 minutes. To people who think at a little bit longer time scale, that is just noise.

P.S. This Show HN post was posted yesterday and got no notice. Until it was kindly re-upped

[https://news.ycombinator.com/item?id=11662380](https://news.ycombinator.com/item?id=11662380)

Thank you dang!

</comment><comment><USER2> In 1968 I was 2 years old. When I was about 10 to 12 years old, I forget exactly, I went on a school trip to an ICL data center to look at the punched card readers and line printers. Even a decade later, Doug's work seemed impossibly futuristic.

In 1984, 16 years after the demo, John C. Dvorak famously wrote of the mouse "There is no evidence that people want to use these things."

<comment><USER3> Another anecdote: an expensive training class onsite in 1987 at a new Adobe Systems building in Silicon Valley, with Apple/Mac developers well-represented and a few financially successful developers from other OS. The whole class was halted ten minutes in because one of the non-Mac attendees realized the whole curriculum of "developing drivers for Adobe Postscript" was going to be presented using a point-and-click coursework, and called a senior contact at Adobe in to make a scene.. because, you know, a "mouse" ?

</comment></comment><comment><AUTHOR> I won't waste time fighting trolls. This is the latest snapshot where we can always reset to:

[https://colab.research.google.com/gist/ontouchstart/9acd0280...](https://colab.research.google.com/gist/ontouchstart/9acd028083152de32878d6e03e9b0409/thedemo.ipynb)

I think the community can clean it up when things get out of hand. Let's see how it evolves.

</comment><comment><USER4> Also worth saying... [https://www.youtube.com/watch?v=yMjPqr1s-cg](https://www.youtube.com/watch?v=yMjPqr1s-cg)

Are we now, this moment, coming to 5:15-5:34? I suspect, and hope, that the eulogist was pointing this toward ARPA and SRI and not me.

<comment><AUTHOR> Thanks for sharing. Very touching.

Added it to the notebook

[https://colab.research.google.com/gist/ontouchstart/c538817e...](https://colab.research.google.com/gist/ontouchstart/c538817e14c5599b9e057f53026efbdf/thedemo.ipynb#scrollTo=4VS3LpRsT00B)

It is best to be watched after watching a few minutes of this cell:

[https://colab.research.google.com/gist/ontouchstart/c538817e...](https://colab.research.google.com/gist/ontouchstart/c538817e14c5599b9e057f53026efbdf/thedemo.ipynb#scrollTo=IHF4o9p19oxI)

</comment></comment><comment><USER5> I remember first hearing about this demo in the book "Fire in the Valley." It was amazing reading about what was unveiled in one demo.

Here is a link to a section on Google Books: [https://books.google.com/books?id=-g5QDwAAQBAJ&pg=PT387&lpg=...](https://books.google.com/books?id=-g5QDwAAQBAJ&pg=PT387&lpg=PT387&dq=%22fire+in+the+valley%22+engelbart&source=bl&ots=1w89-SfVlh&sig=ES9ady21kj1OQN6wv56lezNsSpE&hl=en&sa=X&ved=2ahUKEwj0ubLEhZbfAhXkqVQKHdK6DrIQ6AEwBHoECAEQAQ#v=onepage&q=%22fire%20in%20the%20valley%22%20engelbart&f=false)

</comment><comment><AUTHOR> Since it is a wiki kind of page that any one can edit. Feel free to explore in the sandbox cell.

Anytime if you want to keep a copy, you can save a snapshot copy as gist, such as this one

[https://colab.research.google.com/gist/ontouchstart/2d20c3b9...](https://colab.research.google.com/gist/ontouchstart/2d20c3b9050a25483e898831f19b12af/thedemo.ipynb)

</comment><comment><AUTHOR> For those of you who wants to jump to the mouse demo, here is a direct link (on a saved snapshot):

[https://colab.research.google.com/gist/ontouchstart/7ae904ac...](https://colab.research.google.com/gist/ontouchstart/7ae904acda749f989cde895d4f800d08/thedemo.ipynb#scrollTo=oDmYYW7BAIUk)

</comment><comment><USER6> It's 50 years since the demo, and about 18 years later, I wrote short paper introducing the concept of WIMPs to my then boss. Windows, Icon, Menus, Pointers.

Which goes to show the uptake was not that fast.

Boss let me buy Windows v1.02

</comment><comment><AUTHOR> This post was inspired by a discussion in this thread.

[https://news.ycombinator.com/item?id=18635733](https://news.ycombinator.com/item?id=18635733)</comment>


New browser attack lets hackers run bad code even after users leave a web page - <AUTHOR> https://www.zdnet.com/article/new-browser-attack-lets-hackers-run-bad-code-even-after-users-leave-a-web-page/ <comment><USER2> Is this actually exploitable with the current set of browsers?

Looking at the documentation of the API [[https://developer.mozilla.org/en- US/docs/Web/API/ServiceWork...](https://developer.mozilla.org/en- US/docs/Web/API/ServiceWorkerRegistration/periodicSync)]

and it says in a yellow note at the top of the docs This feature was mentioned as an idea in the SW explainer at some point, but as yet has not been implemented anywhere.

My guess is that is only an experimental feature currently

<comment><USER3> It is only experimental, but it has basic support from most browsers which is probably enough for the exploit (the note might be a little outdated or at the least a bit misleading.) Just check the browser compatibility section on the mdn page you linked it lists the browsers that have basic support that feature.</comment></comment>


I learned to code, build a web app and launch it on Product Hunt in 2 months - <AUTHOR> https://medium.com/@AndreyAzimov/i-learned-to-code-and-build-a-web-app-in-2-months-da8f2932c139#.viphi9e5j <comment><USER2> Often, people new to programming get bogged down trying to get everything right, the project becomes insurmountable and they eventually quit. I like how he skipped all the unnecessary with his mind on the goal and just launched as fast as he could. For the next project he could start incorporating some of the good advice he got to get better at the craft. The final product is quite impressive at his level of skill.

</comment><comment><USER3> I love the enthusiasm and drive of the author's approach. Great inspiration for starters.</comment>


Show HN: I decided to document and share my high-level CSS best practices - <AUTHOR> https://github.com/csswizardry/CSS-Guidelines/blob/master/CSS%20Guidelines.md <comment><USER2> I'm surprised by the lack of spaces in, say,

      .error{ color:red; }

I much prefer

      .error { color: red; }

or

      .error {
        color: red;
      }

(The latter is particularly nice because it implicitly acknowledges the likelihood that additional rules will be added.)

I don't recall seeing the space-compressed version much in the old days. Is it a new trend? I don't like it.

<comment><USER3> I don't understand how anyone using version control can use one liner CSS. There is code folding in all decent text editors.

</comment></comment><comment><USER4> I break about half of those rules and it works very, very well. Please don't label things that can be discussed as 'best practices'. One day some newbie will wonder across it, take it as gospel, and then will screw up projects by applying them when they don't make sense.

Also there is nothing wrong with magic numbers so long as you don't use them where a % would be more appropriate (e.g this text is 12px, because it looks nice). If CSS is used with out a pre-processor you have to use them, as there is no concept of variables.

<comment><USER5> > _I break about half of those rules and it works very, very well._

Can you go into more detail about which rules you disagree with or find unnecessary?

<comment><USER6> Not who you're replying to, but on my list:

CamelCase vs using-dashes is strictly a developer preference. I happen to agree with the author of the doc about using dashes, but I'm not going to call my preference a "best practice". A "best practice" might be more akin to "if you're working on an already in progress project, don't start doing CamelCase if they're using-dashes, or vice-versa", IMO.

Another controversial one is whether or not to have each style on it's own line, or in the same line. The author prefers a new line for each style because it makes for easier diff-ing in version control. The argument could be made, however, that this style introduces too much whitespace and vastly reduces the number of styles you can view at one time, not to mention increasing the linecount of your stylesheet by at least a factor of 3. Neither is, IMO, a "best practice", it's just a developer preference (IME most devs do agree with this doc, however).

There's some other stuff that really just boils down to how the author prefers to read his CSS, and not really about how to structure it in a proven optimal way. I believe it's hard to argue that those are "best practices", something Wikipedia describes as "consistently shown results superior to those achieved with other means". I would like to see the argument that lining up your -webkit prefixed styles achieves this, for example.

Anyway, IMO, a lot of the recommendations in the doc are good advice, just mixed in with some personal preferences. Like the author wrote though, it is his personal best practices, so in that context I suppose these are Best Practices, only the scope is limited to just the author.

</comment></comment></comment><comment><USER7> This is fantastic. While I disagree with some things (I'd rather standardize on px for everything, since em's have also been a huge headache for font- sizes), I love seeing the fact that this document exists.

I've written my own guidelines similar to this for different workplaces, though never publicized them. It would be wonderful if there could be some kind of consensus-best-CSS-practices standard out there, much like people have standardized on a couple common CSS resets, etc.

I've found that client-side developers tend to differ _drastically_ in philosophies behind CSS coding, especially ones with less experience.

In my opinion, CSS is one of the most "dangerous" languages out there -- more often misunderstood and misused than any other language I've ever come across, including VB6 -- and thus most needing a standardized set of best practices.

<comment><USER4> >consensus-best-CSS-practices standard out there

No no no no. Best practices becomes an excuse for developers to switch of their minds and not think. In all cases there are exceptions to the best practices but people always forget that.

The reason there are differences between what people prefer is that they work on different problems. That is a good thing and should be encouraged, not squashed.

<comment><USER8> While I would never advocate developers not thinking for themselves, I think it's shallow to say that seeking out and following best practices is an excuse to not think.

In fact, some languages, like Rails, are considered opinionated by imposing certain practices and standards in order to streamline the repetitive implementations that most applications need. This frees the developer to focus and _think_ more about the more complex and less repetitive tasks.

[http://programmers.stackexchange.com/questions/12182/what- do...](http://programmers.stackexchange.com/questions/12182/what-does- opinionated-software-really-mean)

</comment></comment></comment><comment><USER9> Here is a very petty point that isn't mentioned in the guidelines, but implied by example: Is there a good reason why people don't like putting a space after a colon? Such as...

        margin:0;

Instead of...

        margin: 0;

The latter looks much more natural to me (probably because I'm used to writing English and other syntaxes), so I don't believe there's an aesthetic benefit. Chrome Inspector and Firebug also prefer the latter, so I don't believe there's a tool benefit. If saving a byte before processing was an issue then we'd be hitting less CRs, so there's no real bandwidth benefit. I don't get it, but I keep seeing it more and more.

Is there some benefit to no-space-after-colon that I haven't considered? Was it established as a standard somehow while I wasn't paying attention?

<comment><USER10> I always write

      margin:0;

instead of

      margin: 0;

Here's why.

The first reason I do is because you don't _need_ to write that space. It doesn't seem like much but it makes a difference when you're writing up to more than 1000 lines for one CSS (I type every word using Notepad++).

Second reason is: by removing this space, it _joins_ the property (margin) and the value (0) together. And because I write my CSS in lines, it makes a difference when scanning visually.

      input { background:white; border:none; float:left; font-size:14px; margin:0; padding:5px; width:400px;}

is easier for me to scan than

      input { background: white; border: none; float: left; font-size: 14px; margin: 0; padding: 5px; width: 400px;}

because I can easily target any _pair_ property/value.

And the reason I don't mind the lack of space after the colon is probably because I'm French and in French there needs to be a space before and after a colon. So I guess that if I remove the one before I might as well get rid of the one after (for symmetry?!).

<comment><USER11> I'd never thought of it that way. However, for me,

        input,
        select {
            background: white;
            border: none;
            float: left;
            font-size: 14px;
            margin: 0;
            padding: 5px;
            width: 400px;
        }

Is more readable—each rule and selector on its own line. I am biased as I use Vim and half-page scroll lots, and like an 80-character maximum, though.

<comment><USER10> I started writing CSS just like that. It makes reading _properties_ easy but takes a lot of vertical space (and unlike you, I hate to scroll). So I write properties on one line, which makes reading _selectors_ easy (example: <http://jgthms.com/wings.css>).

I compensate by ordering my properties alphabetically so I can scan horizontally to find any property (background and border come first, margin and padding are near the middle, text-transform and width are near the end...).

<comment><USER12> > I compensate by ordering my properties alphabetically so I can scan > horizontally to find any property (background and border come first, margin > and padding are near the middle, text-transform and width are near the > end...).

Not a bad idea... I'm stealing it.

</comment></comment></comment></comment></comment><comment><USER13> Some nice ideas, but not many new ones. And the new ones don't always make sense:

"For each level of markup nesting, try and indent your CSS to match" <= that made my teeth itch. Mostly just down to personal taste, but I really find it quicker to read css if only the values are indented. It's easier to compare nested classes that way, as repeated values would occupy more similar space.

"Also write vendor prefixed CSS so that colons all line up" <= not all vendor css3 values have the same structure, so this can't be a standard (eg: gradients, mixed border-radius)

I suppose whether or not you add conditional support for IE is a matter of taste. I prefer to handle IE the boilerplate way, with conditionals determining what class the html element has, and including appropriate styles in the main css. Why sacrifice good, standards-compliant css for dirty IE?

<comment><AUTHOR> > that made my teeth itch

Fair enough; any reason as to why?

> not all vendor css3 definitions have the same structure, so this can't be a > standard

Well if it can't be done then it can't be done…

<comment><USER13> The "teeth itch" thing: It feels too much like over-ornamentation. It just wouldn't suit my style of work. I find it much faster to scan css when everything is vertically aligned. If I have to scan left and right as well as up and down, it takes me longer, and comparisons are slower.

<comment><USER14> It could also lead to lazy naming. I'd prefer to see intelligent names used instead. If your css is tab-synched with your markup you might be tempted to lazily name your attributes assuming that people will figure out due to the tabbing. But your css should make some kind of sense independent of the markup.

Also, it confuses the functionality of the nesting (IMHO). When I look at

        .nav
            .nav li
                .nav li span

It looks like the indents imply some kind of syntactic meaning. Is it tabbed because tabs now mean something? In which case the second line might be equivalent to

      .nav.nav li         which it is not.

Usually an indent implies some kind of relation to the previous line. For example when you indent the body of a function it helps to indicate that the body is part of the function. There's a logical difference and most likely even a scope level difference. The indents that you are adding to CSS don't work that way because each new line starts its select with no concern for the line above.

Also, there may be some deeply nested markup that doesn't require css except for the first and last level of nesting. Are you supposed to then have a series of empty tab levels in your css file? And then if you remove some of those nests in the markup, you have to remove them in the css? Not nice. The coupling provides no advantage.

</comment></comment></comment></comment><comment><USER15> If you're this concerned about the readability and/or modularity of your code, you should be using a css preprocessor like less/sass/scss. Even if you have css all dolled up like this, it will still take longer to update and manage than it would if you were using mixins and variable declarations.

Yes it is one more thing in the pipeline. But you should be minifying your CSS anyway, so you're already compiling your css in a way.

</comment><comment><USER16> Any "CSS Best Practices" guide should start with "1. Use a preprocessor."

Also, don't use IDs? Really? The article referenced as a source for this claim ends with "Don't stop using IDs, just be aware of where they can cause you headaches and know where to sensibly circumvent them. Anyone telling you not to use them at all is not wrong, but they're definitely not right…"

That's good advice. Understanding how specificity works will make you realize, when designing your Twitter widget, relying on a selector ".tweet a" is unreliable, and use "a.tweet-link" instead.

</comment><comment><USER17> > For each level of markup nesting, try and indent your CSS to match.

Nope.

> Also write vendor prefixed CSS so that colons all line up

Nope.

> When building a new component write markup before CSS

Yes!

> Instead of building dozens of unique components, try and spot repeated > design patterns abstract them; build these skeletons as base 'objects' and > then peg classes onto these to extend their styling for more unique > circumstances.

This is a bone of contention amongst front-end developers. If you're Facebook, and you have a deep and wide site architecture that would otherwise result in masses of duplication, this makes sense (although arguably using CSS preprocessors like LESS or SASS would make even more sense), but these rules do _not_ make sense for small to medium sized sites. If anything, they encourage a thin layer of abstraction on what would otherwise be entirely presentational markup. You were on to something when you said start with your markup: classify your marked up elements by giving them IDs and classes according to _what they are_ and _what they do_ , and then declare rules for how things of that type want to look.

> All components should be left totally free of widths; your components should > always remain fluid and their widths should be governed by a grid system.

Nope. Again, grid systems are something that should be used on a case-by-case basis, according to the nature of the site you're building.

> Heavily location-based selectors are bad for a number of reasons.

Nope. What you're arguing against is a rule that has a high degree of specificity. Naturally there is a sane limit to how specific a selector should be (if you want to avoid specificity wars) but `.sidebar h3 span` is _not_ too specific a rule.

> An over-qualified selector is one like div.promo

Alternatively you might call this a self-documenting selector. If you're going to apply a class to multiple types of element and you want them to all inherit the same rules then sure, don't apply an element name too — otherwise you're adding classes which communicate zero information to a developer unfamiliar with the markup structure.

> Do not use IDs in CSS at all.

NOPE NOPE NOPE NOPE NOPE. Understand specificity rules. Write good selectors. Don't outright _ban_ IDs just because you're not careful enough to write clean CSS.

> As a general rule, all layout and box-model rules can and will work without > an IE stylesheet if you refactor and rework your CSS.

Hahahahahahahahahhaa.

I'll echo comments from others here; these are _not_ 'best-practices' — they're just a set of arbitrary rules that you might find work for you, but you might find they don't. I'd argue that if you enforce these vigorously, your projects are succeeding in spite of these rules, not because of them.

<comment><AUTHOR> Catch all response:

 _This document is a personal one, and for use at my place of work. I decided to share it in the hope that it might be useful to others but if you disagree with anything please remember; this is a document for me and Sky. You do not have to follow the advice given, nor do I provide any guarantee._ — [https://github.com/csswizardry/CSS- Guidelines/blob/master/RE...](https://github.com/csswizardry/CSS- Guidelines/blob/master/README.md)

> Nope.

Fair enough.

> Nope.

Fair enough.

> If you're Facebook, and you have a deep and wide site architecture…

We're not Facebook, but we are big.

> Nope. Again, grid systems are something that should be used on a case-by- > case basis, according to the nature of the site you're building.

Okay, as mentioned this is doc used largely at my place of work where we do use a grid system. For places that don't use one then this basically means 'don't apply dimensions to components; leave structure to parents and wrappers'. Hard coding dimensions on components should be avoided at all costs.

> Nope. What you're arguing against is a rule that has a high degree of > specificity.

I'm not. Heavily location selectors hinder flexibility; components should not rely too heavily on where they live, they should be movable as easily as possible. Shorter, less location-dependent selectors aid this.

> Don't outright ban IDs just because you're not careful enough to write clean > CSS.

I believe I've got my CSS nailed, thanks. IDs will only ever hinder a CSS developer; they offer zero benefit (where CSS is concerned) over a class, thus why would you ever bother using them? If all they can do is harm then just cut them out; even the most careful developers can get tripped up by the overly specific nature of IDs.

> Hahahahahahahahahhaa.

I've just finished the rebuild a massive front-end, the project as a whole took over a year. Number of IE stylesheets: 0. It can be done.

<comment><USER17> > This document is a personal one

Then they're implicitly not 'best practices'.

> We're not Facebook, but we are big.

Then it's possibly appropriate. I remain unconvinced _even in large projects_ but I do think CSS is lacking some important features that would make this kind of practice redundant; the kind of things that LESS and SASS provide, like variables and mixins.

> Heavily location selectors hinder flexibility; components should not rely > too heavily on where they live, they should be movable as easily as > possible.

This again makes presumptions about what kind of site you're building. If you're aiming for heavily modular, reusable components where you'll be repeating markup patterns throughout, it may be more appropriate. Nonetheless, the example you cited looked like a small, common pattern that is easily self- contained enough to be reused in this way.

> IDs will only ever hinder a CSS developer; they offer zero benefit (where > CSS is concerned) over a class, thus why would you ever bother using them?

Specificity is an important part of the cascade, and a tool in your box. Being able to target an element with a higher priority than another without needlessly complicating the selector is a feature I wouldn't voluntarily give up just because of some nebulous claim of harm they might cause. Another reason is the same one I don't agree with stripping off element names; they are self-documenting and give developers clear, unavoidable signposts about the nature of the elements they're targeting.

> I've just finished the rebuild a massive front-end, the project as a whole > took over a year. Number of IE stylesheets: 0. It can be done.

Every project is different. Some will accept layout degradation in older browsers. Some won't. Some will demand extravagant layout effects that require extra time and effort to get working well in IE6-8. To suggest that IE- specific stylesheets are something you should be striving to omit is to needlessly burden developers with (potentially) unreachable goals.

That's the crux of my problem with these 'best practices' — developers who've yet to spend a lot of time thinking about how to structure their CSS well could come across these and head off in all manner of wrongheaded directions. Maybe that's why there aren't any universally agreed-upon CSS best practices beyond more simple techniques; the general rule I take with me is 'YMMV'.

<comment><AUTHOR> > Then it's possibly appropriate.

It's definitely appropriate.

> This again makes presumptions about what kind of site you're building.

It doesn't matter whether you're building Facebook or the site for the window cleaner two doors down the road; you __never __want issues with maintenance, ever. Make sure you can move a person's wall post to a new location without issue, make sure Bob the window-cleaner can move a testimonial from the footer to the sidebar without issue. Size of project is wholly irrelevant.

> Specificity is an important part of the cascade.

It is, and an ID is the quickest way to f#&k with it. As is qualifying your selectors. You're tying yourself to commitments that you might not want to keep.

The things you are arguing _against_ are the most fundamental in _helping_ build maintainable websites.

<comment><USER18> If nothing else, the discussion you have sparked will serve useful for those of us that are clueless. I've even saved this thread locally to revisit once I feel knowledgeable enough to come to my own conclusions.

</comment></comment></comment></comment></comment><comment><USER19> 2 things I would change.

1\. There should never be a css reset, normalize is better.

<https://github.com/necolas/normalize.css> or with IE6/7 junk removed: <https://github.com/CoryMathews/normalize.css>

2\. Structure the file in the method mentioned

<http://smacss.com/book/categorizing>

"So there would be 5 basic areas in your stylesheet.

Base Layout Module State Theme"

<comment><USER20> Thanks for the normalize link. I learned more about various browser inconsistencies from their comments than I have from months of self study.

</comment></comment><comment><USER20> I'm a relative newb at CSS as I just launched my site last October... I'm mostly self-taught and I LOVE reading stuff like this. Can I beg you for a response?

 _> All components should be left totally free of widths; your components should always remain fluid and their widths should be governed by a grid system._

Okay. I just got away from fixed widths and I like it, so I'm on board so far....

 _> Heights should never be be applied to elements. Never ever set heights on ps, uls, divs, anything._

Okay, but here's where I'm lost. I learned somewhat early on that for a container that will contain anything other than text, you should do something like:

      .container{
          height: auto !important;
          height: 100px;
      }

Supposedly this ensures that the page is pre-rendered okay before images and such are loaded. It may have been an IE6 workaround for something that I don't use anymore... whatever the reason it's still in my code, is it some rubbish that I should do away with?

<comment><AUTHOR> I've honestly never heard of that being advocated; I'd drop that ASAP if I were you. If you want to ensure there is no page jump as images load then simply give the images width and height attributes :)

H

<comment><USER20> I do that already because that just makes sense, but I've been working to clean up my super-newb CSS recently and I'm trying to make it more manageable. I've been using trial and error for the stuff I'm unsure of but that one says it's !important and I didn't want to tempt fate. :D

I'll cut it and see what happens.

</comment></comment></comment><comment><USER21> Welcome to the dark ages of CSS3! Where you have extremely emotional documents like this one, instead of programmer specs to follow. Does lining up colons have anything to do with anything? Of course not.

The reason we're in the dark ages: we have a subset of front-end designers that are extremely emotional because their code is on display for all to see (View Source). So they take it very defensively, even tho most coders worth their salt aren't 'Emotional About Their Code'.

Also NEVER use pixels. For devices like the 2048pixel width iPad, your so- called Web 2.0 designs with static bitmaps are old school.

In the coming years, all of your graphics will be CSS3 graphics for all header graphics, backgrounds, etc. Bitmap is just too old school for multiple DPI requirements.

Currently you have to rely on an emotional HTML/CSS ninja to get anything done. Soon the CSS3 graphics will be beyond 'lining up colons' and be software generated. I can't wait. Maybe then the whining will end.

</comment><comment><USER22> I don't want to see any advice about CSS from someone not wanting to see IDs. This is beyond stupid.

<comment><USER13> That one really bewildered me too. Suddenly there's no motive for having a unique element on a page, and styling it's children accordingly? Nonsense.

<comment><USER23> I recently worked on a project with a relatively new to CSS developer, and I forgot how much people rely on IDs. I almost gave that person a blanket statement to not use IDs, but I guided him towards reusable classes instead.

It all boils down to reusability though. If you have an ID, say for a #promoCol, sure, there may only be 1 promo column on the page now, but what happens when the client/designer says, hey we need a promoCol on the right side as well? Do you go back and refactor #promoCol to .promoCol (as it should have been originally, IMO), or just add #promoCol2?

Maybe a column is a bad example as you might be able to deduce ahead of time that there MIGHT be more than 1. But you could say that of just about any element on the page. Theater was mentioned, but I've worked on sites where we had to add a second theater second to a page (yah...I know, wasn't my call.)

I would even go so far as to say, if you use IDs in any significant factor in your CSS, you are doing it wrong. And it has absolutely nothing to do with knowing how to work specificity, and everything to do with the additional flexibility not using IDs provides you (or your co-workers) both during an initial build and down the line when maintaining or updating a project.

<comment><USER24> _Do you go back and refactor #promoCol to .promoCol?_

Yeah, that's exactly what you do. Just because your new dev doesn't know how to refactor (and it's hardly even refactoring, it's like a two-line diff) doesn't mean we all shouldn't use IDs.

IDs have an extra bit of self-documentation when you use them - when I see #promoCol, I know instantly that there's just one promocol, and I don't have to worry about breaking the look of another promocol while I'm fiddling with the CSS in there. If there's a class, you don't know how many things it applies to until you've done a grep over your project.

</comment></comment></comment></comment><comment><USER25> I also work for Sky (different part) and these guidelines seem mostly sensible to me, so much so I may recommend them to my team, with some caveats:

\- Have no problem with IDs if they're used correctly for unique items. The cascade should not be an issue. \- Formatting of css and vendor prefixes - these aren't guidelines they're personal preferences. There's no appreciable maintenance benefit for any of them in my opinion. Each to their own.

I am in favour of dashes too, On a big project you might spend literally 100s of hours writing or editing css, using dashes will save you enough time in keystrokes to have a an extra long lunch by the end of it.

</comment><comment><USER26> His advice for using 'short selectors' for performance is just plain incorrect.

<http://code.google.com/speed/page-speed/docs/rendering.html> is a great page describing CSS performance.

Selectors like '.nav a' would not be allowed at all as a part of my team's CSS best practices, as it is a descendant selector that uses a tag as the key. (On the other hand, most sites, expecially non-dynamic sites, don't need to optimize CSS at all, as there are usually other things which are the bottleneck)

</comment><comment><USER27> > We use hyphen delimited,

> lowercase selectors: .thisIsBad{},

> .this_is_also_bad{} but .this-is-correct{}.

.

I am a fan of mixing Camel Case and Dash Separated. I use Camel case for specific elements.

eg. ".addClientButton"

However, I use a mix of Camel Case and Dash Separated for IDs specifying a specific element in a specific part of the dom.

eg. "#newClientPanel-addClientButton"

.

I learned this method from looking at how apple.com does their styles on their check out screen. However, it doesn't look like they don't do it this way any more.

How do you handle making unique IDs? I guess I could switch to something like

.add-client-button and #new-client-panel_add-client-button

<comment><USER28> I don't like .this-is-correct{} because sometimes you have the same variable name in Javascript too, where dashes won't work.

<comment><USER29> Dashes map more cleanly to existing CSS syntax, eg nth-child, background- color, etc. Much like camelCase looks more like Javascript than my_variable.

</comment></comment></comment><comment><USER30> Why "We use hyphen delimited, lowercase selectors: .thisIsBad{}, .this_is_also_bad{} but .this-is-correct{}"? I understand if the point is about the styles itself having hyphens, like padding-bottom, but it breaks the complete expression selection with ctrl+arrows (or even with the double mouse click) which I find much more annoying than using underscores instead of hyphens. I'm biased though, I prefer underscores to camelCase anytime (I do obey whatever is the rule on any project).

<comment><USER31> The reason I would advocate using hyphens is you should do what the language (standard libraries) do. For example:

        css:
        margin-left, border-bottom (hyphenate)

        javascript:
        getElementById, documentNode (lower camel case)

        ruby:
        each_index, has_key? (underscore)

<comment><USER30> This would be an interesting discussion. I prefer to use the same coding style for the whole project without caring how the original authors of each language did it. I do however understand that the language API follows the original convention so one would eventually break it by following by reasoning. Ex in js: make_element_slide(getElementById('box')).

</comment></comment></comment><comment><USER32> One tiny tip I have is to use underscores in ids and hyphens in classes. That way if I see $(".things-to-find") the fact that "thing-to-find" is not recognizable as a javascript variable gives that much more of an indication that it will be (relatively) expensive. Likewise #doodad_im_styling looks bad in css files since it doesn't match anything else.

Granted I violate both of these principles, when appropriate, but they're there to keep the average case in line.

</comment><comment><USER33> The advice to be explicit when using shorthand is excellent. This has come back to bite me many times (you end up re-writing background and margin declarations to undo your clever shorthand).

The multiple measurement units is cool too: particularly unitless line-height, magic numbers, and relying on parent box sizing.

Great stuff, thanks for sharing this. Couple questions:

Do you find indenting descendant selectors helpful?

For your comments, do you adhere to CSSDoc or any particular convention?

<comment><AUTHOR> Thanks for the comment, I'm glad you like it :) The shorthand one is a really interesting one; it takes while to kick the habit and be purposely more verbose, but you soon get tired of undoing previously accidentally-set styles.

> Do you find indenting descendant selectors helpful?

Oftentimes yes; it can give a new developer more of a clue of the markup structure that a previous developer intended to be used. I can see at a glance that `x` needs to be in `y` but `a` needs to be a sibling of `b`. Of course you could just glean that yourself by looking at and reading all the selectors individually, but it's nice to get an idea of structure at a glance.

> For your comments, do you adhere to CSSDoc or any particular convention?

Nothing official; I have my own habits but no documented standard. I like the look of <http://warpspire.com/posts/kss/> though :)

H

</comment></comment><comment><USER34> > When building components try and keep a DRY, OO frame of mind.

Two different things here. OO can mean having excessive numbers of things (files, objects) to do something that can be done more clearly and consisely without them, and it could be argued that having additional files is less DRY if you don't need to provide the same amount of code. So it is good to be DRY before OO.

</comment><comment><AUTHOR> I wrote a rebuttal

<http://csswizardry.com/2012/03/hacker-news-rebuttal/>

</comment><comment><USER35> `Whilst this is a very timid example, it does help illustrate how a lot of preprocessors' built in 'helpful' aspects actually go against our ideals; .nav li a{} could (and should) just be .nav a{}.`

Not if .nav li a{} and .nav a{} are specifically meant to be differing nests. They could but might not 'should'

<comment><AUTHOR> > Not if .nav li a{} and .nav a{} are specifically meant to be differing > nests.

But in the example they _aren't_ differing nests; if you change your example then obviously it isn't correct any more.

<comment><USER36> If you're truly reusing the example from above, shouldn't it be:

      .nav {
        li {}
        a {}
      }

If that's not the case, why is your first "nested" pure CSS example this:

      .nav a {}

instead of

      .nav li a {}

<comment><AUTHOR> Because `.nav li a{}` is overly specific; that's my whole point.

 _EDIT_ Hold on, I think I get you… My example was an example of someone writing something incorrectly. An example of it being written correctly would indeed be:

        .nav{
            li{}
            a{}
        }

<comment><USER36> Cool, we're on the same page. =)

</comment></comment></comment></comment></comment><comment><USER37> Could someone perhaps take the relevant suggestions from this HN discussion and modify a fork of the repo? I would do it myself, but I don't think I am proficient enough at CSS to sift through the comments effectively.

<comment><USER38> that's good idea. i have written a bunch of my own guidelines which i'm going to beef up with some of these. the problem with creating a list of the 'relevant' suggestions is that it differs for every developer, project and company. someone's 'relevant' may be another's 'pointless'

</comment></comment><comment><USER38> Some great general rules here, although I don't employ all of them personally, will definitely be using some to beef up my own guidelines. Cheers!

</comment><comment><USER39> Might as well add a "formatting" section and include some tips on ways to format css. Also tools like procssor.com or cleancss.com

</comment><comment><USER40> Thanks for this. This is extremely useful for non-designers.

</comment><comment><USER41> you lost me when you banned IDs. learn how to use specificity properly before claiming you have best practices.

<comment><USER42> He does know how specificity works, I guess. But he is talking about reusability and inheritance. Still I find the claim way too harsh. I use id's in my CSS occassionally. For #wrapper or #carroussel maybe. It it premature optimization to (re-)write everything to classes. Your HTML should be leading.</comment></comment>


Java Grinder: Compile Java bytecode to microcontroller assembly - <AUTHOR> https://github.com/mikeakohn/java_grinder#java-grinder <comment><USER2> I am reminded of writing Java "Midlets", (J2ME - Java 2 Micro Edition) back in the early 2000's. These ran on the then-common flip-phones and candy bar phones. Predating smart phones and esp. iPhone.

I made my own "asteroids" game. Real Java code, written using Eclipse. The Java had some limitations. No floating point was the most notable. So there were some widely circulated Java libraries that did Trig and related functions using integers, offset by some decimal fraction so that about half the bits were right of decimal point. I simply drew vector graphics on each update frame of the game. An asteroid, for example, was a center point with a number of random points around it, connected by lines. Thinking of these points as r-theta instead of x,y made it simple for the asteroids (and the ship!) to rotate using simple sin/cos to convert the r-theta points into x,y for rendering the frame.

The whole thing compiled to a midlet of 21 K bytes. It ran pretty universally on flip phones of the time. The 1 and 4 keys on keypad controlled ship rotation. The 3 key was to fire.

No sound.

Now, how unrealistic is it that today's micro controllers could run a version of Java. Especially if a few J2ME type limitations were imposed.

<comment><USER3> > offset by some decimal fraction so that about half the bits were right of > decimal point.

Seems weird not to use binary fixpoints. Can't really see the point of using a decimal point instead of a binary point/radix.

<comment><USER4> I think they're talking about an implied decimal point, i.e. fixed point math.

<comment><USER5> Yes, but the question is in part why use an implied decimal point instead of an implied binary point. You can do fixed binary point just by treating everything past a given bit as the fraction - it's simpler.

The main reason would be differences in expected precision/rounding behavior depending on how many bits you use past the binary/decimal point. E.g. if you use 4 bits past the point, you can represent 1/10's in decimal but 1/16's in binary. But while the binary representation offers more precision, it allows you to represent _different_ values. If you e.g. want to represent 0.2, a single decimal represented in 4 bits will allow you to do that, but with 4 bits past a binary decimal point means you'll need to round down to 0.1875 (3/16) or up to 0.25 (4/16).

<comment><USER6> if your dealing with currencies you can't use fractions. Unrepresentative decimal values (.33, .34, .66) are non trivial without many bits of fraction space.

Your IEEE standard for floating points has a lot of complex rules and standard binary layouts to ensure these values are represented.

You end up needing a lot more space and rules than just diving by 10^3

<comment><USER5> Of course you can use fractions. You can't reasonably use _binary_ fractions. But the discussion is about fixed point representations, not floating point anyway.

</comment></comment></comment></comment></comment></comment><comment><USER7> Some ARM devices can execute Java bytecode directly: [https://en.wikipedia.org/wiki/Jazelle](https://en.wikipedia.org/wiki/Jazelle)

It never really took off.

<comment><USER8> It was kind of a half baked idea. At best, it could lower the small overhead of the interpreter loop for a subset of Java bytecodes. At some point you'd need a JIT to get better performance, and that JIT would want to target real ARM code (so you can do things like register allocation)

One cool thing about Java on little processors is that you can get memory safety without an MMU. But again at some point you're going to want an MMU anyway...

<comment><USER9> That is the whole premises of language OSes, type safety over MMU.

But it is as you say, given enough memory to manage or the usual performance tricks for GC/JIT, and the MMU will be needed.

</comment></comment></comment><comment><USER10> I understand with class methods you can just jump to them, but how are class instances treated in Java? Where are they stored in a JVM? I assume the templates for them are stored in the constant pool, but I'm having a hard time finding exactly what is stored and then from there, how they're instantiated.

Edit: In an attempt to answer my own question, I came across this blog [0] which is helpful.

0\. [http://blog.jamesdbloom.com/JVMInternals.html#constant_pool](http://blog.jamesdbloom.com/JVMInternals.html#constant_pool)

<comment><USER11> Here's an excerpt from Bruce Eckel's Thinking in Java (4th Edition), pg. 42-43

 _The stack

This lives in the general random -access memory (RAM) area, but has direct support from the processor via its stack pointer The stack pointer is moved down to create new memory and moved up to release that memory. This is an extremely fast and efficient way to allocate st orage, second only to registers. The Java system must know, while it is creating the program, the exact lifetime of all the items that are stored on the stack. This constraint places limits on the flexibility of your programs, so while some Java storage exis ts on the stack—in particular, object references—Java objects themselves are not placed on the stack.

The heap

This is a general-purpose pool of me mory (also in the RAM area) where all Java objects live. The nice thing about the he ap is that, unlike the stack, the compiler doesn't need to know how long that storag e must stay on the heap. Thus, there's a great deal of flexibility in using storage on the heap. Whenever you need an object, you simply write the code to create it by using new, and the storage is allocated on the heap when that code is executed. Of course th ere's a price you pay for this flexibility: It may take more time to allocate and clean up heap storage than stack storage (if you even could create objects on the stack in Java, as you can in C++)._

Not sure if this answers your question. I've only gotten through about 5% of the book, and I can't tell from the table of contents, if he ever goes into more detail on these explanations.

</comment></comment><comment><USER4> More information and example output here: [http://www.mikekohn.net/micro/java_grinder.php](http://www.mikekohn.net/micro/java_grinder.php)

Note that it's just a subset of the bytecode spec (no GC, objects, virtual methods) but might be a nice way to get up to speed on a CPU architecture. I used the SDCC C compiler similarly to learn Z80.

<comment><USER12> How does no GC work? Static arrays?

</comment></comment><comment><USER13> Nice project. This already gave me the motivation to look more into Java bytecode. Does anyone know a good resource which explains Java bytecode?

<comment><USER14> [https://docs.oracle.com/javase/specs/jvms/se9/html/index.htm...](https://docs.oracle.com/javase/specs/jvms/se9/html/index.html)

</comment></comment><comment><USER15> Great name. I'd really like to see this used to convert Java Beans to assembly :)

</comment><comment><USER16> Nice ! But without GC I guess it's just a nice hack and will have a hard time being actually useful

<comment><USER17> GC doesn't have to be complicated if performance isn't an issue.

Also, escape-analysis could be used to run this without GC in trivial cases.

<comment><USER5> As an example of how simple, as I think people tend to see gc as complicated and scary, a simple tri-color mark and sweep gc in pseudo code:

        push_registers_to_stack()  // Simplifies dealing with roots - you can now ignore registers
        // These are the roots:
        // (grey objects are directly referenced from a root, but have not yet been scanned for pointers)
        for_each_stack_value { mark_grey }
        for_each_bss_variable { mark_grey }
        // We then keep iterating over grey objects, scanning the values of those objects for further
        // pointers (which we mark grey), and mark "finished" objects black:
        while (ob = grey_list.shift) {
            for each pointer in ob {
                if white: mark_grey(pointer);
                mark_black(ob)
            }
        }
        // Now any objects you haven't touched are still white (and unreachable), and thus garbage:
        for_each_object {
            if white: free
            else: mark_white
        }

The above is inefficient, but it takes very little space to implement. If you know precise object layout and takes it into account when scanning, it's also precise, if not it's conservative (it may leave garbage if values in memory looks like pointers). Downside is that it is "stop the world", so if your heap is big, it'll cause noticeable pauses.

Simple GC's are easy.... Fast/good/efficient GC's on the other hand...

<comment><USER18> The other downside is fragmentation(which is also why even embedded native tends to be static/up-front allocation based).

<comment><USER5> That's true, and certainly if you can avoid dynamic allocations, do.

But you can actually get "halfway" to a partially compacting gc very easily too if memory use is a bigger concern than performance and you want to avoid fragmentation:

Set a (small) fixed size for all objects. It can be anything from a single pointer to any data that will be present in all objects. E.g. you might have class pointers and flags and a fixed number of bytes for auxiliary data. If any class needs more instance data, you make a pointer in that primary layout point to space in a secondary heap.

Now compacting the secondary heap is easy: Just copy into new buffers and deallocate the old and update a _single pointer_ per object. You can do that by a single pass through all allocated objects, or you can do something more complex.

Compacting the primary heap is still messy (you'd need to identify all sites pointing to each object), but if you chose a small size for the primary objects there's less reason to do so, as while it is still possible to create pathological allocation patterns, unless the application reaches a high water mark and then frees a huge number of objects that it then never need again, any empty space left behind can always be perfectly filled by new primary object allocations, and hopefully each such object is fairly small.

If you want to, though, you can also compact auxiliary data (the "secondary heap") into holes in the primary heap when there's a good enough fit. E.g. on top of the steps I outlined:

For each object, if there's an auxiliary data pointer, check if there's a suitable hole (keep lists by "hole size" for example) in the primary heap. If so, move there. If not, copy to end of new secondary heap. Update source pointer.</comment></comment></comment></comment></comment>


Moral Effects of Socialism - <AUTHOR> http://marginalrevolution.com/marginalrevolution/2014/07/moral-effects-of-socialism.html

<comment><USER2> The idea that the regime in East Germany was an example of Socialism is simply preposterous.

<comment><USER3> East Germany had zero private property, and was governed by the Socialist Unity Party of Germany from 1946 until 1989 ([http://en.wikipedia.org/wiki/Socialist_Unity_Party_of_German...](http://en.wikipedia.org/wiki/Socialist_Unity_Party_of_Germany)).

<comment><USER4> the sidebar of the article you link to says:

Ideology: Communism, Marxism-leninism, Neo-Stalinism

having the word in the name doesn't actually make it socialist.

<comment><USER3> Heck, even Wikipedia lists them as associated terms: [http://en.wikipedia.org/wiki/Socialism_(Marxism)](http://en.wikipedia.org/wiki/Socialism_\(Marxism\))</comment></comment></comment></comment>


Why White Tigers Should Go Extinct - <AUTHOR> http://www.slate.com/articles/health_and_science/science/2012/12/white_tiger_controversy_zoos_shouldn_t_raise_these_inbred_ecologically_irrelevant.html <comment><USER2> _A white tiger that has already been born does not have a vote in the matter and cannot apologize for existing. Humanity has a collective responsibility to care for the two-headed calves and white tigers that we create for our own entertainment, but do we really need to be creating more of the genetic disasters that pull resources away from truly endangered species? There is no good reason to breed another white tiger._

I'm trying to understand the moral implications here. The author paints a very heart-touching and grim picture, and it's tempting to agree. But what happens when you apply this to humans?

<comment><USER3> Did you even read the article? The tigers were intentionally inbred to spread this mutation. There is no analog of this in humans; inbreeding is unnecessary and does no tiger a favor by continuing it.

<comment><USER4> Oh, you mean the way we did so with wolves to create the thousands of dog species that exist today. By this absurd logic, all dogs should go extinct.

<comment><USER5> Dogs are bred to live with humans. Tigers are not.

<comment><USER6> Maybe tigers "should" be? I know quite a few people who would gladly pay for the ability to have a domesticated tiger as a pet...

<comment><USER7> Thing is they're about 100x more dangerous than dogs.

<comment><USER6> But are they 100x more dangerous than the wolves from which domesticated dogs are descended?

<comment><USER8> A tiger on its own, and a wolf on its own? Yeah, probably. Wolves and tigers are both apex predators but wolves are pack animals.

<comment><USER9> And you can only domesticate a dog by hacking its pack instinct to make it follow you instead of another dog anyway. No such hook with a cat.

<comment><USER10> Didn't Siegfried and Roy hack the maternal instinct of female cats to achieve some semblance of domestication? I mean, it didn't work out very well of course, because a cat mauled Roy and nearly killed him by grabbing him by the neck (to drag him to safety, according to them) like she would a cub.

So, I think there _is_ a hook. It's just a really shitty one. Note that the hook for dogs can backfire as well, if they try to assert pack dominance vs. their owner. So we breed really submissive dogs.

<comment><USER9> Tigers and especially lions are somewhat easy, not to domesticate per se but to befriend. I wouldn't really call this a hack the way domesticating dogs was a hack--they just seem willing to occasionally befriend humans the same way ordinary cats do.

Tigers and lions are very confident apex predators, so they don't really have the vicious instinct or the intense fear response that some animals have. So they don't deliberately attack humans. By contrast, leopards and jaguars will kill you out of sheer viciousness, bears will attack you if they feel threatened, and polar bears will attack you because they are hungry and you are made of meat.

The main danger with tigers and lions is that they don't really understand how fragile humans are, so they might accidentally kill or maim you, which happened to Roy.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER11> I asked my wife what she knows about white tigers and she said, "Isn't it some sort of gene that makes them white, and aren't they kinda sick?" Better than I would have said before reading this.

</comment><comment><USER12> As somebody who works for a 501c3... why is there such poor accountability that funding for species preservation is being used on white tigers? If I'm not mistaken, a lot of zoo money is nonprofit money. If we can prove to grant- writers and donors that the money is being used outside of what it was intended for normally the money dries up. Seems like that would solve the problem pretty quickly...

</comment><comment><USER13> If you'd like more in depth look at the "American Tiger", check out the Nature of Things documentary of that title.

<http://www.cbc.ca/natureofthings/episode/american-tiger.html>

It covers everything that's in this Slate article, but actually goes to the trouble of getting opinions from experts in the field of conservation, genetics, etc..

<comment><USER14> It doesn't work from the US. We just get a creepy voice that says, "This content is currently unavailable."

</comment></comment><comment><USER15> Have you seen pictures?

Here's one:

<http://i.imgur.com/LEj1n.jpg>

There's a lot more out there like this.

<comment><USER16> Just a thought: I wonder if we could help the awareness of white tigers by making a meme with a picture of a defect white tiger that look "fun". Similar to all of these [0]. By spreading the awareness of the white tiger more more people seek information on them and hopefully more would be enlighted of their bad shape.

[0] [https://www.google.dk/search?q=animal+meme&hl=en&tbm...](https://www.google.dk/search?q=animal+meme&hl=en&tbm=isch)

<comment><USER17> What do you do then when people decide they are "cute", and we should breed even more?

</comment></comment></comment><comment><USER18> There are less than four thousand tigers in total in the wild. Not white tigers, _any_ tigers. That's shocking.

In a few decades there probably won't be any.

[http://wwf.panda.org/what_we_do/endangered_species/tigers/ab...](http://wwf.panda.org/what_we_do/endangered_species/tigers/about_tigers/tiger_population/)

<comment><USER19> Its true, and maybe irrelevant. There is no place for tigers on a settled planet. We have many uses for land, and letting fabulously dangerous carnivores randomly wander huge tracts is one of the less important ones.

I know there are ecological arguments. Maybe those are meaningful some places, but for an Iowa farm boy they are ludicrous. This continent (North American great plains anyway) has been 'reformatted' several times in the last 500 years. There has been no permanent catastrophic ecological collapse; no runaway doomsday scenario has occurred.

Sure there was a dust storm in Oklahoma (ok, hundreds of them) in the '30s, which drove the science to understand and tame them, which has been done.

We are perfectly capable of 'terraforming' our own planet, and are doing so at an accelerating, perhaps unstoppable rate.

I can only conclude, tigers are doomed. Zoos are amusing; you may argue they're cruel or whatnot but its the only place your grandchildren will be viewing tigers at all so factor that into your outrage.

Anyway, with genetic programming we'll be able to have dwarf pink polka-dotted tigers that fetch your slippers if you want, so really what does it matter? The accidental population of our planet when we 'discovered' it are really of no consequence, compared to what we will be doing with it in the future.

<comment><USER9> There has been a number of mass extinction events in world history, the most well known being the extinction of the dinosaurs. That much impact on an ecosystem all at once had massive, unpredictable effects.

At current rates, we are currently experiencing a mass extinction event worse than the one that killed the dinosaurs. I am _not_ fond of making large, random changes to complex systems that affect us.

<comment><USER20> > At current rates, we are currently experiencing a mass extinction event > worse than the one that killed the dinosaurs.

Interesting assertion. Got a citation for that?

</comment></comment></comment></comment><comment><USER21> I thought the white tigers were Siberian tigers. Thanks for the information.

</comment><comment><USER22>
      Many of the venues that display white tigers have a long
      history of shading the truth about their mutants.

IIRC in the Singapore Zoo (the last one I went to this summer) had some extensive information about the origins of the white tigers, no shading this. Would've been interesting to see some more examples of different takes of the zoos in the article.

</comment><comment><USER23> The real crime is misinformation. If everyone read this article the problem would go away.

<comment><USER24> Most people are aware that animals in circuses don't live a happy life, yet they choose to go see them.

<comment><USER25> I was under the impression circuses with animals were dying out, at least in civilized countries.

</comment></comment></comment><comment><USER26> I don't accept the premise that whatever man touches is somehow automatically tainted or corrupted. Nor do I accept the premise that man is somehow unnatural. All things, including men, obey the laws of thermodynamics.

There is no problem with man changing the course of nature. Why not release some white tigers and actually see how they evolve, instead of simply assuming that they won't thrive?

<comment><USER27> Where is the assumption? How will a tiger that can be easily spotted, is cross eyed and has problems including kidney failure supposed to survive in the wild?

<comment><USER26> From an evolutionary standpoint, all that matters is that the tiger is able to reproduce. If it isn't, an attempt to introduce the breed somewhere will fail. No big deal.

...unless you hold the tiger in your mind in the same way you would your own house cat. But that's warped, because a house cat can't and won't eat you.

I still think the claims of all these problems with captive tigers are overblown. Animals in the wild have plenty of health problems. The difference is that there aren't nearly as many people scrutinizing and treating them.

<comment><USER28> Except there are plenty of healthy wild animals and zero healthy white tigers. So, in the wild ALL white tigers are unable to survive long enough to reproduce.

</comment></comment></comment></comment><comment><USER27> After reading this, I googled to confirm that white elephants, which I thought to be natural too, are indeed natural. They are.

</comment><comment><USER29> Wow. All these days I was thinking that white tiger is a natural habitant of siberia.

</comment><comment><USER30> The question here, as I understand, is not whether breeding programmes are ethical, but whether misleading the general population with false information is ethical.

Is it ethical to ask for donations or ticket prices to zoos by giving people the impression that their money will (partially) go to conservation efforts, while the money is spent to breed animals that cannot survive in the wild but only for "marketing" purposes?

</comment><comment><USER31> This article clarified in my mind what it was that had been bothering me about slate.com. It is tabloid for "sophisticates".

</comment><comment><USER32> Slate keeps impressing me with thought-provoking articles.

</comment><comment><USER33> Or they could do what cattlemen do: systematic outbreeding, and culling of defectives. Excessive inbreeding is not the only choice.</comment>


How Computing's first 'killer app' changed everything - <AUTHOR> https://www.bbc.com/news/business-47802280 <comment><USER2> Visicalc intrigues me because it seems like one of the few apps that seems inevitable, but still revolutionary. Once we had computers it just made perfect sense to have them fill out spreadsheets for us.

It's also one of the few digital products that has almost entirely overwritten memory of its predecessor. Digital books haven't made us forget about physical ones. Online encyclopedias haven't erased libraries. But when you ask someone to make a spreadsheet, they will of course think of an excel sheet.</comment>


Not everyone is going to like the thing you made, and that's okay - <AUTHOR> https://wilwheaton.net/2013/12/not-everyone-is-going-to-like-the-thing-you-made-and-thats-okay/ <comment><USER3> I find human opinion fascinating, and look forward to the glorious future when we can do better than up/down arrows.

Looking at a site like Rotten Tomatoes, where the metric is "professional reviewer thought thing was at least decent" and seeing that there is surprisingly little agreement even on such a simple metric (even a terrible movie, like Season Of The Witch, has a 10 so 10% of the reviews like it; even a great movie, like wall-e, only has a 94 - so somebody didn't like it - <USER2> most movies are in between with lots of critics liking and lots of critics disliking the exact same thing. Yet we still try to arrive at a truth by considering all their opinions equally as a group. This is obviously doomed to failure.)

It's even more clear when you think about something more abstract, like a favorite color. My favorite color is purple. If yours is yellow, does that mean I'm wrong? Clearly there isn't an obvious objective "This Is Good" when it comes to taste or opinions. Why then is up/down arrows the current state of the art?

I know Netflix has managed to do more by looking for similar reviewers and weighting their opinions, and Pandora does audio classification, but I'm not aware of this concept catching on well in other areas, and I particularly don't know of it being applied to multiple things at once - if I want a recommendation about a new movie that isn't on Netflix yet, or if I'm tired of the repetitiveness of Pandora's stations, their clever algorithms don't help me a bit beyond their limited walls. I don't know of a site like reddit or hacker news or videosift trying to capture more than 'good/bad' for evaluating links on the web. I don't know of a site that is really trying to help me pair my taste with other reviewers, so that I can get personally curated content and we can end up with a world that recognizes some people love action movies and others love romantic comedies and recommending a movie for me to see should take that into account. How wonderful will it be when there is finally a site that can suggest I should read these three articles because -I- will find them good, maybe I should be sure to catch Pacific Rim, and a new band I might like has a video out; while giving completely different recommendations to my sister, without trying to limit to an objective non-relative definition of "good", because we're talking about taste and opinions aren't wrong.

When one of you smart folks makes that site, please let me know.

<comment><USER4> Sounds like you want a multi-dimensional rating system that works. Patience, it's coming. We're focused on doing it right.

1\. Sign up at [http://tinj.com](http://tinj.com)

2\. ...

3\. Profit... I mean, we'll let you know when we launch.

<comment><USER5> ranking / rating done right/optimally seems to be a highly problem specific challenge. What problem domains are you focusing on?

<comment><USER4> Starting with entertainment for a variety of reasons.

<comment><USER5> good luck! look forward to learnign more when you get it out

</comment></comment></comment></comment></comment><comment><USER6> You should also remember that anybody giving you a negative reaction might just be having a bad day for totally different factors. This is especially true on social media, where it's so easy to blow off some steam by writing a snarky remark without thinking about how it's going to be interpreted.

So whenever someone isn't very nice with me, I prefer to assume that they're a nice person who just happens to have bumped their toe into a table leg or something.

<comment><USER7> _So whenever someone isn 't very nice with me, I prefer to assume that they're a nice person who just happens to have bumped their toe into a table leg or something._

Nice persons tend to apologise, if they don't apologise they are probably arseholes.

<comment><USER8> I think that's probably situational. There could be aspects in which they couldn't apologize. If the person really is in a bad mood, it's unlikely that they'll turn around a few minutes later, suddenly feeling better and then being apologetic. And it could also be the case that the person was just a random person who could never contact you again to apologize.

I really like the article overall. It seems somewhat like common sense, and even reading it, I know the next time I bump into a situation like this, it'd still be difficult for me to see it this way.

<comment><USER7> Well, I tend to apologise straight away. Perhaps I've spent a lot of my life surrounded by arseholes... Yes, I have spent my life surrounded by arseholes.

</comment></comment></comment></comment><comment><USER9> Six months ago I created an e-mail course for teams that are using Agile, Scrum, Lean, and Kanban. I called it the "Agile Tune-Up Kit" (shameless plug: [http://bit.ly/15sz0Pl](http://bit.ly/15sz0Pl))

Man that was/is a freaking lot of work. Over 30 mini-classes so far. People get one each week. When people sign-up, I ask them for comments, and I hand- reply back to why they're there. When people unsub from the list, I apologize and ask what I could have done better.

I am learning this lesson, but very slowly. Whenever somebody unsubs from the list, I always look at what the last email they got was. Can I make it better? Am I writing the series too long/too short/wrong reading level/to the wrong audience? It's enough to drive you nuts.

But it's been a great lesson, because with any email list, you're naturally going to lose people. It actually doesn't have to have anything to do with what you're creating. Maybe they don't have time to read it any more, or their job changed, or they just clicked on the spam button on Gmail because they had too much stuff in their inbox. Yes, it _might_ be something I can control. Or it might not. All I can do is do the best job I can, ask for feedback, and move on.

Every second and every bit of emotional energy I spend worrying about what I can't control is taking away from the things I can control. Creating things and interacting with people ain't like programming. Things aren't boolean, there are tons of hidden variables, and "debugging" doesn't work the way it does in code. Tough thing to learn.

</comment><comment><USER10> I've had multiple projects of mine on the front page of HN, and while I got lots of upvotes, there have been many negative or overly harsh comments.

Once my business hit substantial revenue, I realized it didn't matter, that it was more important to make a few people love us than to make everyone like us.

I also realized that a lot of hackers on HN are having a hard time making their own business because they don't realize people like things that they might not. Taste is huge.

</comment><comment><USER11> > When I was younger, I would have completely ignored the first one, and > obsessively focused on the second one to the point of feeling shitty about > myself.

That made me sad to hear given how much hate the character Wesley Crusher got.

</comment><comment><USER12> I really like the idea that a product has legs if people love it or they hate it. If everyone is in the middle, they're apathetic, and you're not on to anything.

I'm relaunching a website I've been running for years and I'm relentless about customer service and community management. I don't know how EVERYONE is going to react that's already a member of my site, but I know some people are going to love it, and that's way better than thousands of apathetic users with only a tiny fraction coming back every day. I can't wait.

</comment><comment><USER13> Something that always helped me:

"Most people are focused on themselves. So whatever bad interaction you have with them, is mostly a reflection of them, instead of a reflection of you."

</comment><comment><USER7> One of my goals in life is to write a piece of software that everybody hates. If those same people depend on it to survive, that is a hugely satisfying bonus.

Bill Gates did the same thing, he must got off on that.

</comment><comment><USER14> And if you made something and are trying to make it perfect, make it good and get it out there. It is better to publish to not, and there will be haters. But there will be fuel from the ones that like it, and some good insights from critical ones. Learn more about what people like and get better.

</comment><comment><USER15> People like the things I make, but organizations don't.

</comment><comment><USER16> I've had this with this my personal take of 750words ( can be found here and it's in french so I doubt it's interesting to anyone here : 3pages.fr ), I'm getting a lot of feedback :

* There are people who love you because your application is changing their life

* There are people who gives you pertinent feedback.

* There are people who just don't get it and are suggesting core modifications.

I often ignore the last kind of people because I have a principal view on how I want things to be and making something should be about that. You cannot please everyone and you should focus on pleasing you first.

</comment><comment><USER17> Disappointing truth be told, Theodore Sturgeon's observation certainly applies to programmers talking. Mostly because the same ratios apply to the quality of programmers listening.

Most programmers are quick to pigeonhole you and what you say. Pay attention to their conclusions and note how careful they are(n't) about gathering enough info to arrive at those conclusions. Look for signs to see if they are skeptical of their own mental models.

This is how to pick who you should work with.

</comment><comment><USER18> I think this is true for anything we put out there for the world to see, whether it be software, prose, music, video, photos, etc.

I have had a hard time dealing with some of the feedback I've gotten with the things I've written, whether it be on HN or on my blog, but I'm slowly learning to be okay with the fact that no, not everyone will love what I have to say :P</comment>


Ask HN: What are good books for Authentication and Autorization? - <AUTHOR> Hey, guys, I wanted to learn in-depth about auth and authorization, web tokens, cookie, session, etc. mainly in ASP.Net Core but in general overall. Identity server, OAuth 2, SAML and others? <comment><USER2> Security Engineering 2nd edition by Ross Anderson. [https://www.cl.cam.ac.uk/~rja14/book.html](https://www.cl.cam.ac.uk/~rja14/book.html)</comment>


Why you'll never see 200Mbps from a 200Mbps 'Net connection - <AUTHOR> http://arstechnica.com/tech-policy/news/2009/05/why-your-cable-internet-connection-gets-slow.ars

<comment><USER2> Seems to be just a marketingn ploy by Virgin... like a manufacturer of auto tires saying, "tested to 400 mph." :/

<comment><USER3> Not really, most of that post is FUD from cable competitors in the US (ADSL and fibre-to-the-home providers). I'm not sure how much of it even applies to Virgin Media as their network has a great deal of fibre-optics in it, though not the last mile.

The part about home equipment, where the falling standards of Ars journalism really shows, is just restating "640K is enough for anyone" repeatedly, to the point of absurdity. It appears that to actually have a computer connected physically to the internet via ethernet is some wacky use case and the very thought of providing internet access faster than an 11b wireless router is crazy talk.

In the UK it is the ADSL providers that market misleadingly, they all use weaselly "up to X Mbp/s" language, and for maximum speed you need to be physically located near to the exchange, it drops the further away you are.

Virgin Media have consistently provided whatever you pay for, even as it has increased from less than 1Mbps to 2, 5, 10, 20 and now as we speak 50Mbp/s is in the middle of deployment. I see no reason for their talked about 100 and 200 Mbp/s rollouts to be any different.

A bigger issues is when can they roll them out to the whole country as they always talk about the next big step publicly before having to deal with the very real problem of bringing the whole network up to the level neeeded. By the time it arrives there will be some who can take advantage of it, those who can't or don't want to will be able to pay less for lower tiers of service, generally the stick to three tiers and users on the bottom tier gets bumped up for free, which probably has a big impact on usage too depending on the ratio of users on different plans.

That's not to say Virgin don't have various other things you could complain about but it seems unfair to complain about misleading speed numbers when that is something that (at least from a UK perspective) they are on the right side of.

<comment><AUTHOR> I think you're very lucky if you're not seeing any contention at peak times. In highly populated areas (central Edinburgh and Livingston in my personal experience), there is huge congestion on the local loop at peak times.

I've not got any bandwidth test results to show this but a friend of mine in Edinburgh does log ping times:

<http://cress.dom0.org/cgi-bin/smokeping.cgi?target=DSL>

The contention at evenings and weekends is very obvious from these graphs.

</comment></comment></comment><comment><AUTHOR> This also has some relevance to this post:

The Internet sky really is falling (networkworld.com)

<http://news.ycombinator.com/item?id=597699></comment>


My Weekend Project: Verbal Juicer (Text-to-Speech tour of HN, GitHub, etc) - <AUTHOR> http://verbaljuicer.com/

<comment><AUTHOR> I made most of this last weekend and polished it a bit over the past couple days. You need to install both the Extension and the Plug-In... this was the only way to make it work.

You can write your own mini apps for any website using javascript. If you create one for a public website, send it to me and I'll put it in the gallery to share.

What do you think? Is it useful?

Should I make a Chrome version?

</comment><comment><USER2> This is a pretty interesting concept. I like it! It's really well executed for being a weekend project. It'd be cool if we could integrate Google Analytics to it at some point.</comment>


Ask HN: What is :(){ :|:& };:? - <AUTHOR>

Hi,
I just saw this in a wallpaper saying "beautiful destruction" and got my curiosity.
:(){ :|:& };:
I dont know what it is and search engines tells me nothing about it.
Can anybody enlighten me please? <comment><USER2> Take a look here: <http://en.wikipedia.org/wiki/Fork_bomb#Examples></comment>


Ask HN: Any good Technical books with hilarious presentation? - <AUTHOR> <comment><USER2> If your taste in humor trends toward the absurdist, check out anything by _why the lucky stiff.

</comment><comment><USER3> [https://www.amazon.com/Grokking-Algorithms-illustrated- progr...](https://www.amazon.com/Grokking-Algorithms-illustrated-programmers- curious/dp/1617292230)

<comment><USER4> Great recommendation. Just a good book all around. The illustrations make subject matter accessible to many.

</comment></comment><comment><USER5> Why's (Poignant) Guide to Ruby

[https://poignant.guide](https://poignant.guide)

Learn You a Haskell for Great Good!

[http://learnyouahaskell.com/](http://learnyouahaskell.com/)

Head First Design Patterns: A Brain-Friendly Guide

[https://www.amazon.com/Head-First-Design-Patterns-Brain- Frie...](https://www.amazon.com/Head-First-Design-Patterns-Brain- Friendly/dp/0596007124)

</comment><comment><USER4> Hilarious might be a stretch, but Starting Forth by Leo Brodie is definitely amusing and prompted a chuckle or two. You can read it for free online. I was lucky enough to track down a second hand copy. It is out of print sadly.

[https://www.forth.com/starting-forth/](https://www.forth.com/starting-forth/)

</comment><comment><USER6> The Illustrated Children's Guide to Kubernetes

[https://www.cncf.io/the-childrens-illustrated-guide-to- kuber...](https://www.cncf.io/the-childrens-illustrated-guide-to-kubernetes/)

</comment><comment><USER7> I'm a fan of [http://www.lisperati.com/](http://www.lisperati.com/)

And

Land of Lisp: also by Conrad Barski

Even though, I bet like others, I have yet to finish it :(

</comment><comment><USER8> "If Hemingway Wrote JavaScript"

Different and lighthearted enough for me to recommend.</comment>


Show HN: DayQuant- an app that helps you quantify and analyze your daily life - <AUTHOR> I showed this to HN a few weeks ago and have updated it a great deal since then. This app allows you to grade your overall day on a scale of 1-100, as well as on the criteria of productivity, social interaction and physical activity. You can then view your results on a long-term chart. There is also a program which analyzes the frequency of different grades. Check it out and let me know what you think! The website is DayQuant.com and it is on the Google Play store as DayQuant. <comment><USER2> Interesting idea - the design really needs some work, though. Especially the mobile "app", which is just the website?

BTW: the link in your email goes to [http://dqprogram.php/](http://dqprogram.php/)

<comment><AUTHOR> thanks, I changed the email. I used Bootstrap for the design and tried to make it optimized for mobile. Do you have any specific recommendations on what would make it look better?</comment></comment>