Code by Kevin, Programming, code, business, and other pursuits
Kevin Walzer, software developer.
Subscribe to RSS Feed
Get a syndicated feed of my weblog.
Site design: Skeleton
I've decommissioned my Windows software site. After three months, the Windows version of QuickWho had failed to register a single sale. While QuickWho does not sell in huge volume on the Mac, it does sell a bit, and I expected similar performance from Windows.
Some might say that I didn't give Windows enough time--I released QuickWho for Windows at the end of the summer--but I am not entirely a rookie when it comes to developing software, nor to marketing it. I tried everything I knew to gain some attention for QuickWho, and it gained next to no attention at all. Even a few sales would have persuaded me this investment of effort and time was worth it, but they were not forthcoming.
I do not intend to give up on pursuing growth in my sales and my product portfolio, but my experience with Windows has persuaded me that my time is better spent on the Mac. I'm also going to be investigating opportunities in a related platform developed by Apple. More on that later.Mon, 05 Dec 2011
While I use some outside providers for Internet services, specifically Amazon S3 for hosting demo versions of my applications, I prefer to keep most of my Internet services in-house; the flexibility and cost-reduction that such a setup offers make the trade-off in administrative time worth it. For this purpose, I have always relied on the server version of OS X for web hosting, mail serving, and related services. It provided a robust platform, and required an investment of time to master, but was worth it.
The new version of Lion server is significantly different from earlier versions of OS X Server. Rather than being a separate build of OS X that's optimized for being a server (with a $500 price tag to match), it's a $50 download from the Mac App Store called Server.app. Apple is promoting Server.app as "The Server for Everyone." That initially caught my eye, but this lower price also comes as a significantly simplified version of the previous server OS: it removes a great deal of functionality that previously existed in the server OS.
For my purposes, the biggest difference (read loss) is the ability to comprehensively configure the Apache web server from a GUI. Older versions of OS X Server allowed you to define domain names and customize the configuration of each domain, all from a single interface. It put the power of Apache configuration at your fingertips without requiring you to hand-hack configuration files, with their arcane syntax. By contrast, Server.app on Lion allows you to define multiple websites, set one or two options, and turn them on from the GUI--that's about it.
For someone who uses the server to host a dozen websites, this is a serious issue. It's one that other reviews have noted as well. It means that if I want to provide advanced configuration of my websites, I have to hand-edit configuration files, much as if I were managing the Apache web server on a Linux or Unix system. Additionally, Apple provides little documentation on how to do this in such a way that won't cause problems with Apache. (To clarify: I am certainly capable of hand-editing Apache configuration files, but previous versions of OS X Server discouraged this because Apple's version of Apache had many Apple-specific customizations that could be best managed from the GUI; manual changes to the config files could be overwritten by the GUI or, even worse, break Apache.)
After a lot of trial and error, I finally worked out a process to configure my sites so that they would support the customizations I wanted (CGI execution, domain alias, and files with *.htm suffixes ). Here it is, with the "Code by Kevin" site as a demonstration:
sudo serveradmin stop web
DirectoryIndex index.html index.php /wiki/ default.html index.htm
CustomLog "/var/log/apache2/access_log" combinedvhost
SSLProtocol -ALL +SSLv3 +TLSv1
SSLProxyProtocol -ALL +SSLv3 +TLSv1
Options All +MultiViews +ExecCGI -Indexes
AddHandler cgi-script .cgi
sudo serveradmin start web
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.Thu, 17 Nov 2011
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.Tue, 08 Nov 2011
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.
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.Thu, 20 Oct 2011
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.Wed, 19 Oct 2011
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.Thu, 06 Oct 2011
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.Sun, 02 Oct 2011
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.Thu, 22 Sep 2011
I've released version 4.1 of PacketStream, my network interface application. This new release fixes a serious bug that occurred if Parallels or VMWare are installed on a Mac; this prevented PacketStream from capturing network data. While a cumbersome manual workaround existed, this bug fix alleviates the need for such jiggering.
This release also includes some minor UI improvements for Lion compatibility.
If you want an easy-to-use network monitoring tool for OS X, PacketStream is worth a look.Tue, 20 Sep 2011 Tue, 30 Aug 2011
While I've been quiet lately, I haven't been idle. In fact, if you want to see what I've been up to, visit Windows Software by WordTech--my venture into the world of Windows desktop software. For more details on why I'm doing this, see my blog entry. Hoping it works out!Sat, 02 Jul 2011
With today's release of Phynchronicity and PacketStream, I have now completed a major cycle of updates and modernization of my existing products. Now all my current products have significantly improved look and feel. Of all the work I've done over the past couple of years on platform-specific integration with Tk, my Cocoa toolbar wrappers (mactoolbar and prefstoolbar) are the most important from a visual standpoint.
Just as importantly, all six of my current products are at a good level of maturity; they have been through several releases each, and are relatively feature complete. This does not mean they have no room for improvement or additional features, but all six do what they set out to do, and do it well; none has a glaring hole in its functionality.
Now: it's time to expand the portfolio.
I've drawn up a list of approximately nine products that I will be working on over the next year or so. When all is said and done, I should have approximately 15 applications in commercial release, with varying degrees of active development.
My reason for undertaking this project: I want to grow my sales. And because my existing products sell modestly, the only way to increase my sales volume is to increase the number of products I have to sell. The strategy is simple: more products at modest volume = higher sales = more revenue.
This is something I have wanted to pursue for a long time, but there were several obstacles. First, my existing products needed continued development and maintenance. Second, I was doing a great deal of work on building up my development platform--creating libraries and components that could be used in any program I developed. Third, external market conditions--specifically the Mac App Store--forced me to re-tool both my products and my development process to meet App Store requirements.
None of this was wasted work. I continue to believe that Tk-Cocoa is the best cross-platform toolkit for the Mac. I'm backing that up by becoming one of the maintainers of Tk on OS X. And I'm an active participant in the Mac App Store. But if all that time spent working on libraries and Tk's core and my own App Store development process is like planting seeds, it's now time to bring home the harvest by incorporating that work into more products that I can sell.
As a result, while I will continue to work on Tk-Mac's core, I'm done creating libraries and extension packages for the near and middle future, and I'm not going to be substantially updating my existing apps for a period of some months. Instead, I'm going to be proceeding full steam ahead with development of new applications, trying to increase the number of modest sellers in my portfolio to the level where those modest sales add up to real volume.
This is not an easy strategy to follow. The usual advice in the Mac development community is "make your apps awesome"--as this tweet from Gus Mueller of Flying Meat Software, responding to some of my own thinking-out-loud of this problem on Twitter, demonstrates. Well, the issue here is that I've tried to do this. My applications are orders of magnitude better than they were four or five years ago. I'm also much smarter about marketing, about getting the word out on my products, and taking advantage of promotional opportunities (app bundles, one-day discounts, etc.) to increase sales. But product excellence and good marketing aren't enough. For whatever reason--because of luck, competition, the product niches I've chosen, or, perhaps because I have failed to "take out the suck"--my apps sell modestly, some less than a thousand dollars per year each.
As a result, a realistic assessment of the best path to growth requires me to recognize that I don't have a breakout product--and probably never well. I have a portfolio of modest sellers. There are two ways to increase my sales volume: sell more of what I've got, or make more to sell. I can't seem to sell a lot more of what I've got. So I need to make more products to sell.
There's a name for this strategy: the "long tail," first coined by Chris Anderson in an article in Wired. It's a strategy optimized for the Internet and online selling, in which a huge number of niche products, selling little in themselves, achieve massive scale in toto. Amazon is built on this strategy. So is iTunes. Another business I'm involved in, a publishing operation that utilizes print-on-demand technology to sell small numbers of many, many books, also makes use of this strategy.
So I'm confident the strategy is sound. The challenge will be execution. Software development is a labor-intensive process, and creating good applications is a non-trivial enterprise. My approach here will be to lean as much as possible on projects I've already done or can access--open-source libraries and tools--to do a lot of the work for me. Speed of development and release is a major criterion in selecting which products to do and which products to reject. But my approach isn't totally cold-blooded: I'm only going to work on things I'm excited about, that I will make use of, that will scratch some personal itch of mine. That's always been a rule of thumb: I believe that if a product I develop serves some need of mine, then at least a few other users will probably feel the same way.
I'm very excited about this new path I've chosen. I've been wanting to develop some new products for a long time, and I've finally arrived at the point where I'm able to do so. If nothing else, this will be fun, and I'm also hopeful that it will improve my bottom line in a significant way.
Wish me luck!
Apart from my commercial products and my Mac libraries for Tcl/Tk, I've taken on another important duty: I'm now one of the maintainers of Tk on OS X, responsible for fixing bugs, implementing features, and assisting with releases of the core Tcl/Tk language on the Mac. If you check out http://core.tcl.tk/, you'll see some of my code--bug fixes and new features to help improve Tcl/Tk's core functionality on the Mac. (My libraries, by contrast, extend Tcl/Tk's functionality into areas that the core language does not address.)
While it's unpaid and not glamorous, this is an important job. I'm helping to tend the garden that provides part of my livelihood. I've long wanted to help contribute to Tcl/Tk, and it's a real honor to be able to do so now. It's with a hugely talented group of developers, whom I continually learn from. I'm grateful that my skills have progressed to the point that I am now part of this talented group, and I'm glad I can offer some of my time and assistance.
I've just released versions 4.0 of Phynchronicity, my GUI for the Fink Unix software tool, and PacketStream, my GUI for the Mac's built-in tcpdump network monitoring tool. Both releases include a major modernization of their user interfaces with a native Cocoa toolbar, as well as improvements in their print functionality. The UI modernization lays the foundation for further updates of these apps in the future as first-rate Mac OS citizens.
If you use Fink to install open-source software, Phynchronicity is well worth your time. It is more actively developed than other GUI's for Fink, and I believe it's easier to use.
If you do network monitoring, PacketStream offers a good balance between power, ease-of-use, and price.
Check both out and let me know what you think.
For what it's worth, neither are available in the Mac App Store, for the same reason that PortAuthority is not available--both applications require administrator-level permissions to run certain tasks, and Phynchronicity is also dependent on an installation of Fink. But both are easily purchased from my website.
These releases complete the modernization of my current products with a fully-native Cocoa UI and other under-the-hood changes for integration with the App Store (where appropriate) and better system integration overall.Wed, 08 Jun 2011
One additional note about PortAuthority: it is not available in the Mac App Store, nor will it be in the future. PortAuthority runs afoul of several App Store guidelines, specifically in requiring an administrator password to run most functions, and also requiring an installation of MacPorts to function at all.
PortAuthority's sales have not suffered to date because it is not in the Mac App Store, and I hope that continues to be the case. I am grateful for the opportunity provided by the App Store, but I don't believe it should be the only avenue available for installing software on OS X. That limits user choice, and not just by restricting the channels the can use to purchase software; it also would limit the kind of software, indeed the kind of things, one can do with one's computer.
I've released version 4.0 of PortAuthority, my GUI for the MacPorts Unix software management system. This release, which is Intel-only, adds native Mac toolbars, improved stability with AppleScript, and improvements in the print engine. If you use MacPorts, PortAuthority is worth your time.Tue, 31 May 2011
Since a few of my apps have been accepted (and are selling) in the Mac App Store, I've taken another look at how I handle sales and fulfillment for my non-App Store products. When viewed against how simple and quick the App Store fulfillment process is, my long-standing practice of using Paypal for payment processing and sending serial numbers manually no longer makes as much sense.
After doing some research, I've settled on a new service provider for payment processing and license fulfillment for my non-App Store sales: BMT Micro. BMT Micro is a respected provider among independent developers; they come highly recommended, based on the comments I've seen. Their website is extremely easy to use, much easier than some of the other providers I reviewed. Just as importantly, they also promise to be very friendly and easy for my customers to use for payment processing, accepting payments in almost any currency and with almost any method (credit card, Paypal, wire transfer, etc.).
Finally, BMT promises to improve a long-standing weakness of my customer service: serials will be sent out immediately rather than waiting until my company can manually reply to an e-mail. This policy may have made sense in the past, but the App Store has forced developers to raise the bar in all aspects of their business, and immediate fulfillment of serial numbers is a necessary step.
PayPal is an outstanding company, and I will continue to use them for numerous aspects of my business (custom billing, etc.). However, utilizing them for automated serial fulfillment added a lot of complexity to the process (it requires a lot of Web programming, and I am not a web developer), so moving to a different provider that handles all of that for me--at reasonable rates--is a good decision here.Mon, 02 May 2011
I've released version 4.0 of Manpower, my man page viewer for OS X, on both my own site and in the Mac App Store. This is a significant update for Manpower, which incorporates all the fully-native integration I've been adding to my apps: native Cocoa toolbar, native printing, clickable links in the data display, and more. This release also allow you to set Manpower as the default viewer for man pages on the Mac. All in all, it's a worthy upgrade, and a good app to check out if you're interested in seeing just how much documentation is available under the Mac's Unix hood.
This is the quickest approval I've gotten from the App Store; I submitted the app just a week ago. I paid special attention to avoiding the issues that got my previous submissions rejected, and that seems to have helped it sail right through. Hopefully that will continue to be the case.Thu, 21 Apr 2011
I've just released version 5.1 of NameFind, my file search tool for OS X, following its approval for the Mac App Store. This release has some nice improvements over version 5.0, including a fully-native Mac toolbar UI; improvements in the speed and accuracy of the file search algorithm; and improved integration with QuickLook, specifically calling the native QuickLook preview window. It's well worth your while to check this out if you are looking for an alternative to the Mac's built-in Spotlight search technology.Thu, 14 Apr 2011
Apple has finally approved QuickWho for release in the App Store, and I'm doing a simultaneous release here. This version features improved stability in printing as well as print preview and saving as PDF/PostScript from the print dialog; it also makes use of the native Mac toolbar API for improved usability. It's a nice update, free to registered users, and worth your time.Sun, 03 Apr 2011
I've written before about how powerful I find the Mac's Unix foundation, and how much of it I integrate into my programs. More recently I've replaced some of the Unix integration of my applications with functionality accessed via the Cocoa frameworks. With the changes I'm making to my cocoaprint Tcl/Tk library, I'm now blending the Unix and Cocoa (and Carbon) approaches in new ways.
When they rejected one of my apps recently, the App Store reviewers said that one of the major issues is that the app cannot do print previewing, save as PDF, or save as PostScript. That's correct, and it's by design: I had originally designed the printing code to support sending the data to the printer only. Some initial research suggested that it wasn't possible to handle "print preview" or support PDF/PostScript with the particular printing functions I utilized, since I was not using an NSView to prepare the print data.
(Technical aside: the standard Cocoa way of printing is to draw data that is represented in the window on the screen (inside an NSView display) into a printing graphics context, which is then output at the printer. My approach makes use of a more traditional Unix approach, which is to write data to a PostScript or PDF file using Unix command-line tools, and then send that file to the printer.)
After doing some further research, I found that I could add the required functionality to the cocoaprint library: I was able to implement print preview and exporting to PDF and PostScript. However, I did so mostly by using Unix methods, rather than traditional Cocoa printing methods.
For instance: to implement print preview, rather than writing the print data to some temporary file that is then viewed in a Cocoa window or in Preview, I simply open the existing PDF file in the default PDF viewing application (using NSWorkspace methods). To implement exporting as PDF, I simply copy the existing print file to a new location defined by the user (using NSFileManager methods). And to export to PostScript, I use the Unix command-line tool "cupsfilter" (installed on OS X as part of its Common Unix Printing System, or CUPS) to convert the PDF print file to PostScript in a user-defined location.
While these functions are all called under the hood using Unix or file-system methods, they are driven from the native Cocoa print dialog (NSPrintPanel). Many aspects of the print job, including determining the target location of the print output (printer, file or preview) are also managed by Core Printing functions (Core Printing is part of the Carbon framework that has not been deprecated by Apple).
I'm glad I continue to rely on the Unix tools even as I increasingly make use of Cocoa (and Carbon) API calls in my work; the availability of all three in my toolbox gives me more and more flexibility in determining how I approach a programming task, and increases the range of possibilities available to me.
Initially, this was frustrating: NameFind was rejected for a bug that I couldn't reproduce, and QuickWho had a long list of issues. I had to query the App Store team for more information about the NameFind bug, and the worst of the QuickWho issues was going to require adding some significant functionality to one of my Tk-Cocoa extensions.
Still, a few days later, I'm feeling quite good about the process and bullish on the App Store. Here's why:
I have a bit more cleanup and bug fixes to do on both NameFind and QuickWho before I resubmit them, but the suggestions and requests that the App Store team have sent to me will significantly improve the user experience that these applications offer--and I can roll these improvements into my other applications, as well. I'm grateful for these suggestions and also for the personal touch the App Store team is providing through their responses in the developer forums and even over the phone.
Rather than continuing to see the App Store submission process as an obstacle that delays the release of new versions of my applications, and thus sales, I've come to regard the submission process as free, professional-level usability testing for my apps--a process that leads to substantial improvements in their stability and usability. I've never had this before with my apps, and I'm glad to have it now.Fri, 11 Mar 2011
For the third time in a week I've removed and re-submitted QuickWho to the Mac App Store. Each time I thought I had gotten everything right, but continued testing showed that there were a few little things that weren't quite right--small bugs or minor details that, together, made the app a little less polished to use. So I yanked it and did a little more polishing.
If there's one thing that the Mac App Store is forcing me to spend more time on, it's attention to the little details. Individually they may not be huge, but collectively they can make a big difference in the user experience. And sometimes these details aren't so little. That's the focus of this release of QuickWho--not a big increase in functionality or features, but continued polish and refinement on both a small and large scale.
Visually, there's a big difference: QuickWho now makes use of a native Mac toolbar, built on top of Cocoa's NSToolbar methods. I think this is one of the single most significant improvements in the UI of my applications, because now the application fits in visually without having to fake anything. Up until now, every toolbar layout I've ever used has been implemented in Tk rather than Cocoa directly--sometimes getting pretty close to the native look and feel, but never being 100% native. Until recently, my skills and confidence with Cocoa had never been at the point where I felt comfortable trying to implement the real thing in a Tk application, but it wasn't that hard.
...and new QuickWho.
By way of comparison, below was a previous, fairly ambitious attempt to implement a native toolbar by patching Tk's core itself, to allow drawing of a single background in the window and toolbar (which is how many cross-platform frameworks, such as Mozilla/Firefox, implement Cocoa-style toolbars):
The patches to implement that style of toolbar are now incorporated into Tk's development trunk, but I don't plan to make use of them (nor would it be possible for me to do so with the Mac App Store, anyway, because I have to link my programs to the version of Tk that is shipped with OS X).
I've also implemented a native Cocoa preferences toolbar that you see in all of Apple's applications.
Old QuickWho preferences....
...and new QuickWho preferences.
I finally decided to implement native Cocoa toolbars because I felt the Tk-styled toolbar in my current applications (even the version of NameFind that is currently on sale in the App Store) no longer fit in with the majority of applications on OS X, and it was impossible for me to make use of the work I submitted to Tk's development trunk. I've tried a variety of approaches to implementing Cocoa-style toolbars in Tk applications, but all of them have proven inadequate--so I decided it was time to try to implement the real things. Thus, I implemented Cocoa toolbars as a Tk extension, which has several advantages: the code is not dependent on inclusion in Tk's core code and thus can be submitted to the App Store right away; and more importantly, it's native.
The Cocoa toolbars were in the version of QuickWho I submitted last week; implementing them took about a month. I yanked and resubmitted QuickWho this week to polish up other parts of the application a bit more, smaller issues, but still important enough to get right.
I have no doubt that submitting to the Mac App Store has forced me to raise the level of polish and stability in my applications; I'm sweating the small details more than ever. It's my customers will benefit most from this effort.Mon, 07 Mar 2011
I'm pleased to announce the release of three new Tcl/Tk packages to improve the integration of Tk apps on the Mac, as well as an updated package.
This package creates a Mac-native toolbar (based on the Cocoa NSToolbar) for use in Tk windows. The mactoolbar package offers a basic implementation of the NSToolbar library; it displays toolbar buttons, with labels and images, and does not display other Mac-native widgets such as the Cocoa searchfield. It does not allow customization, nor can it display Tk widgets.
This package creates a Mac-native toolbar (based on the Cocoa NSToolbar) for use in Tk windows. The The toolbar items are selectable, as in standard Cocoa preferences windows. The package offers a basic implementation of the NSToolbar library; it displays toolbar buttons, with labels and images, and does not display other Mac-native widgets such as the Cocoa searchfield. It does not allow customization, nor can it display Tk widgets.
The quicklook package displays a native QuickLook preview panel in a Tk application. The quicklook::quicklook path takes a file path as an argument and then displays a QuickLook panel of the file.
And, the updated package: cocoaprint. This new version fixes a serious bug that caused applications to crash after the print dialog is dismissed.
All packagesare available from http://tk-components.sourceforge.net/ under the standard Tcl BSD-style license.Tue, 22 Feb 2011
I'm participating in a promotion for NameFind next Tuesday, March 1, on Bits du Jour, a software promotion site. Bits du Jour is well-known as a Windows software promotion site, but they are expanding their coverage of the Mac, and asked me to participate. Next Tuesday you'll be able to purchase a license for NameFind for just $10, 60% off the regular price. Here's the link to check it out:Thu, 03 Feb 2011
I've posted an article at my website that offers an overview of the process of submitting a Tcl/Tk application to the App Store, and also delves into some of the technical issues particular to Tk-Cocoa applications. I'd like to elaborate a bit here on those technical issues.
One reason NameFind was initially rejected was that, at a deep level, Tk-Cocoa accesses private Cocoa code, and this runs afoul of the App Store guidelines: no private frameworks, variables, or methods/functions can be invoked by an application. "Private" means code that is internal to the Cocoa frameworks and not exposed via documented programming interfaces (API's). Because of differences between Tk's design and Cocoa, however, it was necessary for the designers of Tk-Cocoa to hook into those private API's to ensure smooth integration between the two.
Since there is no way to remove the private API's from Tk-Cocoa, how was I able to work around the prohibition against accessing them? The answer is surprisingly simple: I linked my code to the Tk-Cocoa frameworks installed with OS X, instead of bundling those frameworks with my app. The system-installed frameworks are exempt from the requirements, because they are installed by Apple.
This linking has come at some cost, however. The version of Tk-Cocoa that ships with Snow Leopard is very immature; it was the first public release of Tk-Cocoa, and it has a number of bugs and rough-around-the-edges bits that were later fixed and improved. Linking to this version of the framework is taking a step back in terms of performance and polish.
Fortunately, there are ways to address these issues that don't compromise the polish of my applications too much. I no long have access to native, modern Cocoa notebook tabs (the older version of Tk-Cocoa uses ancient tabs that Apple stopped using in Panther, or OS X 10.3, seven years ago), but I've been able to create an attractive if unorthodox design using a different Tk widget set called BWidgets. There are certain bugs with the application menu that I can't quite figure out how to fix, but (ironically) using an older approach to setting up my menus (calling the "apple" menu) works around the problem. And, best of all, the various library extensions I've created continue to work with no problem at all.
NameFind is off to a decent start with sales, and I'm already looking at some improvements based on user feedback and the changes I'm making to the next app I plan to submit to the App Store--QuickWho. Stay tuned.Wed, 26 Jan 2011
Well, I thought this day would never come. NameFind, my file search tool that's an alternative to Spotlight, is now on the Mac App Store! Check out the preview link here, or search for NameFind using the Mac App Store application. It appears the final batch of changes I made to NameFind, after two previous rejections, did the trick, and now the app is ready for sale in the App Store.
This release represents a huge update of NameFind as well: while many of the specific changes I made to NameFind only concern its compatibility with the App Store, I had spent several months doing extensive rewrites of NameFind's functionality in preparation for version 5.0. Specifically:
New search algorithm. I removed NameFind's dependency on the external Unix "find" command-line tool that is installed with OS X. I instead used native Mac API's (specifically, the FSCatalogSearch API, wrapped up in a binary Tcl extension) for full hard-drive search, and a fast Tcl-based search library for smaller directory searches. The result is that NameFind is orders of magnitude faster; even full hard drive searches only take a few minutes, instead of up to an hour.
Accessing other API's natively. I also replaced the use of other external command-line tools ("afplay" for playing system alerts, "osascript" for running AppleScripts) with native implementations (integrating the Cocoa API's with Tcl's C API for native access). My use of these external tools has caused numerous crashes in my apps because of conflicts with third-party installations (outdated sound plug-ins, outdated AppleScript extensions); the native implementation seems to avoid these crashes. Replacing the command-line tools with native access has improved both the speed and the stability of NameFind, and this feature will be moved into all my apps.
Full AppleScript and Services menu support. I've implemented a full AppleScript dictionary for NameFind, which I've previously described. Adding AppleScript support makes NameFind a much better citizen on Mac OS X, as does allowing it to provide services via the Services menu. These features are going to be part of all my applications going forward.
Further refinements and improvements to the user interface. The main UI of NameFind is solid, in my view, but I've made some subtle improvements: removing a couple of toolbar buttons to simplify the layout, and also making use of the floating black HUD-style window (heads-up display) that is now popular on OS X.
NameFind's new version is the fullest step I've made to full integration of my Tcl/Tk applications with OS X. A strong heritage of Tcl/Tk applications is providing a user-friendly face to powerful command-line tools in Unix, and this design pattern has exerted a strong influence on me. In fact, a recurring criticism of my applications is that they do nothing more than provide a (paid-for) interface to tools that come for free with OS X. While I disagree with some of this criticism, as my own programming skills have improved, I've discovered the power of accessing system functionality natively via the Cocoa, Carbon or other API's. This provides faster and more stable functionality, in many cases. The learning curve to reach this stage is non-trivial: I've had to learn a fair amount of Cocoa programming, in particular, even though I'm not fond of the Cocoa approach to software development and will not wholly adopt it for my products. In any event, though, I'm glad I've made the effort to learn enough Cocoa and C-level programming to integrate that functionality with my Tcl/Tk programs. (Tcl is brilliantly designed for this kind of integration.) I feel I've outgrown my roots as a Unix-style GUI scripter and am now a full-fledged Mac application developer, using Tcl, Python and the Tk GUI framework.
I'll be posting some more technical discussion of NameFind and the process of preparing a Tcl/Tk application for the Mac App Store in a future post. In the meantime, if you are curious about NameFind or a current user, download and give the new version a try. I think you'll be pleased.Sat, 22 Jan 2011
I first submitted NameFind to the Mac App Store on December 5. It's been rejected twice, for crashing on startup, and for accessing private functions in some Mac-specific frameworks (specifically, Tk-Cocoa, which I bundle with my apps, accesses a number of private Cocoa functions, at a low level). Both crashing and use of private API's run afoul of Apple's guidelines for the App Store. I've since tweaked NameFind yet again and resubmitted the app, in hopes that it works this time.
I realize patience is a virtue, but I am growing quite frustrated with the process of submitting my apps. None of the numerous revisions I've made to NameFind as part of the App Store submission process have improved the application. Most of the changes are simply revisions of the way I build and deploy the application--a lot of behind-the-scenes work with no visible change to the user, simply trying to avoid mysterious crashes that don't show up on my own system.
Worse, some of the changes I've made are what developers call "regressions"--rolling back some features to older, less robust versions. In the case of NameFind, I've replaced the bundled Tcl/Tk frameworks I customarily and link the program directly to the Tcl/Tk frameworks installed with OS X--some of my research suggests that while the system frameworks access the same private API's as the frameworks I bundle, it's kosher for Apple's system frameworks to do so because, well, they're installed by Apple. Unfortunately, the version of Tk-Cocoa that's installed by Apple is immature (c. May 2009), with a lot of bugs and some missing functionality. This means I can't take advantage of some of the improvements I've contributed to Tk in the past year or so, including modernizing the display of notebook tabs and implementing a unified-style toolbar.
Just as frustrating for me is putting my software business on Apple's timetable, rather than my own. The App Store submission process is slow, opaque, and bureaucratic. As an independent developer, I thrive on rapid, nimble development, but things have more or less ground to a halt as I submit my app, wait weeks, and then try again. This brings to mind Joel Spolsky's notion of fire and motion. I'm pinned down by enemy fire, rather than inching forward a little bit, day by day.
Having come this far, I'll let my current submission of NameFind run its course. The potential upside--increased sales--looks promising. But unlike the iPhone/iPad app ecosystem, the Mac App Store is not the only game in town. Patience is a virtue, but my patience is not infinite. And if NameFind is rejected yet again, I'm not going to stand still. Like Rogue Amoeba, I'll keep my focus outside the App Store, and hopefully thrive and innovate--without waiting.Sat, 08 Jan 2011
A quick update on the App Store: submitting my apps is proving to be more difficult than I expected. I've had an app rejected twice for technical reasons, and figuring out how to proceed is complicated. Nonetheless, I'm going to persist, and eventually have the majority of my apps in the App Store.