Rails – Technomancer

Developer’s Log, Stardate I Can’t Believe I Spent That Much Time On That.

For the umpteenth time, one of the extra fun parts of having three intermittent decades of experience in computer programming, both web development related and not, is that you have a near-instinctive idea of how computer logic works. You start out the tech boot camp knowing that you need to make sure the conditions are true, that you haven’t left a loop running, that you aren’t sending the compiler or engine looking for a variable that doesn’t exist. That solves a lot of problems before they can come up. Unfortunately, it’s still not proof against the really–

— I don’t want to call them ‘stupid’ problems, because they’re not. I’ll call them Sub-Optimal Coding Conditions problems. I shouldn’t have tried this on five hours of broken sleep. —

the Sub-Optimal Coding Conditions problems. The SOCC problems. The ones you make when you’re tired, or you forgot to eat lunch (and breakfast), or you’ve been looking at the same code for two and a half hours without a break. I will continually bang this drum, and occasionally have it bounced off my head: you will write your best code when you’re hydrated, fed, and rested. And have recently thought about something that is not code.

Today I was working on a project for boot camp, never mind what it does for now but the setup to the joke is I had two objects, Item and Source. They were tied through the join table ItemSources. I had a form for new Items and a part of that form was you could pick a Source for that item from a list of checkboxes, or pick multiple Sources, or you could create a new Source by name. So let’s go through the code piece by piece, shall we? Can you figure out where the SOCC problem arose before I could? Because it took me a good hour or so.

Everything looks good, right? We’ve got validations, relationships. An Item belongs to a List, and then the aforementioned relationship to Sources. We also had the sources-attributes writer method, where we take the attributes fed in through the form and create a new Source object if we can’t find one by that name already. I went through a couple variations on this code trying to figure out where I’d gone wrong, but this is probably the cleanest version.

So here we’ve got the Item form, and again, everything looks good, right? Well, not entirely, it took me a couple rounds of coding in here to remember that a fields_for method exists, but I did get there eventually and thought, hah, that solves my problem! It did not. I went back and I dug out of an earlier lab the notes where I’d coded this in bare HTML rather than erb language, hoping that would help for some reason. It did not.

Was it in the controller? I didn’t see how it could be, the controller code was already pretty clean and I knew what each part did, I didn’t see a place that I’d missed a step, but I went over it anyway. Twice. Didn’t help. At this point I was getting irritated and nervous, and this is definitely when I started thinking I should have put a pause on the code till tomorrow, but no. Because sometimes I know better, and I push anyway.

I used the tried and true method of taking each step of the code as slowly as I could make it. I put in a byebug interrupt to pause it after the user, that is to say me, had fed data into the form to see what I was working with. I went over each step of the program in the Rails console carrying it through to the next step manually, line by line. By now I was in the Item model code, going through the source_attributes writer method and discovered that it wasn’t actually writing the new Source object. Okay. But why wasn’t it writing the new Source object?

This is the part where, if I’m being honest, it was only luck that made me think of the actual problem instead of going in circles for another hour and then shamefacedly taking myself to someone else to look over it. I didn’t type anything, I went over in my head the steps of creating a new Source object. What were the necessary and relevant items needed to create a Source object? Well, it needed a name, the rest of it could be added in edits, and I went over to the Source model to see what else was going on in here.

And there it was staring me in the face. validates :name, :location, presence: true. The only problem here is that the fields_for method only took in an argument for a name, no location. So the params fed into creating the new Source object would fail validation, the new object wouldn’t be created, and thus my problem. I spent an entire hour figuring out that it was nine freaking characters ruining my whole process and driving me up a wall and back down again. This is why we don’t code tired, friends. It doesn’t entirely eliminate these kinds of errors to make sure you’re working rested, fed, and watered, but it does help cut down on them.

Eventually I’ll have enough practice in Rails to put that validation back in, but for now taking it out was the easier solution to get the project finished and turned in. I did add it to the stretch goals in the project notes, as well as a brief reminder to myself in the dev log to check your validations if you’re wondering why an object won’t write. It’s useful, I find, to have a mental or physical list of first things to check and make sure you haven’t forgotten or miswritten. Double checking to make sure I included a save method where it should go has saved me a lot of grief, I tell you what. And now I can add checking my validations to the list.

Project SEEDs

Every year since we moved to the house we currently live in I’ve had some sort of a garden. In the last couple of years, what with everything that’s happened, my garden has expanded quite a bit. So when it came to the JavaScript project it seemed like a good place to create a tracker for germination rates of every plant I tried to grow from seed.

I didn’t need a complex set of associations for this. I had Plant models, representing the general details of each type of plant I was trying to grow, and I had Pod models, representing the details of each seed or set of seeds that I planted. A pod doesn’t necessarily have to be an individual seed planted, a pod is any block of seeds that is planted in the same unit with the same conditions. I use this word because when I started growing things from seed I used little peat pods and the specially formed Styrofoam tray that came with them. Currently I use recycled plastic six packs in the same sort of tray, and since each pack is subject to the same conditions I call each pack a pod. Each of these models comes with several different attributes, as there are many conditions that can affect the growing of a plant from seed.

As far as the functions went, I knew that I would want a read function, a write function, and an update function. Read and write functions obviously to create new pods, but also an update function so I could update each pod with the germination rate. If I planted six Coyote Tomato seeds, and only four germinated, I would want to update the record with that number. It’s a simple application, but with only three A J A X calls I can keep track of the conditions in which I plant my seeds, how many of them germinate under each set of conditions, and I can see whether a plant germinates more readily on a seedling rack under artificial light or in natural sunlight.

Although the project was fairly straightforward given the material I had learned already, it was a good exercise in programming for functionality, for usefulness towards a users end goal, and frankly it was a good exercise in patience while debugging. I went through several versions of the associations before I settled on the most simple turning out to be the most practical. Once I had the associations down I had to figure out the attributes, which I knew were going to be numerous to begin with because there are obviously a lot of growing conditions that can be either created or considered. Handling a lot of attributes was all right on the back end, but on the front end it required a lot of consideration as to how I wanted to format it, where the information came from, how I needed to format it so that it could be read properly, etc. And of course, this led to the exercise in patience in debugging. Several times, various errors kicked up because I had forgotten to include an attribute, or had forgotten to format the association correctly, or had forgotten that a particular attribute was based on the association and therefore needed to be formatted differently than a plain old attribute. For example, each pod does not have a specific name in and of itself. It takes its name from the plant with which it is associated. And I have considered changing this, so that each pod can have its own name and be distinguished more readily from other pods, such as being able to call one pod San Marzano Tomato Outside, and then calling another pod San Marzano Tomato – Seedlings Rack. This might be something that I change in a future version, but at the moment each pod still takes its name from the plant.

I also had a small bit of trouble when it came to creating the edit function. The way in which I was taught through videos and walk-throughs to create the edit function did not work for either the version I was using, or for some reason I haven’t yet figured out. This came into play when creating the render function: I could not simply write the HTML code and return it, rather I had to create it via JavaScript and append it to the appropriate parent element. Then, because I was doing this in a different way than the walk-through, I had to pay special attention to each element in the HTML and connect it to each element of the edit function in the JavaScript. There were a lot of times when I had to go back, either undo the last several commands I had written or look over the last several commands line by line, see where I had gone wrong, and whether or not the changes I had made were the cause of the application not functioning as I wanted it to (or at all) or if the changes were working but I had failed to do something or if I had done something else incorrectly. It was all very complicated and, again, a good lesson in patience in debugging.

This is the first application project I have created in this boot camp that I feel is pretty much ready as intended for deployment right when I have finished it. I do still have stretch goals, and I would like to implement them, but the overall goal of being able to track germination rates under certain conditions for planting from seed is achieved. The application works. As a programmer I’m very pleased with what I’ve created, and as a gardener too.

The Research Repository

The Research Repository is a continuation or a sister project to Tropiary, the previous project I wrote for Flatiron school. I designed it for written projects, novels and short stories or non-fiction projects such as research papers, but in its current form it could be used for any project that requires research along several different subjects. It’s not quite as intuitive as I’d like it to be, but that may be a future problem, or a problem to address with writing clear directions on each new form page.

Functionally, each user has a profile constructed by their choice of login. Via Github (and the Omniauth project requirement), the user has a username based on their email address but does not have a display name. If you create an account directly you can create a username and a password, but you have no display name until you’re logged in and then can edit your profile. User creation requires a valid format email address, a username, and a password.

Once the user creates an account they have an option of creating a project or a list. A list can exist independently of a project, as it might be just a list of material the user wants to examine in further detail. The List object has many Projects and the Project object has many lists both through Topics. If the user chooses to create a project the options are simple: a project title, a project description (i.e. novel, research paper, essay), and a project summary. Having created a project, the user is then shunted to the project page showing the information and inviting the user to create a topic. This is where things become a bit complicated, and as my skills improve I intend to streamline it a bit. Each topic should be written in the context (and an example is given on the page) as it relates to the project. So, for example, a novel might have topics for the Protagonist’s hometown, the Protagonist’s childhood, the Antagonist’s background, and so on.

That done, the user may want to create a list for the topic. The ‘Create a List’ link takes the user to a page where they can give a list a name and select the topics they want to associate with that list. My test code has, for example, a list for 1930s Greenwich Village and a list for FTL (Faster Than Light) Travel. 1930s Greenwich Village is associated with only one project, through the topic of Main Setting. FTL Travel has two projects associated with it, through the topic Trade and Communication Structure for the project Triumvirate and through the topic Galactic Armada for the project Grumpy Old Mercs. And a list can always be edited to link it to a project via a topic if, for example, a user discovers that there’s a great deal of interest in research about snails and wants to write an informative essay or a listicle with pictures about it.

Once you have a list, you can now begin to add items! There are many fields to the item list but only two are required in validations: name and material. If we want to access the material we have to know what type it is, is it a book? a DVD? an audio file? a PDF? The rest are helpful, but not necessary. We can also, at the bottom of the page, add a source. The source can be a website, a library, a bookstore, a university press, anywhere you can source the material you’re looking for. Once the source exists you can then edit it to add a location or to change whether or not it’s free (such as a library or a web archive), and to add hours and a short description. I have not made the latter two options available for creating a source because the user might not immediately know these things and want to get the source entered in the database so as to remember to look it up later. However, once the source exists, a user can click on the ‘view all’ and be shown a list of sources with links to the individual pages, where the edit button exists. All sources are public, meaning you don’t have to be logged in to view them, and you can choose whether to view free sources or paywalled sources or all sources.

Most wish lists available on the web are bound to a single source: a single bookstore, a library, an audio archive. And even though Amazon is extensive, it isn’t the be-all and end-all of doing research. The main purpose behind this project is to create a single page where users can share sources or lists for various topics (the public/private toggle for lists is next on my coding goals, but was not necessary for the project) and exchange information about any subject they choose.