Archive for December 2009
As I wind down the hours of 2009, I’m reflecting back on some of the themes that have popped up for me over the year. One theme that has been at the front of my mind is that of giving yourself permission. I haven’t really started writing about this, but I’ve been gestating the idea over the last few months, and expect to write a few posts about it in the upcoming year, beginning with this one.
The thesis centers around giving yourself permission to suggest ideas that are not fully fleshed out. I’m not suggesting that we spout off every half-baked thought that comes through our heads, but rather, to pay attention to intuition. There are many times that I will shoot down an idea before I have fully given it a chance to breathe, or I will not have time to fully digest an idea and I’ll put it into my personal notes rather than try to publish it or talk it out with someone else.
The biggest hurdle here is that of perception. What if the idea is perceived as stupid? What if others disagree vehemently? These are certainly risks, but putting aside the ego and allowing a rhetorical question to be phrased can go a long way toward stemming naysayers.
By intuition, I’m certainly not the only one to think about permission in relation to the self and the communication of new ideas, but I have done basically zero research into this so far so I don’t know how well it has been covered yet. I hope that I can add something original to this theme in a later post.
I’ve already blogged about Palm’s WebOS and mobile computing in general in the past, but I saw something today that really excited me. Palm announced that they are introducing a fully web-based development environment for PalmOS called `Project Ares‘. Palm has already embraced the Web full-on as their platform technology, and now they are embracing it as a development platform. This may sound cliché in this age of web-based everything, but it represents a commitment to open platform development. Contrast this with Apple’s development model for the iPhone, which requires a recent Mac running the latest OS X and their iPhone SDK. Having had to jump through all their hoops just to get an iPhone development environment set up I can really appreciate what Palm is trying to do here by allowing developers to try the environment without a serious resource commitment just to set up the required development tools.
Couple this with why I think that the Web is winning, and we have some great technology plays here. I just hope that Palm doesn’t become one of the many `better’ technology solutions that have failed in the past.
I was reading a small, relatively unknown blog the other day while looking for some pointers on setting up eBay accounts. Within a minute or so of reading, I realized that the entire point of this blog’s existence was for link bait, referral links, and cross-promotion. I clicked through a few more articles just to make sure that I wasn’t missing something, and I came to a post where the author was endorsing a product. There was a badge on the post that read something to the effect of `sponsored post, real opinion’. Many other posts were just thinly veiled attempts at dropping a sponsored link, many of which were affiliate links.
I realize that for-profit blogs need to make money somehow, but some sites seem to manage it better than others. Blogs that have a strong editorial opinion seem to make sponsorship more believable. Blogs that are neutral or that seem to waffle on opinions are easy to discredit when mentally evaluating a post’s authenticity.
Some say that we are entering an attention economy. I support this view, as we are seeing that attention really is a zero-sum game, and where there is scarcity, there is the potential for an economy. However, in addition to attention, authenticity is a requirement to get a potential customer’s permission. Permission marketing is a concept pioneered by author / speaker Seth Godin in which a seller earns the privilege of delivering his message to the consumer.
Without rambling on much longer, I’d like to present as a case study the periodical Tape Op. Tape Op is a magazine that serves the sound recording engineering community. What makes it so unique is that it is a free publication that is entirely supported by advertisements. Not only that, it is a free print publication, issued six times a year. Despite the large number of sponsors and advertisements that appear in the magazine, the articles remain extremely neutral and unbiased. In the audio world, where everything is subjective and endorsements can make or break a company, this is no small feat.
How does Tape Op manage to keep its level of credibility so high despite the massive commercial interests required to keep it running? I don’t know exactly, since I’m not affiliated in any way other than as a subscriber, but I’ll venture to guess. It probably starts with editor Larry Crane. Larry is the owner of Jackpot! recording studio in Portland Oregon, which is a highly regarded recording studio for independent music. Larry brings a lot of recording `street cred’ to the table, and has attracted people of similar credibility as collaborators and contributors. As a result, the community that has grown around the magazine has placed a lot of trust in the magazine.
On the flip side, advertisers are very attracted to this dedicated community of readers. I have noticed that Tape Op tends to attract very impressive advertising clients. Most of the ads run are for high-end gear by companies that also run ads in much bigger magazines such as EQ and Sound On Sound.
Wrapping things up, I won’t name the blog that I used as the negative case study, but I really think that Tape Op represents a really amazing match-up of advertisers and the target audience. There is a ton of advertising in the pages of the magazine, but all of the products are genuine and the articles aren’t affected. I get a free magazine with great articles, and the advertisers get to reach me without offending me. Everyone wins.
Previously, I had written/complained about the way that the Git version control system handled newline characters. I wanted to update that with some new information here. The cause of my frustration back then was that I hadn’t created my working copy correctly. I had been under the assumption that since each Git repository is a standalone repository that I could just copy the whole thing around my network using a simple file copy. You can do it that way, but there is a catch: if there are files in the working directory, ie, there are files `checked out’, you will have issues copying files between systems. Note that having files checked out on a `central’ repository, ie one that you want to `push’ changes to, can also cause lots of problems. In general, although Git is a distributed system, and each repository is technically a `peer’, in practice certain repositories should not have their own working directories.
I had been using Mercurial in a quick and dirty way, where I would make a copy of the whole repository quickly using a simple file copy before working on a project. Now that I’m using Git, I simply settled into that old (bad) habit of copying stuff around and ran into the newline issue when trying to commit files that had been checked out on a Linux system, copied along with the repository to a Windows box, and modified.
The correct way of handling the situation is to make sure that all changes are committed to the remote repository, and then create the local repository using `git clone’. When using Git on Windows via the msysgit port, you can use UNC paths. Thus, there is not really much of an excuse to rely on file copy when you can do:
C:\>git clone //myserver/repos/foo.git
Note that all backslashes are written as forward slashes according to Posix convention rather than Windows.
I still don’t like the fact that Git insists on translating newline conventions when working between platforms, but I’ve read that Git places a high priority on data consistency and safeguarding against corruption, so I guess I’ll just be reassured that a lot of people that are smarter than me are looking out on this one.
However, the natives were growing restless, and there were rumors of some new and attractive languages in town, namely Ruby and Python. I had written off both as non curly-brace languages when I first looked into them a while back, but somehow they kept creeping back into my peripheral vision.
Finally, I dug into Ruby.
For whatever reason, the difference in syntax was enough to force me to think about the fundamental meaning behind what I was writing in code. More specifically, meaning in a sense that was abstract from the language itself, since the language was foreign but the underlying concepts were familiar. Previously I would be tempted to map the concept one-to-one with C# or Java, but the difference in syntax forced me to think a little extra.
Ideally, the syntax should become transparent. I haven’t reached this point yet though, except maybe in C#. The problem is that my knowledge of C# is heavily entangled with my knowledge of the .NET platform, so in essence, the very definition of mixing syntax and semantics. One of the main goals I have with learning languages such as Ruby and Lisp is to break the cognitive habits that build up over time in dealing with a single class of language in most of your work.
Lean startups thrive on information in the same way that lean manufacturing plants do. The only difference is that startups thrive on customer data rather than process data. Getting the best return on invested time and resources means leveraging ready made solutions by fitting them into the framework created by customer knowledge.
I just read the latest from lean startup guru Steve Blank in which he talks about building an information culture. Lean manufacturing relies on transparency of the process so that any worker on the line can see manufacturing inefficiencies or defects. Likewise lean startups rely on any employee being able to access and act on customer data. This means that it is not acceptable to have customer data locked up in a sales database that is only accessible by the sales team. It means that results of split testing is not locked up and only available to marketing or, heaven forbid, only to engineering!
At Ubernote we were fortunate to have had great customer responses to our surveys, but could we have acted on the data better? Certainly the founding team pored over the data with a fine-toothed comb, but could we do one step better? We sure could, and did. We took the data and our initial analysis and put it in front of our advisors, and more importantly, the rest of our development team! That’s right, the guys in the trenches need to know what they are fighting and how their work fits into the customer’s perception of the product.
The payoff of the information culture within your startup is that the returns go to the teams that leverage existing commodity knowledge (open source, market data, etc) and are then able to produce non-commodity knowledge from their own data.
I bought a Casio DG-20 digital Midi guitar a few years ago thinking that it would be a cheap way to input Midi data into my sequencer using guitar fingering. I was partially right, but the feel of the instrument is not quite the same as a real guitar. The pressure-sensitive fingerboard is certainly unique, as I don’t know of any other controller that detects input in quite the same way.
My particular instrument was purchased on eBay from a person whom I think really didn’t know much about the guitar or its history. When I got it I noticed that the neck was bowed and there were several dead spots on the fretboard. All in all, it was in working order though, so given the rarity of these things I wasn’t too devastated.
I have made one previous attempt at tearing the guitar down in order to see if I can fix it. I didn’t have time to completely figure out how to get the neck off of the guitar in order to see what was wrong with it. Here I will document the second teardown attempt, which has been successful so far.
Step 1 – Remove the back of the guitar
In order to get started, we need to remove the back of the guitar. There are components attached to both halves of the guitar, so it may be more accurate to say that we are just opening the thing up, or splitting the halves open. Remove all of the screws in the back except for the screw that holds the strap button on. Note that the metal back plate that attaches the heel of the neck must be removed in order to open the guitar up.
Step 2 – Remove the neck
Once we have the guitar open, in order to remove the neck we need to remove the two screws that are still holding the neck on that are located in the area between the heel posts that stick up toward the back of the instrument. There are also three nuts that must be removed. The nuts are located just to the right of the heel of the neck in the picture above. These nuts hold the metal stay that keeps the rubber contacts of the fretboard in contact with the ‘common’ wiring. There is one extra nut that attaches a ground connection eyelet. Once the last nuts and screws have been removed, the neck will lift clear of the body easily. If there is any resistance double check that the screws and nuts have all been removed.
Step 3 – Remove the fingerboard
The fingerboard is held on by double-sided adhesive tape and two small allen bolts near the nut. First, remove the allen bolts using a 1.5mm allen wrench. The bolts can be exposed by gently pulling back the rubber fingerboard material near the nut of the guitar as shown in the photograph above. Once the allen bolts have been removed, carefully pry the fingerboard circuit board up from the neck of the guitar, starting at the heel of the neck and working slowly up toward the nut. Since the end of the board is exposed near the heel, you can pull up gently on the end of the board to get started, and then insert a thin screwdriver several inches down the neck to start prying up the fingerboard. Continue along the length of the fingerboard until the whole board is free of the neck.
The screws that were supposed to be holding the metal truss rod in place were rattling around inside of the neck. Also there was some damage to the screw holes where the screws were supposed to go. I’m not sure if the instrument was dropped, causing the screws to shear off, or if someone had already opened the neck up to try to fix it before. The metal bar is quite heavy, and seems to serve a dual purpose: to keep the neck straight and to balance the weight of the guitar.
Now that the fingerboard has been removed, the hard stuff is over. The rubber contact material will just pull off of the contact circuit board, as the only thing holding it on now is a small grove in the rubber material into which the edge of the circuit board fits. In the next picture we can see the contact surface of the circuit board and the contact surface of the underside of the rubber fingerboard.
Notes on the fingerboard design and operation
The integrated circuits that can be seen on the reverse side of the fingerboard are actually diode arrays that are intended to prevent ‘ghosting’ of finger presses. Since the operation of the guitar requires that multiple finger presses be accurately read by the guitar logic, diodes must be installed to prevent false keypresses from being registered. Note that this is not the same as debouncing. The wiring layout of the fretboard is a simple matrix, which is probably scanned by the input controller logic to determine which frets are being fingered. There is a really good explanation of key scanning and ghosting here. The datasheet for the diode arrays can be found here.
Fixing the dead frets
The resistive contact technology used in this guitar is the same that is used in most synth-action keyboards. Therefore, I am pretty confident that this controller can be fixed by using conductive paint (found in automotive windshield defroster repair kits) on the rubber contact strips of the fretboard. I have repaired my Edirol PCR-30 keyboard in this way. However, there also appears to be some damage to the ribbon cable wiring that is used to connect the fretboard to the rest of the guitar circuits. The ribbon cable was pinched severely in the heel of the guitar when it was reassembled by a previous owner. I’ll detail the repairs in a follow-up post. In the meantime I’ll share a few close-up detail shots that I took of the fretboard assembly.
Close-up of the rubber fret contacts
Close up of the circuit board contacts. Note that the fret itself would fall in the space between the contacts.
Detail of the Sanyo diode IC used