NilObject

Sometimes workarounds are fine, but you shouldn’t work around everything when the problem is simple enough to fix.

2 Comments »

Here are a few things that I’ve read over the past month or two that I thought everyone here would be interested in. Enjoy!

Stroustrup on software development. Bjarne Stroustrup is the person who designed C++, and he offers some insight to his personal feelings of software today, languages, and more. My favorite quote:

… There are just two kinds of languages: the ones everybody complains about and the ones nobody uses.

A short, but great read.

Steve Jobs’ commencement speech at Stanford. He challenges Stanford graduates to “Stay Hungry, Stay Foolish” by recalling three stories of his life. A wonderful speech that should inspire all of us.

Getting Software Done. This article talks about the book Getting Things Done by David Allen and relating it back to the software development process. I’m a big believer in GTD, and you can get the book on Amazon for just a hair over $10 through the link above. I’m working on a todo application that I plan on releasing in January that encourages the GTD philosophy. It’s called, “The art of stress-free productivity,” and after a few weeks of using it myself, I can honestly say that it works wonders.

Nine things developers want more than money. While this article clearly is written for management, it also can help pinpoint what you like and dislike about your job. Give yourself a point for each item that is well done, and monitor the score over the course of time. If you see your score dropping, make sure to bring up why you’re unhappy with your managers. Nine times out of ten they would much rather keep you happy and productive rather than see you move on to another company. Best of all, these things don’t require more money, just a bit of creative thinking on their part!

I hope you’ve all enjoyed these reads. Are there any good articles relating to work/development that you’ve come across recently? If so, leave them in the comments section to spread the wealth.

Comments Off

No, not the social type things, which I’m sure all of my readers are very familiar with, right? I’m talking about Dates as in July 1, 2006. Dates are complicated.

Why, you may ask? Well, just as there were encodings around the world, date formats differed around the world too. If you’re used to the class in REALbasic, all of the mentality in it is based off of the US standards, or more accurately the information given by the Classic Mac OS (since REALbasic 1.0 was not cross-platform, there was no concern of what the behaviors were).

This gets complicated now that there are many translations of REALbasic and are distributed in even more countries. We need to consider that our API needs updating. But what should we offer?

Well, there are three types of information that are useful, at least as I see it. There’s the US locale, the user’s locale settings, and the ISO 8601 standard.

The US Locale is useful because of existing applications and existing business. A lot of code out there relies on the current behaviors, and a lot of businesses operate internally on the US date formats and definitions. So, for legacy purposes, the US Locale format must remain in place.

The user’s locale settings is a no-brainer. End users don’t want to be confronted with date formats that are different from what they’re used to, nor do they want to be told that Sunday is the first day of the week when it isn’t for them.

Finally, there is the ISO 8601 standard, which defines date formats in a universal manner so that there are no confusions. It defines what a week is, what the first week of the year is defined as, and how to format a date-time with timezone information so that it cannot be misunderstood.

I’m not suggesting that we’re changing things this moment, but a feature request prompted me to think about the problem a bit more, and I realized that the complexity of everything made this interesting enough to warrant a post.

2 Comments »

For one of my other projects I am working on, I developed a Universal Binary plugin for REALbasic that interacts with Growl. I figure I must not be the only RB developer who wanted to do this, so I packaged it up and uploaded it this evening. More information can be seen on this page.

2 Comments »

Judging by the poll a few days ago, most of you are just generally happy with a blend of content on this blog, which is what I both expected and hoped for. A fair number are hoping for some more in-depth tutorials, and so now the task is determining what areas of REALbasic in which you, as my readers, are most interested. I’ve only listed topics that I feel I have a good amount of expertise in, but feel free to vote “other” and place suggestions in the comments.

Additionally, if you have a specific idea that you think would make a good tutorial, please do post it in the comments. There are only two hard parts about writing: 1) Finding the time, and 2) Finding the inspiration. Hopefully you guys can help take care of #2

 Loading …

6 Comments »

So, today’s not-so-fun bug fix is pksarnzv. The problem is that on Mach-O PowerPC applications, the unhandled exception event doesn’t fire the first three times that an exception is raised, and then being firing after you choose Quit. A truly odd one that I spent nearly a week looking at during the r3 cycle to not end up getting it fixed in time for release (I did fix many other exception bugs, however). I finally revisited it today, after a much needed break from looking at the code, and fixed it.

The cause isn’t something that can be directly applied to users of REALbasic, per-say. It was actually just a simple porting error on my part when switching from CodeWarrior to GCC. The code that handles exceptions from within C++ code lives in a very old code, and as Mars put it, it’s “a Deep Mystery from Ancient Time.” After noticing a small behavior that I thought Mars could help me understand a bit, I called him up and described the problem again, and as I started explaining the results, he interrupted (thankfully, because I was going off on a wild goose chase) and mentioned that it didn’t look like we were stopping at the main event loop handler. Huh?

My initial reaction was to respond, “But there isn’t one!” However, before I could finish the statement, I then remembered exactly where the problem stemmed from. This short conversation triggered a memory of me looking at a block of assembly (which at the time even had 68k code too). Right below it was a “#else” block for not PowerPC in which we just used the regular C++ style call. My thoughts: “Well, if it works like that on Windows and Linux, it can work that way on PowerPC and Intel Mach-O for now.” It turns out that I was wrong in that judgement — the assembly code had an inline exception handler, which the x86 portions of the code registered in a different way.

I don’t really blame myself for the hasty decision to skip over the assembly code — I was in a “get everything compiling” mode, in which the most common errors encountered were that we had both PowerPC and 68k code, and we assumed if we’re on a Mac and not PowerPC, it must be 68k. So, I was habitually ripping old code out, and getting things to compile.

But I digress, after realizing what needed to be done, I went down the tedious path of porting the assembly to GCC, which in the end was a fairly straightforward task, once I figured out that the cryptic error “block assembly operand not recognized” meant “something is wrong with your method declaration that is causing me to balk at perfectly valid assembly.”

So back to the title. When I run into a brick wall and need some ideas, ask someone who is mostly unfamiliar with the problem you’re solving. By not being familiar with the problem, they’re able to ask you questions about it that you may not have thought to ask yourself. In this case, I called Mars up and a simple guess on his part triggered a memory of the exact problem.

This sort of thing happens a lot. When your mind is set on solving a problem, you will invariably get locked into the thinking, “it must be here” or, “I need to fix this right here.” However, sometimes that route isn’t the simplest or perhaps it isn’t the root cause. An outside thinker may be “stupid” in regards to his or her knowledge of the problem at hand, but each person approaches a problem differently, and thus can provide wonderful insights even from a two-minute conversation.

Next time you’re stuck with a problem, remember that it might be worthwhile to take a break and talk to someone else about it. It may not help at all, but it also might save you a lot of time.

1 Comment »

I decided to add my own section for polls on this blog. The polls I’m using require JavaScript, so if you’re using an RSS reader or aggregator, you’ll probably need to open the site to vote. And of course, all votes are greatly appreciated, and feel free to open discussions in the comments section.

The first one is geared towards understanding your desires in my blog postings. What kind of articles do you like the best, and what would you like to see more of?

 Loading …

Comments Off