I have used computers for decades now but I never fully understood the physics behind a semi conductor until I watched this short educational video.
I saw this referred to on Reddit. Although it lacks headphones, a memory card, or even a USB cable. You can apparently buy an MP3 player off Ebay for $1. Or about $1.50 shipped. I remember buying an MP3 player for $200. I’m tempted to buy one just to take it apart or to use as some sort of a small mobile product case. I find this a bit mind blowing.
I found this really amazing as I had thoughts of doing something similar. This gentleman overhauled his alarm clock to run Linux.
I spent an hour or two to find this correct solution for how to unit test System.Net.WebClient in Visual Studio 2012. I found one page that actually had a minor typo in the implementation that caused me quite of a bit of aggravation. I won’t link to it, cause I don’t want to bump it up higher on Google. Here’s what my System.Fakes looks like:
<Assembly Name=”System” Version=”188.8.131.52″/>
I’ve been experimenting with writing unit tests as I write my code. I find it a very organic way of development and makes the unit tests almost free. My experience so far is that unit tests are best for back end testing.
Adafruit Industries started a series of YouTube videos aimed at people new to electronics called Circuit Playground. I consider myself a hobbyist electrical engineer, and am always looking for videos to keep my knowledge correct and up to date. These videos feel like Sesame Street crossed with an introduction to Electrical Engineering.
I have always been fascinated with small computers. I have a Chumby, some ZipIt Z2s and I had a plug computer that recently died. I’ve been considering replacing the plug computer with a small Linux arm computer. My prerequisites are: Wired Ethernet, Silent, Low Power, ability to host source control and ssh. Video output would be nice. I have been hesitant to spend too much, because I have previously bought them and barely used them. So far I have seen two contenders, NanoPC-T1 and the ODROID-U3.
I am a bit of a tech hoarder, so I have to liquidate some previous older computers before I buy anything new.
I consider myself a generalist when it comes to software development, but I know I have gaps in my knowledge base. If you are the sole programmer or surrounded by people who do not show a desire to learn new things, it is very easy to become obsolete and irrelevant. As hardware keeps progressing forward, software engineers keep adding additional abstraction layers to increase productivity. Knowing these abstraction layers and other technologies is difficult even if you try to learn something new every day. To balance out my finance and science heavy podcasts, I have added Coder Radio to my list. I have finished six episodes and so far the content is great for software engineers. I like it because the host works in an area foreign to my daily development.
I typically listen to podcasts when commuting to and from work and doing chores on the weekend. I have tried to balance the content generation with the consumption, unfortunately there is only so many hours in a week.
If we really want to achieve software with an extremely low defect rate, it is not enough to react to software bugs and fix them after they have been introduced. One of the main principles of my style of software development is that we have to go on the offensive and eliminate or reduce the possibility of their creation.
Now this sounds like a good principle, but it is one of the hardest to achieve. It is hard to achieve because it fights the human desire to get quick results even if the results are not completely correct. We want to show something that works in most cases, but bugs often occur in the least used cases. Also if we tried to avoid every kind of potential bug out there we would probably never finish our task. So we want to find all the situations where avoiding an issue is more cost effective than dealing with the bugs that are caused by them. If you have ever spent a week, day or even an hour on a bug, you will realize how much extra code you could write to avoid the issue and still come out ahead.
Basically go through the kind of bugs that occur and ask yourself “How can I reduce creating this kind of bug again? Is it cost effective to do so?” After a while you will realize that additional code will often get you to a low defect rate sooner.