Blue Static

Archive for the ‘software’ tag

Looking Towards the Future

Posted on October 28, 2019 at 15:30 UTC, filed under the category MacGDBp. Tags: software, MacGDBp,

First, welcome to the new Blue Static! The site has a fresh coat of paint, it has been made more mobile-friendly, and I have updated much of the content, pruning extremely old things while keeping still-old-but-maybe-interesting items around for posterity. For the first time in the history of the site, Blue Static is no longer powered by PHP: the entire site is now rendered as static files by Hugo.

It has been well over seven years since this site was last updated, and that is because I no longer have the substantial amounts of time I once had to dedicate to Blue Static software. Since I now spend all of my working hours writing and maintaining software, the allure of doing so as a hobby has unfortunately diminished.

Over the past few months, I’ve pondered how to move forward with the various Blue Static projects. I’ll outline some of those decisions now:

MacGDBp still has a large number of loyal users. I’m happy to report that in these intervening years, I’ve worked sporadically on the next major version. The first beta of MacGDBp 2.0 will be released before the end of the year! The entire core debugging engine has been rewritten and made more robust, which has fixed many bugs and added new features. The new version will also be code signed and notarized to be compliant with Apple’s increasingly locked-down macOS.

RGB Converter will remain available for download, but because Apple has removed Dashboard in macOS 10.15 Catalina, the widget will not be updated anymore.

Bugdar is the project that I’ve struggled to make a decision on. It is fairly safe to say that any 2.0 greenfield rewrite will not happen. However all of Blue Static’s bugs remain in the Bugdar instance that runs on this site, so it cannot go anywhere over night. I am not currently enamored with other options, such as Github’s issue tracker, so despite Bugdar’s visible age I will continue to run it for Blue Static’s purposes. There may be an infrequent maintenance update, but I do not expect to make major changes to the software at this time.

What drove these decisions is that I have largely stopped writing software in PHP. It is no longer my language of choice, and my interests have moved on to other programming languages and software domains. MacGDBp remains important to me beacuse others find it useful and the code is still fun to work on.

I’ll close with a teaser: there is at least one new project that I will be publishing in the future under Blue Static. It has to do with email and is geared towards power-users.

Look forward to MacGDBp 2.0 Beta 1 coming to a Sparkle update near you!

MacGDBp 1.3

Posted on May 19, 2009 at 03:51 UTC, filed under the category MacGDBp. Tags: mac os x, MacGDBp, software,

I’m pleased to announce MacGDBp 1.3. This release features a new tool that allows you inspect values in the variables list via a HUD (screenshot below). This inspector will allow you to see long strings and to select/copy text values. To access this feature, go to Window → Inspector (Shift+Cmd+I). The currently-selected variable (which now, in 1.3, remembers itself across debugger stepping) will have its full value displayed in the HUD window.

MacGDBp 1.3 Variable Inspector

Under the hood, there are two significant changes. The first is a rewrite of the receiving side of the socket layer (it now precisely uses the message length when buffering memory), which should eliminate the “buffer is incomplete” errors that occasionally popped up. The second is that the PHP stack will no longer be managed internally. After every debugger step, the entire stack will be now re-created because Xdebug proved to be unpredictable for keeping in sync with an internal state. Debugger actions may now seem a little less snappy, but I think accuracy is more important than speed here. In 1.4 I’m going to use a caching mechanism that will speed up performance by reducing network access.

This release also features a bunch of bug fixes, a couple of which would cause the debugger display to not work under certain circumstances. As always, the change log and commit log have all the details on the release.

Toolchain and Gitcrement

Posted on April 4, 2009 at 20:54 UTC, filed under the category Uncategorized. Tags: Gitcrement, software, Toolchain, tools,

I’ve posted today a git repository called Toolchain. This is a collection of scripts that I use that others may find helpful. You can find the repository here. In this post, I’m going to talk about one of the items in Toolchain called Gitcrement.

Gitcrement is a set of two scripts that solves the problem of creating build numbers when using git for source control. Unlike Subversion, where the repository revision is the perfect choice for a build number, git has no such luxury because it uses SHA1 hashes for identifiers.

This is where Gitcrement comes in. Gitcrement is a simple interface to a database that contains a sequential ID number (the build number), a username, the current date/time, and a git SHA1 hash.

The gitcrement.py has four commands: init, next, list, and current.

To create a new Gitcrement database, go into any git repository root and type “gitcrement init“, which will create a new database file called .gitcrement.

When you want to create a new build number, simply type “gitcrement next” to record the current user (`whoami`), date and time, and whatever SHA1 hash `git info .` would reveal.

To see the current build number type “gitcrement current” and to get a list of all the build numbers type “gitcrement list“.

That’s all there is to it. To make this system useful, however, it needs a script that can be run in Xcode to automatically call “next” and save the value as CFBundleVersion in Info.plist. So, there’s another Python script called xcbuild.py, which you can use as a Custom Shell Script Build Phase. This will advance the Gitcrement number every time you build the “Release” target in Xcode.

Gitcrement requires Python 3.0, which is not installed by default in Leopard. You can find it here or through MacPorts or fink.

Also, you may need to edit the installation paths in the tops of both files to point to where your copy of “git” is (in gitcrement.py) and where you install the “gitcrement” script (in xcbuild.py).

You can download Gitcrement here:

Link in Gitweb

Source TGZ

Why Go Open Source?

Posted on December 29, 2008 at 19:47 UTC, filed under the category Uncategorized. Tags: open source, software,

People sometimes ask me why I don’t charge for the software I write. I explain to them that, to me, it’s not about the money. But that’s only part of the story. After thinking about it there are a few reasons why I release everything as open source.

1. You’re Giving Back to the Community

This is what the entire FLOSS community and its mentality is about. You have this great software and you want to give back to the greater community by making it open source. Doing so means that all developers can see how you’ve chosen to implement certain things, they can borrow code, and they can help improve software by submitting patches. For me, I learn a lot of programming languages and techniques by dissecting open source software, and I feel it’s only fair for me to give back to the community as much as it has given me.

2. You Don’t Worry About Business

I’ve been reading some articles about indie development and I watched all of the C41 videos. From doing so, I’ve realized that starting an independent software shop is a lot of work. You have to get a credit card processor, you have to have a licensing infrastructure, you have to worry about piracy, and (arguably the most difficult) you have to find the right price for your software. We’re software developers, not business people. This is not my idea of a good time and I’d much rather spend time developing rather than doing the aforementioned tasks. Going open source frees you from all of that.

3. People Can’t Have Expectations

That is sort of a half truth. People will always have expectations about software, regardless of whether or not they pay for it. But when you develop open source software, you’re essentially a volunteer. People get what they pay for. I try to do my best in creating software and supporting it, but because it’s open source, there’s no expectation that I have to. As a full-time college student, I don’t have a lot of free time — I develop when I can. If I had paying customers, there’d be an expectation for future versions on a reliable time scale, but I’m not under that pressure. Additionally, I do not have to support this software with immediate email responses, blog follow-up comments, or forum posts. I do so because I like doing so. If this were a business, people would have high expectations for support, but because I do open source work, if I deliver good support, it’s only a bonus. If I don’t, they really can’t complain because they don’t pay for anything.