<VirtualHost *:80>
	ServerName www.codebykevin.com
	ServerAdmin admin@example.com
	DocumentRoot "/Users/kevin/Sites/codebykevin"
	DirectoryIndex index.html index.php /wiki/ default.html index.htm
	CustomLog "/var/log/apache2/access_log" combinedvhost
	ErrorLog "/var/log/apache2/error_log"
	
	<IfModule mod_ssl.c>
		SSLEngine Off
		SSLCipherSuite "ALL:!aNULL:!ADH:!eNULL:!LOW:!EXP:RC4+RSA:+HIGH:+MEDIUM"
		SSLProtocol -ALL +SSLv3 +TLSv1
		SSLProxyEngine On
		SSLProxyProtocol -ALL +SSLv3 +TLSv1
	</IfModule>
	
	<Directory "/Users/kevin/Sites/codebykevin">
		Options All +MultiViews +ExecCGI -Indexes
		AllowOverride None
		<IfModule mod_dav.c>
			DAV Off
		</IfModule>
	</Directory>
	ServerAlias codebykevin.com
	AddHandler cgi-script .cgi

</VirtualHost>

Re-start Server.app. It should read the updated configuration files.

This approach is mostly undocumented by Apple, and I have not seen it documented in its entirety elsewhere on the Web either. Part of my purpose in documenting this here is to assist anyone else who might be frustrated by the limited functionality of the GUI tools in Lion Server for Apache configuration. (It's a mystery to me why Apple removed this functionality. The other hugely complex configuration that I deal with in the server, mail configuration, can still be managed from the GUI tools in Lion Server; the workflow is a bit different, with the advanced options removed from Server.app and placed in another program (Server Admin), but it's all still there, one way or another.)

I am certainly please to see the reduced financial cost of server support in Lion, but especially with web configuration, Lion Server incurs other costs. I don't want to discourage anyone from buying Lion Server, but you do need to be aware of its limitations.

[/general] permanent link

QuickWho 3.3

I've released version 3.3. of QuickWho, my application for querying information about Internet domains. This release is aimed at integration with Lion's sandbox requirements, and replacing several external tools that previous versions of QuickWho used for getting domain information. The release is a useful update to QuickWho and I encourage you to give it a try if you prefer to run domain queries from the desktop rather than a browser.

[/software] permanent link

Playing in the sandbox

Apple has pushed back its deadline for applications to comply with Lion's sandboxing requirements, which is coming soon as a prerequisite for new submissions to the Mac App Store, to March 1, 2012. As I've explained before, sandboxing is a big new development for OS X. Briefly explained, it places strong restrictions on what an application is able to do in terms of reading and writing data, network access, and so on. A developer must assign specific privileges, or "entitlements," to the application. The intent is greater security for end users, by making it harder for malware to take over an application and hijack the user's system.

Like many developers, I have some concerns about the entire way sandboxing is being rolled out. Unlike many other major changes from Apple over the year, sandboxing is being introduced without much evidence of internal testing by Apple. Developers are being asked to be guinea pigs as Apple works out the system-level kinks in the sandboxing system. This in turn creates a lot of uncertainty among developers about what will and won't work with sandboxing, what changes developers will have to make to their applications to conform to the sandboxing model, and indeed, whether it's worth it to continue selling applications in the App Store if sandboxing would significantly change the applications' feature set.

In my case, I've had to hold off on submitting a sandboxed version of QuickWho to the App Store, because there is a mysterious crash in the application that is a direct result of sandboxing. It does not appear to be something I can fix, so I've had to submit a bug report to Apple and hope that it gets reviewed and addressed in a timely fashion. That's a form of uncertainty I'd rather not have.

I don't anticipate giving up on the App Store, but I'm going to have to continue to monitor the situation with sandboxing and adapt as best I'm able.

[/business] permanent link

"The language"

Daniel Jalkut had an interesting blog post the other day (in response to a similar post by Brent Simmons) about Objective-C as a programming language: it's not just his favorite language, but instead is "the language." I take that to mean his lingua franca, both the go-to tool and the standard by which he measures other tools:

By no means is it perfect. But for its elegance, and for the fact that it fulfills many of the requirements of object-oriented programming, while maintaining the familiar simplicity of C, it presently earns the title of the language for me.

This prompted me to look at my own toolbox, and to ponder what might serve as "the language" for me. I have several languages that I turn to, depending on the requirements at hand. I make extensive use of both "scripting" languages--high-level programming languages that are executed by an interpreter tool--and "systems" languages--low-level compiled languages that run at blinding speed and integrate with an operating system at the deepest level. With that digression out of the way, let me highlight my go-to languages for various tasks:

Somewhat to my surprise, my language toolbox is rather unusual among Mac OS X developers. Nearly every Mac OS X programming blog that you read will read like Daniel Jalkut's, expressing strong preference for Objective-C as a programming language and endorsing it as the best way--indeed, for most of these developers, the only way--to create full-fledged Mac applications. This attitude has always puzzled me. While systems programming languages offer undeniable power, and indeed Objective-C is an elegant language, the trade-off for developing in such languages is developer time; development in a compiled language is much slower than with a scripting language, mainly because of issues such as memory management (allocating enough memory in the system for the application, which is quite complex) and the code-compile-debug cycle of systems development. These issues are absent from scripting languages. Not only is the development cycle shorter with scripting languages, scripting languages can also usually accomplish a task with fewer lines of code than a compiled language. (See John Osterhout's article for a useful overview of this topic.) Because of these trade-offs, I prefer to develop applications in scripting languages--Tcl and Python are much more in my comfort zone--and save systems languages for projects that require it, such as integrating a native API into Tcl or Python.

I suspect that many Mac developers view Objective-C and the available tools for developing in it (Xcode, Interface Builder) as preferable based primarily on other system languages and toolkits; if you compare Objective-C to, for instance, Windows development in C using the Win32 API, Objective-C and Cocoa do look much nicer. I also suspect that if, as a developer, you are steeped in using systems languages, that may cause you to look askance at scripting languages as lightweight "toy" languages, or, at the very least, to overlook their possibile utility and advantages for desktkop application development. Another aspect is that when Cocoa developers tend to consider scripting languages in the context of desktop app development, they most often look at how the languages bind to the entire Cococa API; Python, Ruby, and other scripting languages have full Cocoa bindings, but accessing those bindings requires an awkward coding style that is not as clean as Objective-C or as standard coding conventions in that scripting language. (That's one reason why I haven't embraced Python's Cocoa bindings, instead preferring to integrate the Cocoa API's into my Tk applications as needed via extensions to Tcl/Tk.)

If I had to pick which one of my tools is "the language," I suppose I would pick Tcl--it's the linchpin for everything else that I do. My GUI's are written with Tcl's native toolkit binding, Tk, even in my Python programs. (Also Ruby, which I am in the process of learning.) If I need to add some specific native Mac integration to my applications, I usually implement that functionality as an extension to Tcl using the language's C API, or via AppleScript in some isntances. I love Tcl, especially its elegance and flexibility. Yet I would never want it to be the only language in my toolbox, and I'm glad that it's not. Having multiple languages at my fingertips makes my applications better, and exapnds the range of products I can offer my customers.

[/general] permanent link

Growl 1.3 and my apps

I've just installed version 1.3 of Growl, the venerable notification system for Mac OS X. This is a update for Growl because it's now available from the Mac App Store, for $2. While the product is open-source and used to be available for free, the modest fee will help fund continuing development, and I was happy to pay it.

The reason I mention Growl in this blog is that Growl notification support is a feature of several of my applications, and Growl has undergone so many changes that Growl support in my own apps is broken. I'm not alone here; many, many applications in the Mac OS X ecosystem support Growl, and a substantial number will need updating to support the new Growl. (I haven't made a count, but based on the comments and complaints in the Mac App Store, I surmise that the changes in Growl have been disruptive for many applications and their users.)

The developers made significant changes to Growl to make it compatible with the Mac App Store, and also to put it on a firmer development foundation for the future. That's understandable. Still, it's going to require changes to my own apps to make them compatible with Growl once again, and I haven't fully formulated my approach to solving this problem. As a result, I don't yet have a timeline for re-enabling Growl support in my apps. However, once that support is working again, new releases of the affected apps will be quick.

[/software] permanent link

Manpower 4.1

Today I've released version 4.1 of Manpower, my man page viewer for OS X. The big new feature here is integration with Lion's sandboxing requirements, which is coming soon as a prerequisite for new submissions to the Mac App Store.

Sandboxing is a big new development for OS X. Briefly explained, it places strong restrictions on what an application is able to do in terms of reading and writing data, network access, and so on. A developer must assign specific privileges, or "entitlements," to the application. The intent is greater security for end users, by making it harder for malware to take over an application and hijack the user's system.

In the Apple developer forums, there's been a lot of grumbling about sandboxing, for several reasons: it forces a lot of rewriting of applications to comply with its requirements; in some cases the restrictions simply reduce an application's functionality because certain things are no longer possible in sandboxing; and also there is a sense that Apple hasn't fully worked out sandboxing, as developers are running into more bugs and blind alleys than is usual. (Apple has a good record of "eating its own dogfood," or working the kinks out of a new feature privately, before rolling out this feature to third-party developers, and that doesn't seem to be as true here.)

Still, despite the grumbling, it's pretty clear that sandboxing is the future for the App Store and the Mac, and so I'm moving all of my App Store apps to the sandboxing model. I had a few kinks with Manpower, but got everything worked out eventually, and I expect the same for my other apps as well.

[/software] permanent link

The tenacity of Steve Jobs

Steve Jobs passed away yesterday at the too-young age of 56. Though I never met the man, I'm taking his death personally. His work has made many things possible for myself and my family that otherwise wouldn't have been.

By now the outlines of Jobs' life are well-known. After founding Apple Computer with his friend Steve Wozniak, essentially creating the personal computer indudstry, and then making the computer a tool for creativity with the Macintosh, he was forced out of the company by the new CEO he helped to recruit. Jobs then wandered in the business wilderness for a decade, founding an innovative-but-unsuccessful computer company (NeXT) and buying an innovative-but-unsuccessful computer animation studio (Pixar).

Then, starting in 1996, he had one of the greatest second acts in American business history. Pixar's animation technology finally matured to the point where it was feasible to make an entire movie using the techology, and the result was the landmark movie Toy Story. Pixar went public, made Jobs a very rich man again, had a long run of hit movies in partnership with Disney, and then was acquired by Disney. And Apple, nearing bankrupty, acquired Jobs' other company, NeXT, to provide the basis of its new operating system--and brought Jobs back to Apple. Apple then began its unprecedented run of hit products, from the iMac to the iPod to the iPhone and beyond, which have continued to revolutionize technology, and is now one of the most valuable companies in the world.

Jobs' work made many things possible for me. The technology he helped to create, particularly the Macintosh, allowed me, then a poet, to learn design and typesetting, which enabled me to take the written word (poetry) and render it on the page, and later on the World Wide Web. I learned to appreciate a beautifully designed book and web page. That gave me a passion for the publishing field, which is how I support my family to this day, taking the written word of poets, creating beautiful books out of them, and bringing that poetry to an audience. Later on, Jobs' creations also inspired me to learn computer and software programming, so that I could take the computer I was using and expand its capabilities. Now, software development also helps to support my family.

The most important way that Jobs has inspired me, however, has little to do with the products he created, but rather his example--and not the example most people cite, of the driven, perfectionist, take-no-prisoners visionary. That example, which has passed into legend and even stereotype, is one of a brilliant but impossibly demanding leader who would alternatively inspire and bully his subordinates into realizing his vision. (One archetypal example is Jobs telling a subordinate: "You've baked a lovely cake, but then you've used dog shit for frosting.") I'm no genius, and I recognize that often compromise is necessary to get something done.

No, what inspires me about Jobs is more basic--it's his grit, his persistence, his tenacity. When he was banished from Apple in 1985, he was not even 30, wealthy enough to never work again--but he still felt he had something to prove. So he founded a new company, purchased another, and nurtured both companies through a periods of slow or no growth, far outside of the limelight. When one stategy didn't work, he would try another. Eventually he found a mix of approaches that slowly brought the companies to modest profitability, and poised them for their spectacular impact later in the 1990s.

That decade out of the public eye was surely humbling for Jobs. He didn't have to work. He poured tens of millions of dollars into his companies as they lost money, and watched his own net worth drop. But even as that experienced humbled him, it also matured him. And it also nurtured an inner strength and determination: he didn't give up. And the world would benefit from the fruits of those efforts, with the iMac, iPod, iPhone, and more.

Jobs' techology and creativity have inspired and enabled much of my work. But as the proprietor of a publishing business (books and software) with my wife, it's Jobs' tenacity that I take the greatest instruction from. It goes without saying that since the U.S. economy's collapse in 2008, running any kind of business has been challenging. The book business is going through tremendous change with the emergence of e-books, the bankruptcy of Borders, and more; the pace of change is breathtaking. The software business has huge opportunity with the resurgence of Apple and the growth of smartphones (driven largely by Apple's iPhone), but it is also extremely competitive and challenging to reach a large customer base.

It takes tenacity and persistence to meet these challenges: changing your approach when the situation demands it, pursuing new opportunities in a way that makes sense, managing costs, and more. Most importantly, it requires not giving up. If you keep persisting, then your chances of surviving and even succeeding are good. My wife and I are still in business amid all the economic turmoil--that's no small accomplishment.

There are other important inspirations in my life. The poet John Haines, with whom I studied, was, like Jobs, a model of uncompromising artistic integrity. His years as a homesteader in the Alaska wilderness also provided an example of the kind of life a poet could live and where poetry could thrive, outside the context of university teaching, where many poets earn their living. Similarly, the poet Dana Gioia, with whom I corresponded, provided a model of how earn one's living. Decades before he became chairman of the National Endowment for the Arts, Gioia worked in corporate life and then as a self-employed writer/editor as he established himself as a poet and critic, writing both books of poetry and criticism that challenged poetry's marginalized place in American culture in the university. As an English Ph.D. seeking employment in a depressed academic job market in the late 1990s, it eventually became necessary for me to find another career path, and the examples of Haines and Gioia were especially helpful for me: my path took me through several years in corporate life before finally leading me to self-employment as a publisher.

Still, today, as a business owner in a terrible economy, I am looking in a different direction for my inspiration: Steve Jobs. During his years in the wilderness, Steve Jobs persisted. And he wound up changing the world. I don't know if I'll change the world, but I'm going to persist regardless. That's how Steve Jobs has changed my world.

[/general] permanent link

Phynchronicity 4.2

I've released version 4.2 of Phynchronicity, my GUI for the Fink Unix software system. This release includes several bug fixes for improved Lion compatibility. If you use Fink, Phynchronicity is a useful tool. Give it a try.

[/software] permanent link