Blogging - purposes and pitfalls.

The hardest assignments for me in this course (672) have unexpectedly turned out to be the blog posts. Perhaps it's my checkered history with blogging (see 'blog fail', again), but it was hard for me to see from the beginning why these posts were important (it might have helped if I'd actually looked at their weight in the grading).

Now, with the end of the course looming and the final project done, I see the point. There's something about documenting a process that changes its place in your consciousness, and opens the door to useful retrospection. As I struggle tonight to turn all of my haphazard draft posts of the last two months into something I can publish without shame, I hope I find time to benefit, at least a little, in the intended way.

When is "management" not a bad word?

Project management is a very interesting concept to me, because I operate professionally in world of projects that should be managed, and that technically have leaders, plans and desired outcomes; yet, somehow, there's never really any sense of project management happening. Management of individual employees, resources or processes, perhaps, but not an overall eye on plan and execution.

Perhaps it's a sign of career maturity that the steps and systems of project management as laid out in PMBOK are both comprehensible and appealing to me. I also appreciated the fact that the treatise began with a clear definition of what a project is - that a 'project' has certain characteristics (short duration, unique factors, a development arc, a specifically assembled team) that distinguish it from every other dang thing you do in the work day.

Unfortunately, I haven't left myself enough time in the semester to do the readings justice. I think it would behoove me to spend some time with the PMBOK (which I picture as a sort of gazelle every time I think the acronym). I did find a lot to think about in the article I reviewed for the assignment, which was a case study of projects and management in action.

This and the technology planning units presented me with some challenges, since I've always worked in environments where planning gets shortchanged, and leadership is present, but boundaries of responsibility are often fuzzy. In a sense, these subjects are much harder for me than configuring a server and constructing a database.

Wrappings

There's a lot to think about in this course, and in a way I don't think it can end at midnight on the 11th for me. When I registered for Applied Technology I expected a lot of hands-on work, and I got it, and very useful it's been too. I've passed that terribly important point where the threads of the tasks we've performed have become interwoven, and I'm beginning to see the shapes of interconnected systems in the weave.

Passing that milestone makes it possible for actions taken, like commands given at the command line, to have all the necessary associations with the bigger picture that really make reason and memory work effectively. There's been even more to this class, however.

That same sense of an overall fabric of technology has also pulled the threads of planning and project management into its weave. These are subjects to which I'd have been indifferent earlier, and which I now see in context. That may be the most valuable thing I'm carrying away, and that realization has come quite late - late enough that I may have to continue studying for this class long after the deadline has passed.

This late post has been back-dated to keep everything in order.

MiSQL es su SQL

I'm surprised at the rather pleasant experience I've had with MySQL. I learned to do a fresh MySQL installation, set up users, and load a particular database almost three years ago, but until this unit I never really knew what it was I was doing. I wasn't the creator or the user of that database, and its tables and relationships are completely opaque to me (or they were - now I know how to look at them without fear of disaster).

I do find the more complex queries difficult to wrap my head around. Something about the terminology of right and left joins is unhelpful in constructing my mental model of what a query's results should be. The simple tables we set up for these assignments may not have the characteristics that would demonstrate the concepts best.

The handling of null values also stumps me a bit - I don't really understand what the consequences of having or not having a null value are, beyond perhaps triggering a 'must have data' condition. In my wee database experiment, null understanding also tangled with some misconception about how default values should work; these issues are probably the tip of the iceberg for continuing database research.

The really interesting thing is that I'm kind of looking forward to it. I would never have guessed that I'd find database work fun, once I was beyond GUI-based software tools that are supposed to make it less onerous. Maybe I just need to see the bones of a system before I'm happy.

This late, late post has been back-dated to keep things in order.

Navigating the ERD

I have a many-to-many problem. Apparently my gift for complicating relationships applies in more than one sphere; it took several readings of Prof. Fulton's warnings about avoiding overcomplication to rein in my database ambitions to the point where I can use it for these exercises.

That wild horse did get tamed, however, or at least hobbled. My wee webcomics database is just three tables with minimal attributes and I've been able to produce an ERD that looks sensible. It responded nicely to normalization and I think I'll be able to go forward with it for the next units.

That's fine for the exercises (I hope!), but it leaves me wanting. I perused a lot of ERDs for this unit, including many of the ridiculous number of examples at databaseanswers.org and I didn't see what I wanted - a way to diagram (and thus explain) the complicated relationship between creator, comic, and strip (instance of a comic) that comes from the common practice of doing cross-overs and guest strips.

I don't need to know how now, but it's a niggling question. I believe that I understand the ideas behind normalization, but I can't picture how to do it on this more complex structure - it's something that's just going to have be tried. I'd like to find a series of database design tutorials that are even more hands-on than the resources I've seen in class. And then I'd like to find the time to do them...

This late, late post has been back-dated to keep things in order.

Technology planning is my bugbear

Well, maybe not technology planning itself - as far as I'm aware, I've never participated in an actual technology plan (although, interestingly, I've experienced everything listed in the What Went Wrong article anyway). This unit has proven to be a bugbear, though, in that I've been unable to effectively organize my thoughts and get the writing done.

Which is just what I'd expect to happen if I were drafted into writing a technology plan (see how I did that). I am very much one of this world's accidental technologists: the child of two IBM lifers who wanted to be an artist. I prefer things to stay organic and intuitive (translation: I don't like to put in the advance work, it's boring). I wonder how many tech plans have been written by people like me?

So it may not be surprising that one of my favorite pieces of wisdom from this unit's readings is to keep things open; don't write a plan that's so specific it boxes you in and leaves you with no place to go when things go wrong or just go different. Another, from Chabrow, is to fail fast. As long-serving state employee (no time off for good behavior), I've seen a lot of projects outlive their usefulness before they've even gotten off the ground.

If a technology planning process ever does come my way, I think I'll have a more thoughtful contribution to make. It will help that I'm making a list of the causes for project failure that come up multiple times in both the readings and on our discussion board; these are the real bugbears - poor needs assessment, scope creep, failure to bring the crew on board before setting sail.

This late, late post has been back-dated to keep things in order.

XMLovin' (part two of the series)

I was fortunate to have IRLS 672 follow on the heels of 515. Organization of Information, with Hong Cui, provided me with a hefty dose of XML recently enough that it's still doing me some good. One resource, of course, that I keep going back to is W3Schools. I can barely abide the layout and appearance of their site, however, and I root around for other tutorials. There's a lot on the web, but sometimes it's not particularly well organized. Google is many things, but it's not a proper index.

I'm a big fan of the O'Reilly books, which almost always have very proper indexes, and 'Learning XML' is available electronically through the ASU library. It's holding up well for its advanced age (a seven-year-old computer book is at least pushing 70 in dog years). On the day I start a serious XML project, 'XML in a Nutshell' will be on my desk.

I have to admit that I'm not very conscientious when it comes to tutorials. I learn by doing, and as soon as I've grasped enough of a subject to come up with a project or interest of my own, I'm off and skipping around, googling up a storm. It doesn't help me cover the material thoroughly, but what I do learn sticks.

I already scooped myself on practice system news in my previous post. It's time for me to admit that I've been working with my practice system all along, doing the exercises in parallel. I know just enough about OS installation and networking to have not gotten myself in trouble. I did have to re-burn the Ubuntu disk once, but other than that it's been smooth sailing all the way. I'm not building any character at all...and the gremlins are late to the party.

This late, late post has been back-dated to keep things in order.

UbuntuServuntu

My practice system is up and running! I'm almost ashamed to say that it went like butter (pronounced "leyk buttah"). I think I could use a few more problems to build my character (and now that I've said it out loud, I bet I'll have them. The gremlins are always listening).

UbuntuServuntu is a Dell Dimension 2400, nearly stock with the exception of an added CDR/DVD drive and 1 Gb of RAM. I've had it for years, and under Windows XP it was like molasses. Any interruption of its thought process in the first 5 minutes after booting caused it to flatten out its ears and drag its mule feet. I did have it set up to dual boot back in the Edgy Eft days of Ubuntu, but alas, I only really needed it for those little things you can only do in Windows. Now I've once again been justified in my general policy of never throwing anything away.

The Dell's a computer that's given me a lot of cussin' practice over the years, but it took to Lucid Lynx like it was born for it. Oh dear, did I just say that out loud?

HTMLovin'

My first attempt to learn HTML came about four years ago, when I decided I was born to blog (ha!). Being a hands-on type with no real sense of my own limitations, I not only decided to blog, I decided to get my own domain name, set up hosting, code my own front page, and do my own Wordpress installation; a week and a LOT of googling later (with a little help from Laughing Squid tech support) I had accomplished my goal. I then proceeded to update on a geometrically decreasing curve, crashing and burning entirely about a year later. Oh well (see Blog Fail).

I wrote that first page using only online resources, including w3schools, Dave Raggett's "Getting Started with HTML, and HTML.net. These three were my staples, but I'm not proud - I'll use any resource I can find, and I'm pretty sure I don't write anything that could be termed well-formed code. If you were to navigate to that primitive page (which I am not linking, you'll notice), you might find it to be eerily similar to the current state of my SIRLS site. I love that backhoe.

A couple of years after the blog experiment, my partner and I wrote a book, and suddenly we needed a website. Cactus Camping was born, in a flurry of ill-considered frames. I wish I could take credit for its current appearance, but my co-author got tired of waiting for me to fix it and took a web design class through ASU. My only consolation is that it's still under construction, too, and my frame-riddled version worked reliably under IE (so there).

Matters of style

This is the part where I wonder if I'm really a creature of the modern world. I really don't like video tutorials. I should probably amend that - I really don't like video tutorials over 5 minutes in length; I mildly dislike shorter ones. (On a side note, I absolutely despise manuals in video form. I don't want to watch the pretty pictures when I'm troubleshooting.) I am glad to have the UACBT resource (note that many of the segments are under 5 min. Yes.), but in general I prefer to read my way through tutorial material at my own pace, and I'm enjoying working my way through Prof. Fulton's assignments.

This may have to do with the fact that I learn much more effectively when I'm doing. Somehow, the attentional shift between reading and doing is not as disruptive for me as between watching and doing.

In the search for condensed knowledge to read, Wikipedia has been a close companion for a long time now. I understand the reservations many have about it as a source, but for brief summations of technical subjects, generally with helpful links, it's a winner.

This was our time to read about learning styles, but I'll have to fess up that the first thing I found was a podcast built around the contention that 'learning styles', at least as they're bandied about in education, are a load of codswallop.

I do think that individuals tend to favor certain interactions with the world with more attention and thought than others, but I won't even try to guess as to whether this is learned or innate. My department has, in fact, built a multi-year research project around the idea that kinematic learning is superior to butt-in-seat-eyes-front for many K-12 students; preliminary assessments seem to bear this out. The project also seems to be accumulating evidence that the right learning style for any situation is affected by a complex combination of individual preference, content, and environmental context, and may vary for each individual from circumstance to circumstance - which isn't going to take well to tidy categorization.

I think, if the term 'learning style' is to have any useful meaning, it can only be determined by an individual during the learning experience, and is largely a matter of 'know thyself'.

P.S. I have been reading a rather neat book from the Pragmatic Programmers called Thinking and Learning - it's worth a perusal.

This late, late post has been back-dated to keep things in order.