Ask Slashdot: Suitable Phone For a 4-Year Old?
Seriously, kids that age should be playing with other kids, not having their parents helicopter over them with a digital tether.
Ask Slashdot: Are We Witnessing the Decline of Ubuntu?
A few releases before I switched to Mint.
Middle-Click Paste? Not For Long
An open message to the Gnome Devs:
We don't want a new interface! We are happy with our crusty old UI! Don't change it to attract new users, or to imitate Apple or Microsoft's UI's. We use X-Windows and/or Gnome because it is not like either of those platforms. You've already lost the desktop war; don't lose your user base as well through stupid changes.
P.S. You don't need to revamp the start menu with each release; we're happy with it as it is as well.
Ask Slashdot: Best Book For 11-Year-Old Who Wants To Teach Himself To Program?
I think the most important thing at your son's age is for him to be able to write a small fragment of code & see its effect. Something as basic and accessible as an Arduino is perfect for this type of experimentation. To link you to a few resources, the main arduino site is http://arduino.cc./ You can find examples of some of the cool add-ons at http://sparkfun.com/
You might even have some fun with one of these things yourself!
Google's Android To Challenge Windows?
I find this kind of interesting... While I haven't yet played with Android yet (or for that matter Windows on a netbook), this does seem to be an interesting development. I would *really* like to see a performance comparison between Android and Windows on the same netbook; both from a speed and resource consumption standpoint.
Overall, I really like the idea of Android, but think the platform is still too new for anyone to really pay it any serious attention. What really needs to happen is for cell phone manufacturers to have a compelling reason to use it on their cell phones.
That being said, I think Android is going to slowly whither away as a technological footnote over the next several years.
Microsoft To Banish Memcpy()
I'm a C++ developer, and I'm mixed on this decision... On one hand, memcpy is a function that you can really hurt yourself with. On the other, it maps to extremely fast assembly that most processors can perform very quickly. There is a time & a place for everything. I think that a memcpy inside a class' constructor or assignment functions is perfectly acceptable, yet doing a memcpy(&destclass, &fromclass, sizeof(destclass)) is fundamentally dumb for more reasons than I care to illucidate (read one of Stroudstrup's or Meyer's books on C++ if you want to know). Doing something like that *really* demonstrates that you don't know the language.
I guess Microsoft is trying to get people that don't understand C++ to program better in the language. IMHO, this will not solve fundamental problems with people programming C++, just cause them to learn the language slower by not having an experience working through a bastard of a bug. I think the world (and not just MS) needs to realize that writing a piece of complex software is difficult. Bugs like an errant memcpy of a subclass into a baseclass instance are *very* easy bugs to solve if you're looking for them. Memory overwrites are easy to detect if you are looking for them. Bad pointers are easy to detect if you're looking for them.
Such problems will always exist in software. I've found a fair number in my own code. What we *really* need to do is train a better caliber of programmer.
OTOH, Microsoft seems hell-bent on trying to make writing software easy to do
Why RAID 5 Stops Working In 2009
A Black Swan is an event that is highly improbably, but statistically probable.
Yes, it is possible for a drive in a RAID 5 array to become absolutely inoperable, and for one of the other drives to have a read failure at the same time. This is highly unlikely though, and is not the Black Swan. The math use to calculate the likelihood of these two events occurring at the same time is faulty. The MTBF metric for hard drives is measured in 'soft failures'; this is very different from a 'hard failure'.
The difference between the two types of failures is that a soft failure, while a serious error, is something that the controlling operating system can work around if it detects it. It is extremely unlikely that a hard drive will exhibit a hard failure without having several soft failures first. It is even more unlikely that two drives in the same array will exhibit a hard failure within the length of time it takes to rebuild the array. In my experience, it is more likely that the software controlling the array will run into a bug rebuilding the array. I've seen this with several consumer-grade RAID controllers.
The true Black Swan is when a disk in the array catches fire, or does something equally as destructive to the entire array.
To echo other people's points, RAID increases availability, but only an off-site backup solves the data retention problem.
What To Do Right As a New Programmer?
This is all great advice. The parts about not being defensive about code you've written are spot-on. I would add the following to the list:
- Invest time in making your tool-chain work for you. I've been a professional developer for close to ten years, and tricks that I spent a day figuring out when I was a newbie *still* save me a lot of time. I don't care what environment you're coding in, but having a tool that cross-indexes the source base your working in, and allows you to (in your editor) immediately jump to a different function will save you hours. All IDE's will do this with a small amount of config tweaking. Additionally, emacs & vim are very capable at this once you learn the black art of configuring them.
- Recognize when you're doing something tedious. Usually when something is a repetitive drag, you'll save time writing a script to do the repetitive work. It can be a crappy throw-away script... Don't make it work correctly... Just make it good enough that you can hand-edit the output and save yourself time. Finally, save that script somewhere so that you can hack it later if you need to.
- I'm going to re-emphasize mr_mischief's point of using a revision control system. Using a revision control system is kinda like always having the ability to save your progress in a video game. An RCS allows you to go back and see what you did that f*ed up the code. I will add that it really helps to have a graphical diff program that works w/ you version control system. IDE's usually provide a graphical diff that understand most version control systems, but find a good one; it will save you hours over time.
- I have no idea of what environment you're going to be coding in, but you would do well to learn the basics of editing text with VI... There will be a point that you're on some random system without your IDE... VI is usually available on any system, or easily installed. This again, will save you hours. (Full Disclosure: I use VIM for development for this very reason)
- Do your development from the command prompt. Once you learn how to do everything from the prompt, you can script the common stuff.
- When someone asks you how long something will take, come up with an honest estimate of the amount of time it will take, and then multiply it by two. It's better to say things will take a while than to be late on a project.
- Prototype your code in a high-level language like perl or python, then port it to the language it needs to be written in. It saves you writing code that has stupid bugs in it. You get to write the code w/o dealing with the ugly low-level stuff.
- To add to the previous point, pick a prototyping language that you have enough knowledge of to translate your code into the end-result language easily. I would advice against picking a prototyping language like haskell or lisp if you're delivering code in C/C++/C#
- Never stop learning