Where I was when the course started and how far I have come

Aside from factual knowledge and technical skills I have learned in IRLS 672, I would say that my understanding of how the component aspects of a typical digital technology implementation relate and fit together have greatly improved. When I started the IRLS 672 course, I had prior limited exposure to many of the concepts that would comprise the course content. I have watched libraries undergo a remarkable transformation in the last 15 years. I was aware of the importance of learning about aspects of this transformation, but it was difficult to determine where to begin. I have begun to develop a good foundation on which to build skills. The focus of my professional development has improved. As a result of my studies, I have gained heightened awareness of the exciting potential for work with digital collections.

When IRLS 672 started, I had read about the Linux operating system, and installed the Debian Linux operating system on a spare computer. I had limited familiarity with live-disk operating systems, such as Knoppix. My use of Linux was limited to graphical user interface (GUI) desktop applications. I had acquaintance with some concepts of networking from workplace exposure and reading. My knowledge of servers was limited to a conception of the role of a server in the server/client model. I had written static HTML pages. I had no knowledge of or experience with technology planning. I had a lot of experience using commercial, GUI-based database products. I had little exposure to project management concepts. I knew that PHP sometimes stood for the "P" in LAMP.

So I think I have come a long way since the beginning of the course. I have a good basic knowledge of using the command line interface (CLI) to navigate, configure, and administer Linux. I have a knowledge of basic networking. I have learned a lot about how HTML relates to XML and PHP. I have worked with web servers and database servers. I have learned something about technology planning and project management. I have learned a lot about how all these things fit together. Generally, I would say that I have developed a good foundation for working with digital technology applications. I can build on this foundation by continuing to learn about the topics introduced in this course.

Readings on Project Management

Personally I found the Project Management Body of Knowledge (PMBOK) Guide to be an interesting and thorough analysis of critical components of project management. The PMBOK Guide typically creates a matrix of nine knowledge areas (scope, time, cost, quality, human resource, communications, risk, procurement, and integration) and five process groups (initiating, planning, executing, controlling, and closing.) It is interesting how general principles such as these can apply to a wide range of projects. I think a good point was made in the readings regarding the challenge of choosing the correct level of detail to implement the PMBOK. I suspect it is this challenging choice which leads to under-implementation of PMBOK and similar principles in many library projects.

Scope management is important to avoid project escalation. I thought particularly interesting the example of project escalation documented in the Mark Keil article "Pulling the Plug: Software Project Management and the Problem of Project Escalation." Keil effectively documented how social and psychological factors can contribute to project escalation. I think such social and psychological factors frequently have significant influence on project outcomes. The Bas de Bar videos "Software Project Management in 15 Minutes" provided practical advice for managing such social and psychological factors. Bas de Bar asserts that project stakeholders are key to the success of a technology project. These stakeholders are primarily driven by tacit expectations of a project. It is the task of project management to divine and address these expectations through the definition of requirements. A key tool to define the scope of a project is the development of a work breakdown structure. I think the work breakdown structure would be a useful tool in many library projects.

It seems to me that much of project management deals with the allocation of limited resources. This resource allocation of limited resources is effectively illustrated by the Tradeoff Triangle diagram, as described in the Microsoft Solutions White Paper MSF Process Model V 3.1. The three aspects of the Tradeoff Triangle are resources, schedule, and features. These three aspects are assigned exclusively the respective qualities of fixed, chosen, and adjustable. So, for example, given fixed resources and a chosen schedule, a technology project product's features should be realistically projected to be adjustable. I think that understanding such realities can aid in the management of stakeholder expectations through the definition of realistic requirements.

A MySQL concept I found difficult to understand

These two MySQL queries return the same value:

select photographer_lname, image_title

from photographer

right join image

on photographer.photographer_id=image.photographer_id;

select photographer_lname, image_title

from image

left join photographer

on photographer.photographer_id=image.photographer_id;

In the first query, the right join returned all the rows from the second table (image), even if there was no value from the first table (photographer.)

In the second query, the left join returned all the rows from the first table (image), even if there was no value from the second table (photographer.)

Left and right refer to the first and second tables. Left- first table, right- second table.

Below, this is the general example for all rows returned, from the table in CAPS:

select column1, column2

from TABLE1

left join table2

select column1, column2

from table1

right join TABLE2