Slashdot is powered by your submissions, so send in your scoop


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 Internet speed test! ×

Comment Re:No brainer (Score 2) 173

But arguable robots.txt should not be a way to retroactively mark previously archived content as inaccessible.

Exactly. The policy where someone with no interest in a site (i.e. takeovers, lapsed domains, etc) can retroactive wipe all archives with just a couple lines in a config is flat-out wrong.

Ignoring robots.txt entirely, though, is a bad idea. Some sites use it to block archiving, sure, but some others use it to tell robots to avoid places where they'll never return from. There's a case for ignoring "Disallow: /", or anything that's significantly different from what, say, the Google search indexer is allowed to see.

Comment Don't improve my screwdriver (Score 1) 388

Or rather do, but don't force me to buy a powered screw remover that needs charging after 20 minutes of use and can only be controlled via bluetooth from an iPhone. Old versions of software should be at least sold it is indefinitely, or placed in public domain if the maker no longer sees a profit from a particular version when the new one is available. It would not be crazy to provide security patches and basic usability updates so long as that is economically viable.

What is actually happening today is worse. A lot of times it is not possible to reinstall or even use an existing install of a software version you paid for, when the new version has removed functionality that was your reason for buying the product.

Constant volatility has in turn devalued software. If I am sure that a particular application will consistently serve my regular needs for 10 years like a screwdriver does, an $1000 investment does not seem crazy. But if your company could go out of business tomorrow and I will be left out in the cold, how can I justify spending anything at all?

Comment Well, yes (Score 2) 388

I can definitely understand that sort of reaction for developers, especially if you're talking about small open source projects... those are projects which usually scratch the itch of the developer, so feature requests are definitely going to be an uphill battle if they aren't interesting to the developer (for some definition of "interesting" which might mean "actually useful", "fun to code/play with", "that code is shit and needs refactoring anyways", "suggestion in the form of a patch/pull request", etc).

I think users see software development effort as zero sum; if someone is working on a feature they aren't interested in, then someone isn't working on other stuff they think is important. It's a well-known phenomenon that often comes up when someone talks about the complexity of Microsoft Excel (in the form of the 90-10 rule)... users don't see the bigger picture and only care about their own workflow and how changes impact them.

The easy solution is to simply not give a crap about the opinions of other users of whatever software you use. They don't have your best interests in mind either.

Comment Re:To do list (Score 2) 58

Could be worse. Step 3 could be "get paid to write some pointless crap for Office 365 while a completely different team writes a shittier version of pointless App that doesn't do half the stuff that pointless App did in the first place."

Microsoft has shown an amazing ability lately to take the Golden Goose, kill it, throw it in the oven and then render it into a greasy pile of charcoal. Granted, they're no Yahoo! or Oracle, but they've got the touch.

Comment Re:I wonder... (Score 1) 445

In my experience as a team lead/hiring manager:

* We had a simple test that any developer should expect to pass.
* Hiring with highly competitive wages and benefits in one of the top tech markets in the US
* We only interviewed people with a degree in computer science
* We had a lower than 20% success rate at candidates writing working code (even ignoring syntax problems and semicolons, and just looking at logic flow)

What was this massively hard test?
1) Write a function that uses recursion to output the Nth iteration of Fibonacci (test includes full explanation of what fibonacci is)

2) Write a function that determines if a given year is a leap year (test includes full explanation of how to evaluate if a year is a leap year)

Nothing tricky at all, a simple "have you ever written code, and can you follow instructions/requirements?"
My 11 year old can pass this test. Tons of people with "Master's degrees" and "10 years experience" have no idea where to start.

It is not shocking that 95% of developers from *ANY* pool of people are worthless. It is not limited to any nationality or country of origin.

Comment Re:Seriously? (Score 1) 358

How did so many people think this was a bright idea?

There's a lot of people out there who seem to think that the more money they spend on a "health product", the healthier they'll be.

I... honestly don't know how these people seem to have the disposable income to pay for this stuff. You'd think they'd have been fleeced and left in a cycle of poverty shortly after moving out of their parents home...

Comment Re:It already bears fruit (Score 1, Informative) 619

Only hours after the announcement, corporations all over America started hiring lawyers to find new loopholes in the law.

Given the "swamp draining" skills Trump's shown so far, I'm expecting that he's going to outsource the implementation and enforcement of the H1B program to an Indian corporation...

Comment Distraction from:The Promise reviewing poorly. (Score 1) 480

This seems to be an article about brigading; but it is not. This article is an attempt to get ticket-buyers to distrust movie reviewers by inflating the perceived effectiveness of stupid IMDB reviews.

Look, Turkey is fucked up and the Armenian Genocide is a real thing that is important. This movie is mediocre at best, according to a bunch of movie reviewers who are probably (almost certainly) not on the Turkish government's side.

It can be both: Botters could have deflated the IMDB rating and the movie could still be bad.

IMDB ratings are garbage, professional movie critics aren't that great either, but they are also not under the sway of the Turkish Propaganda machine, and they think it is a boring cookie-cutter movie.

So I would say it seems more likely Hollywood is gaming the battle against critics, by exposing online trolls, and using the narrative in its own favor.

Comment Well-defined Devops. (Score 1) 313

Developers code. Developers review code. Developers write code to test code.

Developers can't touch production.
Automated checks of ANYTHING are golden because you aren't relying on people, and you aren't pitting people vs people.
It is all about consistency when you boil down to the bones of a well-running team.
Start with those rules and actually follow them and you end up with a pretty awesome setup, because Developers will naturally gravitate to defensive, test-driven programming when those are the rules.

1) All code is reviewed before it is merged, this is easily enforcable in bitbucket or github, probably others, but use one of these two anyway. It won't stop all your problems, but it is great triage and it forces lone-wolf mitigation. I don't even care if the reviewer is an expert... this isn't a gate keeper activity as much as it is a sanity check. "hey why did this variable get set, then re-set before you checked it?" or "hey how come you deleted 90 source files?"
2) All your code goes through some kind of code-quality gate like Sonar Qube or some other Linting tool. This can find and highlight common mistakes, and get them fixed before they are even reviewed. Developers hate to modify a pull request, so give them as many free "oh if I fix this nobody will bother me" wins
3) All unit tests must pass before code is merged. This is slightly tricky but you are going to need Jenkins or some other tool that is not as widely used as Jenkins; and integrate it into your bitbucket/github.
4) All deployments are automated. Sure you can have someone push a button, but they shouldn't have to fiddle with anything. And whoever is pushing that button can't be a developer.
5) Since your deployments are automated, your QA system is exactly like your production system (but maybe smaller scale) this way you are actually testing the thing as it will be deployed. "Kinda sorta how it will work in prod" is never a good test. If your QA deployment is automated, and the deploy is broken in QA, then you have to fix it before it goes to prod. Ideally your developers can't touch QA either, but you can work toward that.
6) Since your developers aren't touching production, they will be forced to do things like: write actual helpful log messages, not make code changes that break the deploy, and reproduce production problems in Unit Tests so they stay fixed forever.

Slashdot Top Deals

Ocean: A body of water occupying about two-thirds of a world made for man -- who has no gills. -- Ambrose Bierce