Heroku – changing your push and pull

I like Heroku. It’s straightforward and free and offers a great service. That being said, I did have some difficulties using Heroku after graduating from Flatiron. Then again, I also had some difficulty setting up a new environment on my Windows computer in contrast to the Mac computer I used in the bootcamp. Setting up my Github ssh also wasn’t the smoothest.

My point is that setting up software and using different services on your own greatly differs from having people immediately around you to help. However, you learn more because you’ll typically encounter more bugs and even go down different rabbit holes. I can also say that anything’s “first time” is typically much harder than the second, simply because now you know.

Today, I want to talk about changing the push and pull address that you have on your local repo. This is important because if you ever want to change the domain name of your application on the Heroku dashboard, the address also changes.

First, let’s check out where our current app pushes and pulls from!

// type in 
git remote -v

And then I get back…

heroku  https://git.heroku.com/sample-example-portfolio.git (fetch)
heroku  https://git.heroku.com/sample-example-portfolio.git (push)
origin  git@github.com:alinan-vn/sample-example-portfolio.git (fetch)
origin  git@github.com:alinan-vn/sample-example-portfolio.git (push)

Interesting! Here we see that I’m pushing and pulling from my github and my heroku repos. So now we want to change the first two, to our new repo!

Looking at our Heroku settings we see…

As we see here our app name and our git url match our current addresses.

Now let’s change our app name to…

As we can see, the app name changes and so has our git url. But if we run “git remote -v” again nothing has changed!

We need to remove our old repo and add in the current url.

// removes our Heroku address
git remote rm heroku

// let's check out what we have now
git remote -v

And we see…

origin  git@github.com:alinan-vn/sample-example-portfolio.git (fetch)
origin  git@github.com:alinan-vn/sample-example-portfolio.git (push)

Good! We just wanted to remove our Heroku address and leave our github untouched. Now we need to update our address…

heroku git:remote -a just-sample

Notice that we aren’t inputting our whole git url! Just the app name! Our Heroku git url is automatically included just based on the app name. Let’s see what we get from running “git remote -v”

heroku  https://git.heroku.com/just-sample-portfolio.git (fetch)
heroku  https://git.heroku.com/just-sample-portfolio.git (push)
origin  git@github.com:alinan-vn/sample-example-portfolio.git (fetch)
origin  git@github.com:alinan-vn/sample-example-portfolio.git (push)

Perfect! Now when you “git push heroku master” it will push to the correct and current heroku git address and properly update your live website.

Just remember to now go your new URL link, otherwise you’ll encounter an empty space where the old URL is.

Project merging and branching within a team

Developing can be one of the funnest fields to get into because a huge premise of this discipline lies in creativity and creation. If you find yourself in a group of developers working on the same repo for a project, then here are some general guidelines that may help you prevent conflicts and bugs. Specifically we’ll talk about branching and merging. How this may be setup and what sort of benefits or drawbacks different styles carry.

Branches

After creating your initial project on whichever framework you are using (react, vue, rails, etc) and you set up the initial structure (file system, empty components, gems/packages/dependencies, seed data, etc) you should always work on your separate branch. Never work on the master because not only do you finalize the repo everyone sees and pulls from, but it makes it much harder to debug or sift through the code to find something specific you may end up looking for.

git checkout -b BRANCH_NAME

This makes a new branch and switches you automatically to that branch. Make sure to commit and push what you currently have (if you already aren’t up-to-date with the master branch) before doing this.

git checkout BRANCH_NAME

This simply switches you to an existing branch with that same name. Again, make sure you are up-to-date with the master branch OR you’ve committed and pushed the current branch’s content before switching over.

Merges

Typically, in a team project, you’ll have a game plan of how you want to divide the work or even how you want to work on certain tasks in pairs or as a whole a group. One example might be having a list of tasks divided by components or files so that only each file is ever worked on by a single person at a time. Sometimes a task is more complex that demands two or more people to work on a single task, page, or file at the same time.

Merging in the former instance is pretty straightforward. Simply push your changes whenever you change/add/delete a method or piece of code of a reasonable size. Then have the team lead look over the merge and approve it or ask for different changes.

The latter case is a little more complex because it depends on the team dynamic. Does the team leader simply have the most ‘say’ and therefore handles the merges by him/herself? Or maybe you want to include everyone who worked on that file/page to be present in the merge to resolve conflicts together so that you stay on the same page? There are pros and cons to either option that either save, keeps everyone informed, or other factors such as task/project progress.

Simply be settling on a system for these two categories, you will prevent many bugs and merge conflicts. Remember to keep everyone on the same page from the beginning and you will save yourself many headaches and keep a team well oiled and functioning.

Deploying a React app with Heroku

Deploying with Heroku is generally one of the easiest ways to get your project on the internet quickly and for free. This is especially great for developers that want a live link to showcase their projects and sample work to prospective employers and companies. The first step is to create an account on Heroku. Don’t worry, unless you wish to have more than 5 projects on Heroku, you won’t need to input any credit card information.

https://signup.heroku.com/

After signing up, the easiest way to directly launch your project is to install the Heroku terminal into your environment. This can be done by following the steps laid out here:

https://devcenter.heroku.com/articles/heroku-cli

This includes setup for Mac, Windows, and Linux. Signing into your account from the terminal is especially easy since it opens a tab to the Heroku site so that you can log in through there.

At this point you either have a project already created or are about to create the actual project folder to begin development. Assuming that you haven’t created the project yet, these are the steps you need to complete.

create-react-app my-app 

cd my-app 
git init 
heroku create -b https://github.com/mars/create-react-app-buildpack.git 

git add . 
git commit -m "react-create-app on Heroku" 
git push heroku master 

heroku open

The first set of instructions should be very familiar. It’s simply the standard to creating your project on React.

Next, you “init” your project and get it ready to be pushed to Heroku, but before you even commit the project you need include the react buildpack. The react buildpack is an important part of this process because it sets up the Heroku connection preparing it to receive a React app specifically rather than a vanilla HTML/CSS/JS combo or other frameworks such as Rails, Vue, etc.

Then you continue on to pushing your newly created project as if you were pushing to Github. The key difference is in “git push heroku master” because you aren’t actually pushing to Github, you’re pushing to Heroku. Any new update in code will be similar to committing your changes to a Github repo, except, you push to Heroku using “git push heroku master”

Heroku open simply opens up your new project in tab using that new live link!

Now, let’s assume you already have a React project that you want to set up in Heroku. The process is similar, but can also have some complications.

git init 
heroku create -b https://github.com/mars/create-react-app-buildpack.git 

git add . 
git commit -m "react-create-app on Heroku" 
git push heroku master 

heroku open

As you can see, the process simply excludes the create-react-app process. However, the key here is in avoiding the bugs!

When you create a React app, often you have have dependencies that you add to make that React app run and include tools you need. After installing them through “npm install” you’ll often see a couple extra files automatically appear, these being “package-lock.json” or “yarn.lock”.

If you attempt to launch your React project to Heroku with these files already generated, you will receive an error that causes the push to fail. A quick dirty fix is simply removing these files BEFORE creating the Heroku app and then creating the Heroku buildpack and pushing the project to Heroku.

You can also attempt to push to Heroku before removing these files and see the error for yourself but just be wary of possible merge conflicts you could have if you’re also working with Github, especially if you are on another branch. Then the bugs can get a bit trickier and involve resolving merge conflicts.

All of which are very solvable, but I like to be prepared and avoid unnecessary conflict because it’s important to learn from your mistakes.

Dirty Ruby Rundown

As said in the title, this is a quick and dirty summarization of Ruby and what you can do with it! By no means is this an in depth look into the language, but rather summary with broad strokes to refresh people who have used Ruby before but haven’t done so in a while. That’s exactly the motivation behind this post! I, myself, haven’t coded in Ruby on a daily basis in a few months, so when I had to return to Ruby, I wanted to quickly refresh myself.

First, install Ruby!

Now that you have Ruby, you can access IRB (Interactive Ruby) where you can code in real time and play with the language.

puts "Hello World"
// Hello World
// => nil

// Puts is the basic command to print something from Ruby, similar to console.log() in JavaScript. The Nil value is always returned from 'puts'.

Basic operators!

3+3 
// => 6

3*3
// => 9

3**3
// => 27

Math.sqrt(64)
// => 8.0

Huh, what Math? Math, in this case, is a built in module. Think of a module as a library hosting many functions and methods that can be used in various instances so that you don’t have to recode the same functions in multiple parts of your code or classes. We’ll talk about this a bit more after we talk about classes.

Methods

def Hello
  puts "Hello World!"
end

Hello
// => "Hello World!"
// =>  nil

Methods have the “def NAME end” syntax, in contrast to Javascript’s “function NAME( ){ }” or “NAME = ( ) => { }”. There are a lot of extra neat things to explore such as implicit returns! In short, Ruby has a lot of neat little features that are designed to make the development life enjoyable, implicit returns, among others, is an example of such a feature.

Classes

class Person
  def initialize(name, age, favorite_color)
    @name = name
    @age = age
    @favorite_color = favorite_color
  end

  def introduction
    puts "Hi! My name is #{@name} and I am #{@age} years old. My favorite color is #{@favorite_color}. How about yours?"
  end

  def goodbye
    puts "Bye! It was great chatting!"
  end
end

In short, a class is an object that can be defined by the characteristic structure set up within these classes. Let’s create one!

person = Person.create(name: 'Alejandro', age: '22', favorite_color: 'green')

And let’s have this person introduce himself!

person.introduction
// => Hi! My name is Alejandro and I am 22 years old. My favorite color is green. How about yours?
// => nil

There are a great many things you can do with classes and it helps reduce the code you have to write, especially when grouping certain types of objects together. There are also deeper things to explore such as attr_accessors and attr_readers which make using classes even easier!

Modules

Modules can be used outside of classes as we saw earlier with ‘Math’, but they can also be used within classes!

module Human
  def human?
    true
  end
end

class Person
  include Human

  def initialize(name, age, favorite_color)
    @name = name
    @age = age
    @favorite_color = favorite_color
  end

  def introduction
    puts "Hi! My name is #{@name} and I am #{@age} years old. My favorite color is #{@favorite_color}. How about yours?"
  end

  def goodbye
    puts "Bye! It was great chatting!"
  end
end

Here we’re using the same class we created earlier but also creating and including a modules within this class.

person = Person.create(name: 'Alejandro', age: '22', favorite_color: 'green')

p person.human?
// => true

First, notice that ‘p’ also prints out data similar to ‘puts’ but there’s a key difference in value type being returned. Second, what happened here? ‘human?’ isn’t a Person class method, so how was it called? Well, exactly the same way we included the module into the Person class. In short, it’s as if we defined the ‘human?’ method in the Person class all along. This can be useful when you have other classes that may also need a ‘human?’ function, maybe a Professor class or a Teacher class?

In conclusion, Ruby is an amazing and enjoyable language to use. It’s a language built by software engineers for software engineers! It can be very powerful when wielded properly but perhaps the greatest power it gives lies in it’s consideration to the average software engineer because it proposes the fact that software engineering doesn’t have to be harder than it needs to be. Why not the opposite?

Thinking about code

How do you think about code? Does it change whether it’s for a fun personal project or for work? Whether cruising through the deliverables or stuck for days debugging? Or in your free time when the lines of code swirl in your mind?

Is it a friend or foe? Is it just ones and zeroes forever dancing on a screen? Perhaps it’s just fancy words setup in fancy way that magically does fancy stuff?

Not too get to far from the idea, but simply thinking about how you think about code is great way to self improve, especially in the problem solving part of programming. Like most things in life, truly understanding a situation comes from being able to take multiple perspectives.

Data Structures and Algorithms has been one of the funnest and most dreadful parts of my programming experience. In essence, they tend to be logic problems, riddles that require being able to think around corners.

Programming methodology, generally revolves around first making it work, then better, then making it look clean. Is this always the best way?

To get back to DS&A, following this methodology implies that best way to solve a DS&A problem is brute force. Maybe that is the answer for some smaller scoped problems, but most DS&A problems need to run a lot of data and brute force can mean creating a solution that requires dozens or hundreds of steps that can really be refactored to a handful.

The idea here is that all programming, by inclusion DS&A, is based on hard logic. Pure, cold math. So do exactly that! Find the independent variables, the dependent variables, and the conditionals. Make sure to include the constraints! Then fit these into equations based off each other that only work based on the variables! Draw diagrams and charts that help you visualize the data or possible scenarios.

The best case here is that you math and logical reasoning is strong enough that you can find an optimal solution quickly! Worst case is that you’re back where you started. This worst case never really happens because trying these new perspectives means you will learn something new about the problem that you didn’t know before.

That just means you’re closer to the solution that you were at the beginning.

In essence, these tips aren’t just useful to DS&A but to most programming (and life) problems. Maybe these processes won’t work for you, but it’s more important to expand your toolset because the bigger the shed is, the wider the range of solutions you can create.

Interviewing and Social Interactions – Jr Software Developer insights

The social part of a job are both my favorite and least favorite parts. They can be amazing because of the amazing people you can work with. These people have shaped my philosophy, challenged my perspectives, and overall improved my quality of life. On the flip side, it can be equally dreadful because not everyone I have met are prepared, engaging, or motivated individuals. Sometimes people want to drag their feet in teams or generally lack effort in team camaraderie. Furthermore, people’s reactions are easily predictable with any guarantee. Some people I meet are types that I have not met, up until that point, or simply lie outside my usual social bubble. Maybe that’s why I love software development. The bugs make sense and are expected. And a console.log(‘hello world’) will always log ‘hello world’.

Even this potential downside of general social interactions isn’t that bad. In fact, it’s a great way to see different sides of people and observe how different people all fit in the single mold of our civilization. Truly no person is an island.

These constant observations have helped me with interviews. Some interviewers are much more methodical and others a lot more loose in structure. Others still are natural speakers and are easy to talk to. In this wild spectrum, filled with many hues, are all the types of people, and therefore interviewers, you may come to meet. The trick isn’t to be able to connect in each interview on some intimate level to guarantee success and to move onto the next stage of the process. In fact, it’s a little more roundabout.

Authenticity is the theme and being genuine is the key. Listen to the question asked, take a moment to breath and form your answer, and then be genuine. Don’t respond with what you think they want to hear, respond with you want to say. Team player, self motivated, independent, etc. These are all characteristics everyone wants other people to have in their teams. These are already a given which means it’s pretty redundant to respond with these answers.

What has helped me is that instead of trying to force these points in the conversation, rather simply move where the conversation naturally goes.

In an interview, early in my job search, I was asked “When was the last time you had a bug or problem in your code that took you days to solve? How did you solve it?” This was a technical interview which meant I had to respond with actual technical jargon. I couldn’t think of a single time I’ve had a bug that took me more than a day or two to solve so I made up an answer.

The answer was unconvincing to myself and frankly disingenuous. Looking back, I should have said that I couldn’t remember off the top of my head and rather go straight into the problem solving aspect and what I usually do when I hit walls. I try to break different things to receive different code errors. I consult stack overflow. I consult other colleagues. I take a night to reset my mind. If all else fails, I go back in my progress to a point where the code wasn’t broken and rebuild my code.

Even though that wouldn’t have been the initial answer he may have been looking for, it would have been a straight answer that not only I knew was authentic and true, but also would have given the interviewer insight into the type of developer I was. After all, that’s what an interview is about.

Borders! Exploring css/scss styling.

Today we will review a bit of styling, borders specifically. In today’s world, if you don’t want to style much, you don’t have to. Many styling libraries exist to fit every need you might want. However, maybe you can’t find the exact fit you need or like visually. This is where directly styling becomes useful.

Let’s just add a border to some text! Here is what the code looks like:

Pretty straightforward, what do you expect it will look like?

Again, pretty straightforward, it simply borders the text without anything special going on. It sticks to the exact size in terms of height and width of the text. But what if we need a custom size?

Simply add a height and a width!

With a little more code you can even change the positioning of the text. With a firm understanding of the styling language, you can visually create anything you imagine. Let’s explore a few more border types.

Rounded border

Dotted Border

Dashed Border

Inset Border

Outset Border

With a bit of practice and study, learning the types of borders you can create and how to manipulate them can prove to be invaluable. Frontend and Styling Developers need to particularly practice this skillset because they often work with wireframes sent to them by Designers. Usually, there won’t be any written or code guide that will help you program the wireframes, instead, you’ll only have your eyes and maybe a bit of responsive data.

At the end of the day, it feels very empowering being able to manipulate code visually at will.

Post Bootcamp – a Jr Software Developer anecdote

I want this blog to serve as a record of what to expect post bootcamp and how you may overcome the challenges of the tougher parts of it. I recently came across another developer who had a bit of trouble remaining motivated and struggling to move forward with progress. It reminded me of my own turmoil immediately after graduating from Flatiron, so I though it would be useful to talk about it and sort my own thoughts on the topic.

I finished my Flatiron classes back in March 2020 and I was very excited at the many possibilities that lay in front of me. I was looking forward to working in development and being the thick of it with modern tech and services.

Unfortunately, imposter syndrome and regular self doubt proved to be the biggest hurdles to any forward mobility. I struggled with small and mid sized tasks and easily shut down at slightest convenience. For example, I needed to launch my projects on Heroku for easier access to potential employers but because I was now working on Windows computer instead of the Mac environment I was used to. I convinced myself that because I couldn’t develop or work on a Windows environment as easily as I could on a Mac, that I wasn’t a real developer. Of course, this wasn’t true, I simply needed to take a bit of time to learn and get used to this new environment. When I eventually decided to block off some time and seriously dive into the Windows setup, I found that it wasn’t that much different or difficult.

This behavior and line of thinking also slowed my job search through network outreaches and updating my resume. Fortunately, I got over this mental block and moved forward.

Although it certainly would have been better to have overcome these issues on day one, they have served me in shaping my philosophy and preventing me from making the same mistake in the future. Additionally, it made the job search a lot less scary and manageable.

Insights

A resume isn’t ever the finished product and is simply constantly a work in progress, therefore it makes no sense to put off writing and posting a resume until I have something ‘noteworthy’ or ‘good enough’. Simply with this line of thinking, there never will be anything good enough so it doesn’t make sense to let it prevent you from moving forward.

People on LinkedIn are real people but it’s a lot easier being rejected via text on a computer screen than in person! All it takes to reach out to someone is a few clicks, a read of their bio, and a few well written sentences. If they don’t respond back there are hundreds of other people you can reach out to! I was a person with a smaller network which meant that it was very difficult for me to receive any messages or connections back but eventually my network grew one by one. Now it’s a lot easier connecting with others and I’ve found some very interesting individuals that I would love to get to know better!

Failure is a part of life. This has been my lifelong hurdle because I strongly dislike failing and I often consider anything that isn’t 100% ideal to be a failure. It’s been a constant process shaping and realigning my mindset to be much more forgiving of myself and reasonable to what failure really is. Failure is a good thing that has taught me the most valuable lessons. Constantly reminding myself of this fact makes it easier to take risks and believe in my actions.

What are some insights that you’ve had in the job search? Feel free to comment and reach out to me!

set interval, part 2: React.js

In a previous blog post, I covered the Javascript functions setInterval and setTimeout. Using setInterval is pretty straightforward and particularly helpful for automating certain functions and features, but what if you need to use in React?

Before we being, feel free to brush up on or learn setInterval in my previous post here –> https://alejandrolinan.home.blog/2020/07/10/settimeout-and-setinterval-javascript/

In vanilla Javascript, probably for a static application, you would setInterval in this manner.

const countUp = setInterval(sayHi, 1000)

function sayHi(){
     console.log('Hi!')
}

function stopGreeting(){
     clearInterval(countUp)
}

Basically, the countUp variable calls the function sayHi every second, and to stop this the stopGreeting function, when called, will stop the countUp variable. It does this because the interval is set within a variable and is then updated. Easy to do because it’s all within the same file and same component. However, in React, where we have multiple components and moving parts, i.e. compDidMount(), compWillMount(), render(), etc, where do we store this single variable that can be accessed from anywhere within this component?

The short answer, is the state, the longer answer requires a demonstration. Let’s build a simple timer. All we have here is a number counting up by 1, every 1 second. We also include a button to stop the timer when clicked.

Basic code setup

What we see

Simple enough, now let’s add some functions that will update our state when called and start our interval when called!

updateTime simply updates the state.time by incrementing the number by one. setTimeInterval calls the updateTime function every second. clearTimeInterval would clear our state.interval when called. Inside our componentDidMount lifecycle we call setTimeInterval so that when the page mounts the timer begins! Here’s what that looks like!

As you can see, it increments by one every second, and when the button is clicked, the time stops. You can the file code here.

Conclusion

Setting and clearing an interval isn’t hard as long as you know to store the value in the state where it can accessed from any lifecycle or function within a component.

Coding Challenges, A different way to think (JavaScript)

As a bootcamp grad, one of the greatest weaknesses I had coming fresh from the curriculum was Data Structures and Algorithms. As such, some coding challenges that were more like this and ‘riddle type’ concepts were harder for me than more practical concepts like setting up a backend, filtering data, or creating a feature in the frontend. Today I want to go over a particular practice code challenge I solved that stood out to me.

This is the problem: https://www.hackerrank.com/challenges/repeated-string/problem?h_l=interview&playlist_slugs%5B%5D=interview-preparation-kit&playlist_slugs%5B%5D=warmup

Essentially, the premise is given an input s and n, where they are a string and number respectively, find the number of a’s in the string where the number is the total number of characters in the string. For example, if the string is ‘abba’ and the number is 11, then how many a’s are there in the new string ‘abbaabbaabb’.

My first code attempt is where I create a new string of length n based of the original string. Then I split the new string into an array and go through each element of the array to check if the element is an ‘a’. And finally returning the number of a’s in the string. My function looked as such:

function repeatedString (s, n){
    let counter = n / s.length
    counter = Math.floor(counter)
    counter -= 1

    let remainder = n % s.length
    let string = s
    let list = s.split('')

    for (counter; counter !== 0;){
        string += s
        counter -= 1
    }

    let splitString = string.split('')

    for (let i = 0; i !== remainder;){
        splitString.push(list[i])

        i += 1
    }

    let letterACounter = 0

    splitString.forEach(e => {
        if(e === 'a'){
            letterACounter += 1
        }
    })

    return letterACounter
}

The function works, but the run time is horrendous, especially for longer inputs. For example, try using the following as the input:

let sample = 'a'
let iterations = 1000000000000

console.log(repeatedString(sample, iterations))

Either it takes a long time to run or eventually it’ll break because it takes too long. Instead I had to use another appraoch.

I realized that the iteration number and the length of a string were important and that I could take a mathematical approach to this. Simply, I realized that I could divide the iteration amount by the length of the string and multiply that by the number of a’s in the original string. The one drawback is when the iteration amount isn’t a multiple of the length of the string. So I had to also keep track of the remainder in those cases and then run through the string the remainder amount of times. Here is the code for this try:

function repeatedString(s, n){
    let countOfA = 0
    let splitS = s.split('')
    let remains = n % s.length

    let times = n / s.length
    times = Math.floor(times)

    splitS.forEach(e => {
        if(e === 'a'){
            countOfA += 1
        }
    });

    countOfA = countOfA * times

    for(let i = 0; i != remains; i++){
        if(splitS[i] === 'a'){
            countOfA += 1
        }
    }

    return countOfA
}

Perfect! It runs much much faster, remains accurate, and looks cleaner as well!

Conclusion

It’s important to take a step back from a problem and simply take a different look at the problem. In this case, I first tried to dive head first and hard code for loops and forEach methods. Taking a more methodical approach using math and simple logic proved to work and also helped understand the problem much better.

Design a site like this with WordPress.com
Get started