DEV Community: Augusto Tomás Ibarrola-Crespin

Firefox Developer Edition DevTools – Debugger

Augusto Tomás Ibarrola-Crespin — Fri, 06 Nov 2020 14:43:56 +0000

A couple of days ago, as I was getting familiar with ol' faithful, the Mozilla Web Docs, I came across one Mozilla's new projects – a "Developer Edition" browser.

Now, obviously there is nothing wrong with ol' reliable, Google Chrome. Chrome's DevTools is one of the most indispensable tools in any developer's toolbox.

Still, I'm a sucker for shiny new things, so I decided to waste a couple of minutes downloading the browser and giving it its fair shot to live up its name and reputation. I mean, how could I resist something branded "Developer Edition" from the people that give us the MDN docs?

So, to cut a long story short I'll just come out and say it: it is pretty fantastic. Firefox's Developer Edition DevTools has a design that reads great and feels intuitive, and is definitely a welcome addition to any toolbox. It even inspired me to learn how to use it's built in debugger!

Mozilla offers a handy dandy debugger playground that guides you through a few starter examples with a simple to-do list react app.

You can open up the DevTools by right-clicking and selecting inspect element. This will pop the DevTools up, typically to the side of the browser window. Like so:

At the top of the DevTools, clicking on Debugger will render three panes: Source List, Source, and Tools

Source List & Source Panes

The source list pane shows all the JavaScript files related to the current page or project, while the source pane shows the content of those files. For all intents and purposes, we can think of it very similarly to our typical editor, like Visual Studio Code.
The left pane describes the locations of files and their relative structure to one another in relation to the whole application, and the pane to its right gives us a glimpse into whatever file is selected in the Source List.

Tools pane

The leftmost pane is the Tools pane, and is where a lot of the useful tools that Firefox gives us (but not all of them!) can be accessed from. In particular Watch Expression and the Scope tabs are useful as they allow us to view whatever variables are in play at any given moment, thanks to Break Points.

Break points are inserted by clicking on the line number in the Source's gutter. This should mark it with a blue flag, like above. Now, whenever the application is run, it will stop right at the line marked with the blue break point flag.
In this case, that means that when we try to add an item to the to-do list, the program freezes.

This might be a good time to go a little more in depth regarding the Tools pane, and in particular the toolbar.

Toolbar

Play/Pause
- Pauses or resumes the execution of the code being debugged. This is useful when you want to continue running your code after hitting a break point – or to move on to the next break point quickly.

* tl;dr – used for stopping and starting the execution of the code in question

Step over
- Executes the immediate next line after the inserted break point. If the next line happens to be a function, it will execute the entire function.

* tl;dr – used for taking the next "step" single step down your code

Step in
- If the line being "stepped" over is a a function, one can instead "step in" and execute the function line by line instead of all at once.

* tl;dr – used for "stepping into" functions and slowly working your way down its execution line-by-line

Step out
- Steps out of a function and runs the code until another break point or until completion.

* tl;dr – used for getting out of the scope of a function and letting it run.

Watch Expression

The Watch Expression tab is also a very useful tool in its own right. By typing in an expression or variable into the tab, we can see how that expression comes to acquire or change its values, line-by-line, by using the debugger toolbar.

Scopes

Scopes is another incredibly simple and useful tool that helps you debug your code more easily. At whatever break point in your code, as with the Watch Expression tab above, your relevant scopes are presented to you.

There is a lot that the DevTools offers, and as far as user experience goes, I'm happy and sold on this Mozilla browser. Keep in mind, though, that it is still in development mode and though I myself haven't found any glitches or pitfalls while using the application, always keep an open mind that something strange could happen. But as devs, I think we can handle a bug or two.

A Short Overview of Popular Programming Languages

Augusto Tomás Ibarrola-Crespin — Wed, 30 Sep 2020 13:14:30 +0000

We're always hearing how popular JavaScript is – was and probably will be –; often enough, maybe, that it starts going in one ear and out the other. But besides good O'l reliable, what are the other programming languages that bear the heavy crown of popularity alongside JavaScript? And what exactly are those languages supposed to do? Below's a short look at some of the other JavaScripts of the computer programming world.

Python

If we weren't constantly hearing about JavaScript, I'm sure we would be hearing about Python. Python came out in 1991 and is currently on its third rendition: Python 3.
It's a popular choice for beginners because it is said to be picked up easily enough because of its readability and flexibility (however, the latter is sometimes cited as one of Python's downsides).
It's a popular programming language for anyone interested in backend web development, data analysis, AI, and otherwise more data and science-focused web development.

SQL

Structured Query Language – abbreviated "SQL" and pronounced "sequel" (¯_(ツ)_/¯) – is a language that communicates with the databases of applications, pooling or otherwise editing the data stored within it. It's been more or less a standard as far as languages that query databases go since the 70s, despite other languages cropping up over the last 40-some years. In 2020, it was voted third Most Popular Technologies by StackOverflow.

Java

Java is an object-oriented and class-based language that came out of the sunny state of California in the 1990s, and has been a popular programming language ever since.
It is currently on its 12 version – Java 12, but has kept up a certain momentum over the last three decades that have made it as an exciting and attractive language for developers to pick up as it was at its beginnings.

It is usable for developing apps and applets (widgets) on laptops, game consoles, cellphones – particularly those running on the Android Operating System, since the OS itself runs on a Java language environment.

PHP

PHP – short for PHP: Hypertext Preprocessor – is a server-side language (like SQL!) released in 1994 (the current rendition is **PHP7*) that allows for dynamic web-pages, and has been ranked consistently high since its release in 1994.
Facebook, WordPress, and Tesla, and Wikipedia (and many others) all use the language, and it is a popular language among seasoned and beginner developers alike; it was ranked number 9 in StackOverflow's Most Popular Technologies list of 2020.

Go

Go is an open-source programming language developed 14 years ago by Google developers, and has quickly become a favorite by beginners in systems programming. It is a convenient language for building web servers and data pipelines. Uber, Twitch, and Soundcloud – along with Google, duh – all use Go in some or other capacity, from determining what's offered to you based on your location (Uber)to powering Google Earth and Youtube, among others.

Swift

Apple's Swift is one of the greener languages on the list, having been officially launched in 2014. It is the de facto language of all iOS, and thus the de facto language of Apple. Although it doesn't rank on every single list out there, it does have a dedicated following (owing to it's devoted Apple fanbase). Although one of the more niche languages on the list, Swift creates beautiful applications for phones and desktops and is friendly enough in its syntax and application for beginners to pick up.

Ruby / Ruby on Rails

Ah, good ol' ruby. Although you can see countless articles on the internet about the death of ruby dawning nigh, the fact of the matter is that ruby – and in particular the ruby on rails framework – remains a popular programming language for beginners and seasoned programmers and developers alike. It can count Twitter, Airnbnb, and Shopify – as well as countless others – as sites that were developed with the rails framework.

There are so many programming languages out there, it might feel a little overwhelming at first to see so many languages out there.

But that doesn't have to be the case! Understanding where your strengths and passions lay is the first step, and the one taken before you can figure out which language you should put your weight behind – front-end-centric languages? Platform-specific languages? Class-based or just Object-Oriented (or not!)?
It's all about getting started with baby steps.

Crash Course Through Rails File Tree

Augusto Tomás Ibarrola-Crespin — Wed, 09 Sep 2020 17:22:24 +0000

Whenever I take a crack at making a new application with rails, the sight of seeing rails create all those new files is a strange mix of satisfaction and being overwhelmed.
There's the app folder, the bin, the config, the db and then a few others on top of that. More or less, it'll look like the below.

I figure this calls for a quick overview of just a few of the different folders that rails provides for us to help us get our bearings and not have that "oh gosh, what have I done?" feeling.

/app

The app folder contains assets, controllers, helpers, mailers, models, and views (& views/layouts!).

Essentially, this is the bread and butter of the rails application. The app folder organizes the application's MVC components. That is, it has a folder that contains the apps models, views, and controllers, all separated from each other to follow standard MVC convention.

./assets

This folder contains images as well as javascript and CSS files that help style your application. These are all generated by rails

./controllers

"Controllers" contain, well, the controller files that handle user requests and that tie our rails MVC model neatly together.

./helpers

This folder is full of .rb files that contain modules. Essentially, files here are used to keep our model and controller code DRY.

./mailers

Mailers seem to be one of the more mysterious -ahem, advanced – concepts in rails, but essentially, any logic for building out a mailing functionality in your application goes in this subfolder.

./models

Our classic ol' models subfolder holds our class models that deal with the database and the data stored in it.

./views

"Views" contains our layouts folder, as well as any corresponding controller "views" folder (which would be the pluralized version of its respective controller). The layouts can be thought of as the standard "look" of the webpage, while the "views" are the particular flavors and logic of each controller. These two files work together to display our application on a server.
Files here are written in embedded ruby (.erb) that create HTML code.

/bin

Contains our scripts that start, setup, test, and run our rails application.

/db

The database folder! Here is where your database schema lives, as well as your database migrations and your seeds.rb file. Our database can only be changed through our migration files (and by running the rails db:migrate command) and our database can be populated using the seeds.rb file.

/Gemfile & /Gemfile.lock

The Gemfile and Gemfile.lock files can be thought of as sister files. Whenever you find a cool new gem that adds some awesome functionality to your app (and lets you escape the task of reinventing the proverbial wheel), it gets installed in your app when you place that gem in the Gemfile file and run the bundle command. This will then auto-generate (or update) the Gemfile.lock file, which should itself never be directly touched. It lists out all the already-bundled gems and their current working versions in your app.

/lib

This is a bit of a tough one. Rails documentation describes it as:

Basically, any kind of custom code that doesn’t belong under controllers, models, or helpers. This directory is in the load path."

Which helps no one. There is actually not a very wide consensus about what exactly should go in here, and many sources seem to work out their own conventions regarding this folder, or ignore it altogether.

/log

The log folder is your overhead glimpse into your rails session. SQL queries, error messages, request information (including URL, controller, params, and view information) is all stored in this folder. It tells us the history of our time on our application that we can peruse and use to track down bugs and errors.

/public

The public folder is used to hold static files. Error files (as in, what to display in case of an error happening)for example, could be stored here. However, storing files in the /public folder is not highly necessary.

/test

Contains the tests for your application that helps guide you to full functionality. These are auto-generated, but custom ones can certainly be built out.

This overview is in __no way__ exhaustive. Really, it barely scratches the surface. But hopefully now firing up that rails new command is now just a little less mysterious.

belongs_to, has_many, & has_many, through:

Augusto Tomás Ibarrola-Crespin — Wed, 19 Aug 2020 07:18:03 +0000

It's a tried and true rule that working on something lends itself to your knowledge of whatever that thing is. If you cook a lot, you know more about cooking. Or if you've got hours of painting under your belt, it's a safe bet that you know a thing or two about mixing colors. Coding follows this same beautiful pattern. The more you code, the better you tend to be at it. The concepts governing coding and development get easier to grasp, and your code goes from a mangled and complicated exercise in mental acrobatics to clean, precise, and – most importantly – simple code of a line or two. Ah, simplicity. Ruby, in particular, is all about simplicity.

But as anyone learning code for the first time will tell you: you've gotta put in the hard work before it gets to be easy. Even the tools that are available to users with the explicit aim of simplifying their code and streamlining their workflow don't immediately lend themselves if the hard work of grounding oneself in core concepts has been shirked. It's important to know that our most important steps are our first steps, and our first steps should always be baby steps.

My baby step moment came when learning ActiveRecord. I thought I could skim through its docs (and there's never a shortage of them), cherrypick a few methods here and there, and build the next great big app.

Haha! Oh, dear reader, how I wish that had been the case. ActiveRecord, like all good things, required me to do my part in understanding what it was all about before it could become my new best friend. Part of that work for me was understanding associations.

Associations can be a tricky abstraction of an otherwise (seemingly) intuitive concept. Essentially, they are the connections between ruby models that express their distinct relationships and unique attributes. ActiveRecord lets us work with six kinds of associations: belongs_to, has_one, has_many, has_one :through, has_many :through & has_and_belongs_to_many. For today's short lesson, we'll be focusing on the three most commonly dealt with by beginner rubyists: belongs_to; has_many; and has_many, through:.

belongs_to & has_many

Let's say that I have two kids, Leah and Paulo. They are two individuals, but they are both children, and what's more, they are both my children. In ruby-speak, we can think of the kids as one model that has a relationship to me, the parent, another model. We can say that Leah belongs_to me and that Paulo belongs_to me too. I can also say, since two kids are more than one, that I have (er, has)_many kids. These two associations in ActiveRecord tend to come in pairs, with the "parent" class being the class that has_many instances of another class. Those instances, in this case, are my wonderfully fictional children, Leah & Paulo.

The relational databases (though for our purposes here, they are really just informative tables) above hopefully help clarify how ActiveRecord understands these associations. The class that belongs_to another class is the one that "holds the reference" to an instance of the parent class. This is represented by the "augusto" parent_id being present alongside both children instances (i.e., "Leah" and "Paulo"). This same column on the children table is the one that also lets the "augusto" instance of the parent class (Me!) know that it has_many children.

has_many, through:

Let's imagine Paulo and Leah are all grown up (it always happens so fast), and they've got little Paulo & Leah Jrs. of their own.
Suddenly, my little family has expanded. Now I can say that I (have) has_many grandchildren, through: (my) children. Suddenly, in ruby, we are dealing with a whole new model, grandchildren, that the parent class is able to access and know about through their relationship existent relationship with the children class.

In the image above, we can see the new table grandchildren and the effect it has had on the two other tables (no man is an island and no database is either). Now, not only do children instances belong_to an instance of parent, but they also (have) has_many grandchildren! Which, as we remember, in turn, belong_to their respective parent (or kid instance). We can see that the grandchildren class holds the reference to the kids class, which in turn holds the reference to the parent class. Again, also, we see that in order to establish these associations, we need to make sure each instance of a "referent" class knows "who" it's exactly related to by including the desired instance of a "main" class in their makeup.

It took me a few days to understand the relationship direction and flow between models that belong_to another model or that have has_many of some other model. Like a lot of ruby, it is deceptively simple! These relationships are much more complex than detailed above – especially when these relationships begin to grow in diversity. Remember: there are six supported associations, and these are only the first three! Not to mention polymorphic associations (oye! makes my head spin!). But also remember: Rome wasn't built in a day. All it takes, really, is patience, close readings of any and all documents available to us, experimentation and practice, practice, practice! Baby steps are hard when you're a baby! But those baby steps turn to walking fast, and eventually, we all get to run.