One of the most puzzling things when learning to code is stumbling upon code examples where there’s variables, functions or classes named `Foo` and `Bar`. What the heck? What are these abstract, made up words doing to help people understand what the code is doing? I’d say, a whole lot of nothing. But before I start ranting, I realize I won’t “win” this battle. I do realize there’s a long history of its use and respect people’s use of it when taking all the options into consideration.

History of foo and bar: https://stackoverflow.com/questions/4868904/what-is-the-origin-of-foo-and-bar

It really blows my mind how pedantic some programmers can be, but then go and use Foo, Bar, Baz in their code examples. This is overcomplicating already abstract concepts and adding to potential confusion. I totally get their use for trivial code examples, but if we don’t write code in this way, why would we learn to read code in this way?

So a few reasons why it doesn’t make sense to use Foo, Bar, or Baz:

1. They are completely made up. They don’t represent reality at all like the real data we use in our code does.
2. They add to potential confusion.
3. As teachers, we must have specific intent with our language and this does not fit in with that principal

But on the flip side there are some good arguments for using this made up terminology:

1. Less distracting to code’s intent so you don’t get wrapped up looking at variable names
2. When there’s no relationship between variables or functions, it can make more sense

So the takeaway here is to choose Foo and Bar when trying to draw attention to functionality and away from variable names. But as soon as functions or variables are doing something meaningful, or have a relationship, it may make more sense to name them as such, with specific intent in those names.

With the help of Babel JavaScript Developers are able to use “futuristic’ features of JS ES7. With the newest additions to the language, code intent and readability have come to the forefront.

One nifty feature in the latest JS is called the object spread operator. It helps build new objects from existing objects without mutating the original.

Let’s take a look at how we might do that before the spread operator.

So it makes some sense, you want to assign an object to a new object, hence Object.assign. But with ES6 we have the spread operator with arrays, `[ newItem, …existingArray ]` and so why don’t we do the same with the object? Readability is debatable, but that will come with convention. This is a much cleaner way to write the same thing. Let’s face it, the 3 arguments need for Object.Assign are confusing.

So here’s how we would do it with the ES7 Object Spread Operator:

Super Clean!

Just be aware that if you’re using this in your code, you’ll need something like Babel to make it browser compatible. Happy Coding!

So in preparation for interviews and keeping sharp mentally, I like to start off my day with a simple code challenge.

This week it was LeetCode: Two Sum

This problem is labeled easy, but intrigued me that it included a solution, so I thought I’d give it a go.

First, I always like to write down my approach like the following:

This is definitely not the best approach. I know that, but I always like to find a brute force approach to solving a problem because it can help when you’re really stumped and need to come up with something at all costs. In an idea world, that would never happen, but I think when you’ve had a long day and you’re wanting to finish what you’re working on, you should get it working if you can and come back to it in hopes of refactoring.

So this is what my first code submission looked like:

Ok, so a nested for loop isn’t very elegant, and most definitely not performant.

Let’s peak at their solution and see what’s up.

via GIPHY

Woah. Aha! So this is a perfect opportunity to use a Hash Map. A Hash Map is a data structure used for storing Key & value pairs. JavaScript has an implementation of this, however, an object was used in my version of the solution.

Here’s what it looks like using a JS Object:

Next I will give it a try with JS’s version of Map and see if that speeds up the run time at all. The fastest I could get was 86ms in JS. Until next time!

So lets start off with a definition.

Declarative Programming is “a programming paradigm… that expresses the logic of a computation without describing its control flow.”

Now, there’s some dispute on some of the details, but generally what we mean by declarative programming is that there’s a focus on the parameters in which to execute certain functions or code blocks based on user input or activity.

So in React.js for example, we might tell a specific element to render only if a button has been clicked, but we only have to worry about the conditional logic which will handle the execution of predetermined code, where to render it to the DOM, and what should happen on a subsequent action.

Conversely, imperative programming is more focused on the exact set instructions given. For example, if you were writing a Jquery program, your instructions for showing a form on a button press would look something like this:

1. Attach an event listener on doc ready for the button
2. When the button is clicked, execute your function to find a container and append the form to the DOM
3. Attach some sort of event listener on to the new DOM element to handle the next set of instructions
4. When the form is submitted you want to find the exact form element, and remove it from the DOM
5. Finally you would need to find the DOM element to re-append your button to and make sure there’s still an event handler attached

In React, since it’s a declarative approach, we can significantly reduce the number steps to reproduce the same functionality.

1. Display your button and give it an `onClick` prop which takes in a function
2. When clicked, the function will execute and set the component state to something like `showForm: true` which will in turn render the form to a predetermined container in the DOM
3. On submitting the form you can pass your function to the `onSubmit` prop and when clicked, the component state would be set to `showForm: false` and subsequently remove the element from the DOM

Sometimes, this means writing a lot of conditional logic, but it’s incredibly efficient for handling the functionality of your app without using your code to give exact, specific instructions for every single piece of functionality. It’s a great way to specify certain conditions needing to be met and upon meeting those conditions, you specify the manner in which your code functions.

Last week I had the pleasure of attending my 2nd React NYC event which was held at the WeWork Chelsea Location. For those of you who don’t know, WeWork is a co-working space for freelancers, creatives, computer nerds and everyone in between. Also, this just happened: WeWork acquires The Flatiron School

So I felt right at home since I’m technically employed by WeWork (I help students with our curriculum as a Technical Coach). Most WeWork’s that I’ve been to are super nice and come with an assortment of beer/wine, tea, coffee and anything else you can put a tap on(Pineapple water anyone?).

So I cozied up with a freshly poured glass of wine from the tap and intently listened to an awesome talk by Harry Wolff on the new features of React 16.

I was definitely excited, because I read the newest features and it didn’t immediately click for me, so it was amazing to get further details about why the update was important and how I could implement it in my own project. I actually already updated my current project to use React 16, but was unaware of some of the awesome features that shipped.

React 16 includes the ability to use something called Fragments. This means that you can write a component that can render without a parent