Small Biz Mac, Small Biz Mac focuses on using Mac as the foundation of a small business--the operating platform, the market, and more. This blog will discuss both the challenges of operating a business on Mac hardware and software, and the impact of the broader Mac market on business.

Your Hosts
Kevin Walzer and Lori Jareo, publishers, software developers, Mac/iPhone users, and small business owners.

Subscribe to RSS Feed
Get a syndicated feed of this weblog.



Privacy Policy

Site design: Skeleton

Thu, 16 Jul 2015

Why I prefer the Mac, developer edition

A few years ago I spent several months porting one of my Mac apps to run on Windows. I went through the entire development and release process, including rewriting portions of the app to conform to Windows UI conventions; converting app resources to Windows format, such as icons; deploying the app in a Windows-standard fashion with an installer; and releasing and promoting the app via a website, submissions to download sites, and so on. The app went through one update in addition to its initial release.

The app really didn't sell at all on Windows or even generate much in the way of downloads, so I decided to discontinue the Windows verison after about six months. I did enough work on the app, however, to gain experience with Windows development, and form an opinon of Windows development: It is a very uncomfortable experience.

I'd like to provide a bit of context on my experience. I'm a longtime Mac user and developer, working on OS X for more than a decade. My particular interest in the Mac is its combination of Unix power and Mac UI polish. That lack of UI polish is why I don't target platforms such as Linux, and the lack of a Unix foundation is why I had not previously considered targeting my apps to Windows. My main development work uses a cross-platform language and GUI toolkit, so I'm not the conventional Mac/Cocoa developer, but my apps and their supporting libraries are highly optimized for the Mac platform and do not focus on cross-platform features.

Given all this, I'm something of a hybrid between a Unix developer and a Mac developer--the same hybrid as OS X itself. Apple's development stack is hybrid in the same way. I am highly comfortable in the Unix environment using Apple's command-line tools (compiler and debugger, also ported as open source to other Unix platforms), but can move higher up in the stack to use Apple's IDE, Xcode, when necessary; under the hood Xcode calls the same tools. The integration between the UI layer and the command-line layer, and the ability to move between them, is what makes the Mac my favorite development environment. Moreoever, all of my development projects and languages (Perl, Python, and Ruby in addition to Tcl/Tk) fit seamlessly into this environment.

Windows does not provide the same harmonious integration of developer elements. Most Unix tools, compilers and debuggers have been ported to Windows and run just fine there, but they are not well-integrated into the environment, so using them feels a bit awkward. Microsoft's own tools are powerful and impressive, and do feature a great deal of integration of the development stack across the command-line and GUI layers, but not all projects make use of them. Using my customary Mac approach on Windows would require setting up a different toolchain environment for each toolkit I wanted to use: Tcl/Tk, Perl, Python, and Ruby. An alternative approach would be to use pre-built binary distributions of each of these languages, which reduces a lot of complexity, but also takes much control of my development environment out of my hands. It's a tough call.

When I contemplated moving back to Windows this year, a lot of these discomforts came back. Building Perl, Python, Ruby, and Tcl on the Mac is a straightforward process. I might have to customize a few settings, but mostly it boils down to running "configure, make, make install" in a terminal. Setting things up on Windows was proving far more time-consuming. Each language requires a different combination of compilers, build commands, and installation settings, and keeping track of them grew very frustrating. I realize I could have avoided some of those issues by using pre-built binaries, but I prefer to run my own builds from scratch.

In the end, I opted to stay off Windows. I am so much more productive on the Mac that it just makes more sense for me to focus there. And that's what I will do.

[/mac] permanent link

Shifting backup method

We are late to the Time Machine party. We've long run an rsync backup of business data on our OS X server to an external hard drive, which is periodically switched out and moved offsite. This is good for data backup but does nothing to help with restoring a corrupted system, which we had to do last weekend after an aborted update to OS X 10.1.4. (The server hard drive died last fall and was replaced under warranty; fortunately, this issue was just a bad installation that was fixed by a reformat of the drive!) While the re-installation process is smoother than it used to be, it is still a major investment of time to reconfigure all server accounts and settings. We read, with envy, how Time Machine users can simply restore their entire system from the Time Machine backup.

This provides a good occasion to update our external hard drives, which are now several years old; prices on 1-terabyte hard drives, twice as large as the installed drive on our server, have dropped tremendously, and will give us plenty of room for Time Machine backups.

We'll report soon on how all that goes.

[/mac] permanent link