Apokalypse Software Corp. regrets disappointing users of Mori and Clockwork in announcing its policy of not providing general access to the source code for these products.
While users who previously had access to the source code when it was in Hog Bay Software's hands might initially be upset at this change in policy, I hope you'll see it for the positive development and improved scheduling that it is.
The primary reason for having source availabile to you before was to permit you to customize aspects of the applications and add features which are important to you. This presents difficulties for me in the future as I continue moving these products forward. Do I change their internal workings and risk alienating you, or moving in a different direction than where your technology investments are going? It is far riskier for you, my users, as you strive to make the changes into which you've invested considerable personal effort current with the progress of the released versions. To even contemplate modifying the Mori and Clockwork requires a signficant amount of knowledge into their architecture, and the Blocks plugins interfaces on which they're based, a depth of knowledge which I will be minimizing in the coming weeks.
One of the most powerful concepts in the development of computer software is coupling, the degree to which different data and behaviors are bound to each other. It has been found that better behaved software tends to be designed such that behaviors and data are not tightly coupled to one another. This has given rise to principles of encapsulation, data-hiding and sharply defined interfaces for software components.
It is my goal to provide you with more flexibility in adding features to Mori and Clockwork than you could have from the source code, yet provide simpler and cleaner interfaces to allow you to concentrate on the aspects that are most important to you. To do this well, I will need to know where the interfaces fail to provide sufficient headroom for you, and trust you're not short-circuiting the interfaces by modifying the underlying behaviors.
It will be easier to move forward by closing access to the source code, both while I gain familiarity with them and steer them towards the future. I hope that you not only understand, but that you applaud this direction, and realize how much more significantly your voices will contribute to the future direction of these products.
Sincerely,
Alfonso
Feature requests and bug reports are listed on the requests & bugs page. To add a new request:
This process documents how to create a new .icns file.
Create a Photoshop template file by copying an existing Hog Bay Software Photoshop template. They are stored in resources folder of application target in Xcode directory.
Open template and run /scripts/makeicons.atn. This will generate four images on desktop sizes 128, 48, 32, 16.
Open Icon Composer.app and drag and drop the images into icon composer. Save. And there’s your icon.
This process documents how to add license key checking to a Blocks application, and how to generate new license keys. This is intended mostly for my own use so that I remember how it all works.
Run the new_public_private_keys.rb script from the terminal. For example ./new_public_private_keys.rb Clockwork. This will generate public and private keys named Clockwork.private.pem and Clockwork.public.pem.
Edit the application delegate so that it returns the public key for the method applicationPublicKey.
Copy the public and private keys into ~/Application Support/License/ where they will be accessible by License.app.
Now that you have license keys open License.app, enter the key name, enter the license name and number of users, and then click the ” Generate License Info File”. This file is a configuration file that is used to generate license files for individual users.
To generate keys for individual users open License.app, choose the license info file wanted, enter user information, and then click the “Generate License File” button.
This process documents how traffic is monitored on the Hog Bay Software website. There are three tools setup for monitoring the web logs.
First there is a visitors process running on the server that updates this files/visitors.html page every five minutes with basic traffic information from the past hour. This page gives a snapshot of how many people have recently visited the site, and where they come from. If this page stops getting updated restart the visitors analyzer in stream mode using this command.
tail -f ../logs/hogbaysoftware.com/http/access.log | ./visitors --stream -R -m 60 --update-every 300 --reset-every 3600 --output-file ../hogbaysoftware.com/files/visitors.html &
Second the site is running a standard long term stats program supplied by dreamhost. These stats are viewable at stats, but it's not easy to make them publicly accessible, so for now only I can see them.
Third I'm also using Google Analytics to track long term stats.
Update project’s Info.plist with new version name, make sure to indicate if it’s a beta or not.
Commit all changes for project and dependent projects in Subversion. These should all be listed in the applications Other/release_dependencies.txt project file.
Make a new release of the application in Subversion and update the project’s CFBundleVersion number by running the tag_release.rb script from the terminal. For example ./tag_release.rb shared/Clockwork. Note it’s important to prefix the application name with the name of the svn repository where it is stored ‘shared’ in the case of Clockwork.
Build the new release by running the build_release.rb script from the terminal. For example ./build_release.rb shared/Clockwork 9. The result will build the Clockwork version 9 release and copy the resulting DMG file to your desktop.
For each new release these files in files/releases will need to be updated:
<ApplicationName>.plist - For example see Clockwork.plist. This file is a plist dictionary that contains the latest CFBundleVersion number for the applications main bundle. The software update plugin uses this file to check if a new update is availible. (NOTE, edit the .plist file last since that will notify people that we are ready for them to download.)<ApplicationName>.dmg - For example see Clockwork.dmg. This file should always point the the latest public release of an application. This is the URL that gets sent out to download sites, so every new public (non beta) release should replace this file with the latest release.<ApplicationName>-<CFBundleShortVersionString>.dmg - For example see Clockwork-1.1.dmg. Each new release should also provide a copy with a version name. These files are listed on the project page for each application so users can download old versions.After updating the releases directory visit this page admin/settings/project/reload to scan the releases directory and rebuild the applications project page.
Next the project release notes clockwork/releasenotes must be updated. Follow the format used in Clockwork’s release notes. Find all open issues that have been fixed and mark them as closed. Add links to these closed issues to the release notes.
ClockworkReleaseNotes.html in the releases folder also needs to be updated. This file should only include the last few sets of changes. When the software update plugin notices a new release this is the file that it will display on the users computer so that they know what changes are in the new release.
IF NOT A BETA VERSION Update version numbers on front page and product page.
IF A BETA VERSION Update product home page “beta” sidebar section.
Clear website caches.
All releases
Big Releases