DEV Community: ycorredius

My Switch To Linux

ycorredius — Mon, 08 Jun 2020 15:42:00 +0000

When I first began to learn how to program and build things, I didn’t understand file structures and how to use the command lines. Windows didn’t particularly help me with this problem simply because everything can done through a GUI, and the command prompts feel a bit confusing to me. This is significant because learning git was a bit annoying simply because I didn’t feel comfortable in the terminal. Windows terminal felt clunky, cumbersome, and overall  intimidating to me. I felt a bit overwhelmed and confused to the point I was literally ready to quit. 

Fortunately or unfortunately, I had been dual enrolled and college at the same time I was enrolled in a coding boot camp and I had to take  a class in Linux. I had heard of Linux prior and used a Unix based software for work, but I didn’t really get heavily involved in the learning it all considering we only used prompts. Going through that class gave me a completely different perspective on the use of the command line that I hadn’t considered. The speed and efficiency of the command line was a game changer for me. The more is used it the more I learned of alias you can create, customizing the look and feel, the different shells available, and a whole community of people with guides to learning. 

Armed with this information, I made the decision to abandon Windows and go Linux. That's where another door opened I was not aware of. The amount of Linux distros available is nutty! I had not clue of what distro to even start on so I did what anyone in my position would do, turn to YouTube. I dove in, watched, read, and gathered information and I came to the conclusion, none of it was sufficient to figure out what to do. I found the only way to figure out what I like was to play with them. I probably went through 8 distros before I finally settled on Manjaro.
Manjaro is an Arch based distro that has a large community of developers that are more than eager to help. It comes default with a startup program that links you to forums, guides, opportunities to get involved with the project, and more. For development and setup purposes its the best! This distro comes equipped with Arch User Repository or AUR that is constantly being grown and maintained. While all distros you can use the command line to download programs, AUR take it step further and downloads and configures everything for. This includes multiple programs at the same time. Because of its ease of use, easy access to system functions, and command line, my quality of like in learning has been drastically improved. I encourage anyone who use Windows to give it a try and my just be surprised and make the switch also.

Technical Stupidity I Overcame Learning Redux

ycorredius — Sun, 07 Jun 2020 18:00:38 +0000

Learning React and Redux has been a quite the experience so far. For about 3 weeks I muddled my way through the docs that were as clear as sin, but I just didn't understand. The first of which was the concept of dispatch. To me simply writing the code out "dispatching" the action was the way things worked, not realizing that connect was a the major component that I had forgotten all about. You may be asking yourself, "There are nice and clear docs that explain everything in detail, didn't you read them?". Short answer is yes, but my perception was to just emulate the examples and not necessarily read to understand. That is clearly a mistake that cost me a lot time and headache that thankfully learned from. The next mistake was not learning what it means to dispatch and action. Dispatching on a very simplistic level is calling a predefined action that returns an object that, at minimum, returns an action type. However, when dispatching you chain action together and pull data from different sources and pass the data to the action. After, the action data is parsed it is based to the reducer. Reducers are are pure functions that take the stores previous state and an action to gives the next state. A pure function is a function that non-destructive function that, if given the same parameters, give the exact same results every time. The way I overcame my ignorance and learned the path in which it functions was the use of debuggers and signal traced. Every where I could think to use a debugger I place it to follow every piece of data to first see that I was receiving data, then see how to manipulate the data for usage.

Variables in JS

ycorredius — Wed, 22 Apr 2020 19:58:43 +0000

JavaScript a wonderful programming that has a few unique twists to it. That especially is true when it comes to variables. There are 3 ways you can declare variable in JavaScript, using the keywords var, let, and const. Var is a variable declaration that is not recommended since var is usually hoisted in a function and yields unexpected result. Let, is the recommended alternative to var simply because the value is easily reassigned and reused through a program. In addition, is provides block level scoping that is valuable when you only need to make temporary variables with a specific context. Like let, const, is used under specific context. The main difference is that const doesn’t not allow for reassigning of name space saving. The important distinction to be made is that you are not allowed to reassign the value of const.
There is another trick neat trick that JavaScript has that is truly tricking, hoisting. Hoisting is basically how JavaScript loaded. On of the first things that is done when a JavaScript file is loaded is to load all variable declarations behind the scenes. This is an important distinction because most other programing languages load the file from the top down. So, if you use a variable before it is declared the program will not compile correctly and will result is an error. Because JavaScript hoists variables if the variable is declared it does not matter when it is called. One caveat is that it only hoist declarations and not initialization. This is where a lot of confusion comes in. Many times, people expected to data to be hoisted along with the declarations, so time is wasted on a problem without knowing the origin. It is important to understand hoisting so that you may be able to trace errors to the proper origins when those type issues arise

Crawling Through the Seemingly Muddy Waters of Rails

ycorredius — Tue, 11 Feb 2020 13:29:26 +0000

I am a student of Flatiron School and I am now completing the ruby on rails section of the course. Starting learn rails seemed to be a exciting new endeavor that I was more than up for. That excitement quickly turned to confusion and a discouragement for me. I was enamored by the 'rails magic' and thought it was going to be the greatest thing ever. Then rails forms happened. I understood the over all point of forms however, it just didn't stick and I couldn't understand the routing of it all. What should have taken a week or two took about 3 for me to fully understand. From there learning rails routing became the equivalent to looking at an electrical fuse book. There were cables everywhere and I didn't know where to start. Not only didn't I know where to start, I was so intimidated I almost gave up. For me the strange part; I have never been afraid of challenges and always welcomed them. After so long of being confused and re-reading everything, searching for videos, and headaches, I came to myself and just went after it like a deranged man. That meant that everyday I was rails code and going through lessons(most times a single lesson) for hours until I could figure out what was going on. Admittedly, not the most effective way to learn, but it works for me because I learn best the hard way. Along the way I picked up some extras the course didn't teach. Like how to render a partial from a different class/controller onto a view. In addition, gems are the best! These simple additions to your projects add a enormous amount of simplicity and reduces time spent implementing features. At the end of this chapter I have learned a lot about the importance of understanding the tools you have and your code base. This Section has reaffirmed of the importance of having grit and being intentional with reading and your time.

Partial Forms on Rails

ycorredius — Mon, 10 Feb 2020 05:08:42 +0000

Hello to all who are reading this. I would like to say thank you for taking the time checking out this quick lesson on partials in Ruby on Rails.

Partial forms in rails are a quick way to reduce redundant forms or pages on you website, a simple example is the ability create, edit, and update a new record. Since most of the information it is simple to create a form with labels and textarea fields of the the different model attributes. To create a partial you simply create a file in the same class view folder with the name for your choosing prefixed with and underscore(_).

_page.htmle.erb

To use this on another page use the helper method render followed by the name for page in quotes without the underscore(_).

<%= render 'page'%>

This simple and effective tool allows you to create simplistic and more readable code without any extra stress.

Quick Tips for Restful Routing from a beginner.

ycorredius — Tue, 12 Nov 2019 00:00:12 +0000

From being completely new to Ruby programming to learning the joys of Sinatra, the journey doesn't seem to end and I love it! My latest adventure, learning restful routes. Here a few simple things that I learned the hard way.

Work on one piece at a time.
This is something that should be common sense but its so crucial. I made the mistake of assuming certain data would pass correctly because it had worked on previous implementation, but I never stopped to think about routing being correct. This obviously caused me to chase some invisible error that was no where near close to what was actually the problem more times that I care to admit.
Pry Pry Pry Params Params Params
These are wonderful tools provided to us by some beautiful big brain angels of mercy. Don't take their hard work for granite because they alone made it possible for me to make it through.
Nested routes make everything better
I tried to come up with this clean design that 100% separated components because I felt nesting made things looked messy. To an extent, I still feel I am right but I also don't know what i'm talking about. I spent days trying to pull of this "clean code" and only minutes from nesting.
Stay consistent
This is also a no brainer but apparently I don't have one at all because its a lesson I had to learn again. No need to try and be fancy or just throw something together, take you time and plan out your approach. Oder matters in routing. In addition, tracing your work becomes a lot easier if you stay consistent in how you layout controllers.

Subtle Beauty in Keeping it Simple

ycorredius — Thu, 10 Oct 2019 22:08:56 +0000

As I continue my long journey into transitioning into a software engineer, the fact of keeping things simple seem to always confront me. I currently work as a Medical Laboratory Technician in a hospital. It is a moderately complex job that is simplified by modern technology. However, it can be a hellish nightmare if you don't mind your p's and q's. As long as you stay consistent and organize a monkey could probably do it at its core. With that being said, it is the simplicity of staying consistent and organized that make the wheel keep turning.

As a new developer still getting my 'sea legs' its something that I realize more and more everyday. My default mode is always to find the most elegant and efficient way of doing this the firs time so I won't have to go back later. I realize that this is not the best of habits. Simply put, I am learning and the last thing I should be figuring at this point is elegance. My focus should be on figuring out how to make my code work. That includes breaking it to fix and really understand it. It feels really silly to say but its a lesson that I have learned in the recent weeks that has given me much less of a headache.

My (not) First Finished Project

ycorredius — Mon, 16 Sep 2019 07:32:43 +0000

As someone who has been on the path to changing careers for approximately 2 and a half years via college, Its dawned on me that I have never truly completed a full project from start to finish. I have been in college the entirety of this time and the most I've done has been bits and pieces of things that did not amount to much, which to me is pretty pathetic on my end. With that being said, what a great feeling to see how far I've come.

Since I've started I have heard the term "imposter syndrome" thrown around a few times. This was something I couldn't relate to (or so I thought) because i just felt like it was all just a challenge and that it was suppose to be this way (which is true). However, it came to a point in time where I just stopped dead in my tracks assessed what was going on and thought "What am I doing?", "You didn't know what this job was 8 month ago and instead of feeling it out, you take one class and you dive head first into the abyss." My mind flooded with doubt and regret, and for a while I wanted to give up. Instead, after several failures to complete different projects and programs(some paid), I decided that I was tired of failing and joined a coding boot camp. So, I work full-time, attend college full-time, and a code boot camp part-time.

This boot camp has been the most inspiring time of my life and has brought to my attention of getting over "imposter syndrome". The secret for me is communication. I've always been a talker and one who wanted to help, so in doing that I answered a lot of my own problems. Someone ask a question over slack, I would have an idea of how to help them but was not fully sure, I would help anyway. In doing that, answered a lot of the questions I wasn't sure about. Having these conversations would in affect bring out the knowledge that I am slowly accumulating in ways I couldn't for myself. I have been in a team player mindset for quite some time, but since being in this boot camp I believe even more that it is the best way to go about things that ever before.