Slashdot Tries Something New; Audience Responds!
Seriously, slashdot has been providing us a great site for how many years now? And at the first sign they are doing something we might not like everyone turns on them like a pack of rabid wolves. It's a bit disappointing.
Yeah, the beta site is ugly, and it lacks a bunch of features. it's *BETA*, as in NOT FINISHED YET. Can we give them a little room to work on it before leaving en-masse? "Release early, release often" is how you get software into shape. When they asked for feedback, they needed constructive criticism, not useless abuse. So they didn't instantly respond to everything you posted complaints about. THEY'RE BUSY. Give them a little time.
This avalanch of ranting, conspiracy theories and threats isn't helping any, and it's a poor way to repsond to people who have supported our community for so long.
How would you use science to innovate upon sports?
I would attempt, wherever possible, to eliminate the human error factor in referees. Tag the ball, wire the field, use computer vision, radar, whatever. Take the pressure off of the human refs and let it be done as objectively as possible. So we don't have entire championships going down in history as "bad call, dude."
Ask Slashdot: What To Do With Misdirected Email?
I had various problems with email address collisions as well. Then when I had to change ISPs, I decided to get my own domain name. It's a little different when you own your own email address. If you register a domain, you can be firstname.lastname@example.org or such. Then you just forward from your actual email host to the registered email address. It's only a few dollars a year. Then YOU decide who gets an email address for your domain, and you can have whatever policy you want to avoid collisions.
Ask Slashdot: What next for Slashdot?
Slashdot commenters are a bunch of hard-core, bleeding-edge and highly opinionated geeks. Surely that's got to be worth something in the tech industry? I mean, where else can you find such a concentration of tech knowledge and experience in people willing to share it?
One thing slashdot could do is to 'rent out' its Ask Slashdot and Poll features to companies who need that kind of feedback. Established companies can get a feel for what new features in a product will attract the tech-savvy. Startups can troll for new product ideas. It could even be used for market failure analysis: "why didn't you guys buy this?"
Of course, slashdot will have to be extra careful about what information it discloses, and also about what it allows on the site. If it turns into just another thinly-disguised ad system, no one will participate. The renters have to be seeking real answers to questions, and not just trying to sell us more crap.
Ask Slashdot: How To Protect Your Passwords From Amnesia?
There are three methods of authentication: Something you know, something you have, something you are. Passwords are the first category. In the case of amnesia, you lose all that. Any method of reclaiming passwords that also requires you to know something will also fail with amnesia, so a device with a PIN or another layer of passwords or those stupid "security questions" won't work. You can transform case 1 into case 2 easily by putting your passwords in some type of lock box. However, if you have amnesia, how do you remember where you put it, and how to open it? If you do get into your safety deposit box and find a piece of paper with 'myxlplix' on it, how do you know what that means, or what it's for, if you can't remember? The third category is basically biometrics, which might work, unless the same accident that gave you amnesia also cut off your right hand, or put out your eye, or lost whatever body part is needed to authenticate you. And of course, you have to remember that you have biometric authentication, how to use it, and what it's for.
And then there's this: any method for storing or reclaiming passwords that is outside your head weakens the security of your passwords. If you can get your passwords back without needing to know something only you know, then someone else can as well.
I wish my cell phone was...
I'd really like to be able to customize my phone any way I want, without having to jump through so many hoops because of the lock-downs the manufacturer, carrier, or whoever have put on to attempt to control what I do with it.a) it doesn't work, b) it's really annoying and c) it's my phone, not yours, as is made clear any time it needs repair.
I might feel slightly differently if updates and fixes came out in an expedient fashion, but the lag time is months for updates, if there are any.
And what is it with them crippling features on my phone? Why are parts of the bluetooth stack turned off? Why can't I use wifi tethering? Where's the API for the IR port? Why is it so difficult to put things on an SD card? I know the base OS can handle these things. I know the phone has the capabilities to do them. So why are they deliberately disabled?
The Telegraph Says Coding Is For Exceptionally Dull Weirdos
...but we are NOT DULL!!!
The Hardest Things Programmers Have To Do
The hardest part of software development is the schedule. Managers and so forth want to have the comfort of knowing when some piece of code is going to be finished. The ugly truth is that it's all guesses. That's why almost any significant software project is usually late. You can't tell ahead of time what is going to bite you. The whole thing may have to be redesigned because of problems you couldn't see at the beginning. The requirements may change. And then there is the debugging, which is really unpredictable.
My theory about why open source code can be better than commercial code is because FOSS is released "when it's done", not on some arbitrary date. The worst kind of scheduling is when you start with the end date and work backwards. Inevitably something (quality, features) gets lost.
The rule for estimating time to write code is this: take your best guess, double it, add one and convert to the next higher units. So if you think you can code something in 3 days, tell them it will take 7 weeks. By the time you flush out the design, write and comment the code, debug it, write the tests, test it, document it and deliver it, you'll be lucky to meet the deadline.
And over-estimating doesn't do you any good either. All it takes is finishing early ONCE, and from then on your estimates are considered "inflated".
"Everything takes longer than you expect -- even when you expect it to take longer than you expect."
- Ashleigh Ellwood Brilliant
"Smart Plates" Could Betray California Drivers' Privacy
I for one would love to have a smart license plate. Just think of the hacking opportunities!
Jailbreak your license plate and display snarky messages to the other drivers on the road. Change your state to "confusion". Temporarily change your plate number and see how many red light cameras you can trip in a row. "Borrow" your rude neighbor's id and run up their toll bill. Steal a smart plate and hack it so you don't have to pay to register your vehicle. The possibilities are endless.
Any "smart" whatever can and will be hacked. If the incentives are large enough, those hacks will get widely distributed and used. How many incidents of license plate hacking will it take before the police decide it's just an expensive way to enable smart criminals? Not too many, I'd guess.
How Do You Get Better Bug Reports From Users?
I've been on both sides of this issue.
As a user, I am often frustrated by the terse, non-informative error messages I get when something goes worng. "Cannot open file" is typical. Which file? In which directory? Why couldn't it be opened? What is the file for? What is supposed to be in it? What part of the program was trying to open the file?
The available on-line help is mostly not helpful in these cases, and FAQ's written by the developers, not the users are useless. Even finding out where the log is kept, much less actually seeing useful information in it? Good luck with that.
How can I as a user file an informative bug report with such scarce information?
So first suggestion: build into your programs meaningful error messages, along with enough information to accurately diagnose the problem. Include options to turn on debug output. When an error is detected, log complete information about it into the log file (the location and format of which should be documented). That way the user has a chance of making a good bug report. And be sure to ask for that information when the bug is filed, with specific directions about how to find and include it. "Append log file" isn't enough, you have to tell them where and how to find the log file.
As a developer, I know the frustration of vague bug reports, that leave out vital information. Simple things like which version of the program was being used, or the configuration settings. You have to make it clear to the reporter that you cannot solve the problem if you don't have enough information. One company I worked for actually had a bug state named "Not Enough Information." The only cure for this is to engage with the end user who reported the bug. And the biggest incentive for that person to engage with you, is the prospect of getting his bug fixed, soon.
So second suggestion: be very reactive to people who report bugs. Get back to them, tell them what's going on, ask questions, and let them test the fix. There is nothing that kills the enthusiasm for bug reporting like going through the process, waiting weeks to get a response, and then be told "Yeah, OK, it'll be fixed in the next version, due out in about 9 months. Thanksbye." And don't underestimate the effect of some user saying to his peers "I reported this bug, and they fixed it for me" to encourage others to report bugs, and make good bug reports.
Of course, there will always be lame bug reports, no matter how you do it. But you can at least encourage good ones, raising the signal to noise ratio.
Ask Slashdot: How To Begin Simple Robotics As a Hobby?
It depends on a lot of factors.
What is your hardware background? 0 electronics experience? Can wire a bread board? Can Solder? Make your own PCBs?
How much do you want to spend? A couple of paychecks? A couple hundred bucks? Coffee money? Pocket change?
What tools do you have available? Machine shop? 3-D printer? Garage full of power tools? Dremel and a glue gun? Swiss army knife?
What aspect interests you the most? Mechanics? Electronics? Programming? Artistry?
The answers to these questions will determine how you approach the field of robotics. You are getting in at a good time: there are tons of options. Here are a few to get you thinking:
- Pre-assembled robots. Cost from $100 to $100,000. If you don't want to mess with building your own, and want to get straight to the programming aspects you can just buy a robot. They range from things like the Scribbler to something from Willow Garage. The more complex behaviors, actions and programming you want to do, the more it's going to cost you. Best option for a beginner: probably the 3pi from Polulu.
- Robot kits. Cost anywhere from $25 to several thousand. These come with all the parts, but you put it together. Some of them allow customization, some of them are just the one thing. The simplest ones aren't programmable at all: they just have various behaviors. These may be a good way to get started if you need to learn to solder. Examples: mousebot, BOEbot, many many others (google!).
- Robot construction sets. Costs a couple hundred to a few hundred $. If you don't want to get into the electronics, but are interested in mechanics and software, a construction set may work for you. You build your robot out of sets of parts and program it yourself. There's no soldering involved (usually) and you can get right to building something as soon as you open the box. Most notable examples are Mindstorms (Lego) and Vex.
- DIY robot parts. ~$100. Basically, you pick out the parts you want to use, buy and assemble them and program your robot. Requires soldering skills, mechanical inclination and some engineering. For example, an arduino with a motor controller shield and a Tamiya tracked base. Takes a lot of work to get all the parts to work together smoothly. You'll spend a lot of time learning and building.
- Scrap/salvage parts. Very low budget option, but lots of fun. Instead of buying robot parts, you get the parts by salvaging pieces of broken or abandoned toys, electronics and appliances. You may need to buy a microcontroller "brain", but everything else can come from garage sales and thrift stores (or just stuff tossed out by friends, family and neighbors). You could start with a remote-controlled toy as the base, add sensors from things like dead VCRs, flatbed scanners or burglar alarms, and program a microcontroller to give it behaviors.
And of course, you can combine any of those options. Lots of people start out with Mindstorms or a BOEbot and end up building custom parts for them, or using salvaged parts to add on to a pre-built robot like a Roomba.
Two suggestions. First, you will need a support group to talk out problems and ideas. Online is fine, in person is more inspiring.
Second, find a good book on what you want to do. There are several mindstorms books, there's several arduino books, and of course there is The Robot Builders Bonanza for the DIYer.
Hope this is helpful,
Ask Slashdot: How Can I Make a Computer Science Club Interesting?
When I was in grad school the local ACM/IEEE chapter sponsored a programming contest for several local high-schools. This is a fun way to get kids interested in programming and computers in general. Competitive games are a draw. Contact the ACM, IEEE or your closest university and see if they have any contests in your area. If not, maybe they will help YOU host one. Your kids will get to meet students from other schools with the same interests, polish their programming skills and have some fun. Cool prizes help.
Another area with some cool factor to it is robotics. There are FIRST and BEAM leagues all over the place. Check them out. You could spend a few months getting a contest entry together, involving not just programmers, but budding engineers as well. Even without a contest, having a school robot is cool. And they have something tangible to show off to the rest of the school.
How Did You Learn How To Program?
I first learned to code by reading the BASIC manual of my Sinclair ZX-81 and laboriously typing out programs one keyword at a time on that little keypad (after assembling it myself). It's amazing what you can do with 1K of RAM.
A Case For a Software Testing Undergrad Major
> Imagine the power of being able to hire a recent college graduate who has been taught how to develop system diagrams,
Using which tool?
> build complex SQL,
For which implementation?
> run log analysis,
On which platform?
> set up a cloud test environment,
On who's cloud stack?
> and write automation scripts.
In which language?
Sure, it would be great to hire someone who could do all that right out of college. But 5 years later, he'd be unemployable because all the specific skills he learned will be obsolete. What is he supposed to do then, go back and get another BS in software QA?
Hire people who know the fundamentals. Choose people who can learn new skills. Train them.
Sure, they won't know the specific tools and environment your particular company uses. But you have to invest in people to get the most out of them. The more highly specialized the job, the more time and money you need to invest in training them. If you concentrate on hiring those who can learn, rather than those who happen to match your particular requirements at the moment, then they can do more than just the one job on the current project. Imagine not having to fire people when the project is over, but instead just move them to something else, even if it requires a different skill set.
> No more crossing your fingers that this eager young face in front of you can really pick up those skills,
> and no more investing so much time and money in training them on the job. We ask no less from
> Technical Writing and Development. Why do we have such different expectations for one of the most
> important functions on the team?"
If you can't tell whether or not the person you are hiring can learn the skills needed to do the job, you need to revise your interview process. Sure, there's no 100% way to tell the gems from the lemons, but you should be able to consistently identify applicants who can do the job.
The fact that development jobs often demand a high degree of specialization is, IMHO, a bug, not a feature.
Ask Slashdot: Why Buy a Raspberry Pi When I Have a Perfectly Good Cellphone?
It's true that even an obsolete smart phone has lots of integrated features that you would be hard pressed to find or add to a micro-controller or tiny PC ( like the PI). There are even a few models that have some primitive IO capability, and lots of them at least have a serial port. So you can, with some effort, get some IO going.
The huge advantage of the PI (and Arduino et al) is the development environment. It's free. It comes with the device. You can roll your own OS, drivers, libraries, programs and interfaces. Or build on the work of others via the community of developers who share their code. In other words, it's an open platform (yeah, yeah, quit nit picking).
A smart phone, on the other hand, is going to be much more difficult to develop for, unless you just want to make apps like everyone else. Many of those neat pieces of highly integrated hardware are not documented, proprietary, and don't give you the source code you need to made modifications. Yes, there's Android, but even there doing low-level things like single pin IO, or even just using the components to their full capabilities, is going to be hard, if not nearly impossible.
So for example if you want to make a robot controller, and you have an old iphone 3 lying around, and compare it to a Ras Pi. The Pi isn't going to have built-in screen, wifi, accelerometers, audio, battery and charger. But the Pi is going to be much easier to use for this application. The number of hoops you'd have to jump through to get the iphone working would make it a much harder prospect to use. By the time you finish getting, or custom making, the connectors/cables/circuits needed to hook it up, you'll have spent as much as a Pi or arduino costs. And that doesn't even address the development environment you'd need. Android phones have it much better off, but it's still not as easy as hooking up and programming a Pi or arduino.
Yes, you have a perfectly good cell phone that could, with some work, be used instead of a Pi. The problem is that the cell phone is going to take a lot more time and effort to hack than the Pi.
Should Healthcare be more like the Airline Industry?
I understand the purpose of the question: how to cut costs and still provide services. But there are so many things wrong with the airlines that emulating them, even a little, can only lead to Bad Things.
- prices are seemingly arbitrary, change without notice and nobody feels like they got a good deal.
- they have an adversarial relationship with their (unionized) employees.
- they not only cut unnecessary "luxuries" (food), but started charging extra fees for necessities (luggage).
- dealing with them is usually an exercise in frustration, especially when things go wrong.
- the experience of using their services is usually uncomfortable at best.
- customers are treated like cattle, herded from here to there, penned up in holding areas and lines, and sometimes stored on planes that are not moving.
- customers are at the mercy of uncontrolled factors such as weather, maintenance schedules, work shifts, traffic and the occasional security "emergency".
The two unavoidable facts about airlines are that nobody but the rich enjoys airline travel any more, and that until they figure out just what it costs to get a person from point A to point B, they are not going to be sound financially. We do not want our healthcare to be like this. Pick a different industry to emulate. ANY thing else.
Now, if you want ways to do more healthcare with less cost, that's a different question entirely.
What Are the Unwritten Rules of Deleting Code?
That's so wrong. Imagine you are on the other end of this process, trying to use that code. You'll never be certain which combination of features exist and are supported and which have either been deleted or not implemented. If you have a logically orthogonal set of features, removing or not implementing a random subset just leaves gaping holes where your users are going to be very frustrated on the day they try to do something you thought was of "zero value".
Just -In-Case development prevents problems in the future, which is what good programming does. Just-In-Time development is a shortcut and leads to incomplete code.
Ask Slashdot: How Can I Explain To a Coworker That He Writes Bad Code?
Take something he wrote several months ago, that he's not likely to have on the top of his brain. Then ask him to debug, add to, modify or analyze his own code. Or just ask him to give you an explanation of how it works. It might dawn on him that his own code is unreadable and hard to maintain, if you do it right.
I'd also push back on your manager, to make it policy that until this guy gets his code in shape, he is the one who has to maintain it. Bad code is bad even to those who wrote it. Make him work on his own code.
The Scourge of Error Handling
For the return value option: It is usually bad coding practice to mix error codes with information the function returns. If a function returns an int, don't stuff an errno in there when things go wrong. Separate the data from the error code. I hate it when functions that are supposed to return a pointer use NULL as the error code. NULL doesn't tell you anything, and it very well may be a valid value to return anyway. Set errno, send a signal, return a separate error code, but don't put your noise (error code) in the signal.
I want to see the errors. Don't hide them from me. Force me to deal with them, at least as far as generating a meaningful error message. (Meaningful!. that's a different rant.) I don't want the hardware, OS, compiler, library or whatever to take away from me the ability to see -- and handle -- the error myself. Feel free to offer me some boilerplate error code, but don't force me to use it. Half of elegant programming is in the error handling. If you think about it, a program seems "smart" when it handles error conditions well, instead of just crashing or quitting.
And the plus:
It seems to me what the guy is complaining about is the aethestics of the code, not the actual error handling. Wouldn't a folding editor help with that? You just mark the error handling code and let the editor collapse it for you, until the time comes when you need to see it (and it will). Problem solved.
When I see gov't CCTV cameras, I think:
take a picture of it.