Wednesday, October 10, 2012

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.

Tuesday, October 2, 2012

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.)

Sunday, September 30, 2012

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.

Wednesday, August 8, 2012

Dropping meetings -- or, making choices

When I took this leap from the safe employer position into contracting, I built my network of contacts in part by attending meetings of technical professionals.

I am now in a position to evaluate those meetings, and I have chosen to drop some of them.

The local Baltimore Linux user group was an easy one to drop. The group has seen a decline in its membership (or at least attendance at meetings) and they may be shutting down. The causes of the decline are two: poor leadership in the group, and a reduced need for assistance with Linux.

The latter is particularly problematic. When Linux was a strange new thing that required expertise, a user group made sense. Members could support each other and share information. Today's Linux distros are quite good at detecting hardware and correcting problems. (And there is the world-wide-web for information.) A user group must be based on more than sharing technical knowledge for a popular operating system.

The not-so-local Linux user group (a separate group from the local Linux user group) is also on the "drop" list. Not due to declining membership or low value; this user group has good leadership, provides informative speakers, and maintains an active membership. My cause to depart is a pragmatic one: they have moved their meetings and the new location is farther than I prefer to travel. I had to play games with the car, staging it at a different train station in the morning, to attend. Now even that does not allow me to attend in time.

The third group that I am dropping is the cloud computing group. I am sorry to stop attending; they had good presentations and interesting members. Their old location was in Virginia but near a metro stop. The new location is further out in Virginia and far away from metro stops.

Letting go of these user groups gives me time in three evenings every month. I plan to use that time in other user groups, preferably ones closer to home.

Tuesday, April 10, 2012

I finally see Windows 8 in action

I attended the CMAP meeting tonight. The presentation was on Windows 8 and Metro. It was good to see the new version of Windows live -- up to now I have only read about it.

Windows 8 is a compromise between classic Windows and the new world of touch/swipe apps. I'm not sure that "compromise" is the right word -- it seems to be two distinct things bound with duct tape. The new Windows Metro UI is quite attractive and very different from the classic UI. Windows 8's classic UI is close to Windows 7's UI; only the "Start" button is absent. Switching between the two modes is abrupt and not always expected.

The push for Metro and a touch-screen interface shows the success of Apple and its iPhone and iPad products. I'm sure that Microsoft had a plan for touchscreen devices and interfaces (the "Surface" technologies) and has accelerated and changed that plan to meet the competition.

Most disturbing with the new Metro UI (and its underlying WinRT API) is the loss of lots of tools and packages. Flash is not available, nor is Silverlight. Developer tools such as Entity Frameworks are not available.

Lots of Windows fans are upset -- and I understand. A lot of their hard-won knowledge has been invalidated with Windows 8 and Metro. While the classic side of Windows 8 still allows for these technologies, one can clearly see that their lifetime is limited. (And therefore the lifetime of the knowledge is limited.)

Yet there is no escape. Microsoft is just as trapped on this treadmill of evolving technology. We are all running as fast as we can to stay in place.

Sunday, April 8, 2012

Why BYOD will encourage companies to the cloud

A number of companies have adopted "bring your own devices" policies, allowing employees to bring their own computing devices to the office and use those devices for work. The policies have been applauded by some (generally the libertarians of the office who see freedom and the accountants of the office who see reduced corporate expenditures for equipment). "Bring your own devices" policies are generally criticized by the security and infrastructure support teams: one cannot lock down an employee's device to the same extent as company-owned equipment, and the larger number of devices is harder to configure for corporate use.

There is another aspect of "bring your own devices" policies, one that I see few people discussing. That aspect is the tie-in with cloud computing.

With a "bring your own devices" policy, the employer-employee relationship changes. With the tradition "company supplies all equipment" rules, the company owned all data and all equipment that held the data. Employees may be assigned computers, but the understanding was that the computer belonged to the company. A company could re-assign a computer, take it off-line for maintenance, and install upon it any software it wished. When an employee moved from one position to another, or from one department to another, or left the company, the equipment (and therefore the data stored on that equipment) stayed behind.

The rules for "bring your own devices" change that situation. When employees bring their own devices, the devices are their property, not the company's. The company cannot re-assign the device. When an employee is transferred from one department to another, or when they end their employment, their devices follow them -- they do not stay with the department or the company.

So what happens to the data stored on that device?

I suppose that some companies will implement policies that insist upon the deletion of data in such instances. They might be difficult to enforce, especially with less-than-friendly terminations of employment.

A better solution is to not store data on the device. Instead, store company data on company servers, and allow employees access to that data. When an employee moves from one department to another, change their access to allow for the new department's data (and remove access to the old department's data). If an employee leaves the organization, rescind their access.

I find this a more secure solution.

Cloud computing seems a natural fit for this solution. Small apps that allow access to data (but do not store the data locally) will let employees get the work done while maintaining the security of the data.

Perhaps "cloud" is not quite the proper solution here, since one may not need the scalability of cloud computing. Perhaps a better description would be "server-stored data and app-based access". But that's quite a mouthful and who would ever want to say all of that?

Regardless of what you call your solution, look at storing data on corporate servers and allowing access through "outside" (non-corporate-owned) devices. I expect that the division of labor will provide you with insight into the work being done within your company.

Friday, April 6, 2012

A day of telework

This week I had the opportunity to telework, or as it is often called, "work from home". It was one day out of the week.

My experience with telework was, overall, positive. I was able to connect to the systems in the office (I keep wanting to use the phrase "dial in", but there is no dialing involved) and run the needed programs.

My chair at home is much less comfortable that the chair in the office. I found that had to stand and stretch every thirty minutes, somewhat more frequently than when I am in the office.

My monitor at home is smaller (in terms of resolution) than the monitors in the office. The remote-access programs run in a browser and assume that your display is as large as the displays in the office. When they are smaller (as mine is) you get scroll bars. The programs I used (Microsoft Visual Studio, the DOS command prompt, and MS-Outlook) wanted windows larger than my home monitor. I could resize them, but only the DOS prompt resized gracefully. Outlook and Visual Studio are designed for large displays, and I found myself scrolling.

Performance was acceptable. My work involves little in the way of graphic manipulation; almost everything I do is in text mode.

I expect telework to be a rare occurrence. Should it become frequent, I will invest in a better monitor and chair.

Tuesday, April 3, 2012

An infinite loop, and success with BASIC

Today I wrote a program. In BASIC. It had an infinite loop. By accident.

I think that the last time I wrote a BASIC program with an infinite loop (accidental or otherwise) was in the 1980s. (Probably the early 1980s.)

The program was a "Celcius to Fahrenheit" table generator. It was easy enough to write (I do remember BASIC) and it revealed some defects in the BASIC-1965 interpreter. One was in the parsing of arithmetic expressions and the other was in the computation of arithmetic expressions. The parsing was easily fixed, once identified. (I had the wrong logic for precedence of operators.) The calculation of an expression was a bit trickier; Ruby (the language that runs the BASIC interpreter) uses two types for numbers: Float and Integer. My math worked for the add, subtract, and multiple operations; I had to adjust the divide operation to return either a Float or an Integer.

After resolving the problems, my BASIC program works as expected. Woot! Today counts as the day that my first "real" program ran successfully.

Sunday, April 1, 2012

Harrisburg Barcamp

I attended Harrisburg Barcamp this week-end. A good choice: it had a lot of creative people and good discussions throughout.

Book-ending the conference (technically an un-conference) were train rides. I departed work early and took the train from Washington to Harrisburg (via Philadelphia) on Friday night, stayed over at the local Holiday Inn, and arrived at the conference refreshed. I departed the conference early Saturday evening, reversing the train trip from Harrisburg to Philadelphia and then on to Baltimore.

I find that travelling by train lets me relax and also lets me get work done. I took the opportunity to catch up on some reading. (I can read on planes, although the seats are smaller and the arrangement is cramped. Reading while driving is not recommended.)

The barcamp topic was "tech and ed"; our sessions were light on the education aspect but not overly heavy on the technical side. One session was about virtual presentations, another was on careers and networking, and a third was on preparing for the next ten years of technical change.

I held a session on "is tech changing too quickly for our own good", and it had a number of attendees with good ideas. I held it as a conversation and not a lecture, and that format worked.

I'm glad that I attended. Its good to get away from "the usual suspects" and talk with other people.

Wednesday, March 28, 2012

One thing a day: programming in Ruby

These past two days saw me programming in Ruby on the BASIC-1965 project. I added functionality to the program and added tests. The tests were the more useful of the two; they verified functionality that I had added for IF/THEN statements. (And revealed some defects.)

The functionality that I added was the ability to use text constants in PRINT statements. They seem simple, yet they require some thought for the program. Ruby made the addition easy -- easier that I expected -- and I am happy with the result.

The "one thing a day" idea seems to be working. With it, I can commit to one simple idea per day, one limited task that I can accomplish as an "extra" to the day's work.

Sunday, March 25, 2012

Ubuntu Server

I installed Ubuntu Server on an old Dell PC this week-end. (This was Saturday's "One Thing a Day" task.)

My first attempt, using a CD burned last year, failed due to errors in the on-disc packages. Writable CDs have a finite shelf life, and my combination of CD burner and CD media (and CD storage techniques) sets that life to something less than a year. I will have to remember that when I use CDs as back-up media.

My second attempt was successful.

I'm pleased that the install CD has the logic to check the integrity of each and every package that it installs. Not only does the install program check as it installs, the main menu has an option to check the entire disc in advance. This is a nice feature and shows the commitment of the Ubuntu team to a quality experience.

The installation of Ubuntu ran pretty much on its own, with a few questions for me: my full name, my account name, and the host name. (And a few questions about keyboard type and timezone.)

After the install, I had more work. I wanted to assign the PC a static IP address; the Ubuntu install configures it for DHCP (easy enough to change in /etc/network/interfaces). I installed the rsync program and configured it to be a server (some research as I am new to rsync and new to xinetd). I still have tests with rsync to run. Yet in the end, it was a good experience.

I now have a PC running Ubuntu server; I plan to server storage from it and keep back-up copies of files.

Wednesday, March 21, 2012

Postgres

Today's one big thing a day: Attend PHP meetup. (Includes presentation on Postgres and conversation with like-minded geeks.) Quite a good "thing of the day". Side conversations included area conferences, job opportunities, and projects with old tech.

Tuesday, March 20, 2012

One big thing a day

With a full-time job, I have little time to work on the career. What to do? I try and complete one big thing each day.

Yesterday I signed up with dropbox.com and installed the synchronization software on all (except two) computers. The sign-up was easier than I expected. Using the software is easier than I expected. All in all, a win!

Today I changed the scripts for BASIC-1965. I now have a 'master' script that runs all tests, and tests scripts for specific cases. I have one test case. It is a small accomplishment, but getting the 'master' script in place is an accomplishment: I can easily extend it with more test cases.

Thursday, March 15, 2012

App Engine and goals for BASIC-1965

I attended the Capital Cloud user group meeting tonight. The talk was on Google's App Engine, and it was a decent talk. But as usual, the best part of the meeting was talking with other folks. I chatted with a few and had the opportunity to explain cloud computing (at least my "take" on it) to some non-developers.

In other news, I have a specific goal for the BASIC-1965 interpreter. I've been working on this interpreter for several weeks now, on and off. (Mostly off.) My general goal is to implement an interpreter that will conform to the description in Kemeny and Kurtz's book "BASIC PROGRAMMING" from 1967. But better than a general goal, I thought of a specific goal. A specific goal is a good thing for me; it gives me a definite target.

My specific goal: write a program (in BASIC) that will print a Fahrenheit-to-Celcius conversion chart.

The goal may sound trivial, yet I find it appropriate. Such an exercise was common in the early BASIC texts, and it is within the capabilities of the (quite limited) language of BASIC-1965.

So now all I need is some time!

Monday, March 12, 2012

Ruby vs. C#

I've been working with C# on the day job and Ruby on a side project. Shifting between the two has been enlightening.

C# is a statically typed language; Ruby is dynamically typed. I have come to rely on statically typed definitions, so I am a decent coder in C#.

I find that the coding experience in Ruby is quite different. I cannot rely on the IDE to tell me when I have assigned an improper value - in Ruby one can assign anything to any variable. It is easy to forget the type of variable and assign the wrong thing; I find out only at runtime, usually with an error of "undefined  method (methodname) for (classname)".

To get things right in Ruby, I must be more disciplined in my thoughts and in my programming. I'm not sure that this is a bad thing... I'm also not sure that this is a good thing. At the moment, I know only that it is a different way to program.

Friday, March 9, 2012

.NET and Ruby

This week I attended the local CMAP meeting, with its presentation on SQL in Azure. I learned a lot; SQL in Azure is different from SQL in the server room due to the "can move at any time" aspect of cloud computing. The differences are not particularly large, but can be significant (especially if you have built your system around one of the server room idiosyncrasies).

The CMAP meetings are consistently good for networking. They draw a sizable collection of people, and the attendees have varied projects and talent. I always have interesting conversations at them, and this month's meeting was no exception.

Later in the week I worked on my side project of BASIC-1965, an interpreter for BASIC written in Ruby. It's a fun project and a learning experience. Ruby has a different approach to programming, and my Java- and C#-trained brain is making mistakes as a learn "the Ruby way".

Sunday, February 26, 2012

Barcamp, Balticon, and github

I made travel arrangements for Barcamp in Harrisburg. (Barcamp in Baltimore seems to be... dormant.) The Harrisburg Barcamp should be fun! At least the travel will be fun, as I can go by train.

I also registered for Balticon, the science fiction convention. (It runs just north of Baltimore every Memorial Day weekend.) Balticon has sessions for science fiction, hard science, and writers, which leads to an interesting mix of attendees. I always find clever people and interesting conversations.

This weekend I posted my first project to github. (github is a "clearinghouse" for git-based projects, allowing others to access them.) It was easier than I expected, which was a pleasant surprise. I don't know that "powerful" is the right word to describe github, but they are well-positioned for the sharing of software. I'm not sure about the word "leveraged" either. Perhaps "well-positioned" is the right phrase.


Wednesday, February 22, 2012

Better than FORTRAN

Sniffles and sneezes kept me home. I spent most of the day resting. Yet I had a little time to build an interpreter for the original BASIC language, and I learned a lot.

Writing an interpreter (or a compiler) forces one to learn the language. All of the language, not just the convenient bits. My exercise forced me to learn about BASIC and think like the original designers of the language.

I looked at the original BASIC, also called "Dartmouth BASIC". It is a simpler version of the Visual Basic we know today. There is a limited command set and variable names are much shorter.

I implemented a fraction of Dartmouth BASIC. I'm calling my implementation "BASIC-1965", in reference to the year in which I think it would have been initially implemented. It is Dartmouth BASIC without the matrix operations and constraints on the use of expressions. In Dartmouth BASIC, expressions may appear in LET, PRINT, FOR, and IF statements; in my version, expressions are restricted to the LET command. (That may change in the near future.)

Another change is the position of DATA statements. In the original BASIC, DATA statements may appear anywhere. In my "BASIC-1965", DATA statements are truly interpreted and must appear prior to the corresponding READ statements. (The fact that DATA statements could appear at the bottom of the program always bothered me.)

My implementation is in Ruby, which performs a lot of the "heavy lifting". Ruby has data containers and regular expressions, both of which made the task easy.

I can see how BASIC was better than FORTRAN: no FORMAT statements, no worries about integer or floating point variables, and interaction with the computer. It *was* a significant increase in usability.

Saturday, February 11, 2012

Various tech of the week

This was a fun week with varied tech. I worked on several projects, bouncing from one to the other as time allowed (and as questions were answered).

C++: I found and fixed one problem, which lead to a number of changes to the output. Some were obvious and expected, others were not. I traced the execution to identify the path from our change to the modified output. Visual Studio is quite good at debugging and examining values, yet I had to supplement it with custom-written logging routines. (The amount of data was larger than I could hold in my head, and some values are hidden from the debugger.)

C#: This was refactoring code to break classes into separate but corresponding 'mutable' and 'immutable' classes. The mutable classes become builder classes (such as ClassNameBuilder) and the immutable classes retained the original name. The division into two classes helps organize the code, and also reduces class size. A win all around, I think.

PDF: Format PDF files and add bookmarks. Perhaps not programming -- I'm not parsing or generating the raw PostScript or PDF files -- yet it was a fun diversion.

Perl and HTML: This was a fun, short task. We had to extract text from an HTML file, adjust the text, and then format the text back into HTML (albeit a different set of HTML). Perl's HTML::Parser class did the heavy lifting of extracting the text, and then it was simple to adjust and re-HTML-ize the text.

Ruby and GraphViz: I was back at the "web site links vizualizer" this week, enhancing the program and fixing some problems. It now grabs the web site files, extracts the links, and builds a GraphViz script for rendering into an image. (GraphViz supports multiple image formats, and we can pick whichever we desire.) Ruby's 'openuri' and 'hpricot' packages helped here, handling the parsing of HTML. (There are lots of HTML parsers available; perhaps I will never have to parse HTML again!)

Sunday, January 29, 2012

A tool to help understand web pages

With a little Ruby, a little GNU, and some reading, I built a small utility to help me understand web pages.

The utility takes the HTML, picks out the links, and draws a map of the web site. It shows which pages link to other pages. (It works only for static pages, not dynamic ones.) The result is a PostScript image with pages listed and arrows connecting the pages.

I can use this to navigate web pages and get a view from a height. I can also find 'orphan' web pages, pages that are not linked.

I used a lot of off-the-shelf components: Ruby and its built-in functions for parsing HTML, GNU sort, and GraphViz. The components do the heavy lifting, and save me a lot of time.

It was a good exercise. I learned a lot, and now I have a useful tool!

Saturday, January 28, 2012

Three years

It was three years ago that I started this part of my journey. I left the comfort of a secure position in a large company and struck out in search of new opportunities. At the time, I knew that it was risky, and that it was either a smart thing to do or a very foolish thing to do.

Looking back, the evidence leans towards the "smart" side. I have acquired a position with a smaller company, and the pay is a little less than before, yet I have met knew people, broadened my view of the technology world, and learned a lot about tech and myself. I am more in touch with the local technology and creative scene. I have a better appreciation for project management and corporate management. I have shed some arrogance and improved my interpersonal skills.

Looking forward, I am positioned for the coming changes in technology. Mobile computing, cloud-based processing, new languages, big data, and user experience will all change the way we build programs. The old ways of project management won't carry us through the changes. (Yet they are not obsolete. The previous techniques for project management are still useful; they are not enough on their own.)

I'm looking forward to the next chapters.

Saturday, January 21, 2012

CreateBaltimore

I invested time at the CreateBaltimore un-conference today. This was a meeting of folks in Baltimore who consider themselves creative, and who want to help improve the city and the state of its inhabitants. It's a good arrangement: people self-select themselves in, so the attendees are all interested in problems and solutions. (It's also a casual and not glamorous event, so there is no incentive for fame-seekers to attend.)

The conference started late, due to inclement weather, but it still allowed for a long session (from 10:00 to 17:00) for conference sessions and informal conversations. It was an excellent way to meet folks in the area, folks who want to make a change. (And a few were looking for developers!)

Wednesday, January 11, 2012

A group meeting about git

Tonight's CALUG meeting had a presentation on 'git', the version control package. (I am starting to think of software in terms of "packages". Probably an influence of Linux.)

I like git. I find it easy to use. Yet I think it has a ways to go. A few years ago, I would have thought that git (with its GUI tools) was a sufficient product. Today, after the "tablet revolution", I feel differently.

Tablet computers have raised the bar for a typical application. Now I expect that an application installs quickly, configures itself (except for a user ID, password, and possibly an update frequency), and handles everything through a simple graphical interface. (Not the command line, and not a complicated multi-dialog interface.)

I believe that the folks working on git can improve it and make it "first class".

I will point out that other version control systems have similar challenges. Microsoft's TFS has a good user interface, but requires lots of configuration. Subversion and CVS need bolted-on graphic front ends which work -- more or less -- and they also need a lot of configuring.

Someone will figure out version control, really figure it out, and then we will have the "iPod of version control". I think that git is in the best position to achieve that goal.

Sunday, January 8, 2012

Apache and PHP

I configured Apache and PHP today, and converted a web page from plain HTML to PHP format. With these changes, we can create templates for web pages and slug in the content that we want. (That's the whole point of PHP.) Separating the content from the HTML will make it easier to update the web page, since we can replace the content file and leave the HTML in place.

Saturday, January 7, 2012

Changing servers at the new year

I'm changing my server configuration at home. These changes will support my efforts with local organizations and their web sites.

I installed Ubuntu Linux Server on //ophelia (an old Dell Optiplex GX280). This install was quite simple, with a no-nonsense approach and few questions. I picked SSH, LAMP, NFS, Samba, and printer server options. It doesn't include NTP, so I will have add it later.

My goal is to make //ophelia my main server, hosting my "alternate home" directory and serving web pages. Certainly not the configuration that a real shop would use, but acceptable for my needs.

Tuesday, January 3, 2012

Refactoring for fun and profit

I have been working on the "convert C++ to C#" project for several months, and this week I have achieved the "factor out code to objects" level. It has been a long, long wait, as I converted code and divided the poorly-organized C++ into better-organized (although not perfect) C# code.

Today I was ready to refactor code into smaller classes. I had the code converted to C#, and tests to ensure that refactoring would change no functionality, and I was looking at the code... and the changes just came to me. It was a no-brainer, an obvious operation. I was able to separate three sections of code into distinct classes -- but the last class needs a bit of work, given the (ugly) API that it requires. But I am even happy with that, since the API is obviously ugly and a sure sign that a better design is waiting.