Cartwright2

Now I understood none of that, but it sounds like a hack to work around something they tried to fix, or is an ugly way of gluing "old" libraries into "new" libraries which should be handled by the compiler. This is just one example of many complexities I worry are going to bog down any developers who take on ASP.NET Core. Remember we only have to face one compiler error caused by this issue before having to do a deep dive and learn all the inner details to fix it.

I am also concerned about the quality of the tooling. DNX can't handle long paths so I have to develop out of C: drive. This reminds me of Node's almost incompatibility with Windows and makes me worry that the tools haven't been thoroughly tested. DNX is going to be replaced yet again in the near future with a newer, probably less tested set of tools.

On top of that the tooling doesn't work well in enterprise because they have poor proxy support. I'm also worried about "everything is a collection of hundreds of tiny packages", the NPM dramas have shown us that micropackages lead to insanity. ASP.NET was a place to hide away from those kinds of things. Now it feels like it's "C#, as developed by the node community". I think they've tried to make things simple but haven't seen the forest for the trees. The fact that they're bundling dead tools like Bower into the project templates is also worrying. They should have had the forethought not to include any JS libraries that have a high churn rate.

One final thing bothering me is the number of choices of the target framework. Why have there been so many meaningless names like "dnx451", "netstandard", "netcore10"? I sit down to make a web app, and I have no clue what I actually need to target. In the old days we'd pick a .NET framework version and choose either the compact or complete framework. When did this become rocket science?

This was a good article about the stresses of entering a programming career.

The strained sexism tie-ins were unnecessary because most of the challenges she faced are universal, I remember hearing the same gloating conversations and feeling the same way when I was young.

As for the back massages and tshirts with men's names on them, that is a bit weird and should probably be taken up with their supervisor if it continues. It's most likely to be caused by poorly calibrated social cues than straight up sexism. There's nothing sexist about awkwardly showing interest in someone, it's only a problem if they don't take no for an answer.

Chariot for Men:

The premise is the same as all the other ridesharing services, There’s a driver app and a client app, except that what makes us unique is our safe driving feature that other apps forgot to do. We ensure every driver in our entourage is a male.

It's a crazy world we live in where someone would post such a candid article about their own under-performance. This article is embarrassing to the individual, and more importantly, to the company that fired him. I think people need to think more carefully about what they post online especially when using real names. This is permanent now. Any potential employer who searches this man on the internet will see this and I don't think that's a good thing. While some might not be turned off by this person's honesty, I certainly would not hire him having read this article. If anything it shows a lack of a diplomatic filter, not only a lack of discipline.

> I'd give it a personality and a set of values and a rudimentary understanding of how the world works.

I don't think you have any idea how complicated such a task would be.

Is it possible to create and verify a PayPal account against one of these cards? This would allow users to have pseudonymous PayPal accounts. It always bothers me when I go to make a donation that I have to give my real name.

Before deleting your account you should edit out and overwrite as much information as possible. Things like your name, e-mail, and any other fields should be falsified before deleting. You have no way of knowing if their "delete" mechanism just flips a deleted bit or if it actually erases your data.

The problem, in this case, is that the company might notify your employer that you're making those changes. Not sure what I'd do in this case. It might be worth creating some dummy accounts to see what actions actually trigger notifications.

I was banging my head against this earlier last week. It was such a jarring change to visit GitHub and not be able to navigate. It gives me pause to see how suddenly an easily-navigable site can become almost impenetrable with the removal of a single search bar. What are they thinking? The "Explore" menu is worse than useless, too.

It is an interesting case study in UX - the difference between a great experience and an awful one can come down to a single, well placed search box.

What is GitHub's rationale behind this jarringly awful, blatantly bad decision?

How are people able to develop on chromebook-like devices with 2GB RAM? I'm seeing a lot of such devices in this thread and don't understand it. Once I spin up a couple of database servers, a few Visual Studio solutions for the various products I work on, and a handful of testing tools I'm easily pushing 12GB ram or more.

Are these low-end machines being used as hobbyist or frontend-only web development? I can't think of any other explanation.

To answer the original question: Thinkpad X220. i7. Maxed out RAM. It's no portable workstation but I can push it just as hard without worrying about it overheating or failing.

One man's "saving money" is another man's "robbery".

Set up a scheduled transfer from your checking account to your own savings account if you can't manage your own money. Don't encourage these kind of rip-off merchants.

I disagree with the title - I don't think this is a sad state at all. This looks very healthy to me. Backbone clearly had a purpose some years ago and it is unequivocally deprecated now. To me, this is a javascript library aging gracefully and opening the way to newer, better libraries. By removing itself from the list of relevant libraries to choose from in the current year, backbone has helped to reduce decision fatigue.

I hope other Javascript libraries and framework follow this trend until we find a handful of "winner" libraries in the same way that each language has its own "winner" MVC library.

Why filter your cousin's world view when you could show him all available options and let him make an informed decision himself?

Microsoft isn't so "bad" any more with their shift towards open source.

> You don't need a firewall on individual machines either; just don't run network-facing services in the first place

I disagree. Firewalls fail closed under user error. The solution you proposed (we'll call it conscientious-wall) fails open under user error. That's to say, once a firewall is set up it will protect me from outside intruders unless I specifically tell it not to. A "conscientious-wall" will not protect me from outside intruders unless I specifically remember to apply it whenever I install an application or download a software update.

I'm still firmly in the camp of having at least an inbound firewall on every machine.

When you say firewall, do you mean a firewall on the edge of a home LAN? Because I still see a firewall on each individual networked machine as being extremely important.

> We fucked up the front door, but we totally won't fuck up the back door.

This is the most apt summary of this whole situation. I expect to see a family-friendly version of this phrase in the media over the coming days.

I dread helping anyone with iTunes related issues. The syncing process is dangerous, it's far too easy to wipe someone's collection of music / family photos / pictures. I'm not sure if this is an isolated issue but I start sweating bullets as soon as I have to connect an iDevice to iTunes. What really shocks me is that instead of showing a big red warning message before a destructive sync, it silently goes ahead and wipes data without even asking. And there's no easy way to tell what a sync is going to do. After any iTunes sync I generally think "Ok, now let's assess the damage".

To add insult to injury it's almost impossible to make a file-for-file backup before decimating a device with iTunes sync. In fact, the iTunes sync process is the main reason I stick to Android despite it having a whole other ecosystem of flaws. I'll take a USB Mass storage device and robocopy / rsync, thanks. They actually work.

Wasn't there a similar issue in another browser here on HN recently? How does this actually happen - two different security companies both push out "secure" browsers that are fundamentally insecure. I'm not even in the security business and I know it would be fatal to publish a Chrome build without cors. What I can't understand is why would they ever disable it? Seems almost like an act of malice.

I sympathize with you that the UEFI implementations are bad, but I don't agree that it's an excuse for everything on top of UEFI to be bad.

I think the two competing ideas are:

Either you make libraries that strictly conform to the spec and are "technically perfect", leaving any bugs that stem from non-compliance to the violating parties (i.e. the UEFI implementors)

Or, you make libraries that conform to the spec and have some "dirty" handling to work around holes left by crappy UEFI implementations.

The first options feels great to write as a developer, but the second option is what most users really need - it's the "it just works" factor that users care about. I know it hurts to code around shitty implementations, but there's no other alternative if reliability and idiot-proofing matters.

The best I can suggest is to make the workarounds "pluggable" so that developers don't have to deal with the harsh realities unless they specifically go looking for the plugged-in workarounds.

Reading poettering's response (https://github.com/systemd/systemd/issues/2402) I'm left feeling like he needs a thorough "Mauro, SHUT THE F* UP" response from Linus himself (https://lkml.org/lkml/2012/12/23/75)

Found the guy who's difficult to work with...

Seriously though, every company has had to deal with one of these people sooner or later. The cost to team morale always outweighs the talent of the difficult developer. Let them go, let them learn, and hope they fix their act at the next company. It always hurts to throw away talent.

Are there any "reputation-based" tools available for home users? I have always wanted a tool that would visually show me every device on my network and give a clear indication when a new device was added.

React isn't slow.

> People should always create and attempt improve upon whats out there. Don't try to stifle innovation...

I agree completely and my argument is that a lot of the Javascript libraries being pushed around over the past three to four years are neither creative nor improvements over what already exists. React is innovative. Redux is (arguably) innovative. jQuery was innovative. Many other libraries have been innovative. I'm arguing against the hundreds upon hundreds of "me too" libraries that make it so much harder to find the truly innovative stuff. These libraries do nothing but add to decision fatigue. Developers have to make decisions, sure, but we need to have limits too.

I think, and hope, that the "modularity" of the Javascript ecosystem will lead to extreme decision fatigue, followed by a doubling-down on the best individual modules, aggregation into larger, monolithic frameworks that work well, and finally an increase in developer productivity and standardization of the choices of frameworks. At this point, the Javascript field will no longer be in shambles as it is today.

All it will really take is one person to merge, say, React with a boilerplate-reduxed Flux framework, a REST library, and a handful of other must-haves, under a single, new product name. Let's call it "Rimble". When people realize they can "import { Component, Actions } from Rimble" we'll see a shift towards monolithic frameworks and the ball will start rolling back in the right direction.

I'm not sure that we should be doing this.

Yes, it stands to reason that if you take framework X, cut out a lot of functionality, remove some of the "ugly" code that addresses edge cases, then you end up with a similar, reduced framework which is smaller in file size.

But this is done at the cost of polluting the Javascript framework environment. The biggest problem right now is pollution, we're all drinking from the fire hose of frameworks and someone needs to cut the supply so we can double-down on the good stuff and stop jumping from one framework to the next like a plastic bag caught in a strong breeze.

Preact is now a decision point for any developer who Googles "react alternative" and scans far enough through the search results. This isn't right. This contributes to decision fatigue. It's time to stop churning out new frameworks that are only marginally different from what's already available.