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.

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.

So with school officially out of the way for the year and a little time left before work begins, I dusted off my copy of Flex 3 the other day to re-learn the basics for a vague idea I had for an RI app. Flex seemed to have some pretty solid means by which to serve up and display data from a database fairly well, so I set out to try it out. The way it works is by POSTing a request to a simple server script (in this case written in PHP) which queries a specific backend database table, returning the list of records in the table as XML. Adding new records to the table and modifying existing ones are accomplished in exactly the same way, just with slightly modified server scripts for each operation. Using the data binding features that Flex provides, hooking up to this data and displaying it in a DataProvider is a peice of cake thanks to the HttpService class (there are plenty of examples of this process on the ‘net).

The problem arose, however, when I wanted to save rich text in HTML format to a specific field in the database. The rich text would save properly, but it would not redisplay since the tags were interpreted as XML themselves; this thoroughly confuses Flex which normally attempts to bind XML straight into a collection of objects for simple programmatic access. Here’s a screenshot of the raw server responses that it was choking over:

Instead of the HTML text between the <description></description> tags getting displayed properly, the cell showed a frustrating value of “[Object object],” with my HTML nowhere in sight (see screenshot below).

The solution for this is to bypass object binding — at least temporarily — and control the HTML before its containing node gets bound to an object. This involves traversing the XML structure as much as we dare; that is, up to the parent node and from there grabbing its internal text. Finally, using the ObjectProxy class, we can bind the HTML as the value to an XML node… converted to an object. In code, this looks like the following (notice that serv_result() is a callback for HttpServer’s ResultEvent):

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52

<mx:Script>
      <![CDATA[
		[Bindable]
		private var _noteList:ArrayCollection;
 
		private function serv_result(evt:ResultEvent):void {
			var xmlStr:String = evt.result.toString();
			var xmlDoc:XMLDocument = new XMLDocument(xmlStr);
			var note:ObjectProxy;
 
			_noteList = new ArrayCollection();
 
			for each (var n:XMLNode in xmlDoc.childNodes[0].childNodes) {
				var szDescription:String = n.childNodes[1].toString();
 
				var indexFirstBracket:Number, indexLastBracket:Number;
				indexFirstBracket = indexLastBracket = -1;
 
				indexFirstBracket = szDescription.indexOf(">");
				if (indexFirstBracket != -1) {
					szDescription = szDescription.substr(indexFirstBracket+1, szDescription.length-indexFirstBracket-1);
				}
				indexLastBracket = szDescription.lastIndexOf("<");
				if (indexLastBracket != -1) {
					szDescription = szDescription.substr(0, indexLastBracket);
				}
 
				var next:Object = { title:szTitle,
									description:szDescription,
									question:szQuestion,
									startdate:szStartdate,
									enddate:szEnddate,
									imageurl:szImageurl};
 
				note = new ObjectProxy(next);
				_noteList.addItem(note);
			}
 
			notes.dataProvider = _noteList;
		}
 
		private function initCellRenderer():void {
			description.itemRenderer = new ClassFactory(HtmlRenderer);
		}
	]]>
</mx:Script>
 
<mx:DataGrid id="notes" x="10" y="46" height="544" width="780" initialize="initCellRenderer()" change="updateButtons()">
	<mx:columns>
		<mx:DataGridColumn headerText="Content" id="description" dataField="description" width="250" />
	</mx:columns>
</mx:DataGrid>

You can see that we are managing a small step of the binding process ourselves to prevent Flex from parsing the HTML and trying to bind it to an object (which fails and just results in the “[Object object]” text). Note that in order for this to work you must set the resultFormat property of your instance of HttpService to “xml” (the default is “object”).

As you may have guessed from the initCellRenderer() function, a custom cell rendering component is necessary in order to display an HTML-capable widget, but this is the most trivial part of the process:

1
2
3
4
5
6
7
8
9
10
11
12
13

// HtmlRenderer.mxml
<?xml version="1.0" encoding="utf-8"?>
<mx:VBox xmlns:mx="http://www.adobe.com/2006/mxml" width="100%" height="140" 
	paddingBottom="5" paddingLeft="5" paddingRight="5" paddingTop="5">
<mx:Script>
	<![CDATA[
		import mx.controls.Alert;
	]]>
</mx:Script>
	<mx:TextArea id="htmltext" htmlText="{data.description}" height="100%"
		width="100%" backgroundAlpha="0" focusAlpha="0" wordWrap="true"
		borderThickness="0"/>
</mx:VBox>

The results were better, but not quite perfect. As you can see from the capture above, the HTML was still getting “beautified” by the XML parser. In order to convince it to leave the HTML data alone, I ended up wrapping the HTML with quotes just prior to sending it to the database, and then removing those quotes before setting an HTML widget to its contents. The final results:

There you have it — embedded HTML in XML, bound to a Flex data view.

I’ve been eagerly awaiting the 2.0 release of MonoDevelop, which happened a bit ago but it took a while to hit the Ubuntu 9.04 Beta repositories. I’d forgotten about it until today, when I was trying to use the alpha 1 release to do some work on GCast; however, it’s been so long since I attacked the code base that for the life of me I could not track down a bug that had recently reared its ugly head. I’d made too many changes since the last SVN commit, so diff’ing a bunch of files was like looking for a needle in a haystack.

Thank goodness, after installing MonoDevelop 2.0 with its integrated debugger, it took all of a few minutes to find the problem. I don’t know how I’ve survived this far on this particular project without a debugger — I’ve had to resort to GDB and MDB at the command line a few times, but only reluctantly — wish I could reclaim the lost time. Kudos to the MonoDevelop developers for making a great product even easier to use!

Get MonoDevelop 2.0 at: http://monodevelop.com/

Work on GCast — the soon-to-be open-source screen capture and sharing utility for Linux — is continuing, albeit slowly, in between school, work, and everything else. Today I decided to take a break from working on the region-selector (which now masks the screen with a semi-transparent overlay like every other capture application worth its salt   and focus on completing the graphics editor, which still has some major work to be done. So far text and rectangles (with text) are supported, so I started to work on ellipses. After happily plunking away at a small bit of Cairo code, I was a little surprised at the results, which was anything but the smooth ellipse I was expecting:

I guess that’s what happens when you switch Bezier control points with nodes. Oops!

I have many more features planned than I have time to implement, but soon I hope to add support for undo/redo, Dropbox, Screencast.com (if they would only allow third-party applications to upload with their own api keys!), state-saving of all the graphics canvas and child items, as well as revision history. Watch this blog for updates concerning the development progress.