Tag: Software Engineering

This article on the abstraction of parameters is part of the Content Collective series, featuring tips and expertise from Flatiron School staff members on topics ranging from program success to the job search. This series is a glimpse of the expertise you can access during your program at Flatiron School.

While programming, you may want to have the same thing happen more than once but at separate times in the code. You can copy and paste the code from the first instance, but then you have repeating code throughout your project.  

While a practical solution, doing this adds many lines of code for you or others to parse through to find a bug should one occur. 

To help minimize code size, stick to DRY (Don’t Repeat Yourself) code.  Using functions with parameters and arguments allow you to reuse that same code over and over without adding all the lines of code each time.

What is a parameter?

A parameter is kind of like a variable that belongs to a specific function. Just like a declared function waits to be invoked or used somewhere in the code, the parameter waits to be given a value. It just sits there in the function until it is utilized and given a value.  

When declaring a function you must also declare the parameter that is attached to it.  To declare the parameter all you need to do is give it a name in the parentheses of the function you have declared. The syntax looks something like this in JavaScript:

function myExample(myParameter){

return myParameter

}

When giving a parameter a name you can name it anything you want to (as long as it doesn’t repeat the name of another variable or function in the same scope). However, it is helpful to others reading your code (and as a reminder to yourself) if you give the parameter a name that represents the value it is given. 

For instance, if you have a function that converts Fahrenheit to Celsius, then the value you want the function to change will always be the Fahrenheit temperature. So, calling the parameter “Fahrenheit” would be ideal.

function convertToCelcius(fahrenheit){

return (fahrenheit – 32) * 5 / 9

}

In this case, the parameter called Fahrenheit will always represent the temperature to be converted to Celcius when the convertToCelcius function is invoked and given an argument.

What is an argument?

Functions exist in two states. 

The first state is the declaration, or architecture of code that will happen when the function is used. 

The second state is the invocation of the function. This is the signal that the code in the declaration of the function should go through its coded steps. The parameter exists in the declaration version of the function and the argument exists in the invocation of the function. The argument is the value that is given to the function and, thus, assigned to the parameter of the function. 

In the previous example, the argument would be provided for that function similarly to this:

convertToCelcius(78)

This signifies to the code that the steps in the previous function example should go through its steps with the parameter (in this case called Fahrenheit) equal to 78. So, when you invoke the function like this, the code for that one time the function performs its steps is essentially the same as this: 

return (78 – 32) * 5 / 9

Notice that the parameter was replaced by the argument that was given to the invocation of the function. That’s because the parameter is essentially a stand-in for the argument that is passed in. This is what makes the function dynamic and reusable with different values.  

How Are Parameters and Arguments Linked?

The parameter of a function is like a container that can hold different things in it. Let’s say you have a favorite glass that you like to drink out of for every meal. On that glass, there is a label of ‘drink’. For breakfast, you have eggs and toast and your ‘drink’ glass you fill with orange juice. After breakfast, the ‘drink’ glass is empty so you can use it again for lunch (after rinsing of course). For lunch, you have a ham sandwich and fill your ‘drink’ glass with milk. Afterward, it is empty again and can be used for dinner and so on.

For each meal, the glass stays the same and always has the label ‘drink’. What changes is what the glass holds. If the meals represented a function, ‘drink’ would be a parameter in that function. Whatever it is filled with represents the argument for each meal (or the invocation of the meal function).

In Conclusion

Using parameters and arguments in your function allows you to reuse the code in the function for different purposes. This will keep your code sleek and minimize the lines you must trace back to find bugs in the code. It also shows employers that you can develop dynamic code for use in multiple places in an application.

About Joe Milius

Joe Miius is a Software Engineering Technical Coach at Flatiron School. He has previous teaching experience and has been helping Flatiron School students understand coding concepts for 2 years. He loves problem-solving and takes on each new problem or question a student presents with vigor and curiosity.

This article on version control with GitHub is part of the Content Collective series, featuring tips and expertise from Flatiron School staff members on topics ranging from program success to the job search. This series is a glimpse of the expertise you can access during your program at Flatiron School.

Have you ever been working on a project and gotten to a point where you wanted to rewind? Perhaps start over from a previous point and go in a different direction? Hitting undo until you get there would work, but then you’d lose all the work that you had. Wouldn’t it be nice if you could go back but still keep all your work? Well … there is for coding!

What is Version Control?

Version control is a system to keep track of each change that is made to the code in a project. 

Many systems can be used for version control. In the Flatiron School Software Engineering program the focus is on using Git and GitHub. Git is the most widely used version control system and is used in conjunction with GitHub. 

Git commands run locally to track each version and change made to a project on your computer. GitHub stores all those changes so that other people can review the changes.

Why Is Version Control Important?

The importance of version control is not just to show you know a new technology but also to show you can manage larger projects in an organized way.

Using version control will be crucial because you will have many people collaborating on the same project and keeping track of all the different code coming into the project in an organized way is essential. It will allow your managers to review your code before integrating it and it will allow your contributors to apply your code to theirs. 

Showing employers that you can organize your code and be able to compartmentalize code into workable sections that can be integrated or reverted will show them that you have the foundations to work in a collaborative environment.

Git Basics

While completing the labs in the Flatiron School Software Engineering program you will become automatic in the basics of Git version control. 

Each submission will be prefixed with git add . , git commit -m “Completed”, git push. These are very good commands to get used to using, and even better to understand what is happening with each command. 

The git add . command takes note of every file that has been changed in the directory and puts them into the staging area. Take note that the period at the end of the command is what signifies ‘all’ the changed files. 

The git commit -m “Completed” command takes those staged files and designates them to be tracked by an identifier.  This allows each newly committed version to be reviewed or reverted back to.  Then, finally, the git push command sends the committed files to the software holding each version, in Flatiron School’s case it is GitHub.

Beyond the Basics

Once you’ve got the basics, it’s helpful to familiarize yourself with additional commands. The deeper Git knowledge you have, the more applicable you’ll be in larger projects with multiple contributors. 

There are several commands you will want to explore to get a greater sense of compartmentalization in Git. They are git branch, git checkout, git merge, and git pull. These commands will help you store commits into a specific section of a project that you are working on.

Git Branch and Git Checkout

There are two ways to use the git branch. The first is to bring up a list of branches that are associated with the project you are working on. The second way includes an argument after the command and creates a new branch that can be worked on. 

For instance, the command git branch new-branch will create a new branch of the project called new-branch.  You can then start working in that branch with the command git checkout. Git checkout also requires an argument to move into whichever branch you want to work on. 

An example of this would be git checkout new-branch. This command would have you working in the branch created by the command git branch new-branch. This will compartmentalize all the code you are working on for a particular feature of an application or website. 

If you have multiple contributors to the project, then the other contributors can review the code before applying it to the main branch of the project. It also allows you to revert the project to a previous state if the new code creates an error. This is extremely helpful when a project has been deployed and you want to integrate a new feature. If the new feature breaks the application, you can return to the main branch to the commit before the integration.

Git Merge and Git Pull

If you are working on a branch of the project that does not have the most updated code of the project you are not going to know if your code will conflict with the updated code. This is where git merge and git pull help. They allow users to see how new code interacts with previous code and how the new code can be integrated with the deployed branch of the project.

To integrate the new code into the project’s main branch, you will want to ensure you are currently in the main branch.  You can check this by running the command git branch. This will give you a list of branches and the one with a * next to it will be the branch you are currently on.  When at the main branch you can take all the new code from another branch. Then, incorporate it into the main branch with the command git merge new-branch.  The argument that the git merge command takes is the name of the branch you want to integrate with the current branch you are on.

In the case that another contributor merged code on the repository stored on Git Hub and you do not have that code in your local directory, then you want to use the command git pull.  This command will take all the code that another contributor added to the repository and integrate it into the branch that you are currently working on.

Final Thoughts

The practice of version control in Git will help you prepare for a professional role. It also will allow an easier transition into the workflow of the position you land. Even in your professional experience, it would benefit you to take the git commands mentioned here and expand on the multitude of git actions that you have access to (https://git-scm.com/docs).  This will help keep your team’s code organized and manageable.  It will also make it much easier to find bugs and fix them.  Being more efficient in your process is a benefit to everyone.

About Joe Milius

Joe Miius is a Software Engineering Technical Coach at Flatiron School. He has previous teaching experience and has been helping Flatiron School students understand coding concepts for 2 years. He loves problem-solving and takes on each new problem or questions a student presents with vigor and curiosity.

This article on immersive learning is part of the Content Collective series, featuring tips and expertise from Flatiron School staff members on topics ranging from program success to the job search. This series is a glimpse of the expertise you can access during your program at Flatiron School.

Starting the Flatiron Software Engineering program can feel a lot like traveling abroad. 

At your first Flatiron School class, you’ve finished the program’s prework and maybe even done some online lessons. You might be feeling prepared and eager, as well as a little nervous, with the feeling of entering a fantastic new adventure. 

This is not dissimilar to how it would feel to travel to Spain, for example. Maybe you learned a few basic words or sentences before heading to the airport. You’d likely be getting off the plane excited to experience a new culture, surroundings, and language. 

What’s more, the learning path for picking up Spanish abroad and coding at an accelerated bootcamp are also very similar. How can this be? One word: immersion.

WEEK 1: Fumbling With Fundamentals

The excitement that led you to take that international flight or sign up for a coding bootcamp will likely carry you through the initial week of learning. Those first few days, all you’ll be able to do is take in all the information cascading over you. You’ll find yourself lost in the culture of code and the language of Javascript. With everything new, including much of the language, you will most likely find yourself completely overloaded with information.  

“You can access the information in the object through bracket notation or dot notation. Bracket notation will allow you to use the value of a variable rather than the literal characters typed to access the key. Dot notation is limited to the literal characters typed as the key”

“Uh, I heard variable and object!”

It’s similar to being surrounded by people fluent in Spanish while only knowing a few nouns. You can pick out some familiar words and concepts from the work you did before the program, but little else. Combining all the pieces of Javascript in a coherent sentence or workable code ends up being like trying to string together a limited Spanish vocabulary into something as simplistic as “me gusta la manzana”.  Though to native ears of Javascript, it may seem childish, it is a big accomplishment to be able to say something like “The variable has been reassigned”, and that is a great start!

The Challenge

You will be inundated with so much information you might be consumed with taking it all in rather than just parsing the important parts. It can be intimidating and make you feel you won’t be able to accomplish the end goal. Don’t let this imposter syndrome shape you into a bystander in your learning.  Taking a passive approach will prevent you from achieving fluency in Javascript, much like only listening to Spanish speakers won’t teach you to respond proficiently.

Tips For Success

Be active in the learning process! To get yourself used to applying code to a blank file you should set up your replit and follow along with the lessons in the curriculum.  When you are done with a lesson try changing the code in your REPL environment and try to predict what will show up in the console. This will help you get more comfortable with producing and thinking in code.

WEEK 2: Practicing In Pairs

In the second week, pairing with other cohort mates to work on different labs and being forced to take the role of initiator will make you think through and cohesively use Javascript. The two roles – driver and navigator –  of this paired programming approach are instrumental in being able to produce code rather, than just understand it.  

Much like starting to use basic Spanish phrases in conversation, this week will challenge you to create things on the spot and respond appropriately to your partner.

The Challenge

Week two labs are an active Javascript thought production that makes you think through the language. The navigator role compels you to verbalize what code should be typed out. You will have to think through how to make a fetch request, what to do with the information from the fetch request, and how it all works with the user through event listeners. In each step, you will break the code down into smaller steps and debug.

Tips For Success

Moving into the “use phase” of week two can be intimidating. Take it slow and try not to stress during pair exercises. If you stumble over the logic, the driver is there to help you.

WEEK 3: Conversing In Code

As the end of Phase 1 of the Flatiron program nears, your fluency with the language will have grown to the point you can code independently. At this point, you can take on the challenge of tackling the end-of-phase labs that put all the concepts you have learned together.  

This translation will be taking someone else’s words and turning them into code. From now on it will feel like each new piece of information fits into an existing framework. Even new languages and frameworks in the next phases will feel easier to pick up. 

Relating back to our Spanish analogy, this is the point where you no longer feel lost on an alien planet. You know the fundamentals, can hold a dialogue, and partake in normal conversation! Though there will be new words to learn, you now understand how to fit them into the language. 

The Challenge

The end-of-phase labs will likely take a lot of time. At first, completing one of the comprehensive labs might take you a full day of work. But, with each successive lab you engage in, the time it takes to complete will diminish.

Tips For Success

Focus on taking the end-of-phase labs one step at a time. Fully engross yourself in one lab at a time. Move on to the next only when you’ve completely finished the first. By the time you’ve completed a few of the labs, it will begin feeling like coding has “clicked”. You’ll be able to see how everything fits together and would be translated from the “deliverables”, or the description of what the code should do for the user.

After Flatiron School’s Immersive Learning Bootcamp

Flatiron School will immerse you in coding, and your job is to let yourself be lost. Lean into the learning curve, engage, and try to converse. While immersion is scary at first, it gets results. If you embrace the process, you will learn new skills faster than you ever imagined!

About Joe Milius

Joe Miius is a Software Engineering Technical Coach at Flatiron School. He has previous teaching experience and has been helping Flatiron School students understand coding concepts for 2 years. He loves problem-solving and takes on each new problem or question a student presents with vigor and curiousity.