Sunday, June 28, 2015

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.

Sunday, January 18, 2015

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.

Saturday, January 10, 2015

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.

Sunday, August 24, 2014

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.

Sunday, July 27, 2014


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, 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 are powering the accelerated development of web applications.

Yesterday I registered and created my first fiddle.

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