DEV Community: acm-sp85

It is like building a puzzle, bring your hot tea and relax.

acm-sp85 — Thu, 04 Nov 2021 14:07:21 +0000

Up until this point in my learning path at Flatiron School I had the feeling that I knew, almost always, where things stood in my projects. During Phase 1 we were working entirely on Javascript and the whole project was just a few pages. Then Phase 2 got a little more complicated when we were introduced to React and its component structure.

On phase 3 we learnt Ruby and its models and relations between tables and things got a bit harder to handle when building a React front end on top of it. But I still had a good feeling of knowing where things were standing almost from day 2 into the phase's final project. But then phase 4 kicked in.

We went into Rails and amongst many new magical tricks, we were introduced to Authorization and Authentication -not only hard for me to pronounce as a spaniard, but also tricky to understand. Out the sudden our projects went from having a few different pages of code to a rather challenging amount, and things got overwhelming pretty quickly.

Troubleshooting your code across different pages is not necessarily anxiety friendly. And what makes things even harder is to try to follow different video tutorials and different StackOverflow threads that use different syntax from different times or legacy code. And it is here where I want to focus my attention.
It is great to watch all those videos and read all those posts, but that doesn't mean copy/pasting their code hoping that it will magically work on your project.

Larry Tesler, the mind behind cut, copy and paste, made it very easy for all of us to save time and effort when "getting inspiration" for our projects. But with great power comes great responsibility, and just mindlessly copy and pasting won't get you any closer to the desired end goal of learning to code.

It very easy to build things very fast by using ctrl+c / ctrl+v, but when things don't work as desired, debugging will be a real pain. When you don't understand what all the pieces in the puzzle are supposed to be doing it is very hard to know why they are not working in their current position. And while you might be able to wing it when you are dealing with a 15 piece puzzle, you certainly won't when projects get bigger and bigger.

When I started building ePunch, my Phase 4 Project, I began jumping from the course materials to YouTube videos to StackOverflow posts to Dev.to articles. The access to knowledge was amazing and I was learning a bit from here and a bit from there, creating a mental collage of how things should work. I started doing some thoughtful ctrl+c/ctrl+v and gradually the foundation of my app was taking shape.

It was all working out great, until it wasn't. And things started to fall apart when I got to implement Authentication.

I wanted to have the option to add more functionality in the future and have the app be used by Coffee Shops and by Customers, so I conceptualized the architecture having two different kind of users: CoffeeShops and Customers. So I decided to start building all my authentication thinking "my user is my coffee_shop", but all the examples I was looking at were using [user_id].

So with every different video, or article I'd try to adapt their naming convention to mine, but I'd forget if I had called it [user_id], or [shop_id], or [coffee_shop_id] or whathaveyou. I thought I was understanding what was going on thought the build, but apparently I had my concepts all mixed up. And so my naming was all over the place, and made debugging very difficult.

When it was brought up to my attention that, even if my app was seemingly working, under the hood was a bug-bomb waiting to explode. I armed myself with patience and started to learn the concepts from the once source of truth, the documentation.

Don't let this happen to you too, so get yourself a nice cup of tea, try to relax, and read the instructions!

PS: This article should be considered as a "note to self".

First time with a Data Base

acm-sp85 — Mon, 06 Sep 2021 14:51:20 +0000

After building a couple of front end projects emulating a database via db-json the time had come to go a step further and jump into the real world of databases. Let me tell you all abut it in this short and screenshot intense blogpost.

How was it like to be working with a db-json

During the previous project at Flatiron School - Phase 2, I built a web app that was able to keep a log of my photographic equipment. I needed to store that information somewhere, but I had no idea about data bases, Ruby, ActiveRecord or any of that fun stuff. So what we were encouraged to do was to build a db-json with all our information and fake a DB that way.

At its core, a db-json is an object with data in it, and the greatest perk of this is that you can get to see what is going on in your code editor.

Adding items to your DB, deleting or updating them is as easy as opening the file on your editor and type it yourself. That is a very big perk!

Adding a layer of complexity with relational databases

During Phase3 of our course we started learning the powerful but old-timey language of Ruby with the intention of creating a strong foundation of the technology before getting into the most popular Ruby on Rails.

With Ruby we learnt about Object Oriented Programming and got introduced to Active Record and RACK, two powerful tools that allow you to program your server and communicate that way with the database.

At this point, the databases we were building looked nothing like the db-json ones, and special software was needed to visualize the data.

Instead you have to use software like DB Browser for SQLite

This made adding/modifying/deleting data a rather cumbersome process, but came with added powers that working with a non-relational DB didn't: the ability to have a DB formed with many different tables that talk to each other via foreign keys and that facilitate data retrieval via Querying.

As an example, here you can see the schema of my database, formed by 3 tables: Brands, Formats and Rolls.

And here you can see the relations in between tables, in which you can notice that every Roll belongs_to a Brand and a Format, every Brand has many Rolls and Formats, and every Format has many Rolls and Brands.

With a structure like this, every time you create a new Roll object you are creating an association in between the three tables and unlocking the true potential of relational databases.

Creating "Your Camera Gear" with React

acm-sp85 — Sun, 04 Jul 2021 20:45:09 +0000

It is the end of Module 2/5 on my SWE bootcamp at Flatiron School and it is time to build our own apps with React. The time has come to chose a topic and start building something from scratch.

Excited and terrified

Up until this point all the exercises I had worked on came with the basic design already built in and it was just a matter on knowing how to pass props from one component to another, or how to update the State. Once I was asked to build everything from scratch I felt completely lost.

With no time to loose I decided to build and app related to something I'm passionate about, something I enjoy doing on my own. Is then when it hit me. Camera Equipment!! Huge surprise...

I have a lot of camera equipment that I some times buy and sell in order to buy other camera related things. Why not building something that could help me keep track of my purchases?

Once I decided the topic it was time to start building it, but first, I wanted to plan out the entire app on a piece of paper. No surprises this time. No more build-as-you-go.

From ideation to execution

Ok. I had the idea and I knew what the app would do. I also had a roadmap of how it should look like (kinda...), now I only had to figure out how to make it work.
Sure, I had been learning react for the past weeks and I was feeling more and more confident about it, but I had no clue about how to put these concepts into a real life application.
Having those drawings from the beginning really forced me to push myself to learn how to code it, instead of letting me code something I was already confident about how to build.

The incredible power of React

At this point I have been working on Your Camera Gear for two weeks and I am still polishing code and fixing some bugs here and there, but the bulk of the application was made really really quickly. I'd say I was able to put together a semi good looking website within the first two days of working on it. It was already fetching info from my database and displaying it nicely on my homepage, and it had several components built in into the home page and there were a couple of events triggering when clicking in my items.

Not only that, some of the components I had built were very easy to recycle and create new components off of the existing code. It is just a matter of which props they are receiving. Simply amazing.

MTG Build Your Own Deck - Coding Experiences v1.0

acm-sp85 — Mon, 10 May 2021 13:18:39 +0000

A couple of weeks back I started working on my JS project from Module-1 at Flatiron School. The ask was to build a single page app that made a fetch request from a public API and then offered some options to do with that data.

I dug deep into Github's repo of public APIs and after a couple of unsuccessful attempts to get inspired by what I was seeing I run into Magic The Gathering API. What a throwback!! The data seemed well structured, it was time to have fun.

As a newbie I've heard many times already how you should plan and sketch before you start coding, but I was so excited to try the API and check if I was able to pull some data from it that I went ahead and started coding right away.

Sure, I made a plan of action, I drew on a piece of paper how things should look like for my MVP, but soon after I had all those deliverables ready I gave myself permission to try things out. The app was working, but the code looked pretty nasty. The event listeners had their functions declared inside them and were doing similar things that other event listeners were doing already. There wasn't a clear way of knowing what functions I had defined through the code and how to reuse them... The time had come for some organization, and it is here, when I was knees deep into the ugly code where I discover I was having fun tidying up.

Not only I was enjoying seeing clean code I was also understanding better how my app worked and saw more clearly how I could improve it and make it more efficient.

What once before had been an event listener that allowed you to click in one card to select and deselect it, now it had become an event listener that trigger an external function that did that. And that function could be called by another event listener too!! So obvious, so basic, but at the same time so easy to forget when you jump at your code without a clear plan in mind like a monkey who has been given a bucket full of bananas.

Moving forward I'd like to learn how to be more organized while coding. Not only the formatting of the code, but the strategy around coding. I am a very visual person and I need to see where I want to get to in order to get there. I should't let my anxiety to get to places fast stay on the way of efficiency.

At this point in time my project is due and I feel confident I was able to build something that works, and it can be of some interest for MTG nostalgic or even current players.
But this project doesn't end here with me submitting it for review. There are still a lot of features I want to implement, and several bugs I'd need to fix to make this app go from something that works to something that is actually enjoyable to use. It also needs some CSS love that I have been depriving it from.

Here to learn - Some of the reasons why I chose SE.

acm-sp85 — Mon, 29 Mar 2021 20:25:13 +0000

For the last 10+ years I've been making a living out of photography and filmmaking. Most would say that it's a great privilege to be able to live out of your passion, and while I partly agree, I believe that statement is not entirely truthy.

In a perfect scenario, my clients would pay me good money to travel the World making incredible photographs or give me the budget that would allow me to invest years of my time to make an edgy documentary. But truth been told, the majority of the paid jobs I've had over the years were just not so interesting. They allowed me to live and finance my side projects. That is where the fun was.

So what if you have to work for others and leave the fun for your free time? Is that such a big deal? Well... it probably shouldn't, but in my case those paying jobs where also eroding my passion for creating overall. And that is where I draw the line.

I needed a change but I never managed to say no to the next gig that would appear. It only took a global pandemic to put a halt to all my projects and give me time for introspection. The time was now.

I wanted to do something completely different that would leave my passion for image making completely intact while at the same time representing a challenge. Ah... it would also be cool to be able to do it remotely, since now it seemed everyone was fine with that.

And that is how I got to this point, 2 weeks into my part time SE course at Flatiron, wondering if I'll be able to keep my two sides of the brain working at their full potential.
Very-excited-to-learn.