The Lounge is rated Safe For Work. If you're about to post something inappropriate for a shared office environment, then don't post it. No ads, no abuse, and no programming questions. Trolling, (political, climate, religious or whatever) will result in your account being removed.
Plus I don't understand how it actually works. I just ported it is all. I haven't dissected it and it's very difficult to do so - basically it would be an exercise in software forensics.
The code I'm porting was produced by two graduate students, and while they built something I couldn't, and so props to them for that, they did so with the most horrible code I've seen since the last time I reviewed an academic's code.
Is it that universities can't teach people to write clean software? Or do I just have terrible luck finding it?
Part of the problem is that software "engineering" and computer science are rather different beasts. If the faculty is focused on computer science, it won't put much emphasis on software and may not even see it as a worthy pursuit. It's just a craft that must occasionally be dragged into various areas of computer science.
The problem is actually more widespread. My experience is that many companies with large software teams don't act as if software is important to their success. A software team is mostly seen as a cost center, and there is little drive for good design. A technical career path for people who prefer to focus on software doesn't exist or is weak. Among other things, a firm that runs a good software shop often has a software architect reporting directly to the VP of Engineering, and that person is compensated the same as the VP's other direct reports.
Part of the problem is that software "engineering" and computer science are rather different beasts.
Thankfully this problem is slowly being addressed at some universities. Arizona State University, for example, differentiates between Computer Science and Software Engineering with separate degrees that diverge pretty heavily around sophomore year. The SE path has degree-specific courses covering topics like version control, continuous integration, project management, requirements elicitation, etc that the CS degree does not.
I think it's hard to teach people how to write clean software. It's more a skill that is acquired gradually, both by seeing examples of good software and by writing software yourself, letting it "speak to you" as the saying goes, and being willing to refactor it even when it works. The largest piece of code I wrote in university was in assembler, something like 6,000 lines of code. In a high-level language, more like 3,000 lines. This doesn't quite prepare you for something that's far larger.
somewhat like the early USB ports that came out on some MOBO's, plug in too much and things stopped working. (say USB powered speakers, business card scanners)
the units would still accept commands ("scan!" "OK"... whir-ur-ur.u...)
the mobo still works, hopefully the scanning app doesn't lock it up, or if it does kill the OS hopefully they set the "Auto Reboot" option.
some of voyagers bits that collect data (photo's, RF waves, catch particles) do the work on their own, analyse then periodically feed back the results.
some updates were sent so some would run a bit slower/less often (they were already programmed to restart one by one because they knew further away power would be limited - probably added longer delays for that too.) and of course each sends back "X started OK" messages so if it fails during restart they will know where (apparently a while back a couple of things have failed and were taken out of the startup list).
So the unit wasn't fully offline (or would restart if it was) but from what I read (a while ago)
- designed to restart if it detected failure,
- upon restart first check (in some cases actually wait) for new commands before anything else
- the radio that receives commands is itself autonomous and has a buffer in case the core is down
of course takes a long time to see if it worked: Amazon "you're parcel has been sent" - takes a day or two before it arrives before you can confirm as complete, working, arrived at all.
NASA engineers are troubleshooting the problem, but it's slow going given Voyager 2's distance from Earth. With the probe 11.5 billion miles (18.5 billion kilometers) away, signals take 17 hours to travel one way and mission personnel must wait a total of 34 hours to see whether a command worked.
after many otherwise intelligent sounding suggestions that achieved nothing the nice folks at Technet said the only solution was to low level format my hard disk then reinstall my signature. Sadly, this still didn't fix the issue!