Mid-Coast Preschool Services Development Screening Interview

Child's Name: Matthew Rasmussen Age 4yrs 4 mo. Date Dec 6, 1984

Four Years

Social:

1. How much does your child do for himself in dressing and washing up?

[X] Unbuttons and buttons clothing

[X] Washes hands and face

[X] Toilet trained day and night

[X] Cares for self at toilet mostly

2. How much does your child do for himself in eating?

[X] Spreads with knife soft things

3. Describe how he/she plays with children. gets upset w/ younger children interfering

[X] Understands taking turns/sharing

[X] Group play (2-3 children)

Gross Motor:

1. What does your child do when playing outside? Pretend play – Boats, Little puppy or Sandbox

[ ] Bounces and catches large ball -no

[ ] Pedals tricycle turning corners no – big wheel too large – snow on ground now

[X] Runs and climbs

[X] Hops on one foot

Fine Motor:

1. What does your child do with paper and pencil?

[X] Copies +

[X] Copies []

2. What kinds of toys does your child play with?

[X] Imitates bridge

[ ] Completes 6 piece puzzle

[X] Builds tower of 10 blocks

[X] Cuts with scissors

Mid-Coast Preschool Services

Developmental Screening Interview

Four years

Page 2

Language/Concepts:

1. How much does your child talk? very verbal

2. Can you give me an example of the kind of sentence he/she uses? Noah and Ethan are my very best friends

3. How well is he understood by others? very well

[X] Relates experiences, describes activities

[X] Names 3 Primary colors

[X] Says most sounds except r s th and l

[X] Repeats nursery rhyme or song for others

[X] Understood by strangers

Carolyn Rasmussen

Interviewer

Cloaking Blosxom

The correct form of a URL is where/what, as a web address exists to organize content. By default, Blosxom serves pages from www.spacetoast.net/cgi-bin/blosxom.cgi, a machine-centric where/how address which breaks the above guideline. A method was needed to disguise the address of the cgi script.

Blosxom’s main site includes instructions for hiding the …cgi-bin/blosxom.cgi address on an Apache server by means of an .htaccess file — a local preferences file. Unfortunately, the instructions did not work for this site.

The first method given for cloaking Blosxom (bullet three, step two) redirected requests for any address in the STP directory to Blosxom, including images, media files and old pages. For this site, it would have been written thusly:

RewriteEngine on

RewriteRule ^STP/?(.*)$ /cgi-bin/blosxom.cgi/$1

The second given method (bullet three) invoked Blosxom only if a real file could not be found. It had problems with directories. Since STP/web/blosxom/ is a real directory, Blosxom did not attempt to create a page there, defaulting to either listing the files in the directory or producing a missing/forbidden error. Here is how it would have appeared:

RewriteCond %{REQUEST_FILENAME} !-f

RewriteCond %{REQUEST_FILENAME} !-d

RewriteRule ^STP/?(.*)$ blosxom.cgi/$1 [L,QSA]

Venerable Apache Server’s developers are a strange, thundering race who produce suitably impenetrable documentation, but after some levelling up the following was arrived at:

Options +Indexes

RewriteEngine on

RewriteCond %{REQUEST_FILENAME} !-f

RewriteRule ^STP(.*) http://www.spacetoast.net/cgi-bin/blosxom.cgi$1

Here is a breakdown. The first line overrides Laughing Squid’s default error when trying to browse a directory without an index file. The second turns the URL rewriting engine on. The third tells it when to work — in this case, when a file can not be found. (Notice that the missing directory line is now gone.) The fourth line tells Apache to remove “STP” and send the remainder of the address to the blosxom.cgi script.

This portion of the Blosxom installation took far more geekery than it should have. Strictly speaking though, it is optional.

Why Blosxom?

I’d been meaning to add blog software to my site for some time, and of all the content management systems I looked into, Blosxom seemed to best suite my prejudices:

  • Free and open source
  • Small and easy on the server
  • No annoying .php pages, as discussed in this rant
  • No database — nothing to yell at me if I make changes with FTP
  • Plugins to add missing features

With Blosxom now up and running, I can report that it delivers all of the above, at the cost of the following:

  • Missing, out of date and incomplete documentation
  • Missing, out of date and incomplete plugins

Blosxom is ancient in web terms, buoyed along by its simplicity of design. The original site is no longer updated, and while the current developers have mirrored the site to SourceForge, they appear to have done little to update it. Newer plugins can be found offsite, without documentation or generally even descriptions of what they do. Plugins listed on the conserved original site are often dead links; mirrors of the plugin code can usually be googled, but any documentation not included in the code itself is often gone. Blosxom has only basic functionality without plugins.

It is (apparently) possible for an artist with only a modest technical background to install, configure and use Blosxom. The core blosxom.cgi script is bulletproof, and the original installation instructions are quite good. Setup is minimal, and there are no dependancies. An understanding of Perl is not required.

Plugins can be another matter. Many of the plugin problems fall under a recurrent fallacy of open source: “It’s free, so I can be lazy.” Certain plugins expect the user to be a Perl hacker, which is counter to the philosophy behind the software. Others omit documentation, or are abandoned with features incomplete. Blosxom’s stop-and-go development over the years has not helped the problem. More on the plugins used on the Space Toast Pages will follow, after some notes on basic installation and the problem of “cloaking” the cgi-bin URLs.

Notes on Installing Blosxom

Blosxom’s official installation instructions are concise and straightforward. Installation required only a standard FTP client and a text editor. (I used JEdit with the FTP plugin installed.) The blosxom.cgi script ran as soon as it was installed; SpaceToast.net’s ISP, Laughing Squid, did not require it to be “blessed” first.

Configuration was straightforward. The settings are stored in the script itself. Many settings can be left at the defaults.

Fitting the Space Toast Pages’ existing layout into the Blosxom engine was equally straightforward. An old Space Toast Page was sliced into three “flavor” files, the head.html, story.html and foot.html files, with Blosxom markup tags added where dynamic content should be placed. (An additional date.html flavor file is required. On the Space Toast Pages it is an empty file, as date stamps are part of the story template.)

Blosxom stores posts as plain text files in the “data directory” and serves them as html files or rss feeds from the “blog directory.” The Space Toast Pages keep everything in SpaceToast.net/stp. Surprisingly, this doesn’t cause a problem. Any of the posts on the Space Toast Pages can be accessed as raw text files by simply substituting .txt for .html in the address bar. The text file is a real file sitting on SpaceToast.net; the html file is a fake created by Blosxom when it’s requested. An .htaccess file makes the ephemeral page look real — more on that in the next post on cgi cloaking.

STP Relaunched

The Space Toast Page has become the Space Toast Pages, a “journal of journals” on Rasmussen’s various obsessions and experiments. The weekly issue format has been discarded in favor of a categorized, feed-friendly, commentable series of blogs and sub-blogs running on the free and open source Blosxom content management system. Thank you as always for reading, and welcome back!

Build Notes: Tape Case Bike Light

Issue 177, for the week of 8/27/2006.

Toast Note: Happy birthday to my sister Becky, who is celebrating in India. Wow. That is way cooler than a Cuisinart.

Boring Preface: Massachusetts state law requires a bike to have a forward light while riding at night. Commuting home on the city’s lit streets, I’m less worried about seeing the road than about other people seeing me. The cheapest bike lights seem to run about $20, so I’ll make that the maximum budget for this project. The light needs to be easy to attach and remove, durable enough to throw into a shoulder bag, and easy to turn on and off. I’d also like it to double as a flashlight the next time a transformer blows up in Central Square.

Theory: The front reflector seems to be the most logical place to attach the light to the bike, though I don’t want to obscure the reflector itself. It should be possible to build a bike light inside an old audiocassette case using two AA batteries, a pack of magnets, and a bright white LED upgrade for a mini Maglite. The light would clip around the bike’s front reflector. This project should cost less than $20.

Get:

  • An audio tape case
  • A three-LED upgrade kit for a mini Maglite
  • Eight (8) round 3/4″ ceramic magnets
  • Two (2) AA batteries
  • Some thin insulated wire
  • A few scraps of aluminum foil
  • Electrical tape
  • A small tube of super glue
  • A pair of needle-nosed pliers
  • A utility knife
  • A ruler or measuring tape
  • Space to work

Make sure that the cassette case isn’t one of the newer “slim” cases, but the regular kind. The mini Maglite upgrade kits consist of a replacement reflector housing three bright white LEDs wired into a resistor correctly sized for two AA batteries. They retail for about $11. You could certainly use your own LEDs (I read that Christmas lights are a cheap way to get them) but I don’t know nearly enough of a damn about electricity to figure out what size resistor to use — just that I need one to keep from blowing the LEDs out. Three-quarter inch ceramic (black) magnets usually come in packs of eight at the hardware or hobby store, and go for about $1.25. They’re fun to play with. If you don’t have a little spool of insulated wire lying around the house, I guarantee you have a broken stereo in the basement you can pillage. Utility knives seem to have been renamed “box cutters” since I was a kid, but I refuse to let the terrorists win.

Step A: Measure the width of your front reflector. These instructions are written for a reflector about 2 and 1/8 inches wide. From what I can tell from a cursory look around Porter Square, this kind is fairly common. Some of the newer bikes have smaller reflectors (why?), which should work fine for our project. A larger reflector would require a larger case — maybe a VHS-C tape case. Everything jams in pretty snugly with this design as is, so if your reflector is a different size you’ll have to play jazz a bit.

Step 1: Take the tape and label out of your audiocassette case and throw them away. Your crappy Sony deck hasn’t worked for most of a decade now anyway.

Step 2: Cut/snap the two prongs out of the tape case.

Step 3: Measure the width of the bracket on the back of your reflector — the part that connects it to the bike. Mine is 3/4 of an inch wide. The metal piece will probably be a little bit narrower than the part it screws into. If it is, just take the wider of the two measurements. Like I said, mine seems to be a pretty standard part, so if your reflector is the same size as mine it’s also probably 3/4 of an inch wide at the bracket too.

Step 4: Cut a notch, using that measurement, in the back of the tape case. The reflector and bracket together are too thick for the case to snap shut around, so we’ll need the bracket to hang out the back. Be careful to center your cut. Cut from the bottom of the case up to about even with the overhang. Mark your cut lightly with a straight edge or ruler, then go over it repeatedly until you cut all the way through. A little bit of splintering around the cut is normal, just don’t be so impatient that you crack the case. Did I mention it might be a good idea to put a new blade in your knife for this project? It might be a good idea to put a new blade in your knife for this project. Before now.

Step 5: Wrap electrical tape around all three sides of the cut. This will cover up the shattery bits, keep any cracks from spreading, and give it a nice rubberized mounting around the bike reflector bracket. Cut away the excess.

Step 6: Grab two of the ceramic magnets. We’re going to be gluing them on either side of the cut, about even with the overhang. These will be to rest against the back of the reflector, hopefully keeping it from moving too much. One by one — and with the other magnets clear — put a good bead of super glue on one of the two magnets, press it into place and hold it there for about a minute.

Step 7: Stick a piece of electrical tape along the entire length of the bottom of the case, folded over lengthwise. Half of it should be stuck to the outside of the case, and half to the inside, with the tape stuck to itself where it crosses the notch we cut. This will keep the bottom from wobbling by holding it tightly against the metal bracket. The electrical tape is a little bit stretchy, which is good. Anyone going for extra credit here might try sticking a rubber elastic inside the tape for extra holding power.

Step 8: Open the LED upgrade kit. You’ll find a little black cup with the LEDs inside and two wires sticking straight out the back, surrounded by a silver reflector.

Step 9: Remove the reflector; the LEDs are bright and directional enough without it, and it’s too thick to fit inside our tape case.

Step 10: Bend the two wires on the back to either side, being careful not to rush and snap them. I don’t really know how much abuse they’ll take, and I don’t want to find out.

Step 11: Cut four pieces of wire: three long ones (maybe 4-5 inches apiece?) and one short one (1-2 inches long).

Step 12: Strip each of the wires half an inch in from both ends. If you’ve never stripped wires with pliers before, it’s easy: Go around the wire worrying the plastic insulation with your pliers’ cutters. Don’t squeeze hard enough to actually cut the wire. The plastic cuts more easily than the metal inside. Begin pulling the wire as you continue weakening the insulation. Look for strong places, and keep pulling the wire and worrying at the insulation. Eventually, the plastic will begin to slide off the wire. Yank it off, and give the wire a twist or two.

Step 13: Take two of your longer pieces of wire. Make a little loop in the stripped portion on one side. Slide this loop around one of the wires on the back of the LED cup. Twist it a few more times, and squish it all together to get a good electrical connection. Repeat, looping the second wire to the cup’s other connection. If you want now, you can solder the wires permanently together — but I hate soldering, and I don’t want to pretend this project requires it. Either way, finish by sticking a square of electrical tape on the back of the cup.

Step 14: Slide the LED cup up under the lip of the cassette case, facing outward. Feel free to glue it in place, but it’s a pretty tight fit — I say don’t bother.

Step 15: Since LEDs only allow current to flow through them in one direction, we’ll need to figure out which side is + and which is -. Hold the wires against either end of one of the AA batteries. If it lights up (cool!) make a note of which side is which. If not, reverse and retry. (If nothing lights up, redo those connections.)

Step 16: Tear off two pieces of electrical tape, each about twice the length of a battery. Lay each strip of tape face up on the table and center the batteries on them. We’re going to be taping the wires directly to the batteries. It’s easy to do, and with the LEDs we won’t have to change the batteries much anyway.

Step 17: Tear off two small scraps of aluminum foil. Stick the wire from one end of the LED cup to the electrical tape beneath the battery contact, and then put a scrap of foil on top of it. Wrap the tape around the battery contact. Repeat for the other wire and the other battery. Wrap the tape around the battery contact. The aluminum foil is here to give us a larger electrical contact. Aluminum foil is conductive.

Step 18: Tear off two more scraps of aluminum foil. Using the same procedure as the last step, stick the short wire to the other end of one of the batteries. Grab a ceramic magnet and the other scrap of aluminum foil. Tape the loose end of the short wire to the top of the magnet, with part of the foil sticking out. Fold the foil over the top of the magnet.

Step 19: Tear off a larger scrap of aluminum foil and wrap it completely around one of the remaining magnets. This will be our “switch.”

Step 20: As in step 18, tape the remaining long wire to another of the magnets, with a piece of foil folded over to make an electrical contact. Let it stick itself to the “switch” magnet.

Step 21: Just like in step 17, connect the loose end of the wire to the remaining battery contact. The LED should light up. If it doesn’t, troubleshoot: We should have a circuit going from the LEDs to the first battery, through the bottom magnet, through the foil on the “switch,” through the second battery, back into the LEDs. Make sure your +’s and -‘s are all going in the right direction. Redo the foil/wire connections with more foil. If it did work, great job.

Step 22: Notice something. When you pull the “switch” magnet out of the stack and replace it with a bare magnet, the LEDs don’t light up. Ceramic magnets aren’t conductive. When the “switch” is in place, the circuit is on. When there’s a bare magnet there instead, it’s off. Leave the bare magnet in the stack between the two wired magnets. Stack the “switch” and the two remaining magnets with the “switch” in between. We should have two stacks of three magnets, which you’ll notice are about the same depth as the tape case.

Step 23: Push the two batteries tightly into the top right and left hand corners of the tape case so that they’re square with the edge.

Step 24: Place the stacks of magnets at the lower inside corners of the batteries. Experiment with closing the tape case. Find the position where the stacks are as close to the lower right and left hand corners of the case as possible, but the case can still close without hitting the magnet stacks or the batteries. We want everything to fit snugly.

Step 25: Once you’ve found the ideal positions, put a generous bead of super glue on top of each magnet stack and close the case. Hold the case shut as tightly as possible for about a minute, to make sure the super glue sets up properly with the top of the case.

Step 26: Flip the case over and repeat step 25, gluing the bottom of the magnet stacks to the bottom of the case.

Step 27: Once you’ve given the super glue some time to set up, flip the case back over and reopen it. Since we had to cut that notch in the back of the case, the back is the weak point: pull evenly on both sides to reopen.

Step 28: The trouble with ceramic magnets is that they don’t like sticking to anything more than they like sticking to themselves. To add strength, encircle each of the glued magnets with another bead of super glue. Let it set up, and cut away the excess if it gets on anything else.

Step 29: Tape the loose wires out of the way. You’re done. Swap the “switch” with the other loose magnet (storing the loose magnet on the other stack) place it around your bike reflector and let it snap shut. You’ve got a light on your bike — a bright one at that, which doesn’t strobe, pops on and off easily, and won’t chew through batteries every couple weeks.

Criticisms: Despite being built in a plastic case, the light is far from waterproof. I wouldn’t even call it terribly splashproof. Silly as it would look, a sandwich bag over the top might not be the worst idea on a rainy day. Opening the light takes some learning, as you figure out how to evenly pull on both sides of the case’s back. The biggest problem I’ve encountered, though, is the one mentioned in step 28: ceramic magnets just don’t like to glue down. Step 28 was an afterthought, after I had to reglue one of the stacks. It’s certainly stronger with an additional bead running around the base of the magnets, but I’m starting to think a gel epoxy (nasty as that stuff is) might eventually be needed.

Final Thoughts: It works, weirdly enough. Assuming you already have things like pliers, electrical tape and a set of batteries, you should have no trouble beating the $20 budget. (If not, they’re good things to own.) Please enjoy your antiluxury good. Build one? Send me a picture.

If you liked this project, you may also dig the previous Build Notes: Junk Mail Blinds.

[Click here for a printable version — or just turn stylesheets off.]

SGV Artillery Game: Proof of Concept

Issue 173, for the week of 7/2/2006.

Toast Note: What with the site redesign (now complete), three concurrent jobs, and a bad summer cold, the Space Toast Page has been a bit neglected lately. Still, I have a treat for you this week. Thanks for waiting.

(If the above opens as plain text, save it to the desktop and drag the file onto your browser.)

This is a proof of concept for a tile-based artillery game using Scalable Vector Graphics (SVG) and JavaScript. SVG was meant to be an open, plugin-free alternative to Flash, but it was a relative failure. To date, only FireFox and Opera 9 fully support the SVG specifications, with Safari’s support still incomplete, and no native support in Internet Explorer. Adobe has released an SVG viewer plugin for most web browsers, but Adobe’s implementation is not fully compatible with standard SVG. Still, the Safari development team is making fast progress, and Google is reported to be working on a translator for Internet Explorer, so SVG may yet see a true dawn.

To date, the game has only been tested in FireFox 1.5 for Mac and Safari 2.0.4. It is buggy, but runs in FireFox. Safari will draw the initial game state, but does not loop.

The game runs at a resolution of 700×500 pixels. In a window smaller than that, FireFox creates scrollbars, which trap the arrow keys. I don’t know a way around this yet. It should be possible to make the game scale up or down to the size of the window automatically, as SVG is resolution-independent, but that may require redoing the artwork and JavaScript to use percentage measurements, rather than pixel measurements.

The game artwork was created in Inkscape, an open-source project which is making great strides toward creating an alternative to Adobe Illustrator. As of version 0.44, Inkscape is not suitable for directly editing graphics in an interactive SVG file. It has a tendency both to mangle JavaScript and to revert custom group names to generic ones. Additionally, Inkscape’s method of saving object attributes like color and stroke width is to bundle them into one long style element (i.e. style="fill:#574736;fill-opacity:1stroke-width:0;stroke-opacity:1") rather than splitting them into individual elements, which are easier to access with JavaScript. The Inkscape team’s progress remains impressive.

My biggest concern is speed. The game currently maintains its frame rate by idling for 10 milliseconds between loops, although I think I’ve come up with a better way to do it — please refer to the JavaScript’s comments. Although I doubt that FireFox’s SVG drawing routines are tuned for game speeds, my biggest worry is the speed of JavaScript execution. Some parts of the script store game data in JavaScript variables, others assign it to the game’s SVG objects — as whim desired, really. The latter seems to be considered more “correct,” in terms of modern programmers’ fetish for object-based programming, but I’m all but convinced it’s terminally slower than the former. Accessing elements (manipulating the DOM) is also an absolute pain in the ass in JavaScript. For both reasons, I suggest doing it as little as possible.

As near as I can tell, this is the most advanced SVG game anyone has written to date — which is sad, but telling. Owing to uneven support, sluggish speed and lack of an integrated development environment, I can’t see SVG supplanting Flash any time soon. Still, SVG is not without potential. Enjoy the game.

Further Reading:

With some previous JavaScript experience, it took me about a week of spare time to get this far. The following sources and examples were invaluable.