Ongoing Investigations

Tag: web apps

  • Reclaim Cloud & Troubleshooting Dates

    I actually did this work on Friday, but I didn’t have the opportunity to write it up – just took a couple of notes so I could put this out today.

    As of Friday, I’ve figured out, at least for now, how I want to store and retrieve dates. When I retrieve dates, I want them to be reverse chronological, so the most recent date can be accessed easily. For now, that means that my retrieval function reads the CSV where the dates are stored into a list, then reverses the list & returns it. Whatever asked for the dates to be retrieved receives a list in reverse chronological order. (My write function appends the date to the CSV, simple enough.)

    During the initial working-out-the-kinks phase, the retrieval function actually iterated over the reversed list, printing off the dates rather than returning them. But after that caused some issues with redundancy, that got revised to returning a list.

    I also ended up setting up a helper function for the printing which essentially iterates over the list, appends each item to a string with a new line at the end (so, 2022-12-17 \n), and returns that very long string (which gets longer with every update), which can then be printed by whatever requested the dates. This is super inelegant, obviously, so a priority is going to be to figure out a nicer way of handling this.

    Another priority is going to be just… figuring out how to denote updates that happen on the same date. Every time I run the program to test it, it’s counted as a separate update and logged to the CSV. This is good! This is what I want! But I ran this program twenty-three times on Friday, so now the datelog reads (reverse chronologically):

    2022-12-17
2022-12-17
2022-12-17
2022-12-17
2022-12-17
...

    … and so on. You see the issue.

    I put together some questions to ask myself about how to solve this. Still haven’t answered them yet, but essentially they consist of: how do I denote the number of updates on a particular day? How do I store that information as separate from the date, and access it easily to update it?

    One way, which sounds very clunky to me, would be to store the date alongside a number of updates (so, 2022-12-17 for the first update, and then edit that to 2022-12-17 (2) for the second update, and so on. The formatting is still under consideration). The second way, which is even worse, is to store the information as above (every date listed neatly for every time updated, which will get super long very fast), and then every time I would need to return or display a list of previous dates, iterate over the information so that I can return it in a nicer format. No, thank you.

    I think the next step might be MySQL, which means that I’ll have to (re-learn) SQL and how to use it in Python. I’ll also have to pick a database, which will probably be MariaDB, mostly because I picked it randomly from the available MySQL databases when I was setting up the Reclaim Cloud environment which I’m hoping to test this on.

    Oh, right, I have some Reclaim Cloud environments now. The environment for this project isn’t currently online and won’t be for the foreseeable future, unless it turns out I absolutely require the MariaDB from Reclaim Cloud to store the information. Which I probably will.

    For the other environment, I’ve also been poking around a little bit with Ghost — not much yet, as I’m still working on getting it updated to the newest edition from 4.5.0, which is what I’m currently on. Once I do, I’ll be experimenting with the blogging features, as Reclaim is considering using it for our newsletter, which start being released at the end of January 2022. That environment is also offline for now until I figure out what I’m missing trying to update from the command line. Currently I’m dealing with this error:

    A very frustrating error.

    What that sums up to is mostly “You need to update using Ghost-CLI, but you can’t, because you didn’t install this using Ghost-CLI” (I used a one-click installer). Once I get the answer I’ll be able to write this up better, maybe as an article for our support docs, but in the meantime: still working on it.

  • Logging Stats Across Sessions

    So it’s been a while since I’ve made a blog post, but I’ve been working on my wordcounter/writing tracker app, and what I’ve been tooling around with recently is the question: how do I track information across sessions? By which I mean, if I run the program in Terminal once, how do I make sure that whatever information I log that time is still there the next time I run the program?

    The answer on its face has been pretty simple: read and write to a CSV file. I haven’t done this in a long time, so I had to look up the methods and practice them a little bit (documentation here), but given that they have examples in the documentation, that part wasn’t so difficult. The problem was the questions this raised, which I don’t really have answers for right now.

    • When I add an update and check whether the update’s date is the same as the most recent update (ie, have I already added an update today?) do I want to:
      • log the date every time (so for three updates on the same day, 12-14-2021, 12-14-2021, 12-14-2021)?
      • log the date and the number of times that day I’ve updated (12-14-2021, 3 updates)?
      • not reflect the number of updates in a day at all (12-14-2021, no further information)?
      • (If I choose option 1, how do I efficiently turn that information into something meaningful for the user? If I choose option #2, how do I store that information neatly?)
    • Where/how do I save my writing streak and my total words counted?
      • If I save the information in my date log CSV, how do I keep this information from getting messy?
      • If I save the information in separate CSVs, how do I preserve relationships between the data?
    • How do I efficiently log and retrieve my data?
      • Do I try to record dates in reverse chronological order, most recent first (aka not what these functions are designed to do)? If so, how do I retrieve only the first row?
      • If I go with the flow and record dates in chronological order, appending the newest date to the bottom, is it possible to retrieve only the most recent row, or do I have to read through the entire file?

    I’m pretty sure the answers to at least some of these questions can be solved with some careful Googling, but I’m a little worried that one or more of them may be “Go learn SQL, you doof”. Which is definitely possible. It’s just a pain.

    And eventually, the looming/haunting question: how am I supposed to turn this into a web app? But that’s way too big to tackle for now, so we’ll build that bridge when we get to it.

    [Super secret end-of-post sidebar: should I have a Git repository that I push to? Should I be pushing alongside every blog post? Would that be elegant/thoughtful/informative? So many questions today.]

  • Refactoring & Rewriting

    So in the past couple of days I’ve been making a lot of… I suppose I’d call them tweaks, because nothing feels big enough to consider it a major change. Could I even make major changes in a two day timespan without just hunkering down and doing nothing else? Probably not.

    So what have I been doing? Mostly refactoring, honestly. Initially I had a couple of methods for updating the wordcount, checking whether to update the day, etc., but I was running a lot of them in multiple lines the __main__ function rather than calling a single clean method. So I wrote a method, getUpdate(), and then subsequently retooled that method to make it more versatile.

    Before getUpdate() would ask you for how many words you’d added to your total, then staple those on to whatever your current total was already (right now it’s always 0, because the program doesn’t retain information between sessions). Now the method will ask you whether you want to add words or give your new total (so, stapling words onto the preexisting total, or replacing that preexisting number entirely); then it calls one of two helper methods based on that, in order to do what you want.

    Those helper methods also ended up having me refactor and split off more helper methods, which has honestly been a good exercise in thinking through what each line is doing and where it might end up getting reused.

    The other biggest “change” has mostly been clearing up my comments, which refactoring has also helped with. Python doesn’t render multi-line comments natively, so the convention is to enclose them in “””s (triple quotation marks), which causes it to register as a multi line string that the computer will just sort of ignore when it comes time to parse. I’ve been using my pre-method comments both as a place to describe what a method is supposed to do — this is good practice — and a place to keep notes about questions/concerns/functionality I might add (this is messy practice). But hey, this project is only for me, right?

    Well, a different problem arose, and it feels a little superficial. My text editor, Atom, color-codes everything in order to help with readability, and it renders all of Python’s strings in a bright green. This works great to offset strings from other things, but when I have lines and lines and lines of green, it makes it hard to see anything else, because it draws the eye so much. Refactoring and tweaking has been as much a way for me to strip down my notes to a point where I can use one or two single-line comments and get rid of the green, as it is to improve my code.

    The next big questions (that I’m scared to answer) will probably be: how do I store information between sessions? And how do I test multi-day streaks? The multi-day streaks will have to come after the storing-between-sessions question, just on account of I can’t have multi-day updates if I can’t store between sessions, but once I’ve got that… hopefully more things will start falling into place.

    More potential avenues for the future, non-immediate: can I/should I practice test driven development with this (might be a bit close to my Model/View/Controller thoughts from last time, haha)? How do I integrate a Python app with Javascript (am I going to need to figure out Flask, which I don’t even know what that is)? Is it possible that I’ll have to “finish” the program, then rewrite it in Java to make it compatible (eek, but I sort of miss Java’s structure compared to Python’s spaghetti-noodle flexibility)? How do cookies work? Should I take a day to just work on building really basic HTML sites with interactive fields and buttons (yes)?

    And, just for the sake of long-term organization and consistency, I should probably a) make a more structured planning document and b) get a GitHub where I can keep better records of what I’ve been doing day-to-day.

  • Rails Girls, Day 3

    Been a while, hasn’t it? Anyway, I’ve finally had a bit of time now to sit down and revisit the tutorial.

    The next steps in the tutorial (the link is here if you’re interested) are regarding adding picture/file uploads to the server (so, section 4). This bit started off pretty simple. I did hit that one error they warn you about, where the uploader cannot be found and you need to add another gem, but that only added a step that was basically identical to the one before it, so it was fine.

    The only major snag I hit was in the step which has you add the code showing the picture (rather than just its filepath).

    They ask you to change

    <%= idea.picture %>

    to

    <%= image_tag idea.picture_url, width: '100%' if idea.picture.present? %>

    Which for some reason generated astronomical amounts of errors. The reason is probably that I did a lot of things wrong. The first error was caused by referring to a local variable as an instance variable (Ruby differentiates these by starting instance variables with an @), but I tried to fix that by using some of the formatting from a different edit RailsGirls had me make, assuming that they had just messed up their second instruction.

    <%= image_tag(@idea.picture_url, width: 600) if @idea.picture.present? %>

    Doing this did not actually fix the problem. It made it worse.

    I decided to debug by adding this as an extra list item, rather than replacing a list item already present, so that I could narrow down where the issue might be coming from. Naturally, I messed up the HTML tags immediately and caused a new issue.

    But! I found that problem almost right away, got that cleared up, double checked why/how the parentheses might be working or not working, realized that the @ symbol shouldn’t be there, removed that and the parentheses, and everything started working again.

    Verdict: I need to review Ruby syntax.

    The static pages and routes finetuning were very easy, and I didn’t run into any issues there, which means that I finished that section of the tutorial today! The next section is about pushing your work to GitHub, but I don’t think I’ll do that right away; I want to do a bit of monkeying around with HTML, CSS and Javascript before I push anything.

    Onward!

  • Rails Girls, Day 2

    It took me a little while to come back to this, as I was never really able to properly figure out what was going wrong with Yarn. Eventually I decided that, since I also have an Ubuntu terminal and Linux running on my machine, I’d get set up over there instead, which let me bypass a lot of the issues I was running into with SQLite3 and Yarn.

    So, onto the next section: Building Your First App.

    Setting Up

    The first steps were to make a directory to store a Rails app in (pretty easy), per their instructions, and then use Rails’ scaffolding setup to generate some ideas.

    This was where I ran into my first hurdle (well, with the design of the tutorial itself — I’m not counting all the technical hoops of the first day): this tutorial is designed to augment a public workshop. What this means is that there are sections that essentially say “Here we’re going to learn about scaffolding. Run this command, and then the coach will tell you what scaffolding is.”

    And then there’s no explanation of scaffolding.

    Which — not the end of the world. Google is free. But it does mean at least a few minutes get expended on sorting through the first couple of results, figuring out which ones are documentation, which are explanations and which are ads, and trying to parse these as quickly as possible without having to do a whole ‘nother tutorial to try and figure them out.

    (For the record, scaffolding is essentially running a command that will quickly write up the basic Model-View-Controller framework of your app for you, which you can then build on. It does exactly what a scaffold should.)

    Working with the Scaffold

    So the first thing, setting up the scaffold, looks a little like this:

    rails generate scaffold idea name:string description:text picture:string

    Guess what was not explained in this tutorial. If you guessed “any of those arguments”, you guessed correctly. I ended up finding the answer in one of the Ruby on Rails Getting Started guides, section 6.1. The quick answer is that this forms a table for storing “ideas” where each idea has three attributes (ideas are rows, attributes are columns). The arguments are the name of each attribute, and its datatype. Simple enough concept, and again something that would probably have come across better in a live workshop.

    [a brief intermission while I check if Rails Girls has recorded any workshops]

    [none that I can find]

    [intermission over, we proceed]

    After setting up the scaffold, updating the database, and running the server, I opened the site and found an empty table with a “New Ideas” button. The button opened a field looking like this:

    The new ideas form and its fields.

    Hey, presto! A couple of ideas later, and the table is beginning to look a little fuller.

    The ideas table, now populated with two ideas: “Add Bear” and “Destroy Bear”.

    And yes, I tested “Show”, “Edit” and “Destroy”. They do about what you’d expect.

    Design

    The next section (again headed off by “The coach will explain this part”) talks about the ‘View’ part of a MVC model, and which part of a view is HTML versus which part is Embedded Ruby (ERB). It doesn’t really explain how the two connect up, nor which part of a view is made of which. I have some familiarity with MVC from my computer science classes, if I didn’t, this would probably be another place where Pilot Stops to Google.

    Went through the design bit; it was semi-easy, semi-interesting. When I’m working in HTML I’m always aware that there’s lots I don’t know, but it all follows so easily from what I do know that it feels like it goes almost too smoothly. I did learn about how ERB works in this context:

    <% %>
<=% %>

    and presumably some other similar related ones are the tags one uses to embed Ruby into the page. I found that one out on StackExchange, where I was also assured that Haml is a far superior alternative for embedding Ruby into web pages.

    Saved the code; ran the code.

    I got surprised when saving the code and visiting the main page (localhost:3000) didn’t do anything, though – the styling only appeared on the page for the Ideas app (localhost:3000/ideas). I don’t know why that is yet. Right now my guess is something to do with the idea that there’s only dummy content on the main page, and the scaffold generated is just for the /ideas page. To be investigated.

  • Rails Girls, Day 1

    Well, day 1.5? Day 2? The point is, I did a (very little) bit of the setup yesterday, but ran into a roadblock that I couldn’t resolve until now.

    I’ve been working for a while on how to learn/run Ruby, and for now I’m settled on following some of the Rails Girls guides for creating web apps. Rails Girls is an organization that runs events teaching girls how to code in Ruby on Rails, but they also have tutorials online here.

    So far, this has been an exercise in Googling a lot of stuff to see whether my computer will run things compatibly. The biggest two hurdles have been SQLite3 and Yarn (out of Ruby, Git, Node.js, SQLite3 and Yarn).

    For the former, the issue has been determining whether they have a toolkit for 64-bit computers (they don’t), whether they have SQLite3 itself for 64-bit computers (they do), whether I can run the 32-bit toolkit on my computer (I can), and whether I can mix the 32-bit toolkit with the 64-bit version (I decided not to bother, since I can run the 32-bit version as well).

    For the latter, it’s been trying to figure out why I could successfully install/update Yarn over and over again using Node.js, which was determined to be running, but not actually use any of Yarn’s commands (apparently you have to restart your computer. No one told me).

    Update from several hours later: restarting did not fix it. I think I’ll need to add the folder to my PATH in order to be able to use the commands. Will investigate tomorrow & hopefully be able to write up a little more about what is happening.

css.php