Skip navigation


I thought I bookmarked this a long time ago – apparently I didn’t.

O’Reilly’s Test-Driven Development with Python (by Harry Percival) is still available to read online at the O’Reilly Atlas site (formerly O’Reilly’s Chimera Labs, if I remember correctly and if the URL is any guide).

Percival’s book was made available to read for free courtesy of O’Reilly’s Open Source Convention (a.k.a. OSCON). Since my budget is currently limited, I’m very happy for the opportunity to read this book without having to buy it (or keep checking it out of the library).

Finding Remote Desktop users connected to a Windows server using PowerShell

(without using the RemoteDesktopServices cmdlet – script uses WINSTA.EXE instead.

From Business Insider: The Best Websites To Find Freelance Work.

I had a post on a similar topic three years ago – Websites for Finding Design and Programming Jobs. Some of the sites in that post were for regular full-time jobs, but at least half of the sites included freelance jobs. Of course, there are a couple of sites that are on both lists.

The sites from the Business Insider story are:

  1. Upwork (formerly oDesk, which was on the earlier list)
  2. Toptal
  3. Elance (also on the 2012 list)
  4. Freelancer
  5. Craigslist
  6. Guru (also on the 2012 list)
  7. 99designs
  8. Peopleperhour (also on the 2012 list)
  9. Freelance Writing Gigs
  10. Demand Media
  11. College Recruiter
  12. GetACoder (also on the 2012 list)
  13. iFreelance
  14. Project4hire
  15. SimplyHired

And just like in my 2012 post, I’m not linking to the sites that Business Insider compiled. Instead, I encourage you to check out the Business Insider post for yourself to get capsule reviews of the sites, as well as direct links.

The first programming I ever did was on an HP programmable calculator with a 49-step program memory. Despite the limit, I was able to program the classic “Lunar Lander” and artillery games.

Ever since then, I’ve had an abiding interest in writing efficient programs and (when the Internet came along) websites. For a while, I was out of step with the industry, as fast PCs and broadband connections made the search for efficiency seem almost quaint.

But the Wheel turns, and everything old is new again. In particular, as mobile phone data plans have gone from unlimited 3G to metered 4G connections, there is a renewed need to get the most design bang for the least bandwidth buck.

Responsive Web Design (RWD) often relies on Javascript libraries to provide the best browsing experience available at a given screen size, but these Javascript libraries (which have to be transmitted to the end-user’s device in order to work their magic) can be quite large.

Filament Group (a web design firm based in Boston, MA) posted about some tips and tricks to “…make RWD sites load fast as heck“.

Well, I say “tips and tricks”. What I mean is “seriously technical hacks and optimizations.”

Filament Group’s approach boils down to “embed as much CSS and Javascript in the HTML to make the page as usable as possible while not exceeding 14kb for the compressed page.”

Simply stated, but difficult in practice. In particular, the hacking needed to get the necessary CSS and especially Javascript into the <HEAD> of the page warms the cockles of my old HP25-programming heart.

I just discovered that RubyConf 2015 will be just down the road in San Antonio, a short drive away. (see what you miss when you don’t attend user group meetings?!)

A short article about the programming learning process via Viking Code School’s blog:

Why Learning to code is So Damn Hard

I’ve just started reading it, but already I like this quote from Quincy Larson at Free Code Camp:

… was convinced that the seemingly normal programmers I ran into were actually sociopaths who had experienced, then repressed, the trauma of learning to code.

PowerShell originally started as a project called “Monad” within Microsoft.

The original Monad Manifesto[PDF] was written by Jeffrey Snover back in August 2002.

BTW, one of the major influences on Monad was a paper by John Ousterhaut:
Scripting: HigherLevel Programming for the 21st Century[PDF]

It’s interesting to read Snover’s original manifesto and see how much of the original vision made it into PowerShell (and how much didn’t).

(originally posted at

There comes a time in every programmer’s life when s/he has to strike out on his/her own, writing new code (instead of typing in examples from books / websites). That time has come now for me with regards to PowerShell.

But first, I have to set up my working environment.

Here at work, we have a common (i.e., shared) network directory on our Production resource server. There were no PowerShell utilities in the directory (probably because I think I’m the first person to do anything serious with PowerShell here, with the possible exception of the IT guys – and they don’t use the Production resource server).

However, it occurred to me that that common directory (call it N:\common\utils, because that’s not its name) would be a good place to put modules meant to be shared.

How do I tell PowerShell to look for modules there, without having to specify this every time I start PowerShell?

For now, I just:

  1. created a PS subdirectory in N:\common\utils (PS for PowerShell, of course)
  2. Started PowerShell on my PC and created a profile file in the $profile directory (per Recipe 1.6 from the Windows PowerShell Cookbook):
    New-Item -type file -force $profile
  3. edited the profile file using Notepad.exe:
    notepad $profile
  4. and added a line to add the common directory to the PSModulePath environment variable:
    $env:PSModulePath += “;N:\common\utils\PS”
    (the leading semicolon is the profile path separator)
  5. exited notepad, saving $profile on the way out.

Now, whenever I start PowerShell, the $profile runs and adds the PS shared folder to the module search path.

To do the same thing (less step 1) for the Windows PowerShell ISE, I consulted Microsoft Technet article How to Use Profiles in Windows PowerShell ISE, which suggests wrapping the New-Item in step 2 in an if statement to prevent overwriting an existing profile, and using the ISE to edit the resulting profile file:

  1. (PS subdirectory already created in N:\common\utils)
  2. Started the PowerShell ISE and created a profile file in $profile:
    if (!(test-path $profile)) {New-Item -type file -path $profile -force}
  3. edited the profile file (using the ISE editor):
    psEdit $profile
  4. and added the same line to add the common directory to PSModulePath:
    $env:PSModulePath += “;N:\common\utils\PS”
  5. then closed the ISE editor tab, saving the ISE $profile file on the way out

Now I just have to figure out modules and module manifests…

(originally posted at

A lot of our Production Quality Control (QC) operations where I work require checking that data has been uploaded to one of our websites, using either one of our internal tools, or our backdoor access to one of our customer-facing sites. This is all right when we’re checking a couple of customer jobs, but gets tedious VERY quickly for routine QC of dozens or hundreds of customer jobs.

A web app works well as a manual tool (“enter text to be searched for in this box, click Search, click the link for desired item in the list of items matching your search term…”), but our internal tools and customer-facing sites were never designed to be scripted.

For a while, when I was working with more cross-platform scripting languages, I was looking at Selenium. Selenium allows you to control popular web browsers from a number of programming languages, including Python, Ruby, and C# – but not directly from PowerShell. It would be possible to write my own PowerShell wrapper for C# to control Selenium, but I don’t have any experience extending PowerShell with C#, and since we’re not a C# shop, I think that would be very fragile from a long-term maintenance standpoint.

Anyway, unlike the typical Selenium application, our Production QC ops aren’t testing a single web app across multiple browsers. We’re searching for a multitude of data items, but we only have to find each one once, in a single web browser. A more robust solution would be to use something more native to PowerShell to control a single browser – which could even be Internet Explorer (perish the thought!).

I Googled “powershell web browser automation” and came up with a number of possibilities.

Web UI Automation with Windows PowerShell, is an MSDN article from 2008 and talks about using COM to control Internet Explorer, which is something I’ve dabbled in using VB Script. My first experiment with the method wasn’t successful, though, so I looked for troubleshooting info for COM in my handy copy of Windows PowerShell in Action. As it happens, the book illustrates COM with an example of “…a COM-based tool to help manage…browser windows,” so the book probably offers a more fertile field for further research.

A post on StackOverflow then led me to WatiN – Web Application Testing in .Net. WatiN allows control of Internet Explorer AND Firefox, so it might be even better than using COM.

(originally posted at