skysight-inc/HackerNews huggingface dataset:
> The majority of my job consists of maintaining about a dozen legacy Rails 2 / Ruby 1.8.7 applications, written between 2008-2010, [...]

I would be sick of that, too.

I'm also sick of criticism on Ruby when you actually want to criticize Rails. There is a significant overlap in the two communities of course, but both have a distinct profile and you can't just lump them together.

In this case, it's also not helping that they have to stay on an ancient Rails version. With Rails, it's a much smoother experience if you can follow the major releases but especially the upgrade to Rails 3 was a painful one.

Edit: I don't want to imply that you shouldn't criticize Ruby but if you do, don't confuse issues of Rails with those of Ruby. Rails and Ruby code do have quite a different feel to them. It goes this far that when I write a clever little Ruby snippet in a Rails app, I almost feel dirty as it doesn't belong in there.
Beyond agile: why agile hasn't solved your problems
How to contribute to Open Source if you are a cat
see also discussion yesterday (different article about the same thing): https://news.ycombinator.com/item?id=15634014
It's very easy to upgrade React incrementally. The only problem is that it's likely not so easy to upgrade your related dependencies incrementally. Especially if they use internal APIs or aren't regularly updated.
Mazda and other partners won't get solid state batteries from Toyota. They cooperate on a shared platform for EVs, not on the batteries tech.

Source: http://www.thedrive.com/tech/15514/toyota-wont-share-solid-s...
I'm not buying this argument.

There's a Rails way, Python famously aims for one obvious way of doing things. That just isn't true of Javascript exactly because there is a history of developers writing several styles of JS, the "right way" to write JS being redefined by diligent people like Douglas Crockford & John Resig and things changing yet again and yet again.

And look at ES6, the JS ecosystem barely resembles what was considered good, idiomatic Javascript just a few years ago. There are a bunch of devs who have managed to stay on top of what's current and I'm sure are laying down examples of good practices & building tools in that style. But you are also talking about an ecosystem that includes people that started writing JS 4-10 years ago, have adopted some of the absolute newest flavor of the month practices but also have seen JS change so much over the years that they aren't throwing themselves into everything that is now considered a best practice because they know their code works and there could be another seismic change in 8 months.

Writing Javascript nearly every line of code is haunted with "is this still the way I should do this?" and no other language has that much hassle.
They may no longer be anti-Catholic but are they carbon neutral?

The times they are a changing.
E.g. depends on whether you consider simply grabbing women by the pussy as a human rights abuse.
> "stdlib can be patched to do random stuff" is a complaint I've often heard about Ruby, but in practice, I've encountered it precisely once in the last five years

We've had something like 20 of those in the last year alone. 70% of those come from Rails, and some have been quite severe. Maybe it's tied to what we do which is definitely not a simple app, for which Ruby is not entirely the right one for the job but it's definitely not obviously the wrong one either. With years of business logic, tuning and bug fixing there are things you should never do[0], but even coming to terms with what Ruby is and what its limitations are after all these years in the trenches doesn't mean we can with absolute certainty avoid getting hit by structural damage coming from idiomatic flaws which we have clearly identified through proper root cause analysis to be endemic to the Ruby way (which includes a complete disregard for backwards compatibility, even when it can trivially be made so[1]).

[0]: https://www.joelonsoftware.com/2000/04/06/things-you-should-...

[1]: https://bugs.ruby-lang.org/issues/10085
Ban killer robots, experts urge Australian and Canadian leaders
Ya'll can thumb your nose at JS all you want. Haters gonna hate. I'm starting to question whether this HN mindset is healthy. People get trapped in this vortex of us constantly chanting about how horrible JS is, and totally ignoring all the incredible things we can do now. It's worth pushing back against this echo chamber and reminding people that you now have the power to grant wishes on command. Someone wishes X exists, and for most values of X, if it's technology and you can shove it into a web browser, you can make X appear out of thin air. Like, within two weeks. How incredible is that? And it's mostly due to JS, not in spite of it.

Let's put it this way. Think of your favorite language. Favorite paradigm, whatever. All the shit you hate about JS, picture the exact opposite of that. Now imagine that the web was entirely built around that.

Surprise: now everyone would hate exactly whatever you love. It would've grown all that hair and all those warts you currently despise about JS. It's what the world does.

So when people knock on JS, it's getting much harder to take this stuff seriously. I've been a dev for over a decade and have been down a dozen rabbit holes, from C++ template metaprogramming to .NET nonsense to elisp verbosity to hardcore functional + immutable paradigms. Loved all of them, each in their own way. What we have now with JS is simply incredible from a raw "get shit done" perspective.
what's messy about drawing?
That's good to know. React Router is the only thing stopping me from updating to React 16. I can't find an NPM package, so assume you need to point it at Github?
Every web application requires at least 2 languages (a sever side language and HTML). Virtually all of them also end up also including Javascript and CSS. And Javascript as a server side language is relatively new. That's not a great argument against Rails.
Job hop.

Early in your career, your skills and market rate improve so quickly that a single employer just can't keep up.

You'll be twice as good at what you do next year. And you'll be even better at picking up new technologies. Repeat this four times at four shops in four sectors and get demonstrably good at lots of stuff. Build artifacts you can point to that prove how good you are.

The sad truth is that no matter how good your first few jobs are, you can't keep them (unless you got hired by Google or Facebook right out of school, in which case you can ignore all the above and coast along until you vest.) The company that hired you as a new grad for an entry level salary will never give you 50% raises four years in a row. The market as a whole will do that though.

Early on, it's all about building up your market rate. Get that up to where it belongs fast. Then find the place you want to get comfortable.
For desktop your options are:

— FX 8350 (Piledriver) from AMD with no PSP: very cheap, no flashing necessary, but not the best performance. Single core performance much worse than even Pentium G4620[1].

— Some Intel processors and a Raspberry Pi: much better performance but you have to ME_Clean the firmware, hence the Pi.

— POWER9 processor for amazing performance and completely open & free firmware all around: the CPU is $400 but you get $400 worth of performance, PCIe 4.0 etc., however the only mainboard you can get right now costs $2000, and it’s not x86, so you’d need to run your Windows VMs (if you need) on a seperate box.

Personally I recommend used IvyBridge-EP or Haswell Xeon E5 system, make sure it takes ECC DDR3 Reg ram and you can pick up lots of very cheap DDR3 ECC memory to go along with it.

Performance is pretty good, on par with mid level Ryzen[1], and it’s recent enough to have all the hardware extensions anyone cares about.

[1] http://cpu.userbenchmark.com/Compare/AMD-FX-8350-vs-Intel-Pe...

[2] http://cpu.userbenchmark.com/Compare/Intel-Xeon-E5-1650-v2-v...

EDIT: Post before wrongly stated that you need pre-Skylake chip. Skylake/Kabylake µarch is also an option now, however some restrictions apply. I don’t think it’s very good value though, at least until Coffeelake is compatible.
Making Your First Machine Learning Classifier in Scikit-Learn (Python)
God is a using 4 dimensional Autocad, unaware that his gears and cogs have created life. that's my guess.
Yeah, using syscall to get uniqueId is kind of controversial...
Bayangtoys X16: Inexpensive, durable, hackable GPS drone
> What? It's certainly not the business role to make any moral decisions

You forget that businesses don't make decisions at all. A business is not a person, it has no capability to make decisions. The employees that work for the company make the decisions, and they certainly have an obligation to behave ethically.
Did they ever find backdoors, or are they still pure speculation?
It's the literary equivalent of a big woollen blanket. Best read in winter, with a warm mug of mulled wine.

It's wonderful.
same thing with google.com and google.com
Coffeescript isn't part of Rails anymore.
Everyone who has used Ruby for some time (at least one full project) will have different bad memories, as well as probably some very happy memories.

Few would dispute that Ruby is a great language for getting things done with small, expressive code. And Rails, which is what probably brought most of us to Ruby, was at its time the ideal web framework. It was able to be generations ahead of most other frameworks because of the capabilities Ruby afforded it.

However, time moves on, versions of the language, framework, and gems change. Projects grow and evolve. These are where the pains really begin. But this is not really so much about the language but about real world project lifecycles.

For me, the first real pain was performance. At some point, you cross a threshold where the performance goes from reasonably ok to WTF is happening?. Then you start profiling and discover that the wonderful collection and ORM operations you've been doing are extremely expensive. That's when it stops being fun.

Then, if you explore other languages, you may discover the absolute joy of Clojure (once you devote the time to think functional and appreciate Lispy syntax). Plus you get a big performance boost (as well as access to tons of Java libraries that are usually very performant). But alas, then you discover that there's no real Rails equivalent for Clojure. (I now understand that there are great options if you're willing to cobble your own together.)

Finally, you might hear of Elixir + Phoenix. Suddenly (again, if you're willing to learn and think functionally), you find joy. Performance is much better than Ruby, the Phoenix framework feels Railsy, and you get the benefit of the industrial Erlang VM underneath it. The downside, however, is that Elixir and Phoenix are young. Fortunately the community is friendly and helpful.

For me, it's not that Ruby is bad; it's just that I now realize how much better functional programming is for me personally. And when I just need something quick and dirty, Python is already installed. Ruby is like an ex-girl(or boy)friend that you still like, but who no longer fits into your life.
Millions of Targets: A Macroscopic Characterization of the DoS Ecosystem [pdf]
>Ruby is "too magical" for its own sake

Magic is extremely useful in the right place (e.g. building ORM or admin frameworks) - these can save you from writing a ridiculous amount of code.

Unfortunately since it's an 'advanced' feature lots of programmers want to shove it in places where it not only isn't necessary, but is actively harmful.

Python has all the same features and allows you to write code that is equally horrible (or powerful), but it benefits from a cultural bias in favor of simplicity.

That said, I've still seen unnecessary magic code written by people looking to prove that they are no longer "intermediate developers".

>People sell TDD like a OCD inducing religion instead of something that might be a good idea in some specific cases

I think TDD with integration testing works in almost all cases, but unit tests fail or work poorly in about 85% of cases. Unfortunately, unit test driven development is what the zealots preach.
Show HN: Serverless logging to S3
Tarantool: when it takes 500 lines of code to notify a million users
DEFCON 25 wifi and radio hacking talks
I am glad you are enjoying Ruby and OOP, but this is not a place to be rude to others.
But you are also talking about an ecosystem that includes people that started writing JS 5-10 years ago, have adopted some of the absolute newest flavor of the month practices but also have seen JS change so much over the years that they aren't throwing themselves into everything that is now considered a best practice because they know their code works and there could be another seismic change in 8 months.

Again, this is a symptom of the "one toe in the pool" syndrome. You have to throw yourself in.

Yarn is a perfect example. It came out very recently, relatively speaking. And yet it's clearly the future. Like, the only reason not to use yarn is if you have a legacy app that explodes for some reason if you try to type "yarn" instead of "npm install". But the common case is that you do "git clone foo && cd foo && yarn" and everything works perfectly.

It's so much faster, and almost never causes problems.

So why embrace that? It sounds like horseshit yeah? I hate to use heavy handed metaphors like that, but that's exactly the feeling that you get when you hear "Oh, now we're supposed to use yarn? what? npm install isn't good enough now? Those fucking JS idiots have no idea what they're doing."

In reality, you're seeing evolution in action. This is what natural selection looks like. The good ideas triumph. And yes, it's subjective what constitutes a "good idea." But when yarn comes along and makes all my npm installs 3x faster, you bet I notice and you bet I embrace it right away.

That's what I mean about throwing yourself in, though. If you don't actually force yourself to love this stuff, then of course you end up hating it. It's insanity incarnate. Yet if you just embrace that fact, and take it as a given, you can actually find it quite fun. It's an adventure to get to learn these new systems, not a chore. If you run across something that doesn't seem to make sense or doesn't work for you, just ignore it.

It just seems like we as developers run the risk of having our heads stuck so far up our own rears regarding our favorite language paradigms or the lack of greenthreads in JS or whatever it is you hate about the ecosystem, that it's very easy to lose sight of the bigger picture. Right now you can build a team of 50 engineers, and if you choose React, that codebase probably won't devolve into utter chaos. React makes it possible to do large-scale coordination. Like, I can send you my React component and it'll probably work in your codebase.

Ditto for Vue. If you hate the complexity of React, and you're a small team (usually just you alone), then you can just use Vue and not have to care at all about React+Redux's monstrous complexity.

You see? You can pivot however you like. If you hate X then just avoid X1 It's really hard to take these concerns seriously when there are so many options.
"What Minnich would like to see happen is for Intel to dump its MINIX code and use an open-source Linux-based firmware. This would be much more secure. The current software is only secured by "security by obscurity".

Changing to Linux would also enable servers to boot much faster. According to Minnich, booting an Open Compute Project (OCP) Server takes eight minutes thanks to MINIX's primitive drivers. With Linux it would take less than 17 seconds to get to a shell prompt. That's a speedup of 32 times."

Anyone else think this is article is pretty FUD and crap? Not saying Minix has been security audited or is more/less secure than a Linux alternative, but there's something to be said for microkernels at the ME layer.

The OpenCompute annecdote (uncited?) doesn't designate whether Minix in ME is the bottleneck, or whether it's just slow to boot (it probably is when you're booting it with a platform worth of devices).

Good to know my involuntary shudder when opening a ZDNet article isn't entirely unfounded.
I'm aware of it. The difference is most European countries have no real way to extend their military or economic power meaningfully.

Only US is capable of invading almost any country it wants relatively easily due to its huge navy and aircraft and military bases all over the world. With its huge economy only US can really put meaningful sanctions on foreign countries (US navy basically singlehandedly controls international maritime trade). Notice that almost all sanctions are led by US as EU just nods in agreement and does whatever US tells them to do.

So similar hypocrisy from European countries is less dangerous but US with its power akin to British Empire before can literally rewrite borders around the world and overthrow governments at whim. So when US says Saudi Arabia is an ally and Iran is enemy, that dictates the policy of the whole western world basically.
It's actually really simple why we can't all just throw ourselves in 100% to every new thing. Instead of learning a new tool I could be writing app code for my client or employer who needs the code for their business. I have a finite amount of time & energy so I try to use it well.
Ask HN: Has anyone learnt to love art?
I don't feel much emotion, if any, when viewing art. I know I'm missing out on a universal experience (http://slatestarcodex.com/2014/03/17/what-universal-human-experiences-are-you-missing-without-realizing-it/).

Has anyone else faced this challenge and overcome it somehow?
I consider forced repatriation to be a no-go. Others probably disagree with me, maybe even Tim Cook himself. IMO if you force companies to do something like that with their capital, then they won't incorporate in the US.

I do want to talk about loopholes. How do we close the "repatriation loophole"?
You mean TI's MSP430
Makes me wonder what Tanenbaum thinks of the arguably most common MINIX deployment. Considering that their conference has been cancelled [0] it would seem that this OS is largely unexplored and by extension not thoroughly audited.

[0] - http://www.minix3.org/
I'm not really trying to make an argument against it anyways. IMO if you haven't jumped in early in the Rails's lifetime, it's really hard to catch up; this is what I'm saying.
> The project I'm working on has over 1000 modules in it's dependency tree.

Why is that a number you care about? Is it causing you actual problems during development, or are you just offended that it's a big number?
‘Family Guy’s Risqué Kevin Spacey Joke from 2005 Resurfaces
> I don't really see how this would be much more different from language to language. The being 'sick of' part, not so much the specific irritations. Every languages has its issues and from all the languages I have tried I have found Ruby to be the most pleasant to work with, but I am sure this is different from person to person.

And yet I never see people getting sick of functional programming after a few years. People either try it and dislike it immediately, or they switch and don't go back.

There really are better and worse languages, better and worse ways to write software.
Here's an implementation of "deep equality" -- a relatively common operation on composite values -- in JS. It has millions of downloads in just the last week: https://github.com/substack/node-deep-equal/blob/master/inde...

It includes special cases for dates, takes O(n log n) time in the number of keys, and has suspicious comments like, "I've managed to break Object.keys through screwy arguments passing. Converting to array solves the problem." There are 15 open issues and 15 open pull requests. A sane language would have this operation built-in.
Which company you work for I’ll give you a reason to quit in 5 minutes.
Why are US mass shootings getting more deadly?
> Also, it is possible that another set of pages could be allocated directly after ours in memory, in which case we wouldn’t detect overwrites beyond the last page. [...] For the second issue, we could reserve an extra page after our pages, but not commit that page. No other object could then claim those addresses and writing to them would still cause an access violation. (Note: This only works on Windows, where reserve and commit are separate operations.)

On Linux (and POSIX in general), you can do the same thing by allocating the guard page as described, then setting its protection to PROT_NONE using mprotect(2). Any access to the page will cause an error.
After a while you can just spot it, LaTeX has a much higher quality typesetting and layout engine than Word or other WYSIWYG on-the-fly editors.

The easy way is usually to spot some of the no-no's of layouting; single words at the last line of a paragraph, sentences spanning over page breaks, spacing in block paragraphs, etc.

It's easiest with letters or invoices with some text, where the spacing and word placing is most obvious but you can usually tell in CVs with less text too.

Of course, sometimes Word gets lucky and does a proper layout, but I've found that it's rare that I get to see properly layouted word documents.
Yes it's whataboutism. Human rights violations aren't binary and the Saudi variety is in a different class entirely from the US.
It isn’t about ties but about history, culture, traditions and wealth.

Take my home country Norway, since we are on the list ;-) It is one of the richest countries in the world as well as most equal which tends to lower corruption. Poverty and inequality raise it.

But of course history and culture matters too. Norwegians have had a reputation for honesty for hundreds of years. In some ways it is self perpetuating. There was a story about a Norwegian sailor who had cheated a prostitute in a foreign city. This angered the other Norwegian sailors who made him go back to her next time the landed to apologize and pay her compensation. To them this guy was risking the reputation of all Norwegian sailors. Something they benefitted well from.

When you got a reputation you become invested in it.
It is always possible to publish without affiliation, but I'd recommend you try and "get" some affiliation nevertheless. Many universities have interest groups, reading groups, loose projects, etc., that in principle anyone can join, and in most cases all you need is one project leader or professor interested in your publications who allows you to mention the affiliation. For instance, at our institute we have the status of a collaborating member, which includes anyone from the outside who works together with someone from the institute on a project. There are restrictions of our funding agencies of what we can count as a publication of our institute, of course, for that you need to be an integrated member, but that's another issue.

At least that's how it works in many places in Europe, I imagine some places in the US have stricter conditions, especially the top universities. Anyway, contact some people at universities and see if they are interested. That's my advice - assuming that your planned research and publications are of high quality. If not, you're going to have a hard time convincing anyone, of course.