|
|
|
reflection on software reflection
Tuesday, January 26 2016
There's that site in Los Angeles for which I have become the defacto administrator, and it's been plagued with occasional hacks aimed at securing credit card information. For this reason, I have a script running on the web server that emails me and the other developers whenever files are added, deleted, or edited within a few select directories. At around 6:20am this morning, the script sent me an email telling me that the shopping cart controller had been altered. Sure enough, the credit card thief had returned and installed code to capture information from a form. I immediately notified my contact at the company, and spent much of the day figuring out what to do next. It's looking like one of the accounts on the web server is compromised, but logging for SFTP had been off, so it's unclear how the attack was launched. Though there has been communication between the company and jargon-spouting "security experts" on things like code review and PCI compliance, my feeling now is that really what needs to happen is that all the SSH passwords need to be changed.
For my daily dose of physical exercise, I returned to the remains of that Chestnut Oak I'd salvaged three pieces from yesterday and managed to salvage three more pieces (and there was still a crappy piece left over) for a load that came to 101.0 pounds. The weather has become warmer than usual for this time of year, meaning my typical backpack loads are providing significantly more fuel per day than I burn. This has led to a good accumulation of wood in the indoor firewood rack, which can hold as much as 1000 pounds. Right now, it looks to be contain somewhere between 700 and 800 pounds. This would be a great thing to have on hand should a big snow storm blow through, but for now, the weather forecast is calling for rain, and then only at around February 1st. It would be best to avoid salvaging wood after a soaking winter rain, but the absence of lingering snow on the ground will mean that I will be able to resume salvaging at my normal rate almost immediately. (If, on the other hand, temperatures were 20 degrees colder and I suddenly had to contend with two feet of snow on the ground, I might not be able to resume the carriage of 100+ pound loads until April.)
I should mention that the weather this winter has been unusually dry. There are the usual frozen puddles and the Chamomile itself is running at a modest trickle (as it normally does through the coldest part of the winter), but for the past couple days I've been able to go back to wearing Crocs (the kind with ventilation holes) on my salvaging missions instead of rubber boots. There would be nothing unusual about that in the four warmer seasons of the year, but something about winter seems to preserve mud if not ice. Checking the USDA Drought Monitor, I see that Ulster County and the rest of southeast New York State is considered "abnormally dry" (the least-severe category they display).
I haven't worked on my Arduino-based projects in awhile, and when I've been away from something like that for a month or two, it's hard to get back into the necessary mindset. Tonight I just wanted to head in that direction from a theoretical perspective instead of, say, opening up the IDE or plugging in my soldering iron. I have had it in my mind that perhaps I should build an Arduino library for my oft-used code that parses commands from a serial port and then executes functions. It's hard to make such code generic, so all my versions of it are modified copypasta, often including bits and pieces from unrelated projects (dating back all the way to its origin, in my solar controller). Ideally, to make such code generic, I would pass it a big complicated data structure that included the names of commands, the specifications of parameters, and the names of functions (or methods) to be called. Initially I thought perhaps I could actually have the names of functions specified as strings, but after a little research, I discovered that this was impossible in C++, particularly on a Harvard-architecture processor such as an Atmega328, where there is a strict separation between code and data. The capability I was looking for here is called reflection, a term I might be more familiar with had I paid more attention during the computer science classes I took at Oberlin.
For most of my life, I've been spoiled by the delicious flexibility of the coding languages I use. In both PHP and Javascript, there's no limitation to treating code like data. Code can be bottled up in strings, stored in databases, manipulated programmatically, and executed in just about any context. Discovering these capabilities in the early 2000s opened my eyes to what was possible in software development. By comparison, the world of Microsoft ASP with VBScript (with which I worked professionally from 1998 to 2001) seemed limited and dull (even if it does include a function called eval() which can execute a string of program code).
My first experience with computer programming had been using CBM Basic on a Commodore VIC-20, and I remember an early project in which reflection would have been useful. I was maybe fifteen years old and writing code to calculate the area under the curve of an arbitrary function using Simpson's Rule (based on an algorithm I'd found on page 9-9 of Train-ing with your EC-4000 Programmable Calculator, copyright 1977). I wanted the program to be interactive and ask me to enter the function to be integrated as just another of the inputs it gathered on its way to producing an answer. But there was no way to type in a function as a string and have the computer later evaluate it. The function had to be a part of the program entered as part of the programming process. As I recall, my solution was to have the program print a hidden line number (in white on white) and then exit with the cursor blinking immediately after that line number. I would then type the function (in the form y=F(x)), hit return, and that function would then be part of the program. I forget now if I had a way to automatically start the program up again at the point in the code following the receipt of that information. I remember feeling proud of myself for having overcome this inherent limitation of CBM Basic, but I also remember feeling disappointed that such capabilities weren't built in. Perhaps, I'd thought, that's just the way it is with all programming languages. The recollection of having been forced through such hoops was part of what made the discovery of first limited reflection in ASP and then full & complete reflection in PHP and Javascript so delicious.
Tonight was news-heavy, starting with the Donald Trump's crazy announcement that he wouldn't be attending Thursday's Republican debate hosted by Fox News because of the lingering emotional damage resulting from the questions asked by Megyn Kelly the last time Fox News had hosted a debate. In the grand scheme of things, that story wasn't too interesting, so when the next big news story happened, that the FBI had managed to nab the leaders of the armed militants who'd taken over that wildlife refuge in Oregon, I was exasperated to find all my news sources still obsessing about Trump's fee-fees. I tried to find a live video stream about the militants' capture, but they all either kept dying or had little to offer beside unmoving shots of buildings or the electronic sounds made by cars when their doors are opened. By the time I went to bed, I'd learned that only one of the militants had been killed, which was a pretty low death toll considering the deathwishes those idiots had been spouting to anyone who would listen.
For linking purposes this article's URL is:
http://asecular.com/blog.php?160126 feedback
previous | next |
