Lightning Strikes Twice as Much over Shipping Lanes - <AUTHOR> https://www.wired.com/story/why-lightning-strikes-twice-as-much-over-shipping-lanes/ <comment><USER2> I really wish HN had some policy/method of changing the links to such pop-sci articles to the actual source. The paper they're talking about is much more readable. These news articles manage to spread all the information in the concise abstract over multiple pages without adding anything of value.

Here's the paper: [https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/201...](https://agupubs.onlinelibrary.wiley.com/doi/full/10.1002/2017GL074982%4010.1002/%28ISSN%291944-8007.GRLHIGHLIGHTS2017)

<comment><USER3> The reason this article was written was because Wired paid a journalist to peruse a bunch of academic journals looking for interesting stuff. If you cut Wired out from the profit loop, you'd have to read those academic journals yourself, or depend on other users on this website to do it. I don't see either happening reliably enough to compete with a paid professional.

<comment><USER4> It's really time for hn to acknowledge that stories have multiple links, perspectives, and chronological events and allow groupings. Take techmeme for example [https://www.techmeme.com/191010/p17#a191010p17](https://www.techmeme.com/191010/p17#a191010p17)

To the left of the story, click the down arrow, thats every repost or perspective of the original story. Then the indented stories are followups.

Circa also designed itself around this, having a story and when you clicked it, THEN you would see the overall structure of the stories development timeline.

It wouldnt even have to be a chance to the existing hn site, somuch as an additional view that allows stories and comments to be stitched together and intermixed.

More on the topic of this post, I love the wired headline, how it reads "lightening strikes twice" and then the sentence continues, modifying twice into "twice as."

<comment><USER5> Never heard about Circa before, but just read a little about them and their feature that has the goal

> "to break down a story into its core elements: facts, stats, quotes and > media", as opposed to a summary where content is reduced for quicker reading > or users are linked elsewhere for the full story

Do you know of any other [general, not tech-specific] media outlets with this philosophy? I find most sources these days are unhelpful even though they think they're adding value with emphasis on narratives.

<comment><USER4> it flies in the face of "chronological feed culture" (twitter, rivers) and "algo popularity" to have people clicking the same story multiple time for updates. chron/ai feeds are meant to let you ever feast on the new without ever going back to the old. that philosophy you are looking for has a hard time competing with out of context constantly breaking news blips. (short answer to your q, I cant think of a good one off the top of my head.) Does wikinews have that sort of metastructure above stories? [https://en.wikinews.org/wiki/Main_Page](https://en.wikinews.org/wiki/Main_Page)

personally id love a menu in a news app that says "updates to stories youve clicked" without having to follow a story. then separately i would have "followed/starred" stories as a different menu entry. they might sort differently, such as, since last clicked vs since most recent update.

</comment></comment></comment></comment></comment><comment><USER6> Hold on a minute! This seems to contradict the often-repeated assertion here on HN that shipping doesn't contribute to air pollution. Despite burning the dirtiest fuels possible and producing more pollution than all of automotive transportation, the smoke was supposed to somehow settle out and not get into the upper atmosphere.

This article claims there're 2X lightening strikes over shipping lanes, because of additional particulates in the upper atmosphere.

How do we reconcile this?

<comment><USER7> > often-repeated assertion here on HN that shipping doesn't contribute to air > pollution

Could you provide a citation?

<comment><USER8> Seriously. You can be talking about air pollution as CO2 or particulate or sulfur dioxide or a number of other things and which sort of pollution you're talking about makes a big difference in how polluting you should consider container ships to be. Also whether you're comparing tanker ships to other forms of freight or to overall pollution emissions or to the hunter gatherer lifestyle.

</comment></comment></comment><comment> jarl-ragnar Anyone with a knowledge of atmospheric physics would say this is obvious. You can even detect shipping lanes because of the impact of the aerosols generated by the shipping traffic on the cloud cover compared to the surrounding area.

<comment><USER9> I would argue that it is not obvious. The impact of ships on low level liquid clouds is a very different process and is comparatively well understood. There is even a wikipedia article on it [1]

However, convective invigoration by aerosols is a different issue. They are suggestions that suppressing warm rain (rain formed through processes that don't involving ice) might lead to more intense updraughts in convective systems [2], but the observational evidence is unclear. Convective storms tend to form in humid locations, where satellite observations of aerosol are biased high by the humidity [3].

Even in this case, it is not clear that the result holds outside the local aerosol enhancement generated by ships [4]. Do aerosols affect convective clouds at a large scale? I would argue that there is no strong evidence either way at the moment.

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

[2] - [http://doi.org/10.1126/science.1160606](http://doi.org/10.1126/science.1160606)

[3] - [http://doi.org/10.1002/2014GL059524](http://doi.org/10.1002/2014GL059524)

[4] - [http://doi.org/10.1029/2018GL078682](http://doi.org/10.1029/2018GL078682)

<comment> jarl-ragnar Try this "Mechanisms of lightning formation in deep maritime clouds and hurricanes" [1] It suggests "that the formation of lightning in maritime clouds requires two conditions to be satisfied: a) significant vertical velocities and a large cloud-depth, and b) the existence of small aerosols with the radii lower than about 0.05 μ m in diameter in the cloud condensational nuclei (CCN) size spectra." The pollution from the ships in the form of sulphate will likely provide such small aerosols so then you just need to significant vertical velocities.

[1] - [https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&c...](https://www.google.com/url?sa=t&rct=j&q=&esrc=s&source=web&cd=14&ved=2ahUKEwjqs6bLrZTlAhUIURUIHfnFCHoQFjANegQIChAC&url=https%3A%2F%2Fams.confex.com%2Fams%2Fpdfpapers%2F167757.pdf&usg=AOvVaw1RsyMiCcpnQo0fskCeZ35P)

</comment></comment></comment><comment><USER10> Regarding the legislation for ships to decrease air pollution - here is an article from two weeks ago describing cheat devices for ships to remove pollution from the air and dump it into the sea instead.

[https://www.independent.co.uk/environment/shipping- pollution...](https://www.independent.co.uk/environment/shipping-pollution- sea-open-loop-scrubber-carbon-dioxide-environment-a9123181.html)

<comment><USER11> Wired also explained that before. In the article of this post they linked to an older article ([https://www.wired.com/story/cleaner-ships-more-expensive- hol...](https://www.wired.com/story/cleaner-ships-more-expensive-holidays/)). It goes into detail about the scrubbers. Open, closed and hybrid systems. Anything other than a closed system is bad. A closed system itself might or might not be bad (depends on what's done with the waste).

Note that apparently the most common sulphur amount in fuel is around 2.7% ([https://www.exxonmobil.com/en/marine/technicalresource/news-...](https://www.exxonmobil.com/en/marine/technicalresource/news- resources/imo-sulphur-cap-and-mgo-hfo)). Currently there's not too much available fuel at 0.50%. What I heard is planned is that they're going to mix the 2.7% and 0.1% sulphur fuel to get to 0.5%.

Going from 2.7% to 0.5% sulphur fuel is apparently an additional cost of 15 billion USD/year. In my opinion once they're at 0.5% new legislation (by the IMO; an organization which basically sets these rules) should be introduced that reduces it further. Often in shipping the actual implementation date is 3-5 years, sometimes 10 years into the future. So new legislation should be introduced to reduce things further.

Secondly, companies can get a significant competitive advantage by not following these rules. As such, countries should be strictly checking if ships and shipping lines are following this. Unlike other industries it's pretty common that a captain is jailed if certain rules aren't followed.

<comment><USER12> Captains of large merchant vessels are salaried or even quasi-gig employees. Indirect operational control is based at the company hq, which is generally in a different country than the port. This leads hq to order their captains to do unsafe or illegal things to maximize short term profit. I recall an article on hn about a captain who was fired for sailing around a tropical storm instead of straight through it, costing the company a few extra days.

Rules targeting captains (essentially disposable middle management) will be ineffective for this reason. They should instead target the ship itself (capital asset).

</comment></comment></comment><comment><USER13> > _This may sound crazy—until you know a little bit about lightning._

        s/a little bit/what every third grader knows/

</comment><comment><USER14> That's nice, something for the sailors to look at :)

</comment><comment><USER15> before I read the article I was going to guess diesel particulates from the ships spewing those.

</comment><comment><USER16> Interesting but kinda logical since the ship is a metal highest point in an ocean of flatness

</comment><comment><USER17> ... would a ship carrying trailers get hit by tornados twice as much, too?</comment>


React is mostly hype - <AUTHOR> http://en.arguman.org/react-is-mostly-hype <comment><USER2> The arguments are pretty vague, for example

> React becomes counterproductive when developing apps that aren't mere demos.

I have developed big apps in Backbone, moving very the same apps to React and the productivity went up madly. Facebook does develop apps which certainly cannot be considered "mere demos" and you can see them in action, for example Ad Manager for Facebook on iOS (written in React Native). Facebook invests a lot in React development and there is a reason for that - they use it internally intensively.

> It's marketed to developers by billion dollar Facebook, a company > historically intent on squashing startups.

This is not an argument at all. I would be really surprised that's the reason for React to exist. Also React is more a way of thinking, the library itself can be replaced if Facebook should enforce it on a successful startup.

> The utility gained by using React's ecosystem is significantly outweighed by > its overhead.

This is certainly not my experience. React has very little overhead and from my experience it's pretty easy to grasp the concept for new developers.

I have no idea where does hate for React come from, it's >> just << an open source library and I wonder how people are willing to start flamewars about a few lines of code. If you don't like React, don't use it. There are a few alternatives like Ember, Angular or even Backbone (although I would say Backbone deserves much more hate than React).

<comment><USER3> React itself is pretty simple and very nice to work with. The whole react/redux/react-redux/react-router/react-router-redux/webpack/babel/flow agglomeration on the other hand is a lot more complex and subject to a lot of api churn. But you can actually get pretty far just using React by itself. Don't adopt other parts of this stack until you actually really _need_ them and you can go pretty far with just a few concepts.

And yes, React is as much a technique for building UI as it is a particular implementation. Learning and using React has also improved the iOS code I write.

<comment><USER4> Why not take your comment a step further? That is, you can get pretty far using plain js `createElement` and similar functions. In fact I've created a fairly complex SPA without using _any_ external libraries. Don't use react until you absolutely need it!

Back in the day, jQuery was amazing because it made selecting and manipulating DOM elements easy. But now, plain JS has mostly caught up to that functionality, to the point that it rarely makes sense to use jQuery over plain JS. I wonder if in a few years the same will be true of much of the functionality in react.

<comment><USER5> This was one of the _problems_ React solves.

Before with libraries like jQuery every potential action had to perform it's own UI modifications.

As the projects grows you have the same UI element being controlled from many different sections of code. States and state transitions not clearly defined.

With React you set the state and the UI will always match, no matter how the current state was achieved.

The purpose was to get rid of ad-hoc DOM manipulations.

The Flux architecture just takes this a bit further by formally defining who holds onto the state/how it's accessed (stores) and the availible possible state changes (actions).

<comment><USER6> Willy-nilly DOM and state modification wasn't a _requirement_ with jQuery, it was just how a lot of people chose to (not) structure their applications.

<comment><USER5> It wasn't a requirement but it was encouraged.

jQuery was all about selecting a node or node list and then applying manipulations to it.

<comment><USER6> To "encourage" means to openly advocate.

Never ever have I seen active _encouragement_ of poor programming discipline. You are correct in that's what jQuery was about, but it had no opinion on how to go _about_ that task.

<comment><USER5> It might not have a explicit opinion stated anywhere but in any library or framework, the API provided influences how those APIs are used.

By having the central unit of work start with a query selector is one such influence which I feel implicitly encouraged DOM manipulations.

Taking a look at the original jQuery website on web.archive, this is the introduction to the $() function:

"The functionality of jQuery centers around one central function: $(). Everything in jQuery is based upon this, or uses this in some way. The most basic use of this function is to pass in an expression (usually consisting of CSS or XPath), which then finds all matching elements and remembers them for later use. For example:"

And then goes to show a DOM selection followed by a chained mutation.

<comment><USER6> > [...] I feel implicitly encouraged DOM manipulations.

That's jQuery's primary job. It isn't DOM manipulation that causes code/architectural issues.

"All" (I'm simplifying) jQuery does is provide mechanisms to select and manipulate DOM. How to organize its usage is an exercise left to the reader, and most readers did it poorly.

It's not jQuery's fault that people wrote shitty code with it. And, in fairness, when Prototype/jQuery/etc. came out, sites were simpler. When people started doing more, if they didn't take control of how they were using jQ/etc., it blew up and made them hate their lives.

At the same time people were doing that, other people were using various organizing principles to tame their jQ/etc. soup, writing tests, and keeping a handle on the sprawl.

You can write shitty code in React, too. It imposes a certain set of conventions that make it harder to want to. Layer on Redux/etc. and it's even harder to want to. Layer on other various conventions and frameworks and you want to even _less_. But it doesn't stop you--just like jQ didn't stop you from using self-discipline before people smarter than me evolved client-side frameworks to where we are now.

While I wrote my share of jQ soup, I also worked on projects that were flexible, extensible, testable, and clean. The choice is always ours to make.

<comment><USER5> Take an average developer (or two) and sit them down in front of React and jQuery for the first time. My bet is anything based on React will be better built than that of jQuery.

Of course you can architect those flexible, extensible, testable and clean projects. But straight out of the box you do not get that with jQuery. It requires planning and architecture engineering.

Whereas every React project starts off with those principals.

In other words, the ways people can use jQuery wrong is worse than the ways people can use React wrong.

<comment><USER6> I both agree and disagree. If you code yourself into a corner with React it can be harder to understand and untangle: it's much easier to understand jQuery under the covers than React, especially if you're using other parts of the React ecosystem.

None of this is related to what I said originally, which is that jQuery doesn't _encourage_ shitty code. jQ's original purpose wasn't to organize developer activity, it was to simplify one tiny portion of it.

> [Good code in jQ] requires planning and architecture engineering.

Precisely what I said.

(That said, if you don't do that with React, you'll _still_ end up with a mess.)

<comment><USER5> I agree and disagree as well.

My point about planning and architecture was to contrast it against what I believe React is better at.

Personally I think React is easier to understand. Honestly the vDom is an implementation detail people get stuck on. Pure functions, well defined state owneeship and transition, and so on are the real benefits.

The other main criticism is JSX which is totally optional and mixing implementing with presentation; the "correct" which I believe to be a outdated but still accepted belief that went out of style around Web 2.0. This separation is not required either, you can rewrite render() to pull from any templating engine or whatever. Or use HOF/HOC via the presentation/containener design pattern.

I realize I went off topic but I've been wanting to compiler my thoughts on this.

<comment><USER6> React _is_ better at enabling planning and architecture; that's part of its job. That was explicitly _not_ part of jQuery's job. jQuery was a tool to be used as part of a larger strategy. Lots of people chose to ignore that part of their code, and paid the price.

I like JSX quite a bit as well; IMO creating an artificial separation between presentation and behavior is not a useful way to think about web apps.

Separating _data_ from presentation and behavior is fine, and is a long- standing GUI tradition.

<comment><USER5> I think we're really in agreement about everything. The tools have intended jobs; some people use them incorrectly or without regard to best-practices. Both have different strengths and failure modes.

I would say JSX and the separation of presentation / behavior is orthogonal.

JSX is just a Javascript powered embedded SGML-like document.

The combining of presentation and behavior is caused by render() being defined inline with implementation.

You can not use JSX by using ReactDOM directly or a templating library while still keeping render() inlined.

Or you can move render() to another class (or subclassed, or HOC, whatever) and separate the presentation and behavior with or without JSX.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> I really don't give a shit what anyone says, for me personally ReactJS makes front end great fun to program and an absolute blast and empowers me like never before to build powerful, interactive front end apps with a code base that is well structured, understandable and makes sense.

Until React I dreaded front end development, painful, weird, quirky, hard to organise and generally problemtic. With React I feel like a front end guru.

AngularJS felt like some sort of weird computer science project developed by Phd's who had spent their university days studying Java - it hurt to learn it.

Call me a hipster fanboy if you want but I choose technology to work with because it is easy and make sense. I don't have much time so I have to commit my limited resource to the optimum set of technologies. At the front end that is React.

<comment><USER8> Angular was a bad idea. In sooo many ways...

-Two-way binding in all cases is slow

-Directives are unecessarily hard to write

-Angular's default DI model breaks on alpha conversion, the basis of every JS minifier ever. All the fixes are cumbersome.

-The system is poorly documented, making it hard for a dev to get started.

-The system is overly complex, slow, and hard to debug ($digest already in progress, anyone?).

-But most importantly, it implements stuff that has _no buisiness_ being in an SPA web framework. It re-implements scoping, modules, part of JQuery, DI, and a programming language, complete with parser.

React, however, did the responsible thing, and stuck to a specific domain. Even if nothing else React did was good (and I have some arguments there), this is a major win over Angular.

<comment><USER9> Two way data bind is fast because a graph of binds and dependency is created. So you can have atomic updates while in virtual dom you must rerun all the tree. See vue.js and ractive But is also true that 2way double binding take more memory that virtual dom.

<comment><USER8> Two-way binding CAN be fast, however, due to various issues, Angular's only option was Dirty Checking, which is sloooow.

And no, a depgraph doesn't make it fast. What can make it fast is firing less events, using better triggers, and basically handling it exactly the way that Angular didn't.

VDOM can help, but really not much. However you want to put it, two-way binding is costly, and it should be avoided whenever possible, or minimized by catching multiple bind events at a higher up element on the tree (see [http://lhorie.github.io/mithril-blog/asymmetrical-data- bindi...](http://lhorie.github.io/mithril-blog/asymmetrical-data- bindings.html))

Just spraying it everywhere, the way Angular encourages, with no optimization (like the aforementioned asymetrical bindings), should be considered an antipattern.

<comment><USER9> Data binding is also about computates function where you know the dependencies of this and know when recalculate it

<comment><USER8> Are you talking about Computed Values? Because Data Binding has nothing to do with that. Not really.

In any case, Computed values make 2 way binding more expensive, because you have to run a depgraph on all the vars that are part of the binding network, every time an event fires. This is O(n). This is only one reason why Computed Values, as implemented in JS, are a Bad Idea. If you have to update a var on event fire, okay, but leaving the things everywhere is slow and ungainly. If you instead change the var to a function call, you can optimize far better, because you only have to update when the value is read.

In conclusion, if you want to polymorphism between functions and variables, treat everything as a function, not as a variable.

At least, I think that's a response to your question. Your English is pretty broken, so it's hard to tell. Sorry.

</comment></comment></comment></comment></comment></comment><comment><USER10> What is this nonsense?

> It's marketed to developers by billion dollar Facebook, a company > historically intent on squashing startups.

This is a poisoning the well fallacy.

> The benefits of using a virtual DOM over the actual DOM are theoretical at > best. The problems that React supposedly solves are theoretical at best.

This "argument" contains zero information.

> That's why there's Redux!

Redux and react don't solve the same problem.

> It solves problems you'll never encounter because you don't have Facebook > scale.

The client doesn't scale like the backend. Not to mention it's in contradiction with this other "argument":

> React becomes counterproductive when developing apps that aren't mere demos.

Do people actually take this serious?

<comment><USER11> This being the Internet, I'm tempted to say it's a parody.

</comment></comment><comment><USER12> I see some point-missing arguments being made here.

React isn't for scale. And it isn't to side step learning about html and css. It's main reason for existence is to make complex UIs easy to manage.

Pretty much the only argument I can think of against React is that it's a boil-the-ocean system.

Once you start doing your UI with it, you pretty much need to make the entire thing use react to really benefit from its model. Having different interlinked components mixed between react and query and what-not is asking for trouble.

But. Building your UI as a description of your current state is so incredibly useful to reason about and prevent bugs, that it's usually worth it to go completely into the system.

The only other major gripe I have is getting time-based elements like animations to play well within the system.

<comment><USER13> "Once you start doing your UI with it, you pretty much need to make the entire thing use react to really benefit from its model."

In my experience React is quite ideal for cases where some parts of a site or an app need dynamic behavior. I'm currently working on an e-commerce platform's admin panel, and for us a complete rewrite would have been nearly impossible. With React we can keep the old HTML + jQuery codebase, and implement/refactor stuff as small or as big as we need (e.g. a live-search component or a whole new dashboard view). We're doing something very similar to this: [https://github.com/reactjs/react-rails#rendering-- mounting](https://github.com/reactjs/react-rails#rendering--mounting)

<comment><USER11> That's the same thing we're doing at my company (with the aim of eventually replacing the old platform entirely), and it's working out very well.

</comment></comment></comment><comment><USER14> > React automatically manages UI updates, but this is only true if your UI is > extremely basic.

The exact opposite is true. The whole point of React is in building complex UIs.

> React becomes counterproductive when developing apps that aren't mere demos.

A few sites using React that are not mere demos:

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

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

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

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

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

> It's marketed to developers by billion dollar Facebook, a company > historically intent on squashing startups.

Except when they are buying them for billions (WhatsApp, Instagram, Oculus). All things being equal, Facebook is probably more likely to buy your startup if you use React.

</comment><comment><USER15> I don't believe React to be mostly hype. It's so frequently being used by skilled and informed teams that I would consider anyone who make this claim to be ill-informed.

But the claim and current consensus around web development is that "you should absolutely use a framework built by someone smarter than you or you'll end up shooting yourself in the foot" I find equally ill-informed.

Consider these popular libs and then consider how poorly they integrate with each other: jquery, bootstrap, require and knockout. If you are off by a version or two in jquery, then bootstrap will not work. Up the version of jquery and parts of your app will break down. Try to fit libs that aren't modularized or that use hard-coded deps with require. You'll end up rewriting those libs (to get rid of deps you don't need).

I feel javascript should be mature enough to use without frameworks. Remember the cutting-and-pasting of the javascript.com era? We're back to that, I feel. I mean, surely there are lots of smart snippets of code or even libs that you want to use in react but can't because the code-snippets or libs aren't following the react architecture. What do you do then? Cut-and-paste those parts that you need and that will fit into react, perhaps?

</comment><comment><USER16> Ignore the react bit, the site is interesting in itself.

[http://en.arguman.org/](http://en.arguman.org/)

The post is bait-and-switch, react is a bite, time for a switch. :-)

<comment><USER10> No thank you. None of the other "discussions" are worth wasting time over. Just people bringing feelings, sophisms and misinformation to an argument fight. It's no better than a reddit thread.

<comment><USER17> You got heavily downvoted, but the linked argument-story is an example for this. Less emotions would be nice.

Some day we may have a forum (in the broadest sense) that uses a sensor, like a webcam, and "emotion recognition" AI. You are not allowed to vote if you are too worked up about a comment, and if you post it will be held for a few hours and you have to acknowledge that you still mean it after that "timeout" period before it gets published. This should/could take care of some hot-headed responses. I think digital discussion needs more ideas, just "post your comment here" and "votes" don't really cut it. It's better than nothing (pre- Internet), but we've seen the disadvantages by now, why not try something new?

Internet discussion and collaboration software could be (should be?) _the_ most exciting thing, instead everybody just copied and barely modifies the core concept in use since the very first web forum software was first published.

</comment></comment></comment><comment><USER18> React is a pretty simple concept (with, perhaps, a complex implementation) reified in a library. It's basically componentized state machines for UI rendering. Comparing it to general "web frameworks" is completely missing the point. Granted, some people do [often needlessly] install a lot of react- whatevers for everything from routing to mysql fetching (yep).

I can see it being replaced by another library with a similar underlying philosophy that just does it better, but I don't really see how the general idea would vanish soon.

And btw Facebook uses it a lot on the web too (not just the often mentioned Ad Manager), messaging (and messenger.com) is basically all React and other components are a mix. Download the React Devtool to check it out, they don't obfuscate the React tree at all. Pretty fun to browse.

</comment><comment><USER19> Whoa. I have been working on larger web apps at pre- react\ angular\vdom time and i'm really glad i don't have to read tons of tutorials about what might cause my Browser to repaint or even reflow the entire doc to get some Good enough performance. And react really shines for bigger projects since you only care of locale components.

</comment><comment><USER20> I'm still undecided as to whether React is up to snuff for large-scale development projects. I work in a medium sized company developing enterprise- targeted web software. We have been using ASP.NET + jQuery + whatever JS design pattern to artificially namespace our JS for about five years. This summer we moved to React + Redux for a new product and it has been pretty amazing. Productivity did not go up (immediately), in fact, learning the React way and constant adjustments to what we were storing in Redux slowed us down considerably. However, we are across that hump and it FEELS like we have some really good, reusable components that will save us lots of time going forward. At this point, extension and composition should be really trivial and the next few months will really form my opinion on React as a tool (and of course, myself as a user of that tool ;) ).

However, the ecosystem, not just React but the npm ecosystem in general, has been a bit disappointing. Things move very quickly in some places but not others. React itself has broken or generated warnings numerous third party packages that, hopefully, will catch up. It's disappointing because it basically forces us to not update our main dependencies until everything has moved with it. Perhaps that's my fault for placing the npm/js world on a pedestal, but then again, I think I've only done that because, while .NET is generally favorable today, the inertia of past criticisms had led me to believe that the .NET ecosystem was somehow inherently deficient or broken when compared to the JS ecosystem. At this point, they seem fairly similar in terms of quality and choice.

One big plus with moving to any npm-centric development is that, coupled to a move to Windows 10 and using bash, a lot of the dev workflow has moved out of, say, Visual Studio and into a command line. This is great because as we move build and deployment configurations between machines and tools (say to Jenkins), there aren't lots of details hidden in our project and solution files. It offers a clarity I didn't know I wanted.

</comment><comment><USER21> I find all the recent negativity around React-related posts to be very frustrating.

I'm a frontend engineer, and I greatly enjoy working with React. But I think that's because I've invested the time needed to learn and navigate the ecosystem.

It's true that React doesn't solve all the problems you deal with when building a web app. But I don't think it has ever marketed itself as a "batteries included" solution. It gives you a strong ecosystem and a great abstraction for building UI's.

</comment><comment><USER22> Quite a few claims with absolutely nothing to back them up.

TruthyOne, if you really believe all this and are submitting it to Hacker News, surely you wouldn't mind sharing how you've come to these conclusions?

</comment><comment><USER23> Our team of seasoned AngularJS developers recently tried out React for its small enough footprint and the huge community support. We loved it, our client loved it. I don't really see such bad things about React at this time.

Shameless plug, but we did wrote an article outlining our experiences at [https://blog.alarisprime.com/e-commerce-case-study- building-...](https://blog.alarisprime.com/e-commerce-case-study-building- faster-listing-pages-on-abof-com-part-1-cb99231a1e8a#.ee37xw6ru)

</comment><comment><USER24> I would think [http://en.arguman.org/web-programming-is-getting- unnecessari...](http://en.arguman.org/web-programming-is-getting- unnecessarily-complicated) is much more interesting, really.

React is _just one framework_. Popular, sure, and occasionally annoying (for very small things, the overhead of building a gigantic workspace vs just using Zepto and ending up with three JS files is... well... pointless), but we should be looking at the broader picture.

</comment><comment><USER25> I did one medium sized SPA in react (using alt.js) last year and wasn't really convinced, maybe i did something wrong but i did not feel the amazing productivity boost that so many people mention. Managing a lot of dependencies of the modules i used for various things like forms, file uploads etc has been painful and in general the module quality felt very alpha in many cases so i ended up reinventing what has already done pretty well in angular in terms of functionality. Code organization and best practices also wasn't easy to come by because of the many ways of doing things and in the end some solutions felt more like hacks than a solid implementation. Angular1 is certainly not perfect but i found the whole thing to be much more consistent and Angular2 using Typescript is what i prefer most right now.

</comment><comment><USER26> I don't really see the difference between most modern JavaScript "frameworks". It's mostly in the details, and any of them would work just fine. At this point it's like arguing which of X number of programming languages are the best.

Part of seems to be: "How dare people not like the tool I prefer", or simply that people don't want to be bothered to learn yet another JavaScript library (which I can understand, but I'm not being prevented from using the tools I like, just because React exists).

One "mistake" I see React make, others do too, is mixing JavaScript and HTML. I'm still firmly in the camp that believes in progressive enhancement as the correct way of developing for the web. React, Angular and most other modern libraries doesn't seem to share that view.

<comment><USER15> First time I read a blog post about react and saw it's artifacts so to speak I threw up in my mouth. Js AND HTML, mixed! Wtf? I spoke about this to lots of front-enders who laughed and called me old. I agree with your point. If markup and UI code can be separated, why wouldn't you strive for such a solution?

<comment><USER27> Because HTML is not a programming language thus you have very limited options to work with.

</comment></comment></comment><comment><USER28> I am not fan of React. It is great to have something like React for people that aren't primarily into software development, because of html and css and js (many designers and hobbyists got into programming with those) but I do not appreciate it. The fact that I do not have (nor want) any single Electron app installed on my computer tells something. It is okay to be there as a choice for app development but I want to see less of it. It doesn't come close to native apps. And Qt is getting really better and better each day, and right now is pretty portable, so you don't have to write 3 different versions of apps for different operating systems. Just not my cup of tea, and I hate that it is hyped, because it is reflecting bad on some developing habits and community.

<comment><USER29> So, you don't like React because Electron which has nothing to do with React?

<comment><USER30> And apparently Qt is so much better, which is in the process of integrating a full browser engine for Qt Quick, which is… somehow better than using a full browser engine directly? Okay.

</comment></comment></comment><comment><USER31> Neither React or Angular are mostly hype. I posit that SPA's, whose implementation is made less painful by React, are mostly hype.

I liken it the Lisp macro analogy. Never write an SPA unless absolutely necessary--stick with a web page with some dynamic js-driven features as needed.

<comment><USER32> SPAs can be a good thing when used internally in a business (ease of distribution, sandboxing, etc.), but I agree that any public-facing web _site_ is probably best served by static HTML with minimal JS where it is absolutely necessary.

</comment></comment><comment><USER33> Erm. What is this? I'm probably missing something but there's no useful content here at all.

<comment><USER34> [http://en.arguman.org/about](http://en.arguman.org/about)

<comment><USER35> Pretty annoying that you can't select text to copy/paste and quote it.

<comment><USER36> I'm sure they would appreciate an issue [https://github.com/arguman/arguman.org/issues](https://github.com/arguman/arguman.org/issues)

</comment></comment></comment></comment><comment><USER37> I've been using React for a side project for a while. Generally it's been pretty easy to understand the concepts behind it and get productive. A couple of things that have confused/irked me a little:

\- Having to figure out babel, browserify and/or webpack before you can write hello world isn't a great first experience. I'm glad to see much of this has been moved to a separate page outside of the getting started guide now.

\- The main React page emphasises that JSX is optional. Even looking at the trivial examples, nesting createElement statements looks horrific. Does anyone use this approach in a large-scale project? If your components are fine- grained enough, perhaps it's passable, but it looks far from ideal. Having used other frameworks, even building up a template in JSX in a return statement feels dirty. I see there are some suggestions around on splitting out JSX, but it would be great if this was the default.

\- I wasn't really sure what to do with CSS. There's a brief comment on inline-styles at [https://facebook.github.io/react/tips/inline- styles.html](https://facebook.github.io/react/tips/inline-styles.html). For a library for building user interfaces, it seems like this deserves more attention. I would've expected the CSS (styling), javascript (logic and state management) and JSX (layout) to be a little less interwoven.

<comment><USER38> IMO the whole CSS issue isn't "solved" yet.

There are like 3 or 4 different ways of doing it, each with their own pretty big drawbacks.

Personally we ended up using CSS Modules with SASS in our "main" react project, but it feels clunky.

The biggest issue we have is determining which element "owns" the styling. Should a widget style itself, or should it let it's container style it, or should it provide some simple defaults and let the container overwrite them (which gets ugly because with CSS Modules overwriting means using !important or doubling classes (like `.button.button` to overwrite `.button`).

All that being said, it's actually working out really well for us despite feeling wrong. And it might not ever become an issue because our largest stylesheet is like 100 lines long since everything is so compartmentalized.

</comment></comment><comment><USER39> I've used React in four projects (after many projects in Angular[1])

1\. In terms of best practices, React for serious development is a disaster just by itself. Read on.. This is what happened in my first project (when I didn't use Redux). By itself it is only good(and great) for POCs. And React- ecosystem is complex to start with. React-Redux, Router, Axios, Webpack make React complete for use in any serious project.

2\. React makes web-componenting pretty easy. However it is counter-intuitive when you start thinking about the all important Smart Vs Dumb components separation. I don't know about others, but I like to see components as behaviour-complete stuff and not just view-complete. React with its ecosystem does things in a view-complete way. Yes, it does result in much much lesser bugs.

3\. React is hyped because of its simple examples. As I said earlier, it makes it easier to create behaviour-complete web components. But then the ecosystem says "NO. NO.. Think in REACT way". That is not wrong but its complex. The first project in React was a disaster because of the complex state management I did without using redux or flux.

4\. After working with React - when I tried Angular2, I moved back to React again. And I did React+TypeScript which makes coding even easier. The only thing I still like in Angular2 is now-not-default two-way data binding.

Do I love React? May be not so much - but its the best I have seen. But I love the way my apps remain bug free without a lot of front-end testing code. And once you add TypeScript, development is just a bit more easier and bugs get thrown up at compile/transpile time

</comment><comment><USER40> This is the same stuff people have been saying about React since its inception. Putting opinions into Arguman doesn't make them factual statements.

<comment><USER41> No kidding. These aren't arguments, they're claims. Making an argument involves using reasoning to support claims... you can't just draw boxes around five claims and say it's an argument.

</comment></comment><comment><USER42> If the point of this post is the site arguman.org, not react, then one small issue (I'm on chrome mobile):

\- No quick submit + signup/in button

Which is why I guess people rather argue here than on the site (says something if the whole point of the site is to make arguing easier)

<comment><USER43> I think this submission is more to promote the Arguman service than anything else. Because most of the submissions come from just two people, who both joined the service less than 24 hours ago.

</comment></comment><comment><USER44> If true, then what is a competing JS DOM renderer with same or nearly same DOM rendering speed?

Closest I've found is Vue but it was still 20-30% slower than React, according to the DOM speed test on a benchmarking site.

<comment><USER45> [https://github.com/ractivejs/ractive](https://github.com/ractivejs/ractive)

edit: developed and backed by the awesome guys at The Guardian newspaper.

</comment></comment><comment><USER9> React is good for complex app desktop but not if you need performant and fast interface with 60 fps otherall in mobile. Last virtual dom like snabbdom preact and inferno are really fast also on mobile. And inferno and preact are compatible with react component. Vue.js 2.0 use an intelligent mixin of reactive data graph dependency and virtual dom separating the static and dynamics parts of template. Monkberry.js translate a template in pure javascript function with createElements and update nodes. Function that can be optimized from the jit

<comment><USER8> Mithril is also apparently really good at fast. But I've merely seen the benches.

<comment><USER9> Mithril for what i know is under a rewrite and with this rewrite should be really fast

<comment><USER8> I never heard that, but it seems pretty fast now. If Leo shows up, hopefully he'll tell us.

<comment><USER9> I know about this [https://github.com/lhorie/mithril.js/issues/1090](https://github.com/lhorie/mithril.js/issues/1090)

<comment><USER8> That's only addressing perf on IE. It says nothing about perf overall.

<comment><USER9> Dom / component recycle and batch updates are about performance

<comment><USER8> Well, okay. Then my favorite framework's getting speed optimizations. I'm not complaining.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> I don't know about the React model and APIs themselves, but VDOM is the Right Thing, from a performance perspective, as well as from the ease perspective. And the advantages are far from academic.

</comment><comment><USER46> Offtopic, but HN usually talks about the value of ideas vs. their execution... well I have had this website's idea, literally, in my notepad for a couple of years as a possible side project, never getting down to implementing. And here it is! Also clicking on the domain I see that it has been sent here periodically during the last year...

I better get to work on my actual project so I'm not overtaken :/

</comment><comment><USER47> Other technologies have gotten a lot more attention due to the support of big name companies but vue.js is easily my favorite Web framework.

</comment><comment><USER48> Was not aware of this until reading:

"Your license to use React.js can be revoked if you compete with Facebook"

[http://react-etc.net/entry/your-license-to-use-react-js- can-...](http://react-etc.net/entry/your-license-to-use-react-js-can-be- revoked-if-you-compete-with-facebook)

This is the scariest part to me:

"The library is open sourced under BSD, but it comes with an added patent clause that you should be aware of."

[https://github.com/facebook/react/blob/master/PATENTS](https://github.com/facebook/react/blob/master/PATENTS)

From reading more, it appears that Facebook can just terminate your right to use their patents, but not React. However, it isn't clear to me what is patented and what rights you lose.

Related past discussions here:

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

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

On the bright side, it's said that Apple and Google are ok with the latest version:

[https://github.com/facebook/react/pull/3554#issuecomment-235...](https://github.com/facebook/react/pull/3554#issuecomment-235569515)

<comment><USER49> It's not if you compete with Facebook, it's if you engage in patent litigation with Facebook.

This is a Mutually Assured Destruction clause for patent fights, nothing more.

<comment><USER48> I was quoting. Did you read everything that I wrote? I thought I did a pretty good job telling the entire story.

<comment><USER49> Right, if you look at the contents of the license in the discussion, they are variants of "if you try to fight us with patents, we will deny you a license/patents".

So you can compete with FB without losing a license. The first blog post you quoted shows a misunderstanding of the license (the word "compete" doesn't show up in the license).

So the correct representation is "If you claim patent infringement by FB, you can lose the license.". This is what the linked comments say, but what your summarised statement didn't properly capture (hence my comment).

<comment><USER27> Or if Facebook claim patent infringement against you. So what he summarised is right.</comment></comment></comment></comment></comment>


Getting a great logo on the cheap: Hold a Contest - <AUTHOR> http://inthebox.webmin.com/getting-a-great-logo-reducing-the-field I posted about this a few days ago, and thought I'd follow up now that we're almost finished with the contest.  Long story short: We're really happy with the results. <comment><USER2> We got ours from <http://www.worth1000.com>.

[http://www.worth1000.com/cache/contest/contestcache.asp?cont...](http://www.worth1000.com/cache/contest/contestcache.asp?contest_id=16511&start=1&end=10&display=)

<comment><AUTHOR> Some of those are good! Do they only do PhotoShop, or is vector and option?

<comment><USER3> They have a $50 listing fee + a charge for extra options. Was Sitepoint free?

<comment><USER4> SitePoint will charge you money too. This is a good thing; it means that you aren't competing with contest holders that are not as serious.

I've never held a contest myself, but I have worked on a project with a design from a SitePoint project and the quality was quite good for the cost. Pro designers hate the idea of spec work, but the truth is that because competition is tough, the top logos generally look quite nice.

</comment></comment></comment></comment><comment><AUTHOR> It's a good thing it's ending today, as we got our first goatse entry today... [http://inthebox.webmin.com/its-just-not-a-contest-until- you-...](http://inthebox.webmin.com/its-just-not-a-contest-until-you-see-a- goatse)

</comment><comment><USER3> Wow, congratulations.

My picks:

#1:Infinity needs system administrators, by fbarriac #2: Modern stylized spider web by vjeko

<comment><AUTHOR> Thanks. We're loving those two, as well (actually, though it's hard to say just yet, those are probably our top two choices right now).

</comment></comment><comment><USER5> See also:

<http://www.designoutpost.com>

They have a forum where you post your prize (usually $100-$300) and parameters, and a bunch of designers compete, revising to your feedback, all in public. Some of the results are very nice.

<comment><AUTHOR> Nice to know. I hadn't heard of that before. While it looks like a pretty high caliber bunch of designers frequent the site and contribute to the contests, the actual infrastructure for running the contests is not nearly as nice as what SitePoint has. SitePoint used to be "just a forum", but they've put a lot of thought and effort into the contests application--it works really well.</comment></comment>


Ask HN: Shouldn't the team behind parse-server just make a bid for parse.com? - <AUTHOR> 1. Get a price tag from FB
2. Kickstart a campaign
3. See if 500k developers support it
4. Buy it and continue from there instead of starting from scratch
Upvote if you agree. <comment><USER2> Developers will find parse-server should they desire it without acquiring a premium domain name (parse.com is alone very valuable - in terms of single word purity and in terms of SERPs / links backs). Any kickstarter cash would be better going to develop community momentum and support contributors imho.</comment>


Ask HN: Finance from first principles? - <AUTHOR> Does anyone know a book/resource that explains major financial concepts from "first principles"
I'm not looking for a book on investing. I'm looking for something much lower level, that dives into the inner-workings of financial systems and how those systems have evolved over time.
To make an analogy with computing, I'm looking for something like SICP or "The Elements of Computing Systems" but for finance. <comment><USER2> No. But I can recommend a book that, through first principles and thought experiment, fortified my belief that efficient allocation of resources can be net positive for society. Nowadays, many people, it seems, feel Finance is a zero sum game where Financiers are net positive, while society at large is net negative.

The book 'Wealth of Nation' by Adam Smith covers the allocation of human capital. Adam Smith argues the ultimate resource being allocated here, really, is time, and how individual's spend their time. When we measure output in dollars, what we're examining is the money value of time.

It's hard to get someone to agree that Finance can be a positive-sum game, if they refuse to accept that society is better off through the efficient allocation of human capital / time. Someone faulted me for being "greedy" and "selfish" to be a programmer in Silicon Valley. That by donating money to the Syrian crisis, I was merely "paying off the debt that you created". They insist I quit my job and go protest the United States government to allow Syrian refugees in. They suggest I quit my job, move to a 3rd world country, and help poor children. I sleep well at night because I read Wealth of Nations. I believe there is no place in the world that is comparable to Silicon Valley. Here, my skills / knowledge as a programmer is fully utilized. As such, I maximize my money, and, should I choose, donate money to causes I care about, to employ people who are more efficient at humanitarian efforts, but not necessarily programming.

Finance allocates money, which, we hope, leads to production of goods / services / jobs. The most efficient allocation of money is the one that produces the most. From first principles, I don't see anything inherently wrong with Finance. By putting money to work over time, rather than lay stagnant, Finance can be viewed as the time value of money. As a society, we'd want Finance and Financiers who help economies grow by efficient allocation of money.

This dichotomy of money-value-of-time versus time-value-of-money is not an original thought of mine. I was first exposed to this idea from a Finance PhD candidate's thought about their program. I couldn't find the article on Google. It'd be great if someone can link to it.

</comment><comment><USER3> Good luck with that.

To be as pithy as I possibly can, finance is basically politics with numbers attached. Studying history has given me a great insight as to how and why modern financial systems work.

Be careful what books you read in your search, more than a few are rhetoric that's shaped like education.

</comment><comment><USER4> [http://www.leftbusinessobserver.com/WSDownload.html](http://www.leftbusinessobserver.com/WSDownload.html)

</comment><comment><USER5> Happy to answer questions - what specifically do you want to know?</comment>


Show HN: Reason to Procrastinate | For when you just need an excuse - <AUTHOR> http://www.reasontoprocrastinate.com

<comment><USER2> Bitdefender has the site flagged as malicious. You might want to get that fixed.

<comment><AUTHOR> I think it might be a false positive because my site is coming up clean in all the scanners I've checked so far but I am still looking into it.</comment></comment>


A Javascript date library - <AUTHOR> http://www.datejs.com/ <comment><USER2> I've used the library in a real project, and I'm on the mailing list. FYI, there doesn't seem to be much development activity going on, nor is it so perfect and complete that further development is unneeded. That's not to discourage anyone from using it, since it's the only JS lib I know that fills the same niche, just to let you know you may need to get your hands dirty. (I've got a patch waiting for integration but not enough attention available to test it for use cases that are not mine and really push it through. If you do have the interest and bandwidth to polish whatever improvements you make, you could probably help quite a bit.)

<comment><AUTHOR> What parts did you miss?

<comment><USER2> My patch (which can be found discussed in the mailing list) provides a callback hook to modify the final result given the parsed details. I use it to modify assumptions: e.g., if you just type a year, for the final output, the library assumes the rest of the date should be jan 1, but if this field is the end of a date range, it should probably be dec 31 since "burglaries from 2001 to 2002" means the burglaries in 2001 and in 2002. I think it's an important function, and the original author agreed, but neither of us has had the time to test and time everything for all the relevant codepaths to make it into the library.

Other posters have had other complaints about missing functionality--some struck me as reasonable, some not so much--but I haven't kept track.

</comment></comment></comment><comment><USER3> My first test was "6.2.2009" and it said "June 2, 2009" where I expected "Feb 6, 2009". So it'll be only usable for an American audience.

</comment><comment><USER4> And a JS timezone library: <http://js.fleegix.org/plugins/date/date>

</comment><comment><USER5> No support for fortnights?! I'm shocked at the omission of this critical unit of time, used throughout society.

<comment><USER6> in all seriousness, it did seem less intelligent than what i've seen (on RTM.com for example). next june returns June 4th? wtf?

<comment><USER7> well today is the 4th. - which day in June 2010 would you pick as the default?

<comment><USER8> This is the test I use on all date libraries I come across. I don't know what the right answer is, I just want it to be logical:

(pseudo) Date d = new Date('1/31/2009'); d.addOneMonth();

What is the value of d? 2/28/09? 3/2/09? 2/25/09?

Writing a date library is not for the fainthearted.

<comment><USER9> And what date do you expect?

<comment><USER10> In what country was the input formed?

<comment><USER11> How profound.

</comment></comment></comment></comment></comment></comment></comment><comment><USER12> Previous related threads:

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

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

</comment><comment><USER13> I had the strangest bug with this library on Konfabulator a while ago where all Date.toString()'s returned an object instead of a string.

Not really a useful thing to know but I wanted to post it anyhow.

</comment><comment><USER14> "the day before last Saturday" doesn't work

</comment><comment><USER15> That's very spiffy. I wonder how it compares to some of the smarter Perl date libraries?

</comment><comment><USER16> Curious if anyone has compared it to the Ruby chronic gem ...

</comment><comment><USER17> That interface... it's so fluent. I love javascript, for just the reason that it's possible to have beautiful interfaces like this.

 _Date.today().add(3).days();_

Be even better if it let you leave off the brackets like ruby, but oh well.</comment>


Sharing Is the Root of All Contention (2009) - <AUTHOR> http://www.drdobbs.com/architecture-and-design/sharing-is-the-root-of-all-contention/214100002 <comment><AUTHOR> This is blindingly obvious when someone points it out to you, but not so obvious when you are actually working on multi-threaded code that has shared data. Whenever you have performance issues, the issue more likely than not is shared data protected by locks that causes all threads to serialize once in a while and minimizing this leads to performance improvement.

</comment><comment><USER2> I've never thought about the fact that 'serialize' as a verb is opposite and antitetical to 'parallelize'.

</comment><comment><USER3> The title seems rather tautological.</comment>


Show HN: Best design courses and tutorials recommended by the design community - <AUTHOR> https://design.instructy.io <comment><USER2> I really like the layout and think this would be super helpful. Obviously it will provide more value once the community grows and their are more upvotes. So far all the categories I looked at all had 0 votes.

One thing you may want to try out in the early days to make it look like there is more activity is to create a bunch of different logins for yourself and friends. Reddit had a super admin tool that allowed them to select from a "user" dropdown anytime the founders wanted to post a comment. That way it appeared there was a lot more dialog and activity.

<comment><AUTHOR> Thanks for your feedback:)

</comment></comment><comment><USER3> A grounded understanding of media theory and media history is the best way to grasp good design.

This can be obtained by looking at the story of media back to the Gutenberg printing press. Look through historical documents, old magazines, brochures, etc. and ask "why did they do it this way?" This gives you a plethora of reasoning and inspiration that you can pull from and reapply throughout your career.

Web design is mutable and loose. Graphic design software is very distant from users and reason. Without grounded thought, your software will do muh of the design for you. The result will be inconsistent and inferior to design with classical uderstanding.

Look to western art history back to the Gutenberg printing press at least. Get more particular in the 20th century and hunker down on Bauhaus influence and mid-century advertising. Learn about Engelbart and hypertext theory and any associated interests of yours.

I find more and more that actual good designers know where their designs come from and reference that understanding in their application of them.

</comment><comment><USER4> Way too much chrome, little signaling as to "is this interesting?", or "is this bullsh1t?"

Not enough content for search to be useful. The other day I was thinking "Text overlaid on a video uses glow, shadow, and similar effects to overcome a variable and imperfectly controlled background. How do I do that in photoshop?"

It turns out to be easy to do (just a setting on the text layer), and I just want to do it and get back to work. I don't want to see seven different ways to do it. I don't want to see somebody demonstrate the wrong way to do and ask for help fixing it (eg. Stackoverflow)

<comment><AUTHOR> Thanks for your feedback, Paul. Any ideas on what can be done to signal that "it is interesting"?</comment></comment>


Smallest-Ever Nanotube Transistors Outperform Silicon - <AUTHOR> http://www.technologyreview.com/computing/39532/?p1=A1 <comment><USER2> The _Nano Letters_ abstract, linked by the TR piece, at <http://pubs.acs.org/doi/abs/10.1021/nl203701g> , has good enough pictures, including a voltage-current plot. That plot seems to demonstrate useful switching (1 nA to 10 uA within 1V).

The abstract's pictures of the structure do a much better job than the TR 'conceptual illustration', which is headed "Nano gate" when the tube really is the transistor channel. The controlling gate, according to the abstract, is buried underneath (not above the channel, as usual in all-Si processes).</comment>


iOS GameCenter hacked - <AUTHOR> http://www.9to5mac.com/47326/ios-hacker-hacks-game-center-scoring

<comment><USER2> This probably means that jailbroken iPhones will be banned from GameCenter soon. Too bad.</comment>


How to Hack a New Brain for Your Old Game Boy with Raspberry Pi - <AUTHOR> https://www.fastcompany.com/3033678/how-to-hack-a-new-brain-for-your-old-gameboy <comment><USER2> You have submitted almost 40 posts today, 20 in the last hour. Are these all really worthy of submission?</comment>


A Camera That Could Care Less About Focus: Introducing Lytro - <AUTHOR> http://mashable.com/2011/06/22/lytro/

<comment><USER2> Duplicated story: <http://news.ycombinator.com/item?id=2681554>

Many many comments there.</comment>


Ask HN: Planning a new company/agency - <AUTHOR>

Hello,
I am a front and back-developer and i am willing to open a new agency to create websites, web/IOS/Facebook apps, and all this sort of jobs. There is already a couple agencies here where i live, but most of them are doing crappy jobs and i am pretty sure my jobs are better than theirs. I married a designer, and she is doing an awesome job, but untill now we are only freelancing, and feeling like we need to make a bigger step, open an agency.
I know a lot of you guys can tell me to wait a bit more, gather a little more money, but i am doing this for (development) for 7 years now and i feel like i need to give a step forward, or else, start a new career.
Well, i have someone who have some money to invest and he is willing to invest in an agency, we just talked a couple times about this, but nothing serious. Now i want to do this, and i was thinking, the first step is to plan everything i need... from computers, to persons to sell my jobs, and i have been planning for a couple months now, but i was wondering, what is the best way to show to this investor the idea? is there any best way to show him?
Some simple word documents with all the info? A couple slideshows showing the idea? well, i am really lost about this part now, could someone help me out here?
Any info needed i will answer in the comments.
Thank you very much. <comment><USER2> I'm not a "you have to have a business plan" person at ALL, but working on one for my own startup helped me IMMENSELY in communicating the idea, the value proposition, how we are going to gain users, and how we're going to scale. Because I spent so many hours refining that document--just for my own benefit --I can speak about the inner workings of the business more confidently. It also gave me the chance to anticipate problems and address them before investors or customers could teach me about them the hard way. Obviously, a good business plan (or "business planning document," or "cool-ass outline," whatever verbiage you want to use to describe it) won't save you from a ton of hard lessons to be surmounted, but it gets your head in the game from the onset if you begin with one.

Besides the normal mapping and purpose you should outline, it helps to think of a list of objectives and then detail meaningful, practical ways you are going to achieve those. That's where you ask that investor for help, and bring all the data and numbers you can.

</comment><comment><USER3> Since you are already engaged in freelancing, then you have the minimum equipment required.

So why are you looking to an investor, when what you need is more clients?

Hiring a professional with a proven track record closing sales in your industry is going to be relatively expensive (as in more than your investor may want to invest). Hiring someone without a proven track record closing deals means that they are less experienced than you.

Good luck.

<comment><AUTHOR> Actually, that made me think about it. The idea came because i am having problems finding clients (same old story), since i am trying to sell my services for (around) 1k USD and they are finding ridiculously expensive, because there are some others around here doing for a lot cheaper.

<comment><USER3> If you're not price competitive with the low end at $1000 [US] raise your prices.

At $4000 or $10,000 you imply greater value and only need to make a small fraction of the sales in order to generate the same revenue. In addition, you will have more time per project to provide better service.

</comment></comment></comment><comment><USER4> I saw your post. I am looking for a freelance computer programmer to do the programming for the websites we design.

Skills needed:

HTML / XHTML CSS JavaScript WordPress and similar templates/CMS sites php and asp a plus

Able to work in Dreamweaver, Photoshop, Flash, ImageReady, Illustrator

If you are interested please email me at firstname.lastname@example.com with your resume or work samples and hourly rate.

Best of luck to you.

</comment><comment><USER5> investor are mostly interested if the idea is working, so i would suggest you start implementing the idea as your in flow your will get more idea about resources you will be needing to implement and running it. which will help you put together a better proposal to the investor and your will get a better prospective whether or not the idea will work.

</comment><comment><USER6> Take all your data with you, and go talk to him. Don't just send a pile of stuff over.</comment>


Show HN: Tag – instantly jump to your ag matches - <AUTHOR> https://github.com/aykamko/tag <comment><USER2> For anyone else confused about what an "ag" match is: [https://github.com/ggreer/the_silver_searcher](https://github.com/ggreer/the_silver_searcher)

(Ag = Chemical symbol for silver)

</comment><comment><USER3> Surprised ag isn't better known here. If you grep through code a lot and you haven't tried it, I'd heartily recommend it.

<comment><USER4> I have limited time for keeping up with non-standard tools. It's the same reason I use bash rather than zsh/ksh/fish. With grep I have a solid mental model of what it does. ack/ag have some magic that is fine most of the time, but will eventually bite me when I do something unusual.

Still, I will check out ag. Maybe this time I will stick with it.

On a side note: People often say that C is just for legacy, and today everything new should be written in a higher level language unless it's a kernel or otherwise inherently low-level. Yet ag is basically a rewrite of ack in C.

</comment></comment><comment><USER5> Can someone explain how searching files is "embarrassingly parallel"? I imagine storage drive to be sequential, the reading head can only be in one place at the time. For SSDs, this may be different, that I don't know. Does this speed up only apply to SSDs? Or is the I/O not the bottleneck here and instead the project benefits from the searching of memory cached files being somehow well parallelizable (memory still seems basically sequential, but is much faster, maybe fast enough to make this problem overwhelmingly CPU-bound?)

<comment><USER6> I'm the author of ag. Hardware may or may not support it, but the algorithms involved are embarrassingly parallel. Searching involves no data dependencies between files. If you're searching 1,000 files, finding results in file #827 doesn't require any information from files 1-826. That's what I meant by "embarrassingly parallel".

Side note: originally, ag was single-threaded. When I added pthreads, it only gave a 15% speedup in my test benchmark.[1] The speedup is larger if checking a file for matches requires more CPU usage (such as when using a complex regex).

1\. [http://geoff.greer.fm/2012/09/07/the-silver-searcher- adding-...](http://geoff.greer.fm/2012/09/07/the-silver-searcher-adding- pthreads/)

<comment><USER5> EDIT: On second thought you basically answered my question in the last paragraph of your reply, I'm keeping it up in case you want to confirm my understanding, but the way I read it, the 15 % speed up comes from the fact that indeed CPU processing (the regexes) was comparable to the file reading in speed and breaking up the bits to individual core caches is what gives way for the speed up, memory is fast enough for this to be possible.

I don't understand the I/O part of the whole deal. AFAIK you can't read multiple files at once off the drive, so are the files read sequentially to memory and then searched in parallel in memory? Does memory allow you to read multiple places at once, even with multiple threads? Surely the files are too large for the processor caches to be of any effect. So if you'd entertain my curiosity a bit more, is what's happening the fact that multiple files are cached in memory and memory is so fast that loading bits of the files to the processor cache takes less time than regexing those bits, moving the balance of this process to the CPU-bound side? Is the actual parallelism in the fact that multiple cores can search their individual caches at the same time and loading those caches from the RAM is fast enough to not become a bottleneck? Sorry for possibly amateurish question, I've never dug deep enough when it comes to parallelism to understand this, but I spent a good amount of time thinking about parallelising I/O stuff and came to the conclusion that I/O must be magnitudes slower and thus always is a bottleneck and any sort of I/O-bound problem (which file search surely is) must be non-parallelizable and instead can only be sped up by keeping indexes the way some OS's do.

<comment><USER7> One of the more important jobs a system's OS does is manage I/O devices. Modern kernels don't wait for a read request and then go and read from the disk drive. They both read ahead, anticipating future read requests from the pattern of requests already made, and cache as much read data as they can to avoid touching the disk when a file is revisited. (I was a kernel architect on IBM's AIX.)

While coding, your overall system is really just idling and it wouldn't be unusual for many of your projects header files and source files to be cached in memory because of your last compile. This effect is more pronounced on machines with a lot of memory of course. The cost savings from careful disk management is very important overall, but will it speed up the ag application? I'm surprised that ag only gets a 15% speed up with threads, but naturally it will depend on many factors.

<comment><USER5> Very cool insight, do you know if the Windows kernel does the same? I'd like to learn more about it in context of Windows first, then Linux.

<comment><USER7> Yes Windows does disk caching. This looks like a nice explanation:

[https://msdn.microsoft.com/en- us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en- us/library/windows/desktop/aa364218\(v=vs.85\).aspx)

</comment></comment></comment></comment></comment></comment><comment><USER8> There is already a ag plugin for vim that will jump you to the matches.

See: [https://github.com/rking/ag.vim](https://github.com/rking/ag.vim)

or see: [http://codeinthehole.com/writing/using-the-silver- searcher-w...](http://codeinthehole.com/writing/using-the-silver-searcher- with-vim/)

<comment><AUTHOR> Yes, you're right! I mention this in my README:

> Inside vim, vim-grepper or ag.vim is probably the way to go. Outside vim (or > inside a Neovim :terminal), tag is your best friend.

<comment><USER9> No, the way to go is to set the `grepprg` option.

<comment><USER10> And in case you need more flexibility juggling one-off calls to various similar tools, try:

:cex system('grep_or_ag_or_whatever -flags pattern') | copen

With proper ':set errorformat=...', you can call your compiler with this, or 'go test', or much more various stuff (even Go panic stacktraces).

</comment></comment></comment></comment><comment><USER7> Does anyone else have the trouble that I do in watching these short animations introducing some feature? I must be slow because I always have to watch them two or three times to figure out what they are trying to show me. I think if they ran at a more leisurely pace I would comprehend them faster.

The worst are new editor packages; trying to follow what's going on in a Vim session or an Emacs session with the author flying through the features of his or her new package without commentary is always frustrating to me.

</comment><comment><USER11> TL;DR: it does this by generating shell aliases which use $EDITOR to open the file. Neat, but does it clean up the aliases when you use one? And what if you don't use any? Kinda makes my OCD cringe a bit.

<comment><USER12> It looks like the alias file is overwritten with each invocation.

<comment><AUTHOR> The alias file is indeed overwritten on every invocation, but tag doesn't attempt to clean up stale aliases from previous invocations. I figured it wasn't really worth implementing this since, as far as I know, shells don't slow down from having "too many aliases".

<comment><USER13> tag is very cool, but please don't implement the shortcuts with shell aliases:

      ~/badcode$ echo "func" > badfile.go\;\ echo\ \"Gotcha\!\"
      ~/badcode$ ls
     badfile.go; echo "Gotcha!"
      ~/badcode$ tag func
     badfile.go; echo "Gotcha!"
     [1] 1:func
      ~/badcode$ e1
     Gotcha! +1

In case that's not clear, I was able to create a file with a name that contains potentially malicious shell commands that is now bound to an alias via tag.

Other ways to implement the shortcuts: create a flag or subcommand to look up an hit from the results file and jump to it (I can alias this command to suit my taste) or prompt me for input before returning to the command line.

</comment></comment></comment></comment><comment><USER14> This sort of reminds me of fasd[1]. The thing is I think I would prefer a menu instead typing "e6". Typing line numbers to go somewhere seems to be an inherent Vim user trait that I just haven't picked up (ie typing the command plus some number is just too much of a cognitive load for me.. I would rather press the keys over and over again).

Maybe you can pipe ag to the venerable "dialog" (yes that thing is garbage and reminds me of old school RedHat installs) but I wonder if someone has something better.

[1]: [https://github.com/clvv/fasd](https://github.com/clvv/fasd)

</comment><comment><USER15> why not have a separate command rather than shell aliases? i.e.

       $ tag func # returns e1..e4, e5, e6 and dumps them in .tag-locations
       $ tagopen e4 # uses .tag-locations to open $EDITOR

you still have scary global state, but at least it's limited to the `tag/opentag` command. Plus, you can do `tagopen` without arguments and show a menu :)

</comment><comment><USER16> Cool. For emacs, here's an interface for narrowing down `git grep` and `ag` results that I've been enjoying using: [https://github.com/dandavison/emacs- search-files](https://github.com/dandavison/emacs-search-files)

<comment><USER17> How does it compare to helm-git-grep / helm-ag ?

<comment><USER16> Not as good :) Thanks, you got me to finally try out helm and helm-projectile. Mine did a couple of things, like searching for function defense that might be nice to implement in helm-world. I expect someone has already.

</comment></comment></comment><comment><USER18> Another tool that uses ag to look for tags (emacs): [https://github.com/jacktasia/dumb-jump](https://github.com/jacktasia/dumb- jump)

</comment><comment><USER19> [https://github.com/syohex/emacs-helm-ag](https://github.com/syohex/emacs- helm-ag) is also super cool, although it works from within emacs; you can interactively preview the matched areas without opening files, and jump directly to matches. tag seems really cool for people who prefer working more directly in the terminal, though (or people who don't use emacs).

</comment><comment> Pirate-of-SV Cool but I'm not a big fan of the idea by storing "state" in aliases that later commands can reference. (It's better than environment variables though.)

For source code I've had a really good experience with ctags[1].

[1]: [https://github.com/universal-ctags/ctags](https://github.com/universal- ctags/ctags)

<comment><USER20> What exactly is ctags? That README and the accompanying docs seem to only describe how the project has changed from an unseen progenitor on SourceForge.

</comment></comment><comment><USER21> It seems to me that a more generic solution would be preferable. For example, why should this work only with "ag"? Also, this could work with vim to allow the user to skip to the next match more easily.

</comment><comment><USER22> Similarly, I'd love a more generic version of this (kind of like Vim's quickfix and `errorformat`). Typing `make` or `cargo build` and jumping directly to any errors would be extremely fast. :)

</comment><comment><USER23> Cool idea but terrible name. No one will ever be able to google this.

<comment><USER24> [https://www.google.com/?q=tag%20matches%20shell](https://www.google.com/?q=tag%20matches%20shell)

</comment></comment><comment><USER25> Are we supposed to know what "ag" is?

<comment><USER26> If you haven't tried [https://github.com/ggreer/the_silver_searcher](https://github.com/ggreer/the_silver_searcher) yet you're missing out

The progression is grep with a ton of flags (or even find | xargs grep) -> ack -> ag.

ag is faster than ack, automatically understands .gitignore, gives you .agignore as well, and is just a really nice piece of software.

<comment><USER27> ag has issues with .gitignore, as patterns are not recognized properly. The matcher that git uses cannot be included due to licensing (see [https://github.com/ggreer/the_silver_searcher/pull/614](https://github.com/ggreer/the_silver_searcher/pull/614)).

Does seem like there is hope, as a BSD licensed version exists. My fingers are crossed that this is solved soon :)

<comment><USER28> ag uses .agignore

I often need to search only on a subset of the files checked in git. Example, I don't search the min.js files but I need them for the deploys.

It would be nice if they could share the same format.

</comment></comment></comment></comment><comment><USER29> as a long time ag user that is neither using vim or emacs, I salute you!

</comment><comment><USER30> Not sure about this wrapper for an unknown tool, "ag". I don't know, what's wrong with good ol' grep -Hnir ?

<comment><USER31> Ag is way faster.

<comment><USER32> It seems an order of magnitude slower to me:

        $ time grep -r some_token .
        real	0m0.467s
        user	0m0.252s
        sys 	0m0.215s

        $ time ag some_token
        real	0m2.948s
        user	0m0.112s
        sys 	0m3.083s

(Both run twice to ensure the disk cache was warm).

Am I doing something wrong?

<comment><USER33> Could be to do with where you're searching. The fact that ag skips everything in your .gitignore seems to have helped when I tested. Both of these were run at the root of my projects directory...

      $ time grep -r f_admin .
      35.87s user 6.50s system 65% cpu 1:04.47 total

      $ time ag f_admin
      1.51s user 4.94s system 196% cpu 3.284 total

<comment><USER32> I'm searching mostly C code. I'm in the src directory, so there's nothing there except the source code.</comment></comment></comment></comment></comment>


How to Land a Job at Microsoft - <AUTHOR> http://mashable.com/2010/12/26/land-job-at-microsoft/ <comment><USER2> I'd prefer to first read an article about why I would ever want to work for Microsoft in the first place.

<comment><USER3> I'm not claiming that Microsoft is the best company to work for.

But - the "I'm to good to work at company X" attitude will not lead you far. Especially if you say that on Microsoft which still has some of the world greatest minds.

<comment><USER4> The windows and office company still has the worlds greatest minds? There's no working web office, they threw their mobile efforts away. They disbanded their browser team. What makes you think they're smart?

<comment><USER5> Occams razor and statistical reasoning. The likelihood that the population contains a (normal) distribution with a not smart mean while also containing enough technical sophistication to create the products they do seems low.

no business skill Implies no intelligence is false

since

Intelligence => Business Skill is false. Business Skill is not necessary for intelligence.

<comment><USER4> Microsoft's last major revenue making product was ms office.

People want to work for successful companies, Microsoft, despite residual income from previous successes, is no longer successful. Not successful at mobile, not succesful at search, not successful for web development. Occam's razor, people don't want to work for Microsoft.

<comment><USER6> Not really true at all. All of their Server and Tools Division grew to a multi-billion dollar business long after MS Office attained dominance. SharePoint, a $1 billion+ product is just one example.

<comment><USER4> What percent of ms profits do those make?

That's what I thought.

<comment><USER6> In 2011 Q1 for the company, Server and Tools was $3.9 billion. For comparison, in the same quarter Windows was $4.7 billion. So it's a business segment largely created in the past 10 years that is 82% of the size of Windows (one of the most profitable business franchises in the history of mankind).

In the past 10 years the company has tripled revenues and is now the 3rd most profitable company in the Fortune 500 behind just Exxon and Chevron.

I hope my startup should be so fortunate as to make that kind of money. I'd gladly put up with all the ridicule Microsoft gets in the tech community, as I laugh all the way to the bank.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Why is this specifically about Microsoft? It seems applying to facebook|google|apple is about the same, and they're seen as more desirable to most people I know.

<comment><USER8> The article reads like Microsoft paid them to write it.

<comment><USER9> Or, it might have been written for any generic tech company, and then "Microsoft" was tagged on for SEO purposes...

<comment><USER8> It has quotes from Microsoft employees.

</comment></comment></comment></comment><comment><USER10> This is decent basic advice for generic advice on landing a job at any number of tech companies.

His advice on how to answer questions, however, fell short. Just saying "I don't know" to questions is a sure-fire way to terminate the interview loop early. Interviewers at Microsoft aren't primarily looking for knowledge, but rather problem-solving skills and the ability to think about issues. If you don't know something, it's fine to explain that you don't know, but you had better follow up with a discussion on what you think and why you think it.

</comment><comment><USER11> the question I wanna ask: is the writer working or had worked for microsoft? if the answer is no, then the article is not worth reading.

</comment><comment><USER12> s/Microsoft/MIT/g and the topic of the article would be much more interesting...</comment>


Russian Opposition Leader Navalny May Have Been Poisoned - <AUTHOR> https://www.themoscowtimes.com/2019/07/28/russian-opposition-leader-navalny-may-have-been-poisoned-says-doctor-a66601 <comment><AUTHOR> Followup events:

[https://www.rferl.org/a/russia-s-navalny-hospitalized- with-s...](https://www.rferl.org/a/russia-s-navalny-hospitalized-with-severe- allergic-reaction/30079648.html)</comment>