skysight-inc/HackerNews huggingface dataset:
Yeah, this is a fair point. Anecdotally, most of the agencies I've worked with use Bitbucket due to their pricing being based around users as opposed to the number of private repos - the lock-in becomes even tighter if they're running JIRA. Github's private repo limit even on organizational accounts can become constricting pretty quickly.
Because "code over configuration". Personally I'm not a fan of Grunt's API which requires huge json files where keys mean special things. It feels very ad hoc and ugly. Gulp's API is like 5 functions.
Building an organic computing device with multiple interconnected brains
I think it comes down to a game theory style argument. Most people who would undergo this would do so unwillingly by pressure from family, religion, etc. and face large downsides. The small minority that actually desires to do this are hurt by making it illegal, but the large majority that would otherwise be coerced into it are spared.

Many laws banning sexual practices are more justifiable under such laws. If society were different, such a law would be net negative, but instead it's a good idea. Thomas Schelling's "The Strategy of Conflict" talks a lot about ideas like these style arguments and I would recommend reading it. For example, it is often illegal to take or display a picture of your voting ballot, since making that universally illegal makes coercing votes harder.
Actually, we're still finalizing pricing. Please contact us, and we'll be happy to talk. https://captain401.com/join
I had been messing around with Bitcoin in late 2010, early 2011. I gave away the five bitcoins I had towards the end of 2011. :(
Elm is doing some really cool things, but I personally prefer Haskell and a proper FRP library like reflex [1] compiled to javascript with GHCJS. It is newer, so it doesn't have the flashiness and polish that Elm has in some places, but I feel like it's built on a more solid foundation.

[1] https://www.youtube.com/watch?v=mYvkcskJbc4
I'm sure I did a bunch of assembly programming on a CPU that had a flag telling you if the last calculation overflowed or not. Branch if overflow was a straightforward opcode.
The article assumes the use of a signed integer, by passing in values that can't be represented with a signed integer you can't assume the same solutions hold.
> But my god the cognitive load involved in swimming through all of the "this library literally saves THE WORLD" marketing fluff is intense.

The problem with javascript libraries and frameworks is that, since the language itself has so many warts and quirks, it's easy to make a lot of "progress" patching over them with your unique library. So you come out on the other side, having won all these tiny victories, making things more sane, and I imagine most authors will believe their library literally "saves the day", when in reality, it just makes the language suck less.
To be fair, what didn't work for Nylas might well not be an issue for others. There's definitely more than one way to skin a cat, especially in the Python world.
Location: Flexible

Remote: Flexible

Willing To Relocate: Yes

Technologies: C / C++, iOS, Objective-C, Android OS, Java, Perl, JavaScript, JSON, Flash, AS3

Resume/CV:
LinkedIn profile: https://www.linkedin.com/in/rohitrohit
(will quickly mail upon response at rohit.neotheone@gmail.com)

Email: rohit.neotheone@gmail.com
We have used Conda for our first python deployment and the process has been seamless. It provides the same sandboxing concept using virtualenvs and also uses prebuilt binaries for native dependencies so you don't have to build them every time. The only drawback I would say is that we have to install miniconda in our production servers rather than just deploying an standalone package.
I've used fpm to make rpm and deb packages that simply include a virtualenv, it works ok.

One of the significant tradeoffs to this approach is you lose the carefully-crafted tree-of-dependencies that the distros favor, so it makes the package pretty much automatically unacceptable to package maintainers.

However, being able to have install instructions that amount to "yum/apt-get install <package>" is pretty great.

I am hoping for an app/container convergence at some point, but we might need to drop the fine-grained dependency dream and have them be more self-contained, like Mac OS X apps.
those that do, go to med school
Stockholders who hold less than a year are going to have very different goals for the company than those who hold for several years. That's the difference.
Show HN: Minimal MVC Framework for Unity3D
previous discussion: https://news.ycombinator.com/item?id=9736598
> Do any people doing them by hand actually make these investments directly, or do they use intermediaries? Is it that hard to require the intermediaries provide end of year reports?

I use an intermediary, but have to report individual stocks nonetheless (fraud avoidance?) And you can only require what they can provide. During tax season, I have to dive through filing cabinets to fish out the cost basis information that's missing on older investments made before they were required[1] to start recording that information, plus double checking splits online to make sure this wasn't a partial sale that I have to calculate the cost basis on. They report what they have on Form 1099-B.

Right now you have to file a separate Form 8949 for each combination of: (Short Term, Long Term) x (Reported to IRS & Me via 1099-B, Reported to only Me via 1099-B, Unreported to Me), plus Schedule D, plus maybe Schedule B. Last year that was "only" five pages of tax forms filed for two stock transactions + various dividends, plus a few worksheets that you don't file. I forget if there was a cabinet dive.

Given how obtuse tax forms get, a tax-rate lookup for each transaction would probably involve a worksheet per stock, just to do the date time calculation of "how long was this stock held".

[1] At least, I think I read they were required to start tracking this.
Weirdly I am re-starting an old project doing this venv/ dpkg (http://pyholodeck.mikadosoftware.com). The fact that it's still a painful problem means Inam not wasting my time :-)
I wonder if "generics + traits" (where C++ is trying to go) is essentially the same as "no generics + interfaces" (Go's version of the same thing, maybe?)

Edit: On reflection, "traits" is probably the wrong word. C++ has a word for this, but I'm drawing a blank at the moment.
> And thanks to Sir Turing and his friends, you know you can always solve the problem with whatever language/system you have.

I'm tired of hearing this. Theoretically true, but infeasible in practice. Try to build an OS in JavaScript and see how long it takes you.
I think you may have validated what the OP was saying :-) It's $3.25 per user per month, but the minimum order is 10 users. So the minimum price is $390 per year.
Seriously, their #1 reason for not using Docker amounts to "we couldn't be bothered to update our kernel." This reads to me more of an interesting story about how they chose to solve the problem rather than a serious recommendation of how things should be done.
There is a petition on whitehouse.gov to get free identity theft insurance coverage for life:
https://petitions.whitehouse.gov/petition/provide-lifetime-i...
tl;dr people who say 'oh I've been a bit depressed lately' after having a bad week may or may not be suffering from the mental illness known as depression, which is characterized by long term feelings of sadness, helplessness etc. and which generally interfere with the everyday life of the sufferer.

Depression in terms of the mental illness is much more than just 'feeling sad', and involves many more psychological aspects and outward impacts on the persons life.
While there's a lot of truth to this comic, I don't necessarily see it as a bad thing. I think it speaks to the flexibility of JavaScript. Sure, all of the tools and libraries can be hard to keep up with, but I'd rather have lots of community support than none.

I have to admit, I was a JavaScript hater for a long time, up until recently when I actually spent time to learn the language. Now its quickly becoming one of my favorite server-side languages. Isomorphic JS was too hard to resist :)
I have just rediscovered the fantastic FreePascal/Lazarus, and have been thinking up desktop app projects to build. Cross-compile to Windows, Linux and OSX with native UI.
You can still trim how much you read when doing chapter exercises. Just start with the exercises and then search backwards for clues when you're stuck on something. Some books have a "chapter summary" which serves as a kind of directory to the details. That is conveniently located between the exercises and the bulk of the chapter: it practically begs to be traversed in that direction. :)
There is no magic and you don't need any fancy equipment or clothing.

If you want to improve your cardiovascular health, do some cardio 3-7 times per week for at least 30 minutes.

If you have the will/want/time, add in some weight lifting 3-5 times a week.

Lastly, controlling your diet will make arguably the biggest difference in your body composition. If you want to lose weight you need to eat less calories than you burn period, unless you have medical conditions. If you have trouble losing weight you need to count your calories and figure out your TDEE using a calculator(google will pull up a few).

So personally I go to the gym directly after work(bring everything you need in the morning). This works the best for me because it doesn't allow me to get home and be lazy.
Pair this with virtualenvs in separate directories (so that "rollback" is just a ssh mv and a reload for whatever supervisor process) and you get to skip the mess of building system packages.

Also, are there seriously places that don't run their own PyPI mirrors? Places that have people who understand how to integrate platform-specific packages but can't be bothered to deploy one of the several PyPI-in-a-box systems or pay for a hosted PyPI?
Its a typo.
>JavaScript is both easy to get into, but difficult to master.

There's no such thing as "mastering Javascript", because a language includes it's ecosystem, and for JS this changes from day to day...
Bad article title. Doesn't even attempt to show a statistical trend that they're 'coming back' (I would argue with the existence of app stores and the like that they never really left). Does talk about the authors experience of offering a desktop app which is very interesting.
New HoloLens video demos usage in medicine, is more honest about field of view
It's very, very difficult to do what GitHub did. They combined a great sense of UX design with an extremely powerful and necessary backend product, and they figured out a way to make money doing it. GitHub's large bank account and horde of developers allows it to quickly take charge of high-stakes situations and come out on top. (This, of course, is not implying that simply throwing money at the problem will solve it...look at Atlassian Stash, a great product but pales in comparison to GitHub) Open-source projects need money and time too, but most of us don't get paid to work on open-source software, so GitLab suffers from the fact that it's no one's job to create it.

Now that GitLab is getting some funding, it will at least level the playing field somewhat.
It's interesting that this theory is that something naturally occurring, like a volcanic eruption, caused climate change during the time of the roman empire.

I've seen so many studies online that claim that volcanic eruptions can't possibly cause climate change. Are we finally willing to admit that it might not all be man-made?
You can nest a financial asset arbitrary layers deep in funds and holding companies.

See other comments in this subthread that illustrate the various ways to structure assets.
Introducing utility pricing to your Managed Private Cloud
Asked a similar question on Stackoverflow recently: http://stackoverflow.com/questions/30213456/transactions-acr...

Didn't get many useful replies. http://ws-rest.org/2014/sites/default/files/wsrest2014_submi... looked promising.
The strongest El Niño on record may be brewing in the Pacific
It's not about absurd valuations at all, and that you appear to think it is neatly epitomizes the self-absorbed myopia of the Silly Valley tech scene.

How many non-tech people's lives are going to be adversely — and far more adversely than the tech people, at that — impacted by a hypothetical tech bubble popping? (Note the lack of assertion that we're in a bubble; that's not the point I'm here to discuss, and I have no horse in that race. I just think the notion of the fallout of a bubble bursting being limited to tech people and private money is not merely ludicrous, but offensive.)

But they can't code, so why should we care about them, right?
On the same vein as omni, the other reasons are "we don't want to learn a new technology, even though it was made exactly for this purpose" and "we don't want to learn how to install docker-registry."
We have software now, and I don't think anyone with capital gains is doing taxes by hand.
Ask HN: Help me finding a video/talk explaining agile problem solving
I am working with an organisation who is looking for input on how to make the switch to agile problem solving and development. Most material out there is quite technical, I am looking for something that business people can understand and relate to; particularly conversative managers who have worked in the same operations environment for 25+ years. Any ideas? I have watched Peter Biddle's TED talk about how to do agile in a large organisation, but it doesn't really cut it.

Key themes I am looking for:

* The concepts of the agile mindset
* Plan to fail
* Impartial knowledge vs perfect knowledge
* Predictability vs change
* How agile teams work

Any help would be greatly appreciated -- I am sure you have been facing the same challenges.
> The state of the art seems to be ”run git pull and pray”

Looks like these guys never heard of things like CI.
Ask HN: A job interview will focus on PostgreSQL/Redshift. How do I learn these?
I think of myself as someone who can learn new things faster than average, so I think I should be fine. Some guidance would be really helpful though, as I'm not sure what the most important topics to cover are. I do use PostgreSQL, actually, but I mostly interact with it through the Django ORM, or SQLAlchemy. Time to time I hop into the database shell, but my knowledge there only reaches up to simple joins, and even those with consulting the psql docs to get the syntax right. I also haven't really dealt with databases with over even 1k rows.

What are the most important topics to cover? All I know about the interview is what I have in the title, practically.

For reference, I typically use Python, and NoSQL data stores. Redis and Elasticsearch are my main tools of the trade right now for data.
I'm glad someone wrote this up. I would love to be able to control who has access to my WhoIS record and to know when it's been queried and for what purpose. The enormous amount of spam and even physical junk mail that comes from having a WhoIs entry is ridiculous. I once got a credit card offer addressed to me (male) and the woman at my ISP who was the admin contact. Luckily my wife thought it was amusing, but it could have been a huge fight if she hadn't understood.
Back to the future:Send video messages 20 years in the future
Was thinking the same. Even when ajax was getting big, i still recall using a lot of the same programs i did then. A text editor/ide, a browser, desktop games, ms word, etc.
Here I delineate my argument more clearly.

Originally responding to the issue of trucks and roads:

"(...) it seems to me that if heavily loaded trucks are causing a disproportionate amount of damage they should be taxed at a rate which allows for proper maintenance of those roads"

I made the following points, implicitly or rhetorically, now listed in earnest:

1 - the above argument is supported by the notion that taxation should be proportional to usage/consumption

2 - that notion is simple and reasonable and one might expect that because of that, this issue would already be resolved by law

3 - that to expect that this issue already be resolved by law is laughable as one can easily see from a cursory glance at extremely current issues, e.g. the supreme court having just ruled on ObamaCare's constitutionality

4 - that the way we come to make these bad decisions is by calling people trolls, pretending not to see their arguments, or reacting emotionally when they point out an inconsistency in our thinking, instead of offering a refutation based on reason; in this specific case, the counter argument could be some crucial differences between the "trucks and roads" scenario and the "women and healthcare" scenario, both of which rely on the structural notion that taxation proportional to usage/consumption is the fair choice

5 - that if the notion cannot be applied to one analogous scenario then it cannot be applied to any analogous scenario

6 - that (5) is the intellectual rut that leftists live in, which contributes to bad decisions like healthcare that taxes the genders equally

So my claim is that those bad decisions (like trucks taxed as much as cars) come from people who are not able to see that the notions that support claims such as "if trucks cause more damage they should be taxed more" are either universally valid or invalid, which is why emotional arguments are offered to defend those decisions, and why you see this kind of reaction to people like me.
https://en.wikipedia.org/wiki/Performative_utterance
> the ecosystem around Javascript is so densely layered and frequently changing that maintenance of any project over any significant period of time is going to be a nightmare

I hear this sentiment often, but don't really see any truth in it. Nobody is forcing you to update your code to be in line with the latest JS trends. If it ain't broken, don't fix it, and if it is broken, it was always broken and that fact has nothing to do with how rapidly the JS ecosystem is evolving.

Oh, but you want to leverage the latest and greatest that the ecosystem has to offer... well, that's your problem, not the ecosystem's and this is true no matter which ecosystem you're referring to. JS developers are just spoiled rotten because JS is so easy to refactor relative to every other part of the system. When the NoSQL hype train came barreling through the developer community a few years back, most of us didn't rush out to rebuild our applications on a NoSQL back-end because the database is too critical to mess around with.

If you want the latest and greatest you have to pay for it, but don't imply that there is something wrong with the ecosystem for giving you more options. Choosing the best tool is part of the job, and if you get hypnotized by every shiny new toy that debuts on the front page of HN, that's a professional flaw that only you can fix.
Problem: Javascript has almost no standard library. --> Why is this a problem? What does he mean by standard library? Like, "strings", regexes and hashes? Not needed.

Problem: Javascript won't run outside the browser. --> Fixed.

Problem: The DOM is too slow for video games. --> Fixed.

Problem: Javascript is single-thread by design. --> Why is this a bad thing?

Problem: Javascript is too slow for video games. --> [Citation needed]

Problem: Javascript has no packaging or a linker to tie these packages together. --> Linker's not needed, and there are many package managers that work pretty good. Also, since the beginning of javascript you could always <script src=""> whatever you need, pretty cool actually.

Problem: Callback Hell. --> This "problem" only bothers bad/lazy/naive coders.

Problem: asm.js is basically unwritable by humans. --> Nope, and also, you may not need to write asm.js at all.

Problem: Prototypal inheritance is just pants-on-head stupid. --> Clearly a joke to try to use this as an argument.

Problem: Web resources need to be minified and zipped for performance. --> Yeaaaaah right, because Javascript == Web.

Problem: Machine generated output is more difficult to debug. --> As compared to... another machine generated output from a compiled language? Yeah right...

Problem: Async is still a nightmare, huh? --> Same as callback hell.

Problem: Balloning project size and complexity. --> [Citation needed]

Problem: Javascript still doesn't do everything. --> Is this guy serious? Does he thinks this is a valid argument for anything?

Problem: Output runs very slowly on mobile devices. --> [Citation needed]

The guy's just a lazy coder. His favorite language would be one where he could just do: "include <what_my_boss_wants>; run();". Good luck waiting for that one.
The Rust community had a series of long discussions about this earlier this year (see [0] and [1] mainly), and I came out of it thinking that a more perfect world would have arbitrary sized integers by default and convenient types for explicitly choosing wrapping, error-ing, or undefined behavior for overflow and underflow. But there are lots of reasons why that world is hard to achieve (for instance, arbitrarily sized integers require heap allocation and indirection, which makes them quite a different beast), and while I think the compromise Rust came to is fairly awkward, the trade-offs seem pretty tough and the path to an optimal solution is not at all obvious.

[0]: https://github.com/rust-lang/rfcs/blob/master/text/0560-inte...
[1]: https://internals.rust-lang.org/t/on-casts-and-checked-overf...
I don't think that's a fair representation of why they don't want to update kernels and also completely downplays that there were three other points mentioned which all added non trivial overhead to getting stuff done now.

In an ideal world you build a system from the ground up, but rarely is that ever possible and the approach taken to iterate is far more valuable than your requested 'serious' recommendation.
Minnesota does a significant amount of research on road surface materials. There is a section of I94 northwest of the Twin Cities that has three segments of highway, and traffic can be diverted onto one of the segments to test new road surfaces. Here's the MN DOT site with some test videos: http://www.dot.state.mn.us/mnroad/testcells/mainline.html (thrilling stuff).

Now that I'm in MA, I have heard several people say that concrete highways do not last through the winter, despite the large number of concrete-type highways in good condition in MN. Maybe this is the result of careful local road surface research? Roads are certainly better in MN than they are in MA, even though MN has colder and snowier winters. That could just be anti-highway spending sentiment from the big dig though...
> I can now be convicted of tax evasion for refusing to pay

Yes, for refusing to pay. If you concede to the IRS interpretation, you just pay the amount you owe plus interest and fees.

> this arbitrary retroactive tax.

that's not what it is
>Generics is the single biggest language feature absent in Go. It’s often missed by newcomers to Go. But it’s more of a type-system mechanism. It’s unclear if it’s an essential language feature.

Oh, it's clear by now. Though "essential" is a weasel word -- in a way nothing is essential in the sense you can do it all with assembler too.

>Generics are incredibly complex in both semantics and implementation. There are considerable trade-offs to consider, such as do you want a larger binary vs. slower binary vs. larger source code.

Unless I use them, I get none of those downsides. And when I need them, I now have to implement support for my types manually, which results in larger source code anyway.

And "larger source code" hasn't been a problem since 1980.

>Language features without competition: goroutines, interfaces, defer (now in Swift)

Those have been around in several other languages... Hardly "without competition".

>Tools without competition: fast compiler

It's fast because it's not doing much. And there are several compilers that are fast too.
I use conda as well and found it to be great. I love how it detects and manages dependencies for you when you install a new module.