David's Saga of Geekery

Apache modules on Debian

Tue, 25 Nov 2008 05:12:33 GMT

I'm thinking of installing Typo. Among the various things it needs, Apache's mod_rewrite module must be turned on.

Debian has its own means for managing apache modules:

a2enmod
a2dismod

Also, for virtual hosts:

a2ensite
a2dissite

Instructions for enabling Apache modules under debian

(Also see another, perhaps better-written version)

Sat, 29 Mar 2008 23:50:18 GMT

I'm dealing with a cloud of objects, where each object references a list of other objects. Every reference is bidirectional. Every reference has a type. Starting with some object, I will need to be able to traverse the structure formed by references of some type to confirm that there is a path between provider-objects and consumer-objects.

I've googled about for some type of design pattern for this without finding anything even remotely appropriate. Anyone have a suggestion?

Ruby #1

Mon, 24 Mar 2008 05:36:07 GMT

The PHP project having gotten down to a routine, I figured that I would add a similar project in some other language. I had been planning on Java, and learning Eclipse while I was at it. Looking for a more interesting project, I thought I would revisit something that I had been using to learn Ruby and rewriting it in Java.

That was the plan on Wednesday. What actually happened is that the project, in Ruby, reached out & grabbed me. It hadn't been left in a bad place, I just had other things that needed my attention, so it fell off of my radar about 20 months back. So rather than a project with which I took one small step every day, I did nothing else for several days straight.

I recall from back in 2006 that I was having problems wrapping my brain around the language. I'm not sure what changed in the interim, but it all felt very smooth to me this time around. Of course I had forgotten all of the little details about syntax and libraries, but I had a program to start with - with unit tests, even!, "Programming Ruby The Pragmatic Programmers' Guide", and a variety of web sites to help me. It might be that 20 months ago I had been working exclusively with C# for quite a while and so a scripting language was not how my brain was oriented while recently I've been working with Perl & PHP. Or it might be that I'm older & smarter now.

In the last few days, I've relearned Ruby's language and libraries (not every detail, of course, but quite a bit of it) and extended and revamped the existing code. I've researched and implemented the Flyweight Pattern. I didn't know the name of the pattern when I started off, but I knew I wanted to accomplish and it seemed obvious that there ought to be a pattern for it, so I started from the Singleton Pattern and looked from there. I got a lot of help on the implementation of that from this blog and learned about mixins in the process.

My intention here is to reduce the time I allocate to this project to an hour or so a day. It might be difficult, as this is software I want to make use of.

More on this tomorrow.

PHP #13

Tue, 18 Mar 2008 02:52:06 GMT

"Checklist instances should be able to be named."

Test: Store a name to a checklist.
Test: Store a name to a checklist and read it back.

Wrote code to deal with this. For the most part, everything I needed was known off the top of my head, or could be copied off of previous code where it had been implemented after consulting with manuals.

I did find myself confirming with the manual that PHP has the typical 'default' switch case.

All tests pass except the one which says that the name is displayed correctly in XHTML. That will be dealt with in the next bit of coding.

PHP #11

Mon, 03 Mar 2008 22:09:02 GMT

Checklist should provide a means for storing the state of each item.

Yup. Same problem as yesterday, but now I have the CheckItem class to build off of.

I'm starting by changing Checklist::add() to store a CheckItem instead of a string. This should make any tests that care fail obviously right from the start. Fixed all the tests that complained about wrong data. This led to fixing ChecklistUI::displayChecklist() where PHP complained that an object is not a string, which allowed its tests to execute, which led to them being fixed.

Added a test to assert that what Checklist::current() and Checklist::next() provide are CheckItem objects.

... and now checked checkboxes persist.

EasyEclipse?

Mon, 03 Mar 2008 13:29:18 GMT

I want to dust off my ancient Java knowledge. First question seems to be "Which IDE?". Eclipse seems to be popular. EasyEclipse seems to be the easiest way to get there. However, the sheer volume of data about this is staggering. Anyone want to comment either way on these choices?

PHP #10

Mon, 03 Mar 2008 05:44:10 GMT

Checklist should provide a means for storing the state of each item.

Now each checklist item is no longer just a name - now it is a name and a state. I'll make a class to represent a checklist item.

Tests: A CheckItem can be constructed, and will contain the name, and optionally the state specified.

Wrote CheckItem class to satisfy the tests. I suspect that I'll need to add setters for the status pretty soon.

I wanted my constructor to work with multiple signatures. (That violates the "simplest solution" principle, but hey, this is all about the learning experience anyhow.) It turns out that PHP does not support function overloading, but it does have the func_num_args(), func_get_arg(), and func_get_args() functions.

Remote Shell Annoyance

Sun, 02 Mar 2008 19:44:04 GMT

One result of a recent change in network connectivity from DSL to a cable modem is that my ssh connections to remote systems time out if I don't interact with them for some absurdly small amount of time. I note in the ssh manpage that there are a variety of keepalive options. I'll have to explore them very soon.

For today however, I've spent more time on administrivia than I really had available, so I'll have to come back to this later.

See the ssh_config(5) manpage and perhaps also SSH connection stability.

Data Storage

Sun, 02 Mar 2008 19:35:12 GMT

My backup strategy (such as it is) is to keep anything important in a subversion repository, then replicate that so there is no single point of failure.

Work projects go into a separate repository.

The remotely located web server also gets its own repository.

All of these get replicated (with rsync) to each computer (local and remote) and also to some external hard drives.

Complicating things slightly is that my primary computer is a laptop. My primary subversion repository resides on this laptop so that it is with me wherever I am. Unfortunately I'm running short of storage space. I've already upgraded the hard drive. I might be able to get something with more capacity, but it would have to be slower, which I don't want.

My largest use of storage space is for digital photographs. I can't browse through them while they are in a subversion*, so I keep them all checked out. This means that they are using up space twice on my laptop. I'm thinking of splitting out the photos from the subversion repository, and keeping their repository on an external drive. (Of course, this repository would be replicated as well, just not to the laptop hard drive.) I thought this would be a nightmare to manage because I had never heard of anyone splitting out a subversion repository, but apparently it is common enough that there is a tool ('svndumpfilter') whose documentation includes an example of exactly that use.

* While writing the above, it occurred to me that one of the graphical Mac OS X subversion clients might just allow me to browse through photographs directly from the repository. I've found a few listed on the subversion project's links page: SCPlugin, SvnX, and ZigVersion. I've looked at ZigVersion's introduction movie, and it does not appear to have this feature. (ZigVersion is not open source, but does allow for free licenses for non-commercial users.)

I've just spent more time on this than I had hoped to. This write-up should serve to allow me to pick up this issue later with minimal loss of context.

PHP #9

Sat, 01 Mar 2008 22:26:23 GMT

Test: receive() should parse 'data_*' items as well as 'newitems', so that they become one checklist.

Wrote ChecklistUITest::testReceiveHiddenData() and ChecklistUITest::testReceiveHiddenDataAndTextarea() tests. Also, in a fit of paranoia, wrote ChecklistUITest::testReceiveBogusKeys().

Modified ChecklistUI::receive() to work correctly. Had to research PHP's regular expression functions and ended up using ereg().

Interlose

Fri, 29 Feb 2008 20:21:57 GMT

I go to check a file into my local subversion repository and discover that it is a mess. It seems that when I reinstalled subversion after loading my OS onto my new drive I 'fixed' where the repository lived. This change was needed so that I could add other subversion repositories in parallel, but things are royally messed up. The files copied from the old drive had .svn directories with the wrong location embedded in them. And obviously, I've not been keeping up with storing my files away properly.

I guess I've got my work cut out for me.

Interlude

Fri, 29 Feb 2008 17:11:50 GMT

NeoOffice lost its mind again, so I spent the morning fighting with software.

While it had a spreadsheet document open, NeoOffice claimed it could not write it. Then in trying to save the document under a new name, there were (unspecified) input/output errors, but a file was produced. It then could not open the newer version of the document.

I downloaded & installed a newer version (2.2.2) of NeoOffice, but that could not open the file either.

Then I downloaded and installed OpenOffice Aqua 2.4 (pre-release) and OpenOffice 2.3 (X11 version) in turn. Neither of those were able to open the document. I tried the version of the document that NeoOffice originally claimed it could not write and was able to load in at least some version of it in to both varieties of OpenOffice. The X11 version has the disadvantage of all X11 programs under Mac OS X, which is that Aqua treats everything running under X11 as a single program. This makes switching between programs annoying, at the very least. Also, the X11 version does not use the Mac OS X keystroke conventions, which is also annoying. The Aqua version is so sssslllloooooowwww at to be unusable.

I'll be dumping the NeoOffice and Aqua versions now.

Oh, and I'll put a note in my Tickler File to check out the current Aqua version in May.

PHP #8

Thu, 28 Feb 2008 18:50:35 GMT

Data in the form should persist from one display instance to the next.

Because HTML checkboxes return nothing if they are not set, a full copy of the checklist data must be stored somewhere. For now, I'll embed it into the form as hidden text fields in the form. (Later, I'm thinking I'll put it into a database and only carry around a reference to that data. For now, there is just not so much data that I need to worry about it.)

Each checkbox input tag must have a unique name. First thought was to use the text of the checklist item, but that is prone to failure in two ways: multiple checklist items might be input with the same text; a checklist item's text might be the same as one of the (current or future) form field names.

Answer is to generate a unique key for each checklist item, and use that key in the value of both the hidden input's name attribute and the checkbox input's name attribute.

Test: Modify ChecklistTest::testAddOne() and ChecklistTest::testAddTwo() to also check the return values from Checklist::add().

Resolution: Checklist::add() was modified to return the result of the array_push() invocation used to add the item to the checklist array. Should we start deleting things from the array, this will break. At that point, Checklist::add() would need to be modified to get the key of the last item in the array. (Perhaps with end() and key().) In the meanwhile, that is only a projected need and I should focus on the known needs.

Test: Modify testDisplayChecklist() so that each checkbox's name will be set to the checklist item's text, rather than the value attribute. Also, a hidden input tag should be provided to go with each checkbox input tag.

Resolution: displayChecklist() has been modified to comply.

Tomorrow:

Test: receive() should parse 'data_*' items as well as 'newitems', so that they become one checklist.

Next day:

Checklist should provide a means for storing the state of each item.

Next day:

Test: receive() should parse 'box_*' items and mark the checklist object appropriately.

Next day:

Test: displayChecklist() should should display 'checked' checklist items with the checkbox checked.

PHP #7

Thu, 28 Feb 2008 04:58:52 GMT

Getting back to this 'daily' work after five days of dealing with personal business to the exclusion of this project...

Checklist data needs to be persistent. Currently, it is parsed and displayed, but immediately forgotten.

Before I start that, though...
Looking at the generated XHTML, I notice that the value attributes of the checkbox input tags have newlines appended to them (except for the last one). This ought to be stripped.

Dealing with this is not the goal today, but niggling little details like this should be dealt with as they are found, or they just pile up.

Test first. It turns out that ChecklistUITest::testReceiveTextareaTwoLines() was incorrect. Fixed the test. It failed.

Guessing that there is a chop() function turns out to be correct. It is an alias for rtrim(). Now test passes again.

In the process of this, I was forcibly reminded of the difference between single & double quotes.

Now. On to the task at hand.

I think that I'll eventually want to persist data in a database of some kind. That's way too big a step to take right now. Until then, I'll put the data into hidden fields in the form. I imagine that even once most data is persisted in a database, I'll still need to pass along some kind of session key, so the code to hide data in a form will not be a waste of time.

I'll have to pick this up tomorrow.

PHP #6

Thu, 21 Feb 2008 05:41:57 GMT

Finally got all of the pieces in place to write (mostly) tested code to parse the incoming data, store it into a Checklist object, and then redisplay it as a list of checkboxes. The textarea is always there, as one might want to add items at any time. When checklist items exist, they are displayed above the textarea. All of the form XHTML has been moved into this new ChecklistUI class.

Things to work on next:
- Preserve the checklist data, so that it is not lost when the form is submitted. This could be done by encoding information into the form, or by storing the data somewhere.
- Parse the checkbox state and store that setting with the item name that is already stored.
- I found myself using <br /> tags to make space between the textarea and the submit button. That should really be done with CSS.

PHP #5

Tue, 19 Feb 2008 18:25:14 GMT

Today is the day to start implementing the code behind the Checklist web page. Slow going is to be expected at first as I learn PHP5's class syntax and PHPUnit2's available assertions. One annoyance is that PHPUnit2 requires that the test class extend PHPUnit2_Framework_TestCase. Since PHP5 has a single-inheritence model, that means that the test class cannot also extend the class under test and so I either have to reveal all of the class's internal data or test indirectly.

At this point I have a tested class which keeps an array and should allow it to be iterated over. Really, nothing more than is provided by the language for arrays, but now I have a framework on which to hang more functionality on.

Tomorrow. Only so many hours available today.

PHP #4

Mon, 18 Feb 2008 23:23:27 GMT

Didn't really have time to correctly implement "Parse Textarea Data", but I did hack in echo() statements to make sure that I was able to find the data. The Variables from outside PHP page was an invaluable reference. Also, I used gettype() to figure out what format the data was in, then once I had determined that the results from a textarea were returned in a string, I guessed that a split function existed and used that to turn the newline-delimited string into an array.

PHP #3

Sun, 17 Feb 2008 16:47:26 GMT

The CSS that I was using was convoluted beyond what is needed for this project, so I simplified it.

A lot.

The working example form that I had found online contained only a text input, while the form I'm using needs a textarea. I was concerned that this might be part of the cause of the problem interaction, so I swapped out the textarea for an input box. When everything else was working, I swapped it back and determined that this did not cause my problems.

I never did figure out exactly what in the old CSS was causing my problems. It would be nice to know, but I would rather use my time to push forward on this project.

In any event, the drastic simplification of the CSS and minor simplification of XHTML removed whe conflict. Now I can move forward. Sometimes simpler is better.

Observant people will notice that I didn't post a Daily Tech yesterday. I'm hoping do fit in more programming later today, but I suspect that other geekery will take precedence.

PHP #2

Fri, 15 Feb 2008 16:49:58 GMT

What I didn't mention yesterday is that I hope to be able to put in an hour or three each day on one of the development projects, with each day having a specific goal.

Today's goal was to parse the input into a PHP array. As I got started, I noticed that the form was not allowing text to be typed in and the submit button was non-functional. A small bit of playing around isolated the problem to be in the CSS. Something to do with float and position: relative. Several hours of searching the web and trying things leave me not too far advanced. I do have an example that works, which I'll have to unravel tomorrow, as I'm out of time for today.

PHP #1

Fri, 15 Feb 2008 14:19:28 GMT

While being unemployed and dealing with other facets of my life, I've lost track of a whole lot of technologies. To repair this situation, I've started two new software development projects. The first is in C#. I might eventually move development over to mono, but for now that development requires access to a borrowed windows box. The second is in PHP5. That is at http://www.davidsilber.name/phpChecklist/ and can be worked on wherever I have Internet access.

Yesterday, I made a base HTML page. I swiped a lot of it from my online resume. You might think that would make it easy, but there were a bunch of things to research.

For the most part, a .php page can have just plain (X)HTML content in it, but it (not surprisingly) interferes with server side includes. The non-functional server side includes, of course, are replaced with snippets of PHP code. In order to do that, I had to look into PHP's predefined variables and the date() function.

PHP also cannot cope with an XML declaration (it gives a syntax error). The solution to this is to send the XML declaration with the header() function.

I also spent a bit of time rearranging the swiped CSS, warping it to my purposes. I probably spent more time on it than I needed. I was thinking that I would end up with a fixed top menu bar under which all else would scroll, but after fighting it for a bit I realized that it was way beyond the scope for the day's work (I don't yet have any menu items) and put it aside.

To get embarrassingly basic, I even had to read up on (X)HTML form syntax.

There are no tests yet. I suppose that I could check to see that I'm displaying correct output, or have the correct date format. Right now it is all one monolithic web page. The non-trivial code for this will be implemented in separate class files and tested. I expect that this will become multiple web pages fairly soon, at which point the wrapper text will be factored out into units that can be tested.

NUnit 2.4.5

Tue, 11 Dec 2007 01:42:19 GMT

I figured that I would try to compile the current version of NUnit. Cleverly enough, the default target for NUnit's top-level .build file is 'help', which suggests targets that one might need to specify when building the package.

Building proceeds just fine until NAnt runs in to the need for 'log4net'. This is used, but not provided by the NUnit code. A bit of googling finds the Apache log4net web site.

Downloaded log4net & built with 'nant compile-mono-2.0'.

The NUnit .build files want to copy log4net from a lib directory off of the main NUnit directory, so I made such a directory and copied .../log4net-1.2.10/bin/mono/2.0/debug/log4net.dll into it.

Then, building NUnit with 'nant mono-2.0 build' worked just fine.

But I couldn't put the new NUnit anywhere where it could be linked to without it conflicting with the existing, older version. I spent a while fighting with it, then reinstalled Mono & gave up on having a new NUnit. I suppose I should bother the mailing list about it. If I do, I'll need to try again and capture error messages so that I can write intelligibly about it.

NAnt

Mon, 10 Dec 2007 16:59:42 GMT

The project builder of choice in the open-source .NET world seems to be NAnt. I've gotten the trivial bits of code that I have so far to build with it. I've not seen a good tutorial yet, but reading through the extensive set of .build files that NUnit uses is a good education on the subject. My .build files are not nearly so complicated, of course.

The default for NAnt is to build using the Mono 2.0 framework. Because I want to be able to run unit tests, and Mono only provides a 1.0 version of NUnit, I had to figure out how to specify the target runtime. Again, I cheated off the NUnit .build files.

C# Compiler Notes

Sun, 09 Dec 2007 20:26:27 GMT

It turns out that the mcs compiler targets the 1.1 runtime. 'gmcs' targets the 2.0 runtime. (There is also 'smcs' which targets the 2.1 runtime, but it doesn't seem to function on my system.)

Apparently, the nunit.framework.dll provided with Mono 1.2.5.1 is compiled for the 1.1 runtime, because gmcs cannot find an appropriate version in the GAC.

To enable the C# 3.0 features, use the -langversion:linq option. LINQ stands for "Language Integrated Query", which looks like some cool functionality, but the option apparently does turns on all of the 3.0 features that have been implemented, not just the LINQ stuff.

If I want the C# 3.0 features & NUnit 2.4 features, I'm going to have to build my own copy of NUnit. I think I'll bother people on the mono mailing list about it first. Perhaps there is some reason why a more recent NUnit was not built for the newer runtimes.

Sun, 09 Dec 2007 17:07:21 GMT

For my trivial tests of yesterday, all of my files were in one directory. Today I'm attempting to set up a real development area, which means in part that I set up separate hierarchies for the program and its tests. Compiling a library of program code is the same. Compiling a test that references the program dll requires that I provide a relative path to that program dll. Running the test gives me an error complaining that it can't load the program assembly:
"The assembly was not found in the Global Assembly Cache, a path listed in the MONO_PATH environment variable, or in the location of the executing assembly"

I wonder how to add to the Global Assembly Cache...

According to Assemblies and the GAC, I shouldn't throw things into the GAC if its API is likely to change in a non-backwards-compatible way, so my answer is to add the path of the program code directory to $MONO_PATH. Then I don't need to specify the path for the reference when compiling the test and nunit-console2 can find the program assembly.

Don't forget to export the revised $MONO_PATH!

Sun, 09 Dec 2007 02:22:34 GMT

A month after installing Mono, I finally get around to try to write software for it.* I want NUnit, so I start to install it, only to find that NUnit is included in the Mono distribution. That's cool - all I need to do is use it. Using it is not entirely obvious.

I need to compile to a .dll instead of to a .exe, as the "Hello, world" example does. The trivial code I wrote is:

	namespace Try {
	  public class Storage {
	    public int Number = 17;

	    public void Setter( int value )
	    {
	      Number = value;
	    }
	  }
	}

... and the command-line for the compiler to generate a library is:

	mcs -target:library try.cs

The code I wrote to test it is:

        using System;
        using NUnit.Framework;

        [TestFixture]
        public class Attempt
        {
          [Test]
            public void TrySetter()
            {
              int number = 9;

              Try.Storage victim = new Try.Storage();

              victim.Setter( number );
              Assert.AreEqual( number, victim.Number, "Same?" );
            }

          [Test]
            public void TrySetterFail()
            {
              int number = 9;

              Try.Storage victim = new Try.Storage();

              victim.Setter( number );
              Assert.AreEqual( number + 10, victim.Number, "Not Same?" );
            }
        }

The command-line for the compiler to generate a library and reference the pre-existing NUnit and Try libraries is:

	mcs -target:library -reference:nunit.framework.dll -reference:try.dll attempt.cs

To run nunit-console:

	nunit-console2 attempt.dll

And of course, one test passes and the other test fails, as expected.

Blind alleys that I stumbled down on the way to this were:
- Not realizing that NUnit was installed as part of Mono.
- Not knowing the syntax to tell mcs that I wanted it to produce a library. (What does -target:module produce?)
- Not knowing the name of the nunit.framework.dll assembly.
- Forgetting to make the Storage class public.

Instead of a .dll, nunit-console can be started with a .nunit project file which presumably will allow multiple test .dlls to be run. I have not been able to find out the format of this file.

* This is perhaps not entirely fair to myself. In the interim, I did waste a bunch of time trying to find an IDE to use. I think I want MonoDevelop, but I keep running into roadblocks to installing it under Mac OS X.