Now that Fall is here, it's been a time for a lot of home projects and not a lot of time for programming. I caught up on a couple of things that needed to get done before Winter kicked making them all but impossible to do. One of those things was building a drum riser for the kit in the basement office. Since the web is surprisingly bare of reasonable instructions on how to do this, I thought I would share my plans. The link below goes to a static page because the content is far too in depth for this blog. Enjoy...

How To Build A Drum Riser

It's been a busy, busy month here at O&C, both at home and at The Day Job.

Simple Cataloger is steadily selling still and I've gotten some great feedback from customers and trial users. A lot of their feedback has been for features I had thought about doing already, but I wanted the application to be out there for a while and wait and see what users would ask for. An upgrade will be coming before the end of the year hopefully with those requests. At the very least, I need to make sure that the app works in Mac OS 10.5. Those .x really change the rules every time.

People have been working furiously working on the new ARBP members website. I contribute as best I can, but I feel I'm more than a little out of my depth with the web work, though I'm learning more than I'm doing which is more important than anything (and one of the main reasons why I volunteered in the first place). So, it's all good.

I've noted earlier on this blog that I got an iPhone. I'm not going to write yet another review, because that's been done a gazillion times already elsewhere by people who are much at doing such things. What I am going to write about is how an iPhone app led me to a quick but fun REALbasic project.

I recently picked up the Bloom application from the App store (links to iTunes). The application is an exercise in ambient, generative music. A user can interact with the app by clicking on different areas of the screen to play simple musical notes, or the app will take over after being idle for a period of time, all while playing over a well padded drone.

It's all very Eno and a great app to show off the iPhone. Brian Eno is one of my favorite musicians, so even before I knew anything about the app, I picked it up. A risky move, I know, given all of the flotsam and jetsam in the App store already.

It proved to be a fun investment, and as I played with it sorting out how it worked, options and all, I began to think about how I could write an application like that. The application is simple in concept but leaves open a good number of variations within itself.

Over the weekend, I wrote up some pseudo-code, and coded the core of the app in REALbasic. It doesn't look or sound exactly the same because I'm tying into the same frameworks as their code, but I created a reasonable fascimile of the core of the app. I realized after writing it that it answered some of the questions I more commonly see on the Forums and the NUG. It's a fun little app that is ripe for customization and expansion.

Normally, I'm not one to release any of my code. I mean, I usually only code for the Day Job and for my own commercial stuff, and besides someone might actually look at it and actually...yikes...critique it. But I decided that the ARBP would be a good place to start getting some of my work out there. So, I uploaded REALbloom's code the code repository on the soon to come members only site.

REALbloom offers a simple structure for handling animated graphics with dynamic transparency. It also includes Joe Strout's YNotePlayer class, a currently Mac OS X-only replacement for the now de-emphasized NotePlayer.

I also uploaded the code for a little helper app that I have for IDE scripts that mimics the clippings window in BBEdit that call RBClippings. It shows not only how helpful code generation can be, but also offers an easy to maintain user preferences module. It's another app ripe for customization and expansion.

Share and enjoy! If you make any useful modifications to the code, please feel free to show me and upload to the code repository once it's up. You have to join (free, even) to get it, but I think the rest of the ARBP members site will be worth your time even if my code isn't.

Today I went from a four year old "comes free with the account" flip phone to an iPhone. The flip phone served me very well and easily had another year of life in it. I just got tired of coming across questions I just knew I could get the answers to if I only had an iPhone.

It's worth every last penny.

Sent from my iPhone

Every so often I see comments in the REALbasic mailing lists and the forums from Mac users claiming that REALbasic is a Windows-centric tool because it doesn't offer certain (or enough) Mac-specific capabilities. But, then, I also see the same sentiment echoed from the Windows users claiming that it is a Mac-centric tool for the very same reasons (I don't read through the Linux forums so I have no idea what they're saying).

The latest round of claims got me to thinking about why that must be, and I hit upon the answer in a rather roundabout way. I stumbled upon it while digging through some older emails looking for some information where an RB engineer (who shall remain nameless) basically said the reason why they weren't going to implement some control was because wasn't cross-platform. In other words, you couldn't use that control on all of the supported platforms. Huh. I never thought about it that way, but fair enough. REALbasic is a cross-platform tool so it only stands to reason why some controls are past a certain line.

So, the truth is, as I see it, in the end REALbasic is neither a Windows-centric nor Mac-centric tool. In fact, it's neither and both all at the same time. What it is, really, is the Lowest Common Denominator. But I don't mean that in a bad way, in fact, I think that quality is one of its greatest strengths by far. Even though I program primarily on the Mac, I've done the cross-platform bit. It's really cool. I've literally written one set of code, compiled for Mac and Windows, I didn't have any platform-specific issues, and blasted it out to dozens of users who have used my app daily for two years running now without a single complaint. (Good luck with that, Java.) Now knowing that, I think it not only renders the Windows- and Mac-centric arguments null and void, but also shows really just how great REALbasic is at its core. There's nothing like it.

However, I think a case could be made for more platform-specific features, particularly in the area of controls. REALbasic offers a wide variety of controls, enough to suit the vast majority of needs. I really can't complain. Controls like the Canvas and Listbox are so robust that I think one could do just about any kind of app they want with just those two alone.

But, there are times when a Mac-only control would just do the trick to polish up an application into something that looks like a Mac application through and through. You know, something that users would expect. The Round and Help buttons come to mind, as do the Segmented Cell, Segmented Control, and the Circular Slider. These are relatively simple controls, but they are so decidedly Macintosh that there have been times when one of them would have been the perfect control to put into an interface. They are, as far as I'm concerned, signature controls for the Mac; they help make the Mac the Mac. I'm sure that if I dig around VB.NET long enough I would find some controls that have that "Ooh! That's the one!" factor to them as well.

I've always had the impression that being the lowest common denominator is a really tough job mainly because it is, in this context at least, trying to be all things to all people. It's a double-edged sword. I experience that now in my Day Job to a smattering of internal "customers" (other departments), and it is really hard to keep up sometimes. But, the book publishing landscape changes (albeit slowly) and there are times when I just gotta give in and do things that more or less go against my department's paradigm up until that point. Thanks, e-books.

My naivety about how things work over at Real Software, which I feel is the same naivety that drives the complaints that are the topic of this article, wants to think that it shouldn't be too hard for them to sprinkle in a few more controls on each of the platforms. I mean, we already have Windows and Mac-specific features in the framework itself like FolderItem.MacCreator, FolderItem.MacType, and all of the Microsoft Office classes (which, BTW, were cross-platform at one point. Thanks, Microsoft). Controls are obviously much more complex than datatypes and values, but still, I think the case could be made for more platform-specific controls, and the extra work I think would be worth it.

I can, as an alternative, use declares for getting Mac-specific controls into my applications. But, man...have you seen those things? I dig all the power and all that, but that's a whole lot more typing than the rest of my code for one object, and a whole lot of "math", too. As clean as the REALbasic syntax is, declares are still a hassle. I could also use a funky combination of screenshots, masks, and a canvas to recreate these controls, and I'm about to do just that, but doing so is...well...funky. I would much rather leave that to someone else to maintain.

I can certainly understand the REALbasic engineer's point that they didn't support the given control because it couldn't be found on all platforms. However, I think that may be a bit of a hindrance to the framework, and it would be nice to see some of these deprecated objects replaced with items that speak to a renewed focus. REALbasic's inevitable move to Cocoa I'm sure will open up many doors for the framework, as will Windows 7/Vista 2/Whatever. Exciting stuff is in the works from all directions. REALbasic has given me everything I need to get my work done while having fun at the same time, and I'm hoping that I might get just a little bit more.

From the recent Bank of America commercials featuring Keifer Sutherland voiceovers (money a bit tight, eh, mate?):

This is America. Do we let the sun just shine and the wind just blow? No. We put them to work.

Well, actually, Bank of America, we don't put them to work. Why does energy policy exist only in absolutes?

---

I abhore automotons and ATNA managers in any organization.

---

I find it laughable that industries which absolutely abhore government regulation and fight any intervention at every turn are usually the first ones that cry for help from the government when they are the victims of largely their own devising.

---

While driving up I-495 one day I came upon a gasoline tanker truck that was weaving through traffic moving faster than most cars would reasonably allow. I was appalled when at one point, the driver wove through two cars so quickly, he put his truck at a fairly jaunty angle while weaving between them to the point where I swore it was going to crash. At that point I sped up to get as much asphalt between me and him. Soon after I did that, I came across a septic disposal truck doing the exact same thing. Which immediately made me wonder that between a gasoline tanker truck and septic disposal truck crashing and potentianlly spilling its contents, which would be worse to deal with?

---

You can't be against globalization and still get your coffee at Starbucks.

I have a strict personal rule about discussing political issues on this blog for all the obvious reasons, but also mainly I really don't care all that much what people's affiliations are just as long as they vote. Voter turnout here in America is appalling. Really, we, as a country, ought to be ashamed of ourselves.

At the same time, I think the single largest problem facing the voter turnout issue is by far the easiest to fix: the complete and utter lack of convenience. Why are we still, after all this time, still voting on a weekday in the winter? If we can tweak the constitution to enact something as inane as Prohibition, then we can move voting day to a freakin' Saturday in April. Or even just April.

On the last Presidential election day, the blizzard facing us was so big, I actually had to decide between voting and going to grocery store before the storm set in and dumped at least a foot. Vote or food? Hmmm... It's a decision I should never have to be faced with again.

Why Tuesday?

To not change election day to a better time of year, if not a better day of the week is just foolish if we wish to keep the masses interested.

Whatever spam storm that flitted through here seems to have passed. So, I've allowed comments, and even then, they have to be approved first. So, if there's a delay, it's because I haven't gotten to it yet. We'll see how it goes...

My two favorite features...

Language Reference search results
The new search in the Language Reference is fantastic. I have other similar LR-like tools in other development apps, like Coda and Xcode, but REALbasic's search results are the most useful by far.

Constants can be used in declarations
No more Magic Numbers! Now there's no excuse...

MusicSketch has hit a milestone: It has surpassed 10,000 lines of code. I agree with Bill Gates when he says "Measuring programming progress by lines of code is like measuring aircraft building progress by weight." I've seen awesome apps made very economically, and total crap made with enough bloat and convulation to make a bureaucrat's head spin. Really, I was just curious about what it was and was greatly surprised at the number.

The list of things to do is small but deep, and coding has been going really well lately. There's the Undo/Redo system, the Help system, a few multi-track editor specific features, and a myriad of small but necessary bug fixes and tweaks to ensure a quality experience. I've found that even though the code is large and complex, it's totally maintainable. I'm actually having fun working on the hard problems and seeing almost immediate positive results.

In honor of this important-yet-not milestone, I've compiled the following list of things I've learned along the way, both the hard way and the easy way. This is all the stuff I wish someone told me at the very beginning even if I didn't understand it at the time...

• Patient and careful program design at the beginning before you write one line of code pays off in dividends when you are writing code and even more when fixing bugs later.
• Bug tracking doesn't have to be complex, you just need to be diligent in finding (or creating) and using a system that works for you.
• Comments = overhead. A well thought out, and consistenly used, coding convention = self-documenting code = less comments = less overhead.
• Don't be afraid to put something aside and work on something else (in the application or out) if you've finally wrapped your head around one issue but are stumped by something else.
• Pseudocode is your friend. Brainstorms are good suggestions at best but are rarely followed to the letter.
• An Undo/Redo engine needs to be thought out before and during the development process and not after the fact.
• Don't be afraid to rewrite.
• Always be sure to end the programming session with a working build, even if it means you have to comment out not-quite-working-yet code, then spend a little time just futzing around with it. You look at the project from a different perspective (the user's) and it really helps with your morale.
• Encapsulate methods, functions, and properties first, and make public only when necessary.

A lot of this is simply echoing Code Complete. If you haven't read it, you should.

Comments have now been de-activated until further notice. I saw myself getting into a pitched battle with some wanker spammers, people (scum) whom I have absolutely no patience nor tolerance for, that were abusing the comments system here. So, I took it down. Now nobody wins. Idiot wanker scum.