Rules to follow when setting up and running an open source project:
- Your project must have an unintelligible name that cannot possibly be linked to the actual purpose/use of your product. The stranger the better (e.g. Zynga, Apache, Redis, Firefox, Chrome, etc.)
- Your website must be written from the point of view that everyone viewing your site already knows all about the project.
- At least half of the download mirror sites listed on your website must have broken links
- At no time do you ever put a date anywhere on your website, on your downloads, or on your documentation. You don’t want anyone figuring out that your project was abandoned 15 years ago…
- Every book regarding your project must have a really large opening chapter that tells the uninteresting story of how your project began.
- All white papers and blog articles on your main website should be written as sales ads rather than offering anything of engineering value.
- You need to program your online support forums so that whenever anyone asks a technical question, the forum automatically picks a team member name at random and forges a reply post asking “why do you want to do that?”
- You set up a kickstarter project and once you get the money and start developing your project…you sell out as fast as you can to the first bidder then grab the money and run, leaving all of your donors who thought you’d continue development after your kickstarter project was completed twisting in the wind. It is best if you can be bought out by a very rich punk who runs a social networking site that has no foreseeable use for your technology.
Just lessons learned from a lifetime of working in technology…
As you saw in my last post, I didn’t really plan carefully for the arrival of my Raspberry Pi and Beagle Bone Black boards. Sadly, the saga continues…
So what MORE could go wrong you ask? Plenty, as it turns out. And in this case, my enemies were:
- Rapidly moving technology
- Failure on my part to read the specs carefully (a.k.a. being a dolt)!
So after my (mis)adventures with the power supply, I finally got a few moments to begin to load up my Raspberry Pi with the base software to boot a Linux distribution. I downloaded the NOOBS software (as it is called…a set of software that you load on an SD card so that you can easily load up one of several popular Linux distributions with the touch of a key) but ran into problems when I tried to transfer it to my brand new class 10, 32-gig micro SD card.
You see, I kept getting “crc check errors,” meaning that I wasn’t getting a clean copy to the card. After several attempts, I began to suspect that maybe I had received a bad memory card. Since I had purchased two cards (one for each board), I tried writing to the second card…only to get the exact same error messages again. At this point I began to suspect that the problem was NOT the card. Not just because TWO cards were failing, but because I had purchased these two cards several weeks apart. I doubted that they were from the same lot (I COULD believe that two cards from the same lot were bad), so it was probably not the card.
Now my suspicion turned to my micro SD card reader.
Was it the speed of these SD cards (class 10)? Was it the size of these SD cards (32 gig)? I had never used micro SD cards of this size or speed before with our current USB card reader, so I began to suspect that the card reader might not be up to the task. Whether it was the card speed or the size didn’t really matter. It looked like I was dealing with obsolescence…and no true geek TOLERATES obsolescence!
A quick check at Amazon showed a micro SD card reader that several reviewers indicated they had used with class 10, 32 gig micro SD cards, and since the price was a ridiculously low $7 delivered to my door thanks to Amazon Prime (click here for the Transcend card reader that I purchased), I only had to wait the three days for it to arrive.
Once the reader arrived it was two days before I had time to unpack and test the reader. In less than two minutes I had the micro SD card loaded up…problem solved!
I figured from this point onward it was smooth sailing. All I had to do was plug the memory card into the board, connect the board to my monitor using the HDMI cable that I had purchased with the board, and I should be ready to “rock and roll.”
As I unwound my brand new cable, I began scouring my monitor for the HDMI port. Simply put: there wasn’t one.
THEN I remembered how, many years earlier, when I had purchased my first flat screen monitor (which is the one I’m still using), that I made the decision to save myself a whole bunch of money and buy the monitor that only had the DVI interface, and not the HDMI interface as well. It was a good move at the time as I did not own, and did not expect to own any time in the near future, a device with an HDMI output. Now it had come back to bite me. Obsolescence had reared its ugly head a second time!
Once again it was Amazon to the rescue!
After a quick search I found that there is indeed an HDMI to DVI cable to be had for the low, low price of $7.99 delivered to my door with Amazon Prime (click here to see the HDMI-to-DVI cable that I purchased). Another three days…and my cable finally arrived.
I have not, as of yet, had time to test my board with the cable or with the new loaded memory card. Maybe within a week I’ll a get a few minutes to do so.
But if you haven’t been paying attention all this time, I’ll lay it out for you: If you don’t want to be a dolt, read the specs and check your equipment! Fortunately the solutions are cheap…but they will cost you time…and geeks HATE to waste time!
Until next time…
Recently I acquired both a Raspberry Pi and a BeagleBone Black computer boards. My purpose for obtaining these boards is of course, to further my geek status, but also to explore the possibility of using one or both of these boards for some projects I’ve been toying with.
At the top of my project list is a task to create a computer system that is small enough to be easily portable and that can be run from a battery (or at least some portable power supply) to allow me to add it to my portable amateur radio station, which runs off of a deep-cycle battery and a solar panel. More specifically, I desire to be able to run digital modes like PSK31 on my portable radio station, and for that I need a computer.
Both the Raspberry Pi and the BeagleBone Black appear to be capable of the job…if I can locate or create the proper software. However, I discovered I had a misconception about these boards and thought that perhaps a reader might be under the same misconception.
Specifically, when I purchased the two boards, I also purchased a single power supply, thinking that both boards would utilize the same power input scheme. Why did I think this? I have no idea! Well, it turns out that this is NOT the case.
The Raspberry Pi uses a USB-type cable to supply power to the board. This is handy because most cell phone chargers will work with the Raspberry Pi board. However, the BeagleBone Black board uses a rounded plug similar to the plugs you see on home network routers. In fact, some network router power cords work just fine with the BeagleBone black. Unfortunately, none of the extra cords I had on hand from old routers worked. They either had the wrong type of cord/connection or else did not provide 5 volts (many provide 12 volts).
Now enter the Roku…
It turns out that a few years ago we purchased Roku box…one of the first generation devices. We stopped using it in favor of our Wii because the software on the Roku was atrocious. However, the power cord for the Roku works PERFECTLY with the BeagleBone Black. It has the correct connector and produces the proper 5 volt output.
Speaking of power, I need to see if you can power the BeagleBone Black board solely by its USB port. I’m guessing that you can, but keep in mind that the BeagleBone Black board only has ONE USB port, whereas the Raspberry Pi board has TWO. However, if you want to power the BeagleBone Black board from its specifically designated power port, you will need a 5 volt power cable with the rounded plug at the end.
No matter what I end up doing with these boards, I do expect that when I have my plans fully realized, the boards will be running separate from a computer…or at least part of the time be needing to run separate from a computer. Therefore, it is wise to understand how you can supply power to these boards.
A very Merry Christmas to all from Compublab.com!
Recently I have been working in Amateur Radio to develop a portable communications package that I can use both for the Amateur Radio field day as well as for emergency communications deployments…whether official or just for personal experience. Since digital modes are very handy when it comes to making contacts in emergencies, I have been looking for a method to include a computer in my portable equipment.
The Raspberry Pi is very much an ideal choice as it is small, has low power requirements, and is priced to sell ($35). As such, I have just begun to investigate the possibilities of this relatively new device.
In my first exploration into this area I have come across a blog post that talks about one user’s experience with trying to run PSK31 on a Raspberry Pi. I include the link below because I think his experience would be useful to anyone endeavoring to do the same thing.
Raspberry Pi as a platform for PSK31
Yes, it’s true! In addition to being a certified geek, I’m also an avid fan of Amateur Radio. As such, I have added a new category called Amateur Radio to be used to mark posts that involve topics related to that field.
Stay tuned for some amateur radio goodness…
Scripting languages today are incredibly useful and certainly varied. Perl, Python, shell scripting, etc. These are all incredibly useful tools that I use on a daily basis. But I have to admit, my heart lies with traditionally compiled languages. A lover of Pascal, alas, the world has moved past Pascal to the point where I feel I have no choice but to embrace C++ nowadays for my compiled code fix.
Recently I heard about the new standards release for C++. Since I’ve been away from C++ for many years, and indeed was never all that deep into it (I preferred Pascal, and back then a company called Borland produced THE Pascal compiler of dominance), I wanted to see how the years have treated C++.
In the spirit of full disclosure, I was never C++’s biggest fan. I have always maintained that C was a great language if your alternative was assembler, but I always felt that C was over used at higher levels of programming. Large scale application development in C seemed like trying to do arithmetic in roman numerals. Well, actually it seemed to me to be much worse than that. C++ always seemed like it was “tacked on” to C, and thus I wasn’t overly fond of it.
So when I decided to refresh my understanding of C++, I wanted to find a source that would give me more than just the language facilities. I wanted a book that could explain how the philosophy of the language had evolved over the years, and how the language features should be used. In addition, I wanted a solid reference for the language along with a light tutorial of the newer features. I had seen Bjarne’s new book advertised for advanced sale on Amazon for many months. I toyed with the idea of buying an already available book both because of cost and because I was afraid that, like many technical people, Bjarne might not be able to write worth diddly. However, I read reviews of his previous editions and decided I’d take the risk and wait for this particular book to be published. Boy did I hit pay dirt.
The C++ Programming Language (4th edition) by Bjarne Stroustrup is absolutely a gem of a book, and I highly recommend it to anyone, but especially for people like me who have been away from the C++ scene for a long time and want to see how the language has grown. In case you don’t recognize the author’s name, Bjarne is in fact the man credited with designing/creating the C++ Language.
In a word, I think this book is GREAT!
While I have been reading the book casually (Solr, which I use at work, has been dominating my study for quite some time as I’ve been trying to come up to speed with it), I am already impressed with its content. It is thus far EXACTLY what I have been looking for.
Bjarne’s book is worth every penny in my opinion as it not only details the language features (old and new), but gives you the kind of analysis and comparison of features between the current C++, the older versions of C++, and other languages that you would only expect from a man who has spent the greater part of his professional career in the design of the language.
A small example (and really one of the smallest) is a tidbit that Bjarne leaves for us on page 862 of the book: “A standard library is not merely required to perform its tasks. It must also perform these so efficiently that users are not tempted to supply their own alternatives to what the standard offers. Otherwise, implementers of more advanced features are forced to bypass the standard library in order to remain competitive.”
On the surface this seems like a rather innocuous statement. However, when you ponder it carefully, these three sentences demonstrate a subtle insight into the design and use of language features that you don’t ordinarily find in lesser mortals. Time and time again in this book (of which I have only made it through about 25%) I find such insights and background as to WHY certain language features are present, the evolution of those features in cases where they’ve seen change over the years, and also a clear discussion of programming practices and classes of problems that the specific features were designed to solve. Indeed, you discover in reading this book that nearly (or perhaps every) feature of the language has very specific design goals and intended uses, and Bjarne has done an excellent job in pointing all of this out. So much so that I have abandoned my misinformed notion that C++ was simply C with a bunch of additional features tacked on.
Now I don’t know about you, but for me, after reading the previous paragraph, I’d be afraid that the book is filled with all sorts of self-aggrandizing drivel that I have to wade through just to figure out how a new feature is meant to work. Nothing could be farther from the truth. With Bjarne’s age and experience I think he has done as good a job as can be done in balancing the presentation of material such that you can find what you want quickly and efficiently, but can also delve into these other aspects of the language if you wish. His writing is very concise and well organized.
In the beginning of the book, Bjarne writes about it’s layout, designing the book to be suitable for both a partial tutorial of the language and as a language reference. Many have tried to write books to satisfy both of these demands. I cannot ever recall reading a book that managed to satisfy both roles so well. This book pulls off its goal with incredible aplomb. Of course, the book *is* 1346 pages in length. He didn’t skimp on the content at all.
I don’t want this post to get too long, but once again I will emphasize that this book demonstrates what I have to believe is a personality trait of Mr. Stroustrup: I don’t think he does anything without a clear purpose or without considering his end goal. Both the book, and the language, seem to highlight this fact.
In a profession that is being increasingly dominated by young, energetic individuals who can crank out code and applications in the wink of an eye, I find it refreshing to read the insights of a man with possibly more language design experience than 99% of the general population. If you are anything like me, you will find this book both useful and a good read.
Thank you Bjarne Stroustrup: Thou Art the Man!
Some mornings I wake up and think: “Time to make the donuts.”
Today I woke up thinking: “Time to make the configuration management service for controlling solr search clusters serving up 300 million records in the computing cloud.”
When I was attending my very first college course in computer science at the University of Michigan, I recall talking about the types of things that computers did well…and the types of things they did NOT do well.
At the top of the list of things that computers do well is the ability to count. In fact, a computer will happily sit and count all day, all month, all year, and so on until you tell it to stop (and even then it will probably keep counting).
So why on earth are we all subjected to the following insult phone call after phone call that goes something like this:
system: “Welcome to <insert company name here>. To better serve you, please enter your 12-digit account number…then press pound.”
Excuse me? Enter my 12-digit account number…THEN press pound?
Are you telling me that your computer, knowing full well that I intend to press 12 digits, is incapable of counting the 12 tones and then knowing that I’m finished? What kind of 10-cent per hour programmers/system designers are you employing???
Now, to be fair, back in the day when these telephone systems were just being developed, the hardware and software on the base system was tuned to always expect the “pound key” as the end of a line of input (much like you press the key today…or click on the “OK” button).
But times have changed people! Systems now are capable of counting the numbers I have to enter into one of those cursed phone systems, so please…PLEASE…stop asking me to press pound when you KNOW how many digits I am going to enter.
The second most annoying trait of any phone system I have ever encountered is the “waste your time data collection algorithm” that so many of them employ. You know the system I referring to as I’m sure you have encountered this exchange before:
system: “Welcome to <insert company name here> To better serve you, please enter your 12-digit account number…then press pound.”
you: <enter your 12 digit account number and press pound>
system: “Thank you. Please enter your date of birth, then press pound.”
you: <enter your date of birth and press pound>
system: “Thank you Please enter your secret password, then press pound.”
you: <enter your secret password and press pound>
system: “Thank you. I will now connect you to a customer service representative.”
Customer Service Representative: “Hello, my name is <insert name here>, could you please give me your account number, your date of birth, and your secret password so I can verify your account?”
At this point you are seeing red and contemplating the purchase of a firearm and a plane ticket to the location of this company’s call center!
Now, I’m sorry to say that some companies actually have it as their goal to prevent you from speaking to a human being, and so these systems are DESIGNED to get you frustrated and hopefully to hang up before you ever get to the call center representative (I’ve worked for companies like this in my past). I suspect, however, that other companies just buy into one of these systems without ever seriously considering the type of “face” it shows to the customer.
So all of this is well and good, but what can you do about it? That’s simple. Complain about it.
If I have had my time wasted with an annoying phone system, the first thing I do when I get a human being on the phone is make certain I waste AT LEAST as much of their time as I had to waste getting to them. The easiest way to do this is to rag on them about their phone system. Be certain to request that a complaint be filed in your file, or else get from them the mailing address or email address of where you can file such a complaint. Then be sure you DO file the complaint. There is power in a large number of complaints
Kudos Note: I have to say I am thoroughly impressed with the phone system being used by Blue Cross and Blue Shield of Michigan (who manages my health insurance). You would not believe how their system works:
- The system GIVES YOU THE CHOICE of using voice responses or numeric responses. I for one hate trying to get a phone system to properly understand my responses, so I always use the numeric responses (that is, by pressing keys on the phone).
- If the system asks you to enter a 16 digit number, it doesn’t ask you to press pound at the end. It actually counts the number of button presses you make and knows you are done when you have pressed the required number of buttons. HOW COOL IS THAT???
- When you actually *do* get to speak to a human being, they have all of the information you just entered into their phone system. How novel!
Stupid technology exists in part because people accept it as given. Start giving feedback to the suppliers of your stupid technology. I cannot guarantee it will make it difference, but I *can* guarantee that nothing will change if you do not provide feedback.
I’ve opened up a new category for posts called “Tech Rage,” which is dedicated to all of those gloriously stupid moments in technology where common sense failed. As a technology professional, it has been my experience that most often such failures occur when one or more of the following take place:
- The developer of the technology goes through a lengthy development cycle and manages to never once use the new product or tool themselves in an environment that comes close to the environment that exists around the target customer.
- The developer of the technology gets caught up in thinking about how a computer scientist or engineer (or whatever vocation the product is targeted at) would solve a problem, and forgets that their end users are NOT computer scientists or engineers.
- The developer of the technology suffers unavoidable interference from an unqualified HiPPO (highest paid person’s opinion).
- The developer of the technology gets so bogged down in the details of the product that they forget to look at the big picture.
- The developer of the technology fails to apply common sense.
Tech Rage is all around us, and I hope to shed some light (and if nothing else, some laughs) about something we all love to hate.