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.
Sunday, February 26, 2012
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.
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!)
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!
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.
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!)
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.
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.
Subscribe to:
Posts (Atom)
