Uncategorized – Page 2

Routines and Sub-Routines

Once again, started programming at an early age, developed certain habits. I don’t actually know where these habits came from. They might well have come from me getting fed up with writing a couple thousand lines of HTML to encompass all my various fan postings and whatever else I was working on at the time. I was fourteen, and it was probably X-Files related. The habits I am about to describe to you are not necessarily either best or worst practices, but they are my practices, and if you find them useful feel free to adopt them and work them into your own coding life and habits.

Commenting! I am assured by my mother, who has been programming for almost as long as I’ve been alive (as of this writing), that commenting your code is a good and helpful thing to do. Since people who are not me are now looking at my code I’ve toned down the editorializing a bit but you may still occasionally see an f-bomb in my code comments. A helpful comment both to Future You and to other people who may have reason to take a look at your code is one that concisely and clearly explains what the preceding line does. For preceding line you may also substitute preceding method, preceding block. You might also put a line of comment or three at the top of a file indicating what the file does. Basically, what I do is read over my code and after every couple sentences of saying “this code does this” I write a comment to that effect. This also helps by doing half your rubber duck debugging for you; you can read along with your comments and make sure that line, block, or piece of code does what you said it does. F-bombs and editorializing like “Once you put it in it stays in the act forever” are optional, just don’t put in so much of them that it crowds out the code and the useful comments.

Scrap files! The tricky part to scrap files is remembering what they were in the first place. In some projects I have only a file called “scrapcode.txt”, so it doesn’t interfere with the running of any of the parts of the project. I surround each portion of code I paste in there with something nice and eye catching, like a row of &’s or #’s, and label it. This might be “Capybara Doesn’t Like This”, or “Potential Method For Adding Object1 to Object2”; the purpose of the label is to remind me why this is there in the first place. This is a common theme in my habits, I need to be able to read, immediately, why this thing is here. Conciseness and clarity of language will come with time though.

Scrap files are useful because you might want to test out a different way to achieve a result, but you don’t want to lose the code. And you don’t necessarily want to paste it in a notepad or text file elsewhere on your computer, because what if your computer shuts down abruptly? Or what if you have to leave your desktop, you come back, you finish up what you were working on and start closing windows and come across this now orphaned text file with a bit of code in it? Did you need that? Did it serve its purpose? You may not remember! And this is vastly annoying, so I get around it (mostly) with a scrap file. I have to periodically go through it to discard pieces of code that have definitely served their purpose, but it helps keep it all in one place and relatively neat.

Dev Logs! Pretty much what it says on the tin. Having never worked as a programmer officially I can’t say if this is a required practice in most places or not, but as I’m working my way through school and the projects therein and thereof, I can say it’s very useful to me as a programmer and developer. It helps me both to figure out where I am in the process and what I’ve done, and also works as a larger medium in which to write down everything that’s happened in every version. For example, if I don’t want to write out everything I did on May 20th but I don’t want that git commit to go naked and uncommented, I can simply say “see dev log” and then I will know I wrote down an expanded list of updates, debugging, attempts or cleanups or whatever else I did.

Project Notes! This is different from dev logs mainly in that dev logs are for the day to day log of things, and that only. Project notes get cluttered enough on their own, it’s helpful to me to separate them into two files, usually md files at this point although in the past they were text files. In the old, pre 2nd millennium days. Project notes usually contain project objectives, stretch goals, if it’s an assigned project it will have the assignment requirements, if it’s an independent project I’m working on with other people it might have point of contact or contact information, it’ll have a Bug Hunt list (although if the whole thing gets to be too big, Bug Hunt definitely goes in its own file too) (we hope there aren’t that many bugs but it happens to everyone). It might also have links to specific pages that have documentation I know I’m going need later, or a rough text-based sketch of a project map.

Non computer related habits I try to get into include keeping a water bottle on my desk, taking a sip from it when I feel like it. It doesn’t have to be filled with water, obviously, but water is my drink of preference so I have a liter of it by my desk at all times. And it’s in a spout bottle because the last thing you want is to spill beverage all over your keyboard when you’re in the coding zone. In order to be kinder to my circulatory system I try to get up every time I get frustrated with my code, walk around the area or (since I’m working from home, I don’t advise this in an office setting unless they’re one of those places with ping pong tables in the work area that I’ve heard so much about) do some exercise, lift some free weights. Sometimes moving around and changing your visual perspective can also change your perspective on your code, jar something loose. Sometimes exercise increasing the blood flow can also increase the blood flow to the brain for a positive effect, and it doesn’t have to be anything a personal trainer would formally recognize as exercise. It could be putting on some music and dancing. Related to that, try not to code on an empty stomach. That doesn’t mean always be eating, but definitely remember when the last time you had a food was, and if it was more than five hours ago that’s too long. The brain runs on, among other things, glucose. Keep it topped up and it’ll be much more help to you.

These are most of the habits I’ve developed over the last We’re Not Going To Talk About It years of doing web scripting, programming, poking around in computer languages learning them for my own amusement. If you’re new to thinking about code and programming and creating things through computer logic, I encourage you to practice explaining your code to yourself and working on making it concise and clear. It doesn’t have to be in comments or any of the formats I discussed here! Being able to explain your code will help you understand the code, and will help you reassure yourself that you do understand it. Also, when you work in a team, it will help your teammates. If you’ve been doing this for a while, I hope you enjoyed my rambling descriptions of how my brain works regardless.

Tropiary

In retrospect it seems fitting that I picked novels and novel-writing as the subject matter for my Sinatra project, because I have a tendency to let my imagination run away with me in the process of writing fiction, and so too has the project.

In my other life, in my free time, I write fiction. Usually genre fiction but not always, often novels but not always, and I keep track of all these projects in a couple of different spreadsheets. I used this information to create three different models to use in my MVC application: a novel model, owned by a user and containing several different attributes as well as many character models, each of which has its own array of trope models. A trope, as used here, is a shorthanded narrative device that is repeated often enough to enter public reader or viewer consciousness, often tied to genres but not always. The frantic rush to make a last-minute love confession, usually at an airport or wedding, is a romance trope. The moment when the last heroes standing believe the monster is dead, only to have it rise up one last time, is a horror trope.

Originally I had it in mind to assign the relationships thusly: a novel has many characters, a character has many tropes, a novel has many tropes through characters, and tropes belong to characters while characters belong to novels. Halfway through writing this I remembered that the assignment was also to create a user class and apply sessions, login/logout functions, etc. Easily enough fixed, a user could have many novels.

Overall the project was refreshingly simple, despite the number of moving parts I had to shuffle around. Models, views, and controllers fall into the category of computer logic that I learned at a very young age: to put it into Logo terms a model is the turtle, the controller is the series of commands used to move the turtle and instruct the turtle to generate the content one wants, and views are the colors you can change the turtle. (I believe Logo is now taught in schools as MicroWorlds.) The application did not have to be this complicated to fulfill the requirements of the project, but I enjoyed expanding it to this degree both because I enjoyed the process and because the repetition reinforced the knowledge for me.

I will admit that towards the end of the project my ambition nearly got me. Once I had all the model interactions functioning properly in their controllers and the styling was done to my satisfaction I decided to add a description field and attribute to each model: Trope, Novel, and Character. The novel and character descriptions coded simply, but probably owing to a need to put the code down and go to bed I accidentally coded the patch action to receive input and code it all into the Trope class rather than a specific instance of the trope class. Suddenly, instead of adding a summary of the “There Was Only One Bed” comedy trope to its name, I had turned all of my tropes into that one. The irony of there now being Only One Trope kept me giggling while I found my error and fixed it. Lesson learned: after a certain point no matter how energized I am by my success at coding it’s time to go to sleep and finish it in the morning.

The main conclusion I drew from this project, apart from enjoying it thoroughly and being comforted that a career in web development is probably the right one for me, is that computer logic is a specific kind of sub-language unto itself. Knowing intuitively how the model-view-controller application works, how each part connects to the other and mainly getting hung up on issues of syntax is a skill set akin to being fluent in Spanish or Japanese. As such, it is varyingly difficult to learn but once you become fluent in it, it becomes much more comfortable to code and debug.

Just Another Really Very Intelligent Song Suggester

A staple of my music purchasing process is going onto Amazon and complaining about how their algorithm won’t suggest anything I want to listen to, and that Spotify is hardly better. This is equal parts exaggeration and truth: Spotify’s recommendations are usually good, Amazon’s are not great. Had I but world enough and time, I’d like to pull together a music search engine where you could cross-reference by not only artist or genre but also recording label or studio, instrumentation, composer, songwriter, possibly even tour roster.

However, this is a code camp project with a necessarily limited scope, I was working to outside-imposed objective rather than my own overly ambitious goals. The objective was this: write a CLI Ruby gem to interact with a user and deliver data scraped from a website or called via API (Application Programming Interface) based on the user’s specifications.

Even with a narrowed scope I started out trying somewhat more than I could do. I wrote up a CLI that greeted the user and asked for input based on a choice of music selectors, two of which (instrumentation and composer) were not, as it turned out, standard on Bandcamp album or artist sites. Alas. So my choices were down to search by artist or search by genre. At this point it probably could have been done by If-Else statements, but I’d started out with Case statements instead with the expectation that I’d have several criteria to present to a user to pick from, and I opted not to change that for no functional reason. Using Case statements would allow me to expand in the future if Bandcamp changed their formatting or if I decided to use other websites, or for other reasons was able to search by more criteria, so the Case statements stayed.

Bandcamp artist pages don’t necessarily have tags, but all of the album pages I visited did, so I prompted for an album and an artist. It may be expecting much of the user to have that information to hand these days, but if you’re sitting at a computer with CD in hand looking for similar music such a data gem could be helpful. With that information, reformated after input to provide the data gem with the correct Bandcamp URL to look for, the scrape could begin and present the user with a list of tags to choose from.

Alternatively, the user can opt to search by genre in a broader sense. Bandcamp also sorts their offerings into genres accessible via the search bar, and since their genres are a mixture of conventional music genres and newer, less conventional ones, I included a step between selecting a genre and receiving the list of artists where the user can view a definition of the genre they’re looking into. “Rock” music as a concept carries a definite expectation of a certain sound, “Ambient” or “Experimental” as labels are less clear.

In both branches of the decision tree the ultimate result is the same: a final scrape to pull artists from the Bandcamp landing page for that genre whether selected by broad category name or tag assigned to an album and present them to the user for further study. Future versions of the program might include choosing from the sub-genre tags or even scraping from a second site (Wikipedia, maybe) to find more information on that artist or band. Even further into the future I’d like to pull together a program that searches through YouTube Music, Amazon, Bandcamp, MySpace, Wikipedia, and other sites to present information to a user about an artist’s projects, a list of projects involving a specific instrument combination, a recording studio’s albums involving a specific sound mixer, or any equally arcane combination of factors. But for now, I’m satisfied with sorting through Bandcamp.

Hello world!

There are two wolves inside of me. One impressed early upon Sneakers. The other impressed early upon Hackers.

This is not where I expected to find myself at the beginning of the year. I don’t suppose many of us are where we expected to find ourselves from then to now. A month and a half ago I found out that the store I’d worked at for twelve years was finally closing down, owing primarily to recent events. A week before that my mother, who knows whereof she speaks, suggested that if the store closed down I should apply to a coding boot camp. I’d always loved working with and on computers, right? Three weeks ago, very roughly, I started at Flatiron School. And here I am.

Becoming a web developer is an interesting thing for me. My mother’s not wrong, is the funny part. I spent high school lunch periods shoveling food into my mouth and racing with my friends to the computer labs; we were all on BBS’s. I made fan pages for tv shows and books I was into at the time, hideous looking things with starkly patterned backgrounds on HTML v1, I tootled around and joined web rings. I did not commit the offense of marquee tags much. The graphics, on the other hand, were objectively hideous. But they were the best we had at the time, it was early days and we were all gleeful at the possibilities of the radical new technology. This was just before and into the earliest years of the dot com bubble. I wasn’t in a position to witness the September That Never Ended, but I remember hearing about it from those who were.

All of this was in no small part due to my even earlier experience with programming and computer code. In elementary school my grandmother taught us how to program in Logo and LogoWriter, as it was called then. (I have since learned these programs are still active, now known as MediaWorlds.) We had a little cursor called a ‘turtle’ and with the use of a handful of basic commands we could make it move in various directions, draw a line or move without a line, fill in a block bordered by lines or the entire screen. With these simple commands we could even make primitive animations, which we did either for the 1988 or the 1992 Olympics, memory fails on the dates. I do remember there were some excellent trampoline and gymnastics animations in my elementary school class. We also learned BASIC, although that was less interesting to 8 year olds than blinking cursors and making pretty pictures.

So where does that leave me, twenty and thirty years later? As it turns out, going through tech school alternating between incensed frustration and the glee of remembering how if/then/else logic works. My mother suggested I sign up for a coding boot camp and get a job in software development, specifically web development, no doubt because she remembered me cackling in the basement as I sat hunched over the family computer banging out the latest chapter of X-Files fanfiction and formatting it to post to the web. That is definitely the extent of what I want to share about my awkward teenage years, but I did, and she did, and she was right. We can do things these days that teenage me could only dream of being able to do on the web, and the prospect of being a part of that makes my inner fifteen year old very happy.

So, how does this relate to Sneakers, and Hackers, and the two wolves? Well, when I was first coding web pages a good twenty five plus years ago we had 28.8bps modems. The luckiest had T1 lines, at a transmission rate of a whopping 1.5Mbps. Our web pages were static, they conveyed information and occasionally moving pictures in gif or .mov format. Youtube, a quick Google search tells me, wouldn’t exist for over ten years. I learned how to code static pages with HTML and CSS and I learned how to code lean and clean and neat, so that a person on a 14.4 clunker could view them without much difficulty. Zip back to the future and now we have television on the web, we have entire computers built on the premise that you don’t need an operating system, only a web browser. It’s a very different game with much more intense system requirements than my little computer that could. So I needed a new computer.

Being a person who rather recklessly plunges hands-first into learning new skills, I decided to build one from scratch. Other friends in software and web development assured me that it would be easier to upgrade a home built computer, I checked the specs for what I needed, bought parts, and promptly discovered that owing to the gaming industry many of the larger parts inside a computer now… glow. My motherboard glows in rainbow lights. I remember when you needed a soldering iron and pliers to assemble a computer, and it came in your choice of gray or… gray. Green circuit board or black circuit board. We put stickers and spray paint over them, you could get RGB floppy discs out of different colored plastic. Now it’s LEDs and the motherboard comes with stickers and swag. I’m torn between disdaining a computer case that has a window so you can see all the glowing blinkenlights in it and giggling like my fifteen year old self because finally, finally I have a computer worthy of hacking the planet.

So, there are two wolves inside of me, and one is grinning maniacally at getting to put the pretty pictures and fantastic games on the web again, and the other one is somberly looking at the web as it stands today and thinking about the Sneakers quote “It’s about who controls the information. What we see and hear, how we work, what we think… it’s all about the information!”