The alternative Flash IDE from SoThink, normally $72.21, is free today ONLY on http://www.giveawayoftheday.com. SWF Quicker has some interesting features such as importing a project from .SWFs and .FLVs, as well as a standard editing interface that resembles Flash CS3 but with a seemingly snappier interface. For a complete list of features, see the first link below.

Product home page: http://www.sothink.com/product/swfquicker/
Download page (today only): http://www.giveawayoftheday.com/swf-quicker-4-7-holiday/

I’ve put together a quick video to show you how to extract the installer file from its Giveawayoftheday wrapper (useful since the wrapped executable will only allow installation today). The video also demonstrates importing a .SWF as a new project. Running length: 5:32.

During the school year, I work from home on a part-time basis, and for most of the semester I kept track of my tasks and time on pencil and paper. At least, I tried. More often, when the time comes to write my end-of-day summary, I have difficulty remembering everything that I’ve worked on, let alone how much time was dedicated to each task. It’s typically at these points of crisis that I turn to technology to solve my problems (and though there is something to be said about the value of stepping away from the computer when planning and brainstorming, mundane time and task management is hardly an effort that should require creative juices. At least that’s my excuse for playing with new technology, as always.)

At any rate, this time the solution comes in the form of Grindstone 2 by Epiforge Software, a free program for the Windows platform. Linux users can consider checking out Project Hamster, but I’d like to detail my pleasant experience thus far with Grindstone here.

The most appealing aspect of Grindstone is that while it is relatively straightforward to use, the app includes enough tools to make the power user happy, too: diverse report generation allows me to export a nice-looking timesheet, glance at the summary for a task or for a given date/time range, and view a pie-chart breakdown if I’m feeling visual. Grindstone supports custom fields and values for sorting tasks, the ability to parse custom fields from task names (with a little Regular Expressions), multiple profiles, and a dozen seemingly minuscule features that nonetheless make a world of difference in usability.

After setting up a profile, selecting a task and clicking the Start icon displays the egg timer; this tiny window sits at the top of my screen and lets me select the current task I’m working on throughout the day without revisiting the main program window. The egg timer’s window opacity can be adjusted from the program’s Options dialog.

About half a dozen times throughout the day, I walk away from the computer without remembering to hit ‘Stop’ on the current task. But no worries: when I return, Grindstone’s inactivity timer triggers, yelling politely prompting to account for my time. If, on the other hand, I forget to start timing a task (which also happens more than I care to admit) upon returning from the 4th coffee break of the day, the application will display a friendly reminder.

(P.S.: Just in case you just noticed the change from XP to Windows 7, I must mention that Grindstone’s profile backup and restore capability is quite convenient.)

Confession time: as annoying as I thought these features would be at first, they have turned out to make a world of difference in rendering the time management system an effective way to manage my day. Of course, if the notifications are a bit too intrusive for your taste, their settings can easily be adjusted.

At some point, I decided I needed to be able to categorize my tasks based on priority. Grindstone easily accommodates this with custom fields, so I created a field named “Priority” and enabled sorting on that field.

So far so good, but manually adjusting every task that I had to enter after I entered it became tedious rather quickly. Luckily, the Advanced Entry tab of the custom fields box (under Profile Configuration) allows one to set a match and format pattern in order to parse a field value from the task name. In my case, I decided that I would like to be able to enter a new task such as “Begin world domination (high)” in the quick task pane and have the new task “Begin world domination” be automatically added to the “High” group. Unfortunately, the description of the “match” and “format” patterns is a little terse and there is currently no help topic available on how to use it. However, to my delight, my cry of distress posted on Grindstone’s user forums was answered in less than an hour. How’s that for customer support?

The result of the endeavor is shown in the screenshot below, which also attempts to explain the fields. (Thanks Daniel!)

Okay. I’ve saved the coolest part for last: the report generation.

In my opinion, this is invaluable asset both for reference — at the end of the day, as I wistfully look over the progress report wishing for better productivity (kidding!) — and due to the fact that it allows me to generate a summary of the time spent over the week (or any interval, for that matter). Below, the summary report is being used to copy and paste a pre-formatted table into Excel:

If your time tracking needs are a bit more advanced, Lifehacker reviewed some pretty heavy-duty time management solutions some time back. But as far as I’m concerned, Grindstone does the trick for the extend of my needs. Kudos to the guys at Epiforge for a great product!

Psst: when can we expect a Linux port?

As this semester draws to a close, I thought it would be appropriate to share some of the notes, some written and others floating around in wetware, that I have accumulated over the course of the semester concerning my first experience with formal Computer Science classes. These classes included an Introduction to Comp. Sci., an overview of C/C++, and a course on Discrete Math. Most of my thoughts concern the latter two. This post will be part I of these notes, where I will discuss my experience in the Program Development (CSCI 241) C++ programming class. Please bear with me as I brainstorm out loud.

[Begin lengthy intro. Feel free to skip if you're interested in the bullet points.]

The background to this unofficial series starts with an admission that towards the beginning of the semester, being a fairly self-motivated programmer accustomed to reading books, articles, documentation, and other self-help resources, I had a fair bit of consternation over whether forking over such a high dollar amount required for accumulating technical skills would yield a sensible ROI; technical skills that, frankly, I have pursued independently up until this point. Along with this, sometimes I wonder what advantages a graduated “white-collar” Comp. Sci. graduate has over a self-trained, so-called “blue-collar” programmer, but that’s an topic for another time.  (Please understand, I’m talking about practical skills and not arguing over the necessity of a diploma here.)

Parenthetically, it must be mentioned that this decision to delay my CS classes until my Junior year was not by choice but rather because I attended a Community College during the first two years with a scarce curriculum in Comp. Sci. Having been encouraged by a former professor, mentor, and good friend to make the most of my education by recording my experience so far, this post will serve as a sort of journal entry, marking the beginning of a two-year journey towards finishing my Bachelor’s in Computer Science, where I will record a few observations that I may end up retracting later on. Disclaimer over.

[End lengthy intro.]

I mentioned in the last post that I’m reading a book called Coders at Work by Peter Seibel. Sunday evening I read chapter 8, in which Mr. Seibel interviews Peter Norvig, the Director of Research at Google. I particularly enjoyed this article because in it, Norvig and Seibel discuss the interview process used by Google and what the company looks for when hiring new programmers. One of the questions that came up is what the purpose of using infamous trick questions (a practice that Google is known while interviewing candidates). I am paraphrasing Mr. Norvig’s response to Seibel (in reference to the paragraph at the bottom of page 320), but he essentially makes the point that it’s not as important that you know how to solve every type of problem, but rather that you have a well-developed approach to solving the problem. To put it a different way, it’s not necessarily the breadth of your knowledge, but rather the maturity of your thinking process that is of value here. Knowing the “tricks” helps, but that likely won’t be of aid when you need to apply a more broad problem-solving approach to a similar, but sufficiently different problem.

With this maxim in mind, I’d like to evaluate CSCI 241 at my institution and mention a few ideas that came up during those long hours of class.

My first grievance is with contrived examples. These are indeed useful for getting a novice programmer’s feet off the ground, but they are not what hold our interest nor motivate us to stay involved in the material. I want to know, how does this teach me to write code that matters? Do I really care about implementing a set of Dog/Mammal classes to (re)learn inheritence? After all, I dare say what drew most of us to computer science in the first place was developing a solution to a problem that was of personal interest.

So how can we fix this?

Or, how do we design a computer science curriculum in a way such that classes which teach programming languages present a greater advantage than, say, students picking up a few books and teaching themselves? An abstract solution is to teach “meta-programming” concepts in which things such as

• the importance of writing efficient, but readable code,
• the importance of reading others’ code,
• the importance of code ownership and responsibility, and
• the important skill of being able to find and use resources to further one’s own education on the job.

I am firmly convinced that none of these are possible unless there is personal interest on the part of the student in the applications that the he or she is writing. So, perhaps some more concrete possible solutions include:

• Have each individual in the class checkout the source code of an open-source project of their choice, examine, debug, modify, and do whatever it takes to understand its overall working.
• For a final project assignment, have each student write technical documentation based upon their understanding of a module or two in the open-source project.
• Is the student already involved in an open-source project? Why not, as a professor, support it?
• Provide homework assignments of tiered difficulty so that students of all levels can be challenged to expand their knowledge of the language. How can you optimize the code in the assignment? Do you understand the concepts of a LinkedList? Great, rewrite it using templates (and so on).
• While we’re at it, let’s leave the PowerPoint slides and their near-useless pseudo-code at home and crack open Visual Studio in class.

One final point to make. If all students, no matter their prior skill level, are going to be required to jump through the hoops and take all the introductory classes to get a degree, then an effort should be made to adapt the assignments so that every student is challenged by the right degree.

After all, we should be teaching a mindset, not a language. Old languages go out of date, and new ones are invented, but the process of learning them does not change.

My apologies for the long gap of time that has elapsed since I’ve written a “real” post; it is true that school and work have been keeping me busy, but the whole story is that I’ve had less to write, and more to think about lately. This includes slowly working through two books that I’ll briefly mention here.

Coders At Work by Peter Seibel is a series of real and raw interviews with some of the most high-profile programmers of our day (though I’m rather ashamed to admit that the only name that was familiar to me before I started reading the book was that of Donald Knuth). After reading the favorable review of this on Coding Horror, I picked it up, and I’m glad I did.

Within its 601 pages, each interviewee is asked some predictable (though interesting) questions resembling:

• How did you get started programming?
• What was it that drew you to it?
• What do you think about C/C++?
• What tools do you use?

And then some more useful ones:

• In retrospect, how much of a role did academia play in jump-starting your career? Was it necessary?
• How about graduate study?
• What is the process that you use to design software?
• How important are formal proofs to testing?
• How do you read code?
• What are the skills you are looking for when hiring new programmers?

Obviously, as a rather new programmer in undergraduate study, these questions and more I find especially fascinating to hear addressed this early into my career. Though these folks have strong opinions which vary widely in some aspects, there are nuggets here such as the huge importance of reading code that others have written which I am glad to discover. The book has been reported to read like a novel, which it truly does.  Caution: because of the informal interview settings, the book contains occasional (though concentrated) strong language.

When I wandered over to Barnes & Nobles to pick up the first book, a second grabbed my attention entitled Pragmatic Thinking and Learning by Andy Hunt. This is, not surprisingly,  another addition to the Pragmatic Bookshelf (TM) series, but it turns away from the technical skills to concentrate on the art of thinking — but not in the analytical, procedural, mechanical, left-brain approach that we employ at work. Instead, Hunt emphasizes capturing and taking advantage of the creativity and intuition that sets apart an expert from an advanced beginner on the Dreyfus model of skill acquisition, and how to stimulate and encourage such thought patterns that he contends are not overly common to the field of Computer Science. With a well-established background, plenty of humor, well-placed quotes, hand-drawn illustrations and practical ideas geared toward those in the software industry, I am finding this to be a fresh and unique perspective on skills useful to a programmer.

For those of you not yet ‘Waving’, I have 4 Google Wave invites remaining. If you’d like one send me an email at cameron {at} odevelop {dot} com.

Just the other day I decided to change my password for an important online account to a secure one generated by KeePass, the free, portable and cross-platform password safe. It almost ended in a very bad situation when the program (which is otherwise an excellent one) decided to crash right after I had added an entry for the account, but before I had saved the database… and just after I had logged out of the account! Argh!

My online banking site doesn’t seem to have a simple way to reset the password, which is probably a good thing in retrospect, but… it’s a weekend so calling the bank was out of the question. After a few moments of panic, however, I realized that I had used KeyPass’ automated keylist generator a few days back, which meant the password was still there. The only thing lost was the account association, and — phew! — I was able to log back in with the first unnamed password from the list.

So obviously, I’m convinced that utilizing the keylist generator serves more purposes than one. If you haven’t done so, save yourself a potential headache:

Select Tools > Generate Password List… from the main window.

Set the length and characterset for the generated passwords, and click OK.

Enter the number of passwords to generate.

To add a site, edit the next blank item from the list along with its random, pre-generated password.

The later versions of Eclipse (I believe 3.4+) have migrated the menu system for plug-ins from using the antiquated actionSets to org.eclipse.ui.menu’s, commands, and handlers. Using an ISourceProvider, the state of your plug-in’s menu items can be managed dynamically; something that was rather painful to do with the old actionSets (when instead it was necessary to wait for the action to be invoked in order to get a handle to its IAction). There’s a great set of tutorials on the newer technique here and here.

In the process of migrating my plug-in to the new system, however, I came across a bit of trouble enabling and disabling the items. Seemingly, setting the “enabledWhen” flag for the menu items wasn’t working. Here’s the sample XML for the extension (can you spot the problem?)

<!-- Managing the UI state (enabled or disabled) of the menu item is accomplished by setting the 
variable referenced below within a class that extends ISourceProvider. -->
<extension point="org.eclipse.ui.services">
	<definition id="com.example.SampleItemSourceProvider">
		<variable name="com.example.SampleItemState" priorityLevel="workbench" />
	</definition>
</extension>
 
<!-- Menu item definition -->
<extension point="org.eclipse.ui.menus">
	<menuContribution locationURI="menu:org.eclipse.ui.main.menu?after=additions">
		<menu id="com.example.menuitem1" label="Example Menu Item" commandId="com.example.command1" <!-- Defined elsewhere --> >
			<enabledWhen>
				<with variable="com.example.SampleItemState"><equals value="stateEnabled"></equals></with>
			</enabledWhen>
		</menu>
	</menuContribution>
</extension>
 
<!-- Handler definition -->
<extension point="org.eclipse.ui.handlers">
	<handler class="com.example.MenuItem1Handler" commandId="com.example.command1" <!-- Defined elsewhere --> >
		<activeWhen>
			<with variable="com.example.SomeOtherVariable"><equals value="stateActive"></equals></with>
		</activeWhen>
	</handler>
</extension>

So as a note to self in case I forget (likely!), apparently an inactive handler is enough to override the enabledWhen flag of a menu item, which occurs when they are not managed by the same variable (or kept synch’ed). The opposite is also true. It’s easy to forget about those tricky handlers when they don’t define the actual menu item but are merely associated with them.

This summer, I’ve learned an incredible amount as an interning software engineer. Although it has certainly been informative in a technical sense, one of the things that I am growing to appreciate in greater depth is the emphasis on improving the process itself in which I have traditionally programmed. My company, like many other companies which practice agile development principles, stresses the importance of proper coding habits such as code reviews, team transparency, sensible object orientation, Test Driven Development, and so on — pretty much the textbook pragmatic programmer stuff, at least in the ideal.

Admittedly, none of these have come particularly easy. Each concept introduces an additional learning curve  on top of the hard, technical concepts that are necessary to make satisfactory progress during the day. Add to that the pressure of having a clearly defined task but only a limited interval in which to accomplish it (read: summer employment woes), and the temptation to forgo the ideal in favor of what’s more efficient is even stronger. But we all know that early “efficiency” can lead to a nightmare down the road, in terms of code quality, stability, and maintainability. So wherein lies the balance?

I’d like to use TDD as an example here, though this problem extends to many other coding practices. It is a practice that has, in my very limited experience, been particularly difficult to convince myself that a) the initial investment pays off; and b) having conceded the first point, to apply the technique effectively. For myself, adaptation of TDD has been rather evolutionary; however not in the sense that I don’t fully understand the importance of testing — rather, in the idea of development being driven by tests that you write. For those that need it, here’s a quick recap of the process:

1. Write a test that prototypes the functionality you wish to achieve. This forces the developer to think of the overall architecture before any code is written that, had it been written beforehand, could influence the developer’s willingness to make design change decisions.
2. Run the test. It might (and probably should) fail.
3. Write the minimum code necessary for the test to pass.
4. Repeat, refactoring as necessary.

So… it took me a while to realize the power of testing (and as a side note, how using proper design techniques like MVC and its derivatives make it a much less painful process). I learned this partly from hearing it evangelized so heavily at work, and to some degree the hard way from the first implementation of GCast. Always present is the tension of how to balance “perceived” productivity (i.e., what’s tangible that you produce), and the satisfaction of knowing you did things right.

I’m convinced that this boils down to three elements: efficiency, quality, and sanity. Sanity because testing is, um, boring.

But from here it gets tricky: in rewriting most of this code from scratch, I have used tests extensively and so far am tickled at how useful they are in the design process, let alone for their obvious benefits. Yet, the closest I have come so far to true TDD is concurrently designing classes and their tests (and that itself mainly due to the fact that in the case of GCast, the situation is prime for such a mode of development). The reason for this particular method is that I dislike the added formality of writing out the tests and then implementing the classes. If I’ve spent my spare time dreaming up the implementation already, I’d rather code first and then test, code and test, et. al. — in the wrong order, yes, but iterative nonetheless.

Thinking about it, my adaptation of testing has been progressive as my perception of the added benefits has widened: Use tests, waste less scarce time hair-pulling and debugging. Use tests during the design process, and they contribute to better architecture decisions. Begin the process from tests, and it’s the berries. Right?

Only that’s where I’m stuck in the balancing act.

Well, we do call it Open Development, after all.

I was recently reminded that the source code for a few of the applications hosted on this website is not yet available, something that I’ve put off for a while. The time is far overdue, and here’s a shout out to JAWS for sticking it to me. I’m releasing the source code for two projects, L’Hospital’s Rule Illustrator and APID. Although currently neither are being actively developed any longer, both are available for modification/redistribution under the GPL v2 license (which basically means, please retain author credit somewhere if you wish to redistribute any of them — and I’d love to hear how you’re using either or both).

What follows is a brief description for each, as well as the SVN repositories and development notes for each. On Windows, you might find the TortoiseSVN client useful for checking out the source code; Linux users might prefer KSvn over the command line.

L’Hospital’s Rule Illustrator

This app illustrates L’Hopital’s rule, intended for Calc I students. There are two independent editions available, mostly because I wanted to learn Java/SWT at the time!

Qt edition:
Repository: http://svn.odevelop.com/lhospital
Devel. notes: C++, Qt 4.2 (also imports directly into Qt Creator and compiles with 4.5)
Platforms: Windows, Linux, possibly Mac (not tested)

Java edition:
Repository: http://svn.odevelop.com/jlhospital
Devel. notes: Java, SWT, Eclipse. You’ll want to run this from the .JAR so resources are found correctly (I’ve set up the ANT build.xml with this configuration). JLHospital was my first attempt at Java and the Standard Widget Toolkit, so please forgive the hardly-object-oriented code!
Platforms: Windows, Linux, possibly Mac (not tested). Requires the specific SWT native library compiled for each platform.

APID (Win32 API Debugger)

APID is intended for a bit more advanced audience; that is, those who find delving into Assembler and low-level addressing redirection intriguing (like myself!). A relatively unstable proof-of-concept application. Please use responsibly.

Source code repository: http://svn.odevelop.com/apid
Devel. notes: Microsoft Assembler (MASM) v9, RadASM IDE, OllyDbg for debugging
Platform: Windows (NT based systems only, i.e. Win. 2000 and above)

Features I’d love to see implemented: Multi-threaded support, redirect routine using a code trampoline instead of the same offset for each call, reliability for heavily-used API (such as Send/PostMessage etc.).

Note: if you’re just interested in just trying the applications out, the release packages for both of these are available on the download page.

If you are interested in contributing, drop me an email at cameron {at} odevelop {dot} com.

It’s been a little while now since I added the “preview” of GCast, the screen capture and sharing application for the GNOME desktop, to the download page. Given that a fair bit of time has passed since then, I just wanted mention briefly where the project is currently at.

I’ve decided to rewrite the way that editing is currently done, before moving ahead with the rest of the application — certainly before releasing it. The reason for this (from a technical standpoint) is that GCast in its early state uses underlying widgets to represent graphics items (such as rectangles, text, and so on); something which I have discovered is costly in terms of performance. As far as accepting interaction goes this was the easiest way to get started, but it has become a hindrance.

So although GCast’s editor works, it could be much better. I’ve come to the conclusion that it will be worth taking the time to do things right before releasing it, even as a beta, and I’ve developed a prototype of a new system of editing (undoubtedly the standard, but hey, I’m learning this as I go) which is able to cast off the handicap of widgets by being able to independently manage the editor rendering/interaction process. For you, this means a faster and more reliable product.

As it turns out, I think that having less time to work on it as life has gotten busy this summer has been beneficiary. By being forced to step back and look at the scope of the project in a larger perspective, priorities — namely, the balance between a rich feature set and a smaller subset of well written basics — often get re-arranged for the better.

I’m excited to resume development on GCast again soon. Until then, thanks for your patience.