What I learned this week - National Geographic CD ROM set

National Geographic issued a CD ROM set in the late 1990s. It was an impressive collection, a box set of 30 discs with all of the National Geographic magazines issued to date.

The magazines offer a glimpse of the past, from the late 1800s to the late 1990s. The software is also a slice of the past, with special options to install internet link software.

It ran on Windows 3.1 and Windows 95, and also on Macintosh systems. For those operating systems, it is clearly 16-bit software.

Windows 10 does not support 16-bit software. Windows has not supported 16-bit software for quite some time.

But that doesn't mean that this CD collection is unusable. Only the software that comes with the CD set is unusable. (I have no desire to install Windows 95 and use the old software.) The data on the CDs is still usable.

Examining the CDs shows that each CD includes a copy of the SETUP.EXE program (which we'll ignore) and a nunch of DLLs (which we'll also ignore) and a few directories. One of those directories is named 'images' and it contains usable data.

Each disk has a directory named 'images'. In those directories is a collection of oddly-named directories. The names are all three-digit numbers and a single letter, starting with '188a' and working upwards. Each disk has a different set of directory names.

Those oddly named subdirectories contain .JPG files. Each file is a scan of a single page of an issue of the National Geographic magazine. Thus, we have the images of the pages, and we can still display them. (The .JPG format has remained constant, or at least compatible, over time.)

Examination of the directories show that each directory contains a single issue of a magazine. Thus the odd name for the directory is really a year and a month, encoded as a three-digit number and a single letter. The first year, 1880, is encoded as 188; the first month, January, encoded as 'a'. The directory 188a is for January 1880.

The pattern is easy to decode. The directory 189a is January of 1881, and so on. Not every year and month combination exists -- the National Geographic Society did not publish monthly at the beginning.

So now the task becomes a simple matter of programming. Can we write a program to ask for a year and month (or better, present a list of year-month combinations and let the user select one), then display a window and let a user scroll through a series of JPG images? That seems quite possible.

Notice that we are not using the old 16-bit software from the CD ROMs, just the data. We're not reverse-engineering the code, or cracking encrypted data. We are simple reading data files.

I'm looking forward to this project.

What I learned this week: blockchain and golang flag and WCF headers

Things I learned this week:

I learned how to set headers on a response in Microsoft's WCF. This helps by letting requests that result in web pages appear in browsers, instead of being downloaded as files. Most requests return data, so only a few request types need headers set.

I attended the PSU "distinguished speakers" lecture on BitCoin and blockchain. I have a much better understanding of BitCoin now. Some folks are concerned that BitCoin will have deflationary aspect as there are a finite number. I'm not worried. If BitCoin were the only currency, the concern is valid. We can create other crypto-based currencies (we already have) so the economy is bigger than any one currency.

My progress with the Go programming language continues. This week I added the "flag" package to my virtual processor, to add a command-line option for tracing execution. I was a little disappointed that "flag" doesn't handle non-options (like Ruby's argparse does) but maybe I just need to learn "the Go way" of doing things.

This week I learned about Go and Python and IDLE

This week I learned about the Go language ('golang' for search engines) as I worked on my assembler and virtual processor. I like the Go language; it is an improved version of C without the complexity of C++. I wonder what would have happened if Go had been introduced prior to C++.

I also learned about IDLE, the Python editor (and debugger!). I found debugging a little confusing, most likely because my long experience with debuggers is mostly Visual Studio. (Although I did write an interactive debugger for 8080 assembly language programs, back when the Heathkit H-89 was popular. I called it 'BEDBUG', for "BEtter DeBUGer". The name was suggested by my father.)

And on a third project, I find I need an RS-232 breakout box. I used to have one, a Heathkit PMK-130 that I had assembled myself. I don't know where it is now; I suspect that I sold it some years ago. (And now breakout boxes are rarities, with only one model available on Amazon.com.)

Today a BASIC interpreter, tomorrow a BASIC compiler

A side project is building a compiler for the BASIC programming language. (Why? Because it's fun!)

A previous fun project was a BASIC interpreter. (Two interpreters, actually.) For them, I used Ruby. The projects were a way for me to learn the Ruby language, and I succeeded.

For the compiler, I want a language different from Ruby. I find Ruby is an excellent language for high-level concepts; I don't know that it can read and write individual bytes and I don't know how it can convert integers and real numbers to bytes. (It probably can, perhaps with the assistance of a library.)

If the language will not be Ruby, what will it be? First, a few requirements:

It has to run under Linux. I use Linux for my development work and I don't see that changing.

Specifically, it has to run on my workstation, a venerable Apple PowerBook G4 which runs Ubuntu Server 16.04 LTS. It has to run in text mode (which just about every language does).

My plan is to create a compiler that generates bytecode, or p-code. I'm not going to target a real processor like the Intel 386 or ARM chip; I will write bytecode and use a runtime system to execute them, much like Java and C#.

Some possible languages and thoughts:

C++: Available on Linux. But my day job sees me working with lots of C++ code, and I want something different.

C: Not C++, but not quite different enough. And I am comfortable in C; another language is another opportunity to learn.

C#: Available on Linux, but I'm not sure that the .NET environment is available for the PowerPC architecture. And I would rather have a compiler language, not a bytecode language. (My own bytecodes will be enough, thank you!)

VB.NET: Exact same problems as C#.

Java: Available but uses a bytecode arrangement as C#.

Python: If not Ruby, why not Python? I'm using it for a different project, so not for this one. And it is not a true compiled language.

Perl: Umm... no.

Go: Possible. There is some support for PowerPC, and it may run on my PowerBook.

Swift: Compiled. May be available for the PowerPC. My preference, knowing nothing about either language, is for Go rather than Swift.

Pascal: Compiled. Probably available for PowerPC. A language I know. (Or knew, a long time ago.)

Forth: Interpreted and not compiled. Probably available for Powerbook. The Forth I learned was an operating system and took over the computer. Can modern Forth read and write files?

Objective C or Objective C++: I don't see a future for either of these languages. Learning them now would be... unprofitable.

Fortran: Really no.

Ada: More "no" than Fortran.

* * * * *

Update:

There is a Go compiler for Linux, and it does run on the PowerPC processor. I've installed it and written "Hello, world!".

There is a Pascal compiler for Linux, and it does run on the PowerPC. Almost. The "Free Pascal" package doesn't install on Ubuntu 16.04, and I'm not the only one to experience problems. It also appears that Free Pascal is the only Pascal compiler for Linux. Therefore, Pascal is out.

With no option for Pascal, I'm choosing Go as the language. (In full disclosure, I must admit that I tried very little to resolve the problem with Free Pascal. Maybe I wanted to use Go all along, and the install failure was enough to push me to Go.)

The BASIC that wouldn't die

I started a project several years ago: write a BASIC interpreter. Not Visual Basic, but the old-school interpreted Beginner's All-Purpose Symbolic Instruction Code, with '10 PRINT "HELLO"' BASIC.

My real purpose was to learn the Ruby language. It was a good choice: the BASIC interpreter was complex enough to provide a challenge, yet not so complicated as to be daunting. I learned a lot about Ruby, and I also learned a lot about BASIC.

Writing a BASIC interpreter is not the easiest thing in the world. Writing an interpreter for any (serious) language is a non-trivial task (and yes, I do consider BASIC to be a serious language). I used several vintage books to help me: Kemeny and Kurtz' "The BASIC Programming Language", Coan's "Basic BASIC", Tracton's "57 Practical Programs and Games in BASIC", and Dave Ahl's "101 BASIC Computer Games". All of these (except for Tracton) predate Microsoft's dominant variant of BASIC.

We think little now about language variation. Before Microsoft's BASIC became the standard, there were different implementations of BASIC from different companies. DEC, HP, GE, and others created BASIC for their hardware, and each was unique. Differences ranged from simple appearances (a LIST of a program would left-pad line numbers with zeros, or not) to syntax (subscripted variables use parentheses, unless they use the now more traditional square brackets) to execution features (in one version, FOR/NEXT loops leave the index set to one beyond the terminal value). Early versions of BASIC also had statements that Microsoft dropped, such as the MAT statements and multi-statement user-defined functions.

I added many of the variants into my interpreter, using command-line switches to enable or disable specific behaviors.

I also added to the language and the interpreter. I added a set of ARR statements ('ARR' for 'array') which correspond to the MAT statements for matrices. In the interpreter, I added a profiler and a cross-reference output. I have seen neither of these in BASIC, and I wanted them.

Now, with not one but two versions of the interpreter near completion, I find myself looking for a new project. I'm considering a compiler for BASIC. Seriously. My inspiration is the old CBASIC compiler and the UCSD p-System. Both compiled code to an intermediate byte-code (or p-code) that was executed by a runtime environment, much like Java and .NET programs of today.

My idea is a simple compiler, one that generates assembly language for a fictitious processor. An assembler will convert that code into bytecode, and a runtime system will execute the bytecode.

The compiler can be as simple as an extension to the existing interpreter. I should be able to run the interpreter, load a program, and then type a command (probably 'COMPILE') and write the pseudo assembly code to a file. After that, a separate program can assemble the code and create the bytecode file. Finally, a run-time system (or an interpreter) can execute the bytecode.

So I have convinced myself that this new endeavor is worthwhile, and I will work on it as time permits.

BASIC just won't die!

This Week I Learned...

This week I learned that Visual Studio 2015 provides timing information when stepping through code in the debugger. We previously used Visual Studio 2010 which did not provide such information.

This week I learned how to configure a Python-based web app service in Azure to handle multiple routes. (The right magic must be put in the web.3.4.config file.)

Data tools pay for themselves over time

Several years ago I worked on a project that required we pick apart Excel .XLS files at the byte level. We didn't use Microsoft's COM components to read the file. We didn't use a third-party library. We read the file (in C++ and in binary mode) and did exactly what Microsoft recommends we do not do: we parsed the file ourselves.

As part of this effort, I built a small utility to "dump" the contents of an Excel file. The common programs extract cell values, but I wanted something more detailed. I wanted a list of the various BIFF records in the file. (Microsoft Excel .XLS files consist of a series of binary records, each record describing some aspect of the contents. Each record contains a type field, a length field, and a set of fields that depends on the type of record, and some fields have a variable size. It's a compact and powerful format.)

The utility program (called "DumpXls", cleverly enough) was useful to identify the different records needed to construct a proper .XLS file. It took some time to create, time that turned out to be an investment.

It was a useful investment, because this past week I had a problem with the Python 'xlwt' library. (The 'xlwt' library lets Python create an .XLS file.) My old "DumpXls" utility helped me diagnose the problem and find a solution... and quickly. The time spent creating that program years ago was more than made up by the time saved in finding this week's problem.

The "dump" program was simple, yet it required a good understanding of the file format. When working with a new file format, it helps one understand the format to build such a "dump" program. The program is useful, as is the knowledge of the format.

Success with Ruby and BASIC

A while back, I started a project to learn Ruby. The project was to implement a version of BASIC, using that as a means to learn the Ruby language.

I am happy with my progress. I've learned a great deal about Ruby -- and learned more about programming. Ruby has a different "take" on programming than C++, Java, and C#, and those differences forced me to re-think a lot of ideas about programming. The design patterns for Ruby are different from the patterns of the "classical" object-oriented languages. I found that much of my code followed the classic patterns, and it worked poorly. Only after I changed my thinking about programming and my designs in Ruby did my code "work".

Rubocop helped too. It complained about many things, from spacing around operators (or lack thereof) to the number of lines and complexity of functions. At first I thought that some long functions would have to remain long -- in C++ or Java I would leave them as long functions. But with Rubocop's prodding, I redesigned them and made them smaller, many times breaking them into smaller functions.

i started using Rubocop after a significant amount of code had been written, and Rubocop reported somewhere north of 80 "violations". Over time, with thought and experimentation, I have reduced that number to one. The changes have, I believe, improved the code and made it more reliable and more readable.

My success has been due to the design of the Ruby language, the Rubocop tool, the Ruby documentation pages, and StackOverflow. These made it easy to develop in Ruby. Yet there were two other things: an open mind and time. I needed to change my thinking about programming, and accept the Ruby way of code. I also needed time. Time to think about the code, time to try things, and time to revise my initial code into something better.

Impressed with Python

I've been impressed with Python of late.

I'm using Python on a project for a client. The work involves computations with data in Microsoft Excel spreadsheets. Processing involves, at a basic level, the extraction of data from a spreadsheet, some calculations, and then the generation of a result spreadsheet (different from the first spreadsheet).

Python has been surprisingly useful here. The libraries 'xlrd' and 'xlwt' handle the reading and writing of data in spreadsheets, allowing me to focus on the computations.

Python has helped in other ways. It runs a lot of our tests, and summarizes the test results. It also drives the tests of an old MFC Windows application.

This last item is important. We had no way to test the GUI for this program -- other than manual testing. The 'PyWinAuto' package lets us use Python to "drive" the GUI and run tests.

I am impressed with PyWinAuto. Perhaps more impressed than others; some years ago I created a library (in C++, not Python) to drive MFC GUI programs. The task was not trivial and my attempt was clunky and inadequate. Yet it was that foray into Windows API calls and Windows controls that gives me the appreciation for the effort of PyWinAuto.

Over the years, I have worked with many languages: BASIC, Pascal, Fortran, C, C++, Java, Perl, C#, and even a little COBOL. My experiences with each language vary. Some were fun, others were frustrating. Python is in the former category, as I have been able to do just about everything I wanted, and with little effort.

Backups - rsync and Google cloud storage

I've been using Google's cloud storage for backups, and I am impressed with what I have found.

My previous method was to use rsync and store backups on a local server. It works, although the local server is old -- and a bit small. Eventually, I would need a larger disc.

Google's cloud services remove that problem.

Synchronizing with the Google store is, interestingly, faster than the synchronization with the local server. The first time was longer, of course, as the Google gs_utils package had to transfer every file to the cloud. But after that first transfer, successive synchronizations have been must faster.

Google cloud services aren't free. But for pennies a month (literally), I can have backups that are accessible anywhere I have a network connection.

New old equipment: Apple Powerbook G4

A friend provided me with an old Apple PowerBook G4. It's been sitting on the shelf for a while, staring at me. I decided to do something about it.

Examination showed that the unit was in good shape, except the keyboard. No scratches or dents, or other signs of abuse. But the keyboard was not firmly attached to the underlying layer -- the top two rows of keys had rolled away and were floating in air. This position is not untenable, but it does mean that the key hinges would come loose. More troubling is the missing keys for F1, F2, and F12.

Super-glue helped get the keyboard back in line, although the result is not perfect. The edges are still up a bit, so the ESC and F11, F12, and EJECT keys are floating up. And F1, F2, and F12 are still missing. But its workable.

The unit needed a power adapter, so that was the next order of business. It had to be -- i could not test anything else without it. So off to the good folks at macbookadapter.com! They provided me with a genuine Apple PowerBook adapter with the proper plug.

Testing showed that it would not boot from the hard drive. I could boot from a CD-ROM, and I used Ubuntu 12.10 for the PowerPC. Ubuntu came up and found the video card and the network adapter, but it could not install on the hard drive.

On the assumption that the drive had failed, I ordered a replacement. Finding drives for a PowerBook G4 is a little tricky, as it uses IDE (or PATA) drives, not the SATA drives in today's laptops. Persistence paid off, and I found a nice little 40 GB drive for $20.

Installation of the drive was challenging but not impossible. Opening the G4 requires removing quite a few small screws (about 20) all but two being Phillips head, the other two required a hex key. Carefully lifting the keyboard tray reveals the innards.

Removing the old drive was simple, once I recognized that a small bracket held the drive in place. Remove two screws, lift out the old drive, unscrew the four mounting screws, screw them into the new drive, and attach the cable and insert into its position.

Then replace the keyboard tray and its 20-odd screws.

Now for an operating system. I could install Mac OS X 10.4 (Tiger). I have a copy, and it is the latest version of Mac OS X that supported the PowerBook series. But Apple ceased supporting 10.4 quite some time ago, and the old software and Safari provided a poor experience. Also, modern software for Mac OS X doesn't want to install on 10.4. So I needed something else, and I chose Ubuntu.

The PowerBook G4 uses a PowerPC CPU, not an Intel chip. Therefore, the standard (Intel) issue of Ubuntu won't do. I needed the PowerPC version, which is available. Ubuntu PowerPC 12.10 is the last version that has an install that fits on a CD, so that was the one I selected.

Ubuntu installed without difficulty, but needed some assistance. It found drivers for video, Ethernet, and touchpad, but not for wifi. Those had to be installed from the legacy broadcom package.

There is a later version of Ubuntu (14.10 LTS) but it cannot talk to the video card. (I tried the upgrade and it failed, leaving Ubuntu in an inconsistent state. I re-installed 12.10 and left it there.)

The experience, so far, is tolerable but not excellent. The Apple PowerBook G4 has a nice 15" screen but is heavy, and it runs a bit warm. The screen is bright and clear but Ubuntu doesn't recognize the brightness controls (F9 and F10, if the keys are to be believed).

Ubuntu 12.10 LTS for PowerPC has Firefox (version 39) but not Chrome.

Performance is sluggish. Web pages load, but I guess I've been spoiled by newer computers. Yet it's a nice machine, one I'd like to use more.

Projects and technologies

Credit subsidy calculator: Develop a replacement for the existing C++ Windows desktop application. The new version will be written in C#/.NET and will run as a web service. There is a small command-line executable that will be distributed to agencies for them to use the web service.

We expect a release of the old (C++) version in September and again in November. We may, depending on progress, see a test release of the new (C#/.NET) version in November.

Interest model and Sensitivity model: Improve and modernize the code of these two interrelated applications, preparing for conversion from C++ to C#/.NET. These may remain Windows desktop applications; unlike the Credit subsidy calculation, the Interest Model and Sensitivity Model are used by a very limited number of people.

The models are used prior to the preparation of the budget and the preparation of the mid-session review. There are a number of changes for the Sensitivity model's calculations that must be made in September.

We have a number of technical issues with these projects (mostly with the new version of the Credit subsidy calculator). The issues appear to be resolvable with the right amount of time, research, and testing.

I have upgraded my home PC (which I use for remote access) to Windows 10. I have successfully connected to the office with Windows 10 and the new Edge browser. Performance is about the same as with Windows 8 and Internet Explorer.

 

Building a BASIC interpreter in Ruby

I've been working on a side project: Build a BASIC interpreter in Ruby. The purpose is to help me learn the Ruby language, and to that end the project has worked well.

Learning a new programming language can be difficult. It's easy enough to write a simple "Hello, world!" program, but that simply confirms that the compiler (or interpreter) is installed correctly. What does one do next?

I picked the BASIC interpreter as a task with some complexity, but not too much. The BASIC language gives me a challenge but not one that is insurmountable. Also, I have an early text on programming in BASIC that provides example programs with their expected outputs.

As a bonus, programming a BASIC interpreter is a stroll down memory lane. BASIC was the first programming language that I learned. It is an old friend, one I have not seen in quite some time.

So as a project, the BASIC interpreter is challenging, supported, and fun.

I spell BASIC in all capitals because of the variant I am implementing. The BASIC language had a number of variants over time, from the early Dartmouth implementation in the 1960s to the DEC versions of the 1970s and 1980s, culminating in Visual Basic 6 from Microsoft. (Or perhaps VB.NET, but that seems less BASIC than any of the variants.)

My project is to implement an early version, one that is close to Dartmouth BASIC. It has a simplicity about it, yet it also has its intricacies. Dartmouth BASIC allows one to specify user-defined functions, but only on one line and only with a very limited set of names ('FNA' through 'FNZ'). It supports some elements of structured programming but still allows GOTO statements, and one can 'GOTO' from the inside of a loop to the outside, do some work, and 'GOTO' back into the loop. (One can also 'GOTO' out of a loop and not return into the loop.)

Early version or late, my experience has been a good one. I have been forced to learn the Ruby language. While I am not an expert, I am at least comfortable with the major constructs and classes of the language. And that was the point.

Cloud9, part 3.

More work with Cloud9. I did not intend to write multiple posts. Yet here I am.

I'm getting more impressed with Cloud9 (the proper spelling does not have a space) and I am getting more impressed with Python. (Cloud9 lets one use Python, Javascript, Ruby, or plain HTML/CSS.)

My project is in Python, and this weekend I was struggling with a problem in the webapp2 framework. The problem was not in the framework, but in my use of it. Having the source for the webapp2 framework and the Paste and WebOb packages made it possible for me to find my mistake and fix it. Such investigation would not have been possible with a language like C+ or Java.

Python's debugger was not helpful in tracking down this problem. It may be due to my unfamiliarity with 'pdb', or it may be caused by the use of multiple threads. I had to fall back to 'debug by printf()' to find my problem. Once I saw the actual values of certain variables, I knew the solution.

I'm getting familiar with Cloud9. It is an IDE that runs in the browser, which means I can access it from anywhere. That's a nice feature; I don't want to drag my files around with me. (It also allows for better collaboration among team members, a feature I have yet to try.)

Cloud9 copies a lot of the features from regular, PC-based IDEs, but it has its own style. I find it easier to use than Eclipse, which I have tried to use several times. Cloud9 sits on top of Linux, and it provides bash and terminal windows to your virtual machine. Anything you cannot do in the IDE you can do in a terminal -- but I've resorted to it only once or twice.

Cloud 9, part 2

After several months of ignoring Cloud9 (the web-based collaborative IDE) I sat down today and did something with it. Today's task was to build a cloud app that was compatible with Google's App Engine. And after a few hours, I did just that.

Cloud 9 supports several languages: JavaScript, Python, Ruby, and PHP. I picked Python, as I have experience with Google's App Engine (GAE) and Python.

To build a Python app for GAE, one needs the webapp2 framework. Webapp2 handles the inbound and outbound web requests. Cloud9 supplies a number of libraries for Python, but webapp2 is not one of them. Not a problem, however, as one can quickly install it with the 'easy_install' utility, which *is* included. (The webapp2 website has the instructions, and a sample program.)

Getting the webapp2 sample to run took some doing. (In my opinion, their sample is almost correct byt not quite correct.. I had to import the 'os' module and enclose parameters to the 'getenv()' function in quotes.

I found the documentation for Cloud9 useful -- once I found the right page. The Cloud9 web site has poor indexing into their support pages. Finding the right page is difficult -- until you switch to Google.

Problems were not limited to the Cloud9 website. Google Chrome failed as well, often displaying its "aw, snap!" page, forcing me to re-load the Cloud9 website (not a small site, due to JavaScript).

Overall, my experience was a bit frustrating, yet successful. Cloud9 may not have perfect documentation, but the IDE itself seems workable.

Cloud 9 web-based IDE

I registered with Cloud 9 for their web-based IDE. I've been looking for a web-based IDE for some time (half-heartedly at best, though). A recent article on either ComputerWorld or InfoWorld pointed me to several.

I'm impressed with the capabilities of Cloud 9. Once you create a profile, you can create projects, edit code, and run your programs. Cloud 9 supports many languages and web frameworks. It also lets you connect other services but exposing your tests to the internet. Perhaps an arrangement not without risks, but necessary for other web-based services like Jenkins.

Cloud 9 has a free level and a premium level. The free level works for individuals; the premium level is suited for teams and supports collaboration among members.

JSFiddler

I've been looking at several new technologies, including JavaScript. I have some ideas for single page applications (SPAs) and JavaScript is a necessity.

Searches for specific techniques quickly led to the site jsfiddle.net, a web site that lets one create, store, and publish "fiddles", small sets of JavaScript code.

I was impressed with the site. The user interface is elegant and flexible. It supports oodles of JavaScript libraries. It cleanly separates HTML, JavaScript, and CSS while allowing you to edit any of them.

Tools like jsfiddle.net are powering the accelerated development of web applications.

Yesterday I registered and created my first fiddle.

Early warning for the end of the contract

My contract was extended, yet I received a taste of the true end of the contract.

The contracting company uses a web site to report hours. They entered the initial (un-extended) termination date of the contract (October 5th) and did not update it when the contract was extended. After the 5th, the web site refused to let me enter hours. (Actually, it refused to let me sign on at all, which is another issue. I would expect the ability to sign in and review hours.)

A few e-mails to the right people got the problem solved. But it did get me thinking: what will I do when the contract ends? What would I do if the contract were to end early?

The opportunity was a welcome one. It forced me to evaluate my situation, which I think is pretty good.

• I have some savings, so I can live without a paycheck for some time
• My expenses are predictable and steady
• I have a good set of contacts in the technical and recruiting worlds
• I have a set of marketable skills

I can ponder the situation and I know that I can cope with it. That's a good place to be.

And a lesson: When the end of the contract approaches, reach out to people and ensure that everyone has the same understanding.

CMAP meeting: ASP.NET MVC4

I attended the CMAP (Central Maryland Association of .NET Professionals) tonight. The topic was "ASP.NET MVC4", a new version of Microsoft's web development framework.

Impressions of the meeting: Well attended. Every chair in the room was filled, with more attendees than planned. There were more attendees than the 'after meeting survey' forms, yet enough pizza for all attendees (at least those who desired pizza). It's nice to see interest in technical knowledge.

Impressions of the tech: This new version has some nice features. I'm not qualified to list them; I don't work with earlier versions and cannot compare them. Yet the tech follows in Microsoft's tradition of Visual Studio tools: wizards to built 'empty' projects (with varying degrees of non-emptiness) and a steep learning curve to accomplish anything meaningful. The .NET framework is large. It does a lot, and it demands a lot. The biggest challenge is knowing the classes available; even the presenter tonight stumbled on some class names. (A case of knowing that classes to perform specific chores do exist, but not remembering the name.)

Pennsylvania Renaissance Faire 2012

Sometimes the best way to build one's knowledge of the craft is to get away from the craft. And the best way to rejuvenate is to walk away from the marketing and "always on" thinking and to relax.

Which is what I did this weekend. Instead of updating my resume or curating my LinkedIn profile, I met up with friends and visited the Pennsylvania Renaissance Faire. It was a splendid day, with nice weather and good companionship. Ren faires are always entertaining, with a variety of shows, merchandise, and activities. We walked around and took in the sights, chatting with people as we went.

I returned home energized and relaxed at the same time.