DEV Community: danielpdaniel

Flatiron Phase 5 Blog

danielpdaniel — Wed, 17 May 2023 23:25:36 +0000

Working on my Phase 5 Capstone Project, I’ve felt a heady mix of emotions. Throughout the Flatiron Software Engineering Flex program, I’ve continually put off thinking about the end of the program or the next steps that come after graduation, choosing instead to focus on whatever work was right in front of me. Now, working on my final project for the program and getting (hopefully) closer and closer to graduating with each bug fixed and feature added, I can’t ignore the bittersweet feelings that come with nearing the end of something that I’ve worked hard at.
I’ve also sensed a bit of a shift in my thinking for this project when compared to my projects for previous phases. Whereas before I focused almost entirely on functionality and best practices, I find myself with this project thinking more and more about user experience and the precedents set by apps that are similar to mine. For example, my app functions a bit like a social media site, with different profiles people can visit. To keep things RESTful, the structure of a user’s profile url looks like, “/users/:id”, but what if someone wanted to visit their friend’s profile and didn’t know what their user id was? Wouldn’t it make more sense on the user side of things if the url looked more like “/users/:username”? This kind of thinking has led me down some real rabbit holes. It can be tough to decide when and how to prioritize user experience or developer convention, especially when I’m so new to all of this and haven’t really gotten a chance to peek behind the curtain at how these decisions are made.
For now, though, I’ve been happy to focus on those elements of user experience that I can upgrade from previous projects without compromising existing conventions. For this project, I decided to incorporate Active Storage into my project to handle storing and attaching images to user posts. My previous projects required users to submit image urls if they wanted to upload images. This worked fine and it was nice and simple to store an image url as a string, but it put the burden of sourcing or hosting images onto the user, adding steps into making a post that complicated the whole process. This time around my project was very image focused, so I wanted to make posting images as easy and intuitive as possible. And Active Storage allowed me to do just that!

create_table "active_storage_attachments", force: :cascade do |t|
   t.string "name", null: false
   t.string "record_type", null: false
   t.bigint "record_id", null: false
   t.bigint "blob_id", null: false
   t.datetime "created_at", null: false
   t.index ["blob_id"], name: "index_active_storage_attachments_on_blob_id"
   t.index ["record_type", "record_id", "name", "blob_id"], name: "index_active_storage_attachments_uniqueness", unique: true
 end


 create_table "active_storage_blobs", force: :cascade do |t|
   t.string "key", null: false
   t.string "filename", null: false
   t.string "content_type"
   t.text "metadata"
   t.string "service_name", null: false
   t.bigint "byte_size", null: false
   t.string "checksum"
   t.datetime "created_at", null: false
   t.index ["key"], name: "index_active_storage_blobs_on_key", unique: true
 end


 create_table "active_storage_variant_records", force: :cascade do |t|
   t.bigint "blob_id", null: false
   t.string "variation_digest", null: false
   t.index ["blob_id", "variation_digest"], name: "index_active_storage_variant_records_uniqueness", unique: true
 end

The Active Storage tables in my schema file. Installing Active Storage created a migration that sets up these three tables: active_storage_blobs, which stores data about the attachments, active_storage_attachments, which acts as a join table to connect blobs to models, and active_storage_variant_records, which tracks variants if variant tracking is enabled (I haven’t really used this one so far). More can be read about Active Storage here.

My app is a sort of digital sketchbook/social media site geared towards artists posting the studies they make to hone their technical skills. Using Active Storage opens up all kinds of functionality that makes posting images with a given study much more straightforward for users.

params[:images_to_delete]&.each do |image_id|
        study.images.find_by(id: image_id).purge
       end

Here’s an excerpt from my Update method in my Studies controller. Using the Active Storage purge method, I’m able to remove any images whose id has been passed in an array with params from the study post being edited. This deletes the associated blob and image file from the database while keeping the study intact, all thanks to Active Storage!

My simple little post submission form. Note the Choose Files input option for uploading images from the user’s device!

It feels very strange to be finishing this stage of my programming journey. For so long, I’ve been focused on just learning what I can and getting things to work in my projects, but now with this project I feel I’ve expanded my goals and thought processes to include investigations of my own experiences using various apps. I’m also glad I’ve gotten the chance to incorporate art into my capstone project. Transitioning from art to a career in tech has been very exciting overall, but it’s been a bit sad too to feel like I’m leaving my artistic roots behind. Working on this app has shown me that my art and tech journeys can continue forward together. This project has even gotten me to start painting again! Going forward, I’m eager to see how my creative endeavors can inform my programming career and how my programming career can inform my creative endeavors. I’d be lying if I said I wasn’t nervous about this whole career change, but it’s very exciting as well. I’m very grateful for all I’ve learned at Flatiron, and I can’t wait to see what’s next!

Flatiron Phase 4 Blog

danielpdaniel — Mon, 20 Mar 2023 19:24:22 +0000

As I’ve made steady progress on my phase 4 project, I’ve continually come back to questions about online safety as it relates to my project and web development in general. My app is called “Take a Hike” and is meant to function as a sort of activity log for hiking enthusiasts. Users can add trails to the database as well as create their own hike entries that correlate to those trails. Initially I imagined more of a social aspect to this, with users being able to follow or become friends with each other, but as I get closer and closer to submitting the project, this feels more and more like a stretch goal that I won’t be stretching for…

Part of this is of course in the interest of saving time and effort. I’m now well past the “blue sky thinking” phase of this project, and implementing more features and further complicating the database structure with more tables feels like something to worry about after my assessment, if at all. More than that, though, are my apprehensions about adding such features to an app that incorporates users’ real world locations. I would probably feel uncomfortable tweeting that I was alone on a specific, remote hiking trail, so why would I make a similar course of action one of the main features of my app?

This has led me to think a lot about the nature of online safety and social media, especially with applications specifically geared towards outside activity or location based events. Where is the line between a user’s responsibility to protect themselves and a programmer’s responsibility to protect their users? I do think there are many cases where the responsibility of user protection clearly falls on the programmer’s shoulders. For example, I could place the responsibility of using a unique password for my app on the users, so that if their password is leaked, it wouldn’t affect the security of any of their other accounts on different applications, but this isn’t really realistic just given the way people tend to use and reuse passwords for convenience and easy memorization. Instead I’ve opted to use the BCrypt gem to avoid saving any plaintext passwords to my database.

create_table :users do |t|
     t.string :username
     t.string :password_digest
     t.string :avatar_image
     t.string :about


     t.timestamps
   end

The setup for my users table, which uses a :password_digest instead of a :password column to work with the BCrypt gem.

class User < ApplicationRecord
   has_many :hikes
   has_many :trails, through: :hikes


   has_secure_password
   validates :username, uniqueness: true
end

My user model, which includes a has_secure_password macro to save an encrypted, salted :password_digest string to the database instead of a plaintext password.

def create
       user = User.find_by(username: params[:username])
       if user&.authenticate(params[:password])
           session[:user_id] = user.id
           render json: user, status: :created
       else
           render json: {error: {login: ["Invalid username or password"]}}, status: :unauthorized
       end
   end

The create method in my sessions controller that handles login post requests. The .authenticate method ensures that the :password submitted with the request is equal to the user's unencrypted :password_digest value

There are many other cases like this where it is clearly up to the programmer to protect their app’s users, but I think there are also situations where those lines become more blurred, especially with social media. Sharing your location on a hiking app could lead to some scary situations if a stalker were to take advantage of that information, for example, but not allowing any location sharing at all would hamper the experience of sharing posts about the hikes you’ve gone on. Things get even more complicated when you consider that people can also get lost or injured on hikes, in which case it could actually be helpful to have a record of where they’ve been, even if it’s just to figure out a range of where they might be. So, should we plan for the best or the worst case scenarios? Does protecting users come at the cost of limiting their freedoms to do what they want? Should the internet world and the physical world be kept separate as much as possible to prevent these kinds of situations altogether? Or are we too far past that point given how ever present the internet is in our lives already?

I don’t really have the answer to any of these questions, but they’ve been on my mind nonstop throughout the process of working on this phase’s project. I imagine that these concerns only grow in volume and complexity as you work on bigger projects that handle more things for more users. It all makes me a bit nervous, if I’m being honest, to have that kind of responsibility and try to plan for it all. But my hope is that as I continue on in my coding journey, I will gain the necessary experience and insights to make these quandaries a little easier. I think safety will always be a balancing act of protection and security with freedom and usability, but hopefully in time that balancing act will feel more and more intuitive.

Flatiron Phase 3 Blog

danielpdaniel — Sun, 15 Jan 2023 04:08:25 +0000

Throughout my last couple of projects for the Flatiron School Software Engineering Flex program, I’ve come across a repeating issue. I’ll be doing alright, following along with the project instructions and using what I’ve learned from that particular phase, when I suddenly realize that there are actually two ways of doing something. This can very easily send me into a tailspin. Which way is more inline with the rules and guidelines of the project? Which way is more efficient? Which way would be easier for an outside coder (or even myself a couple of weeks in the future) to immediately grasp and understand? How do I decide the best way of coding a particular project or feature?

This time around, I felt this insecurity most while working on the various fetch routes for my backend. My project is focused on musical artists, the songs they’ve performed, as well as the covers they’ve performed of other artist’s songs.

ActiveRecord::Schema.define(version: 2023_01_10_211010) do

 create_table "artists", force: :cascade do |t|
   t.string "name"
 end

 create_table "covers", force: :cascade do |t|
   t.integer "song_id"
   t.integer "artist_id"
   t.string "performance_link"
 end

 create_table "songs", force: :cascade do |t|
   t.string "title"
   t.integer "artist_id"
   t.string "performance_link"
 end

Using ActiveRecord, I was able to link these tables with particular relationships to each other. For example, each Artist has many songs and many covers and each Song belongs to an Artist and has many Covers. This creates a one to many relationship between the artists and songs table, as well as a many to many relationship through the covers table, with each cover belonging to a particular Song and a particular Artist. Just getting to this structure was its own process of decision-making and fretting, but then it came time to actually set that data up to be ready to interact with my React frontend. This was a whole new process of decision-making and fretting… For example, I wanted to create a GET handler to take care of requests made for the data in the artists table:

class ApplicationController < Sinatra::Base

get "/artists" do
   artists = Artist.all

   artists.to_json
 end

end

I also wanted those artists ordered alphabetically by name in the json data that would be returned. So, would it be best to simply handle that ordering in the application controller itself?

class ApplicationController < Sinatra::Base

get "/artists" do
   artists = Artist.all.order(name: :asc)
   artists.to_json
 end

end

Or is it better to define a specific class method in the Artist model then use that in the controller?

class Artist < ActiveRecord::Base
   has_many :songs
   has_many :covers

   def self.sort_by_name
       self.all.order(name: :asc)
   end

end

class ApplicationController < Sinatra::Base
get "/artists" do
   artists = Artist.sort_by_name

   artists.to_json( include: [:songs, covers: {include: [:song]}])

 end
end

(spoiler this is the one I ended up going with. I also used Active Record to include the associated songs and covers table data for each artist)

I think there could be arguments for both (and even arguments for handling the ordering on the frontend, but I didn’t consider that one here as it didn’t seem inline with the project guidelines). With an application as simple as the one I’m making, It might be easier to read and understand the code if things are all kept in one place in the controller. But, on the other hand, it might be better for compartmentalization and specificity within the program to handle the ordering within the Artist model. Ultimately I chose to go with a separate class method within the model because I felt it offered its own kind of clarity. It might take a couple extra steps and switching between files to see what it is doing, but everything is in a place where it can do its own specific thing. That, and I’d just spent an entire phase learning about how to use Ruby to write methods… and I wanted to use that somewhere in the project…

I think that’s something that’s really struck me about the end of phase project this time around. That there are not only so many ways of getting to a particular functionality or goal with your code, but that there can also be so many reasons for why someone might choose one way over another. And not all of those reasons are entirely centered around the code’s performance or legibility. I’m a student doing a project, so I’m constantly thinking about what’s going to work well within the criteria of the assignment I’m doing. “Based on this assignment’s rules, what will best show that I understand the material?” is a much different headspace to be in than that of someone working towards a deadline on a team within a major tech company, and that is a much different headspace to be in than that of someone working alone on their passion project in their free time. It’s kind of staggering how many “right” answers there can be to a particular problem, or at least how few “wrong” answers there really are.

Lately I’ve been trying to learn more about music making, and one thing in particular I’ve been trying to learn is how to mix and master. Watching this video, “The Art Of Mixing” the other night, I was struck by some of the things David Gibson said about mixing. Replace what he says in this quote about “mixing” and “recording” with words like “coding” and “programming” and I think the quote works pretty well!

[...] no one knows everything about recording. Because every session, every project is a completely new experience. It’s kind of like life, you never know what you’re going to get. We can only do the best with each situation and who knows what the best is? There’s no god of recording out there grading us. Therefore, I’m not here to tell you how to record a certain way. Each mix should be based on the song you’re mixing. I’m not here to tell you how to mix like me. I’m here to help you to prepare yourself to handle the most unlikely type of situation possible. I’m not going to tell you the one way to mix. I want to show you different ways that people mix, so you will have a choice. I’m here to help you do the most difficult job of all, to make art out of technology.”
–David Gibson, The Art Of Mixing

I think if I can apply that philosophy to mixing music (which I have no knowledge of) then I can certainly apply it to coding (which I now have some knowledge of…). Ultimately, I think what these thoughts have led me to is that I don't always need to fret so much about what is the "best" or "right" way to code. Coding is an ongoing process of constant creation, testing, editing, and experimentation. I think its open-ended nature is one of its greatest strengths and it's something I will try to celebrate rather than fear as I continue onward in my coding journey!

Flatiron Phase 2 Blog

danielpdaniel — Tue, 15 Nov 2022 04:45:55 +0000

As I near the end of Phase 2 of Flatiron School's Software Engineering program, I find myself looking back on all that I've learned about coding with React. Perhaps what strikes me the most, especially when compared to the previous phase which mostly covered vanilla javascript, is React's declarative style of programming. The concept of saying “give me this final result” and allowing the computer to figure out the rest feels almost like cheating at times. This has gotten me to think about how often it feels like I’m cheating when it comes to coding. So much is built on other people’s packages or dependencies or tools or plugins that often it feels like being a good programmer is less about how much technical knowledge you already have and more about how good your googling is! I’ve had to really question that “cheating” feeling. Through learning more and more about coding, I’ve come to deepen my understanding of the whole “standing on the shoulders of giants” thing. I’ve always understood this to mean that all great achievements are made possible by the previous great achievements of others, but I’ve never really considered just how much it plays out in the day to day. Like how I don’t know everything that React is doing to take my components and render them to the DOM. Similarly I don’t know everything that is happening in HTML to make a select box which opens a drop down full of options when clicked, but the computer is able to do it all for me because I knew the right way to ask it to do that… isn’t that just magical?

function EmojiSelector({ onChange, foodEmoji }){

   const emojiArray = ["🍽","🍏","🍎","🍐","🍊","🍋","🍌","🍉","🍇","🍓","🍈","🍒","🍑","🥭","🍍","🥥","🥝","🍅","🍆","🥑","🥦","🥬","🥒","🌶","🌽","🥕","🧄","🧅","🥔","🍠","🥐","🥯","🍞","🥖","🥨","🧀","🥚","🍳","🧈","🥞","🧇","🥓","🥩","🍗","🍖","🦴","🌭","🍔","🍟","🍕","🥪","🥙","🧆","🌮","🌯","🥗","🥘","🥫","🍝","🍜","🍲","🍛","🍣","🍱","🥟","🦪","🍤","🍙","🍚","🍘","🍥","🥠","🥮","🍢","🍡","🍧","🍨","🍦","🥧","🧁","🍰","🎂","🍮","🍭","🍬","🍫","🍿","🍩","🍪","🌰","🥜","🍯","🥛","🍼","☕️","🍵","🧃","🥤","🍶","🍺","🍻","🥂","🍷","🥃","🍸","🍹","🧉","🍾","🧊","🥄","🍴","🥣","🥡","🥢","🧂"]

   return(
       <div>
           <select name="emojiSelect" id="emojis" onChange={onChange} className="selectEmojis" value={foodEmoji}>
               <option>Select Emoji...</option>
               {emojiArray.map(emoji=><option key={emoji}>{emoji}</option>)}
            </select>
       </div>
   )
}

(my EmojiSelector component which allows users to select from a list of food emojis. It felt so simple to execute thanks to React's declarative programming--I must be a fraud!)

My course instructor mentioned the concept of “pattern matching” the other day. It’s a pitfall of learning code in which students don’t necessarily learn the concepts of what they are programming, but simply memorize whatever code they need for a particular action, without really understanding it. This sent me into a bit of a panic, I'll be honest. For example, I might understand something like a fetch request--a client makes a request to a server for certain data, the server sends back a promise, which acts as a sort of I.O.U., which then gets fulfilled (or doesn't) when the server sends the data it’s promised. But like……… HOW is it doing all that, right? I have no idea… well maybe I have some idea, but I’m definitely not getting the full picture just yet. And I wonder if all coding isn’t like that to some extent, because where does it end? The programming languages we use today are built on older languages from the past right? And those are based on even older ones? Back and back until you’re dealing with ones and zeroes flipping switches on and off? Is it really cheating to code declaratively? Is all coding cheating?

It’s interesting to think about. How far down the iceberg do you need to go to really know what it is you’re doing? Like ultimately computers are hardware, should I be learning mechanical engineering too? Electrical engineering? Should I mine for the metals and plastics myself? Make my own tools to put it all together? I feel like… no! My time is better spent elsewhere… and isn’t the whole point of living in a society to collaborate so that we don’t all have to toil away in the computer mines to free our own laptops from the granite? I think part of the beauty I’m realizing is inherent to coding is just how collaborative it all is. Even the most solitary, genius programmer blazing their own trail through the digital world is ultimately reliant on the work of other people in a million different ways. To be a programmer is to collaborate with countless visible and invisible people across space and time in the endless quest to facilitate the sharing of cat pictures… and I think that’s really cool!

Coding can do some pretty intense, high concept stuff, but I really love the channels it opens for smaller communication as well. Like with my phase 2 project! For this phase, I made a single page web application called Our Lil’ Picnic Basket. The main goal of the site is to collect some of the little stories people have about their favorite foods. So it’s almost like I’ve been collaborating with the creators of React, JSON-server and all the dependencies I’ve been using in order to then further collaborate with any visitors to the site who would like to add a story to the mix! It's like standing on the shoulders of giants so that I can call out to people standing on different giants and be like “Hey… what’s it like over on that giant?”

return (
   <div className="newFoodFormContainer">
       <h2> What Are You Bringing to Our Lil Picnic? </h2>
       <h3>what's a food that reminds you of home? Tell us about it below!</h3>

       <form className="newFoodForm" onSubmit={handleSubmit}>
           <FormInput name="name" label="What's this food called?" value={foodName} placeholder="Food Name" onChange={handleChange}/>
           <FormInput name="city" label="Where did you eat this food?" value={foodCity} placeholder="City" onChange={handleChange}>
               <input type="text" name="country" placeholder="Country" onChange={handleChange} value={foodCountry}/>
           </FormInput>
           <EmojiSelector onChange={handleChange} foodEmoji={foodEmoji}/>
           <label>A Fond Memory of This Food:
               <textarea type="textArea" name="story" placeholder="tell us a story..." onChange={handleChange} value={foodStory}/>
           </label>
           <input type="submit" name="submit" value="Add Food!" onMouseDown={()=>setBtnClassName("clicked")} onMouseUp={()=>setBtnClassName(null)} className={btnClassName}/>
       </form>
    </div>
   )
}

(my call from the giant I'm standing on to the people on other giants)

Even though I won’t always be working with declarative programming languages in the future, I will always be working within a network of knowledge and technology built by both contemporary and non-contemporary coders who've made whatever I'm working on possible. And hopefully in doing this work, I will make my own little additions to help others raise themselves up from the giant’s shoulders even further, like a stepladder or perhaps a bench they could stand on… whatever I do it’s nice to remind myself that I’m not doing it alone.

Flatiron Phase 1 Blog

danielpdaniel — Wed, 28 Sep 2022 16:32:59 +0000

Coming into coding from a creative background, I thought that I might someday use coding to make artistic projects. So far, though, I've been surprised by just how much coding for its own sake feels the same as making art does. The mediums and end products may be vastly different, but there's something about working on my phase 1 project that feels much the same as working on a standalone animation or short story. Maybe it is just that creating anything requires the same parts of the brain to be used and so will feel like a similar process, but I think there's something shared within the end goals of both coding and art that makes them feel like two sides of the same coin. Working on my project was a constant search for "what do I want the user to experience?" And I think that's what working on an art project is like too. At the heart of both lies communication. Sending information from one place to an audience somewhere else. But what's interesting about coding, at least in the case of the Phase 1 API project, is that it's not just about conveying an idea from one artist to an audience, but an artist acting as a vehicle to convey existing information from a source outside themselves to the audience, and then taking information back from the audience to update that original source. My phase-1 project... is not some beautiful globe-spanning collaborative art piece (it only has one patch event!), but it is deeply exciting to me to see the seeds that are there and recognize what could be possible down the line as I learn more and more and expand my coding knowledge.

My current project uses json-server to make fetch requests to a db.json file containing information and images for 5 dogs. This is pretty straightforward, but what excites me most about is the way the user activity can update and affect the original db.json file!
Here I have the condition for when the game has been won, as well as a patch request to update the number of times won:

if (boneCount === 3){
                            bonesCrunched.textContent = `Bones Crunched: 3, Congrats! You've Crunched all the bones!`
                            let currentDog = dogOptions[document.querySelector("select").options.selectedIndex]
                            currentDog.wins += 1;
                            document.querySelector(`h4#${currentDog.name}Wins`).textContent = `Wins: ${currentDog.wins}`
                            console.log(currentDog)
                            patchDogWins(currentDog)
                        }`

function patchDogWins(dog){
        fetch(`http://localhost:3000/dogs/${dog.id}`, {
        method: 'PATCH',
        headers:{
            'Content-type': 'application/json'
        },
        body: JSON.stringify(dog)
        })
        .then(res => res.json)
        .then(data => console.log(data))
    }

When the games is won (all 3 bones have been crunched), the player's selected dog that they used to win has their win count increased. It's a very small thing, but its potential is so exciting to me. For example with this game, I've thought about making the win number affect game play somehow, like maybe the size of the player image is related to how many games have been won with that dog, making it easier the more games have been won. But more broadly I think it's so cool just to have something I've made be interacted with like this. Usually with art projects, you make it, put it out there, and then that's it! someone might make something inspired by it or iterate on it in someway, but for the most part it's just there for other people to consume. But with a coding project like this one, interactivity and changeability based on user activity are built into the very code itself, it can even be the whole point of the application. That's so exciting! And gives me a whole newfound appreciation for the digital systems that surround us. Like social media platforms. I'd never really thought about it, but many social media sites are almost like these giant scrapbooks that exist on a global scale, with everyone posting and sharing their favorite things or their personal thoughts. Giant databases of stuff that people care about and want to communicate to the world. That's really cool! It makes it doubly sad that so much of the social media world has been overtaken by corporate greed, misinformation campaigns, and bigotry, but maybe there's a way back to these kinds of idealistic forms of social media through looking at it through this lens, at the very least as a user if not as a coder.

I've learned a lot throughout phase 1 of this program. That includes the technical side of things, like the coding know-how that allowed me to make my dog walker project, but it also includes these more conceptual, philosophical ideas that I've started thinking about. What can coding be used for? How do its applications relate to my own interests? What are its strengths as an artistic medium and how might it bring people together? I definitely don't have satisfying answers to those questions just yet, but I'm excited to continue pondering these questions as well as new ones as I work through future phases of the program!