Saturday, 30 August 2008

Seasons

“God knows what He's about. If He has you sidelined, out of action for a while, He knows what He's doing. You just stay faithful – stay flexible – stay available – stay humble.” Charles Swindoll (1994) Growing strong in the seasons, p 531.

Over the last eight months, I have primarily been focussed on the writing of my PhD on practitioner perceptions of object-oriented programming. It has been a difficult road as we have learnt to survive on my wife's income. During that time, I have applied for positions in academia and in industry but so far there has been no offers for employment. Now as the cash reserves from the redundancy payout dry up, the feeling of having been sidelined grows stronger.

It would be nice to argue that my faith has remained strong throughout, that I have never once doubted that this is where I should be and what I should be doing. But that isn't true. I have wondered whether I have lost touch with those programming skills that I used to have and whether I would ever be teaching again. The sense of being sidelined forever has sometimes been overwhelming. That isn't helped when you have spent weeks writing a chapter only to have it pulled apart by your supervisors and you are back redrafting and hoping that this time, you are finally writing what they think is wanted.

This is where Swindoll's quote offers reassurance. God knows what he is doing and we simply need to remain faithful, humble, and available. In his time, he will open the path ahead and we will see more clearly what he has planned for us. As Jeremiah 29:11 says "For I know the plans I have for you," declares the Lord, "plans to prosper you and not to harm you, plans to give you hope and a future." That message was delivered to Jeremiah when Israel was in exile and looking like it had no future.

Power and Love

Barclay (1975), in a commentary on Mark 14:17-21, says “Here is the whole human situation. God has given us wills that are free. His love appeals to us. His truth warns us. But there is no compulsion. We hold the responsibility that we can spurn the appeal of God's love and disregard the warning of his voice. In the end there is no one but ourselves responsible for our sins” (p 391).

Barclay makes this comment in response to a passage where Jesus openly speaks of one of the disciples betraying him. Jesus never says which one. Barclay says that Jesus could have stopped Judas or if he had identified him, the other disciples would have taken action to stop Judas. But that isn't God's way. God doesn't force his will upon us. He appeals to us to follow the path that he desires for us. In the end, the choice is ours.

The consequences of not hearing God's appeal are all around us. As Barclay says we are responsible for our sins. Without that being the case, we would not learn or turn away from sin.

If God in his power continually moved to stop us or to cover over the consequences, why should we stop doing things that have the potential for disastrous consequences. Those consequences would never happen so the actions no longer matter.

In Barclay's commentary on Mark 13:3-6, 21-23, he talks about the antinomians who believed in nothing but grace. The law was abolished. To go on sinning was to ensure that God's grace continued to grow. If god stepped in to stop the consequences of our actions then we could argue the same. Why stop if it allows God to show more of his power. It doesn't matter what we do God will always stop us. We lose our responsibility for our actions.

Love seeks us to follow but it does not force us to do do even if it is within the power of the lover to do so.

Reference:

Barclay, W. (1975). The gospel of Mark (revised ed.). Edinburgh: The Saint Andrews Press.

Saturday, 23 August 2008

Photography

Two things have helped the photography effort this week. These are the the Kererü, the New Zealand native wood pigeon has been back in the trees around our house and the second has been the snow dumps on the Rimutaka ranges just north of the Hutt valley. The ranges are visible from different points around the Hutt valley and Wellington.

The Kererü are fairly large birds so that are not easily mistaken. We have the additional advantage that they like the Köwhai trees along our neighbours drive and the buds on our rather poor specimen of a pear tree. Te Papa in conjunction with the University of Victoria run a Kererü discovery project in which they encourage people to report sightings and send in photos. We have up to five birds visiting each day at present and on Thursday, I managed to capture some photos of the birds in flight. Usually when I see them they are up high in the trees and surrounded by foliage. This doesn't lead to very good photos although I do have some that have made it to the Kererü Discovery pages.


Also on Thursday afternoon, it was a beautiful clear sky so I took advantage to use my spherical panoramic tripod head to capture some panoramas of the snow covered mountains. With the orange of the willows as they prepare to sprout leaves, some of the images when stitched are quite spectacular. None of these are 360° or spherical images. Although we do have some of those to share once we resolve the final stage in preparation.

Thesis writing

Thesis writing is my other primary activity at present. I am in the last stages turning my attention to the discussion and conclusions. I have to admit that although the subject matter was of interest nearly two years ago, I am finding it frustrating now as I try to write the results up in a way that initially satisfies my supervisors and later the examiners. Partly because my these changed direction over the period that I have been working on it and partly because I wasn't encouraged to write sections earlier, most of the thesis has been written over the last eight months. Some of the difficulty is writing an educational thesis when I have been more focused on technologies. The shift in thinking is quite large.

From a technology perspective, my thesis is looking at how practitioners perceive what object-oriented programming is about. This has involved looking at how they express what an object-oriented program is and how they talk about designing an object-oriented program. The method that I am applying to the research is based on phenomenography. The objective is to uncover an outcome space that details the different ways that a group of practitioners express their understanding of a phenomenon. The result is a set of categories of description that in theory covers all the ways expressed by the group. This isn't a statistical exercise. It is very much an analysis of texts. As well as practitioner interviews, I have examined a set of textbooks based on the categories arrived at from analysing the practitioner' interviews.

The educational perspective gave the basis for the study. I have taken a relational perspective of learning (Ramsden 2003) that argues that the way that a learner approaches a learning task is dependent on their perception of the task. Some would call it the task representation. From a phenomenographic perspective, learning occurs when there is a change of conception of a phenomenon (Marton and Booth 1997). Hence if we understand the way that people perceive a particular phenomenon and the variations in critical aspects that make up that perception then we may be able to plan teaching to ensure that the perceptions that cause the greatest learning are those that are visible to the student and plan a pathway to those perceptions from those currently held by the learner.

My original plan was to implement a teaching plan and gather data on the change in learner conceptions over the period of the course but that failed when student enrolments in our courses began to drop and finally when I took redundancy rather than a position as a tutor. Losing the context for the research hasn't helped my struggle to complete the writing. I enjoy tasks where I can see a practical application. Now, the thesis seems to be little more than an academic exercise which occasionally gives me some enthusiasm when I uncover a new insight.

If you are reading this and think that any of this might be useful to you then consider leaving a comment and maybe we can get in touch. Job offers in teaching programming will also be accepted gladly.

Reference:

Ramsden, P. (2003). Learning to teach in higher education (2nd ed.). London: Routledge Falmer.

Marton, F., & Booth, S. A. (1997). Learning and awareness. Mahwah, NJ: Lawrence Erlbaum Associates.

Flex Programming

The last week has seen me focus on completing a programming exercise using Flash and the Flex development tools. It is difficult to believe that after 17+ years in the computing industry programming on a wide range of equipment and in a range of languages, and 17+ years of teaching students to program at tertiary institutions, that I am having to prove that I am capable of programming and of learning new environments quickly. Still if that is what it takes then we will do it.

I wasn't overly confident to begin with as I have found JavaScript frustrating and Flex using a combination of an XML based language for developing the layout and ActionScript. ActionScript and JavaScript are very similar sharing a common standard of ECMAScript. The company also wanted me to use a particular model-view-controller (MVC) framework for the exercise so there was quite a bit to learn. They also mentioned a FlexUnit testing framework and as I don't go the simple path, I decided that I would use that as well especially as they claim to use agile methods and I prefer test-driven or behaviour-driven approaches.

Over the last week, I have downloaded Flex Builder, the frameworks, borrowed books from the library, and set about learning the language, environment, and frameworks. There are two testing frameworks so I compared both a selected the one that I found easier to use. The end result was a small data entry system that felt more like a desktop application rather than a web-based application.

Maybe using a solution like Flex would give me an easier road to the type of facilities that I want to offer on our website. Flash is one of the options for displaying the 360 and spherical images so it would integrate nicely. Watch this space.

One of the things that I did with this exercise was write journal entries on the experience. Others have done this and published them on the web. I think I still need to learn about writing up the details as the entries make sense to me but have few code examples.

Three significant learning issues came out of the experience.

  1. When I installed Flex builder, it told me that I needed to update the Flash Player but I was sure that I already had the latest version installed so declined. Well, I did have the latest player installed but not a version that incorporated the debugger. Without the debugger feature, I couldn't step through the code and the testing frameworks simply reported success of failure. They didn't provide me even with the expected and actual reporting line. Once I was frustrated enough to try and resolve why the debugger wouldn't work and reinstalled a version of the player that incorporated the debugger, not only was I able to trace execution and use breakpoints, the testing frameworks actually began to report expected and actuals, and gave a stack trace so I knew where the problems were occurring. This made a surprising difference to progress and reduced the levels of frustration. Lesson: If you are told an install that something is out of date then check what the problem is and resolve it before moving on.

  2. Flex Builder doesn't know how to do refactoring other than rename. This proved to be a real frustration as I endeavoured to extract methods or relocate items within the hierarchy. Refactoring and test-driven development go hand-in-hand. Not having one part of the combination didn't lead to good code design. I recognised that I was already too eager to move on to implementing new functionality. Not having the refactoring tools just added to my resistance to get in and improve the code design before moving on to the next feature. I did find that I was fairly naturally looking for ways to reuse already written code and I was a little frustrated that I didn't solve this with a couple of my form panel layouts that only differ by the source of the data in the data provider tag. Moving on, they may differ by more than that but since this was a proof of concept, well proof of skill, exercise that may never happen. Lesson: Ensure that you refactor and look for support in the tools.

  3. I have often heard questions asked in programming forums about how big a step should a test represent. During this process, I often thought that my next test was simply a small step but once I started coding, I found myself running into problems. More than once, I went back and wrote another test that simplified the expected results. Guess what, that often resulted in a much smaller amount of code needing to be added or modified in that step. I am beginning to think that if a test requires more than a couple of lines of code to be added to the production code then the step is too large. Certainly, don't make a test that requires too many variations to be checked to ensure that it works. Guess what! It is likely to cause grief. Part of this project was about ensure a space was covered by a number of rectangles but that none of the rectangles overlapped. The place to start is with a rectangle that covers the whole area then look at two that cover the whole area. When you start looking at overlapping then again avoid having any uncovered area and having multiple overlaps until the basic functionality is there. Grow complexity in small steps. The smaller the better. The debugger becomes a thing of the past. Lesson: Ensure that tests increase the program complexity in as small a step as possible.

I hope this proves helpful to someone.

Saturday, 16 August 2008

Zero sum games?

This blog is stimulated by reading Mark 12:28-34 and Barclay's commentary (1975). There Jesus is responding to a question by a scribe as to “What is the first commandment?” Jesus response is to love the Lord your God with all your heart and your neighbour as yourself? What I want to talk about isn't so much what it means to love God or our neighbour but rather the attitudes that we develop in a society aimed at producing winners.

In part, we often look at things from a zero-sum perspective. A zero-sum describes a situation in which a participant's gain or loss is exactly balanced by the losses or gains of the other participant(s). That is there is never an overall growth so for someone to win others have to lose. Many games work on this basis. There is a fixed quantity of resource and some will gain while others lose.

The difficulty is that we take this idea of there being winners and losers into many of life's situations. We have to out play others in order to ensure that we get ahead. I used to work in a university were the emphasis was “publish or perish” but I discovered it wasn't simply publish, it was publish more than others in your department or college. You might be publishing on a regular basis but because others are publishing slightly more, you are the one under threat. It was a competition based on the number of papers published. Constant comparison and competition with little encouragement or support.

That to me isn't love your neighbour as yourself. I could describe other situations where competition is the primary objective and not encouragement and building up but I want to look at this from the perspective of game playing.

There was a game that we played with youth groups that was very simple but clearly illustrates some of the issues. The group was split into two teams and they were each given a small chart that told them how the scoring was done. They were instructed that the goal was to maximise the score. All the team had to do was chose either A or B. The scoring chart was:

Team

Both chose A

You chose A

They chose B

You chose B

They chose A

Both chose B

Your team

+1

-2

+2

-1

Other team

+1

+2

-2

-1

The objective of the game is purposely ambiguous. Life is a little like that. If maximising the score for your team is the objective and you want to win then you want to chose B and have the other team chose A. That way your team gains two points and the other team loses two points. Of course if they chose B as well, you both lose a point. If both chose A then both teams gain a point but the risk is that the other team will chose B and you will lose two points while they gain two. Between rounds, you send a negotiator to negotiate the play for the next round.

As long as teams focus on competition, either both teams will lose out. Both teams scores will decline. There seems to be no way to ensure that your team will increase its score. Only through cooperation can both teams improve their individual scores and by the nature of the game, the game score but can you trust the other team.

My argument here is that if we are to love our neighbour as we love ourselves then we need to be willing to take the risk. Cooperation and encouragement builds positive relationships and enhances productivity for all. The real questions is whether we are prepared to take the risk.

Reference:

Barclay, W. (1975). The gospel of Mark (revised ed.). Edinburgh: The Saint Andrews Press.

Saturday, 9 August 2008

Academic story

With the James Hargest High School reunion back in March, I decided that I needed to do some exploration of my school records. Not surprisingly, the school reports say that I would do better if I applied myself consistently. Now as I struggle to complete the writing of a PhD, I really wish that I had learnt to apply myself better at things that I didn't really like. One of those things is writing and now, I am working on a major writing effort. Back in my recollections on 29 March, I talked mainly of my involvement in sport. Except for involvement in motor sport, that died when I went to university but I didn't really focus on the academic work unless it inspired me or was of interest to me. That is how I ended up in computer science.

Not doing particularly well in my first year at university other than in the labs, I wasn't allowed to progress with my planned course in mechanical engineering. Having passed two maths papers, I took options that would allow me to progress toward the completion of a B.Sc. Computer science needed only two first year maths papers and I had those so I enrolled. The practical nature of the course with a focus on programming caught my interest and since the programming exercises supported the theory, I applied myself. The result was a B.Sc. and work in the computer industry.

As I reflect back, I realise that most of the subjects that I applied myself to involved some form of learning by doing. At high school, I focussed on maths because there were lots of interesting practical problems to solve such as plotting the path for an aircraft to get from one place to another in a cross wind.

Maths turned to theory at university but computer science had some interesting practical problems to solve and it drew on some of that maths knowledge built up through practical exercises. Theory for the sake of theory is a meaningless exercise for me so if I want to examine theory, I need to look for practical applications.

Now, after spending a number of years teaching in tertiary organisations, I argue that students need a conceptual foundation if they are to be able to be life long learners. Their conceptual framework lays the foundation from which they expand and develop new ideas. This leads to my current exploration of the ways that practitioners express their understanding of object-oriented programming. If I want to teach students to be good programmers then I need to know the possible conceptions that will help them to be good programmers and my learning exercises need to help them develop the appropriate conceptual frameworks in a way that grabs their attention and helps them to learn by doing.

But... and its a big but, I struggle with the academic writing. If I apply myself, I can write but I don't enjoy the exercise. I would prefer to be taking what I have learnt and applying it in a classroom. Yes, I would gather data that would help show that the teaching was effective but do I need to publish the results? To stay within the academic community, publishing is a requirement but publishing also serves another purpose. It puts your ideas out there for others to critique and provide their input. Again, I am not interested in critique that simply aims to pull apart. I am interested in critique that aims to suggest improvements that is it adds to what is being done in a productive way.

In 2006, I attended a pattern writing workshops at the OOPSLA conference in Portland, Oregon. What interested me was their approach to looking at what someone had written. The approach isn't particularly new but they apply it consistently. Richard Gabriel (2002) outlines their process including the submission, shepherding, and the sessions at the workshops. There are some key things that happen in the workshop sessions that I think need promoting in dealing with academic work everywhere.

First, the author reads a short portion of the paper that is the heart of what they would like the workshop to examine. The writer then sits back and listens to the conversations. The conversations start with summarising the work and then presenting some positive feedback. The reviewers, the other participants in the workshop, then make suggestions for improvement. This isn't pulling the work apart but are intended as pointers for improving the quality of the work. Once that is over, the author can re-enter the discussion seeking clarification of any of the suggestions for improvement. In effect, this is a learning opportunity for the author so that they can learn from others in the workshop and improve the quality of their work.

I would have love such support as I learn this academic writing process and struggle to complete my thesis. So much of the feedback that I am getting simply appears to be negative. It tells me what is wrong and leaves me guessing at what I need to do to improve. I struggle to find any positives in the comments and as a result, I wonder whether the task will ever be completed. Is anyone prepared to offer their encouragement?

Reference:

Gabriel, R. P. (2002). Writers' workshops and the work of making things: Patterns, Poetry ... Boston: Addison Wesley.

Saturday, 2 August 2008

Spherical Images

I went out a shot a new sequence of images that take me closer to having a full spherical image. For these images, I am using a Canon EOS 300D with a EFS 18-55mm lens. Not exactly top quality gear but it does the job for these experiments. I am still using trial versions of the software to build the views. What I will describe here is the process that I went through in order to capture the image, stitch it and prepare it for display.

Taking the photos

The first step is taking a sequence of photos. I still didn't have any accurate idea of the field of view both horizontal or vertical for my lens but I knew that 16 images had a high degree of overlap on the horizontal rotation so I experimented a little when I first arrived at my location (Days Bay wharf, Lower Hutt, New Zealand) and determined that I could get away with 12 images or 30° of rotation between images. Experiments on the vertical plane suggested about 60° of rotation would give me some overlap so I set the tripod and camera up so I could take two sequences of photos. The first sequence I took at 15° below the horizontal and the top sequence at 45° above the horizontal (the software tells me it was closer to 43°). Reading the degrees off the head wasn't all that accurate.

Once I had worked out these angles, I waited in the hope of getting a nice sun set but it was becoming obvious that this wasn't going to happen so I took the bottom layer and then adjusted the pitch and took the top layer. Twenty four photos all with manual focus, aperture (f 5.6) and shutter speed (1/50 sec). The focal length was 18mm.

With the temperature dropping and obviously no red sky sunset on the horizon, I packed up the gear and set out for home.

Stitching

I downloaded the images into LightRoom and attempted an initial stitch with PTGui. On this attempt, I endeavoured to allow the software to find control points (matching points on overlap between the images) for stitching. Although it found control points for many of the lower pairs of images, it found no control points between the lower images and the upper images or between the upper circle of images. A revert to manually identifying control points enabled a first attempted stitch but it wasn't anything like expected. Hugin proved to be no better; if anything, it was worse at identifying control points. A different strategy was needed. I stitched the lower circle of images simply so I had something to show for my labours.

It seemed to me that if I knew the pitch (vertical) and yaw (horizontal) angles for each image that I should be able to tell the programs and have it stitch the images using these angles. In reading PTGui's help related to entering these coordinates, I learned that there is a Panorama Editor that would allow me to drag and drop each image into position. This revealed that my angles didn't match what I thought when I took the photos but it did allow me to line up the images with some degree of accuracy. It would have been easier if I could have zoomed in on particular parts of the image but this doesn't seem to be supported. Still an stitched image 360° panorama was created and didn't look too bad.

Hugin allowed me to enter the yaw and pitch for each image but doesn't have the Panorama Editor to make minor adjustments to positions. A panorama preview allows you to check the output and seems to do some other things but it didn't seem to allow for the repositioning of individual images or to zoom in to check details of the overlap. Not as helpful as I would like but at least it also stitched an image. The lack of documentation makes learning the Hugin features difficult.

I am still not satisfied with the stitched image. Some of it comes back to the angles I chose when I took the images but some are problems in lining up for stitching. I did try Canon's PhotoStitch and although it allows for the positioning of images in two rows, it really didn't allow for the curve that you get when taking close to 120° of vertical angle from top to bottom of the image. It also needs to be able to identify the overlap before you can adjust the blend lines. It looks like its days of use are coming to an end.

Creating viewer images

The file created from the stitch process is an equirectangular image. Basically a flat panorama that can be viewed in a 360° viewer like Canon's Panorama Viewer. To make it viewable as a spherical image, it needs to be converted to a different format. There are a number of options here but one is into six images that form the sides, top and bottom of a cube. To do this, I am using a trial version of Pano2VR. This crashed when I tried to drop the image onto its window but opened up the image if I started it by by selecting the image and asking for the image to be opened in the program. It would create the view images for Quicktime or Flash but wouldn't allow me to adjust some of the parameters for the image. This might be a problem caused by my stitching process and the fact that my image isn't a true 360° by 180° image. Still I had an image that I could review.

If you click the image, you will see the completed image as a 360° image in Quicktime.

Calculating requirements for taking the images

Having worked out what I needed to do to get a 360° by 180° image, it was time to think about how I ensured that I captured the right set of photos. I can't afford to buy a fisheye lens that would allow me to take about four images to achieve the desired result so I needed to calculate the number of images required. The key to doing this is knowing the field of view for the focal length of the lens when attached to your camera. This turns out to be fairly easy to calculate if you know the size of the sensor and the focal length. There are also calculators on the web that will give you this if you know the focal length and the focal length adjustment for your camera. The focal length adjustment simply recognises that for most digital cameras the sensor is actually smaller than the image that you would get from a 35mm film camera. For my Canon EOS 300D that multiplier is 1.6 for the 35mm equivalent focal length and the sensor is 22.7mm by 15.1mm. Building a spreadsheet to perform the appropriate calculations proved reasonable easy. The result is that at 18mm focal length, I need to take 10 images in the horizontal plane and 4 layers to capture the vertical. It is probably best to look at taking one image at +90° (straight up) and layers at +45°, 0°, and -45°. A -90° image could also be taken to complete the sphere but isn't essential. There is a small hole in the bottom of the image that can be plugged with a logo or some other suitable filler. A total of 31 images will be required. Unfortunately the weather here isn't helping for doing another experiment.