JavaScript on both ends

After 4 pomodoros on @AnthonyPAlicea's NodeJS course, Lecture 90, I think I understand how JavaScript code runs on both front and back-end.

Looking at this code, I can see how the array of JavaScript objects is declared on the server (/app.js), then passed on to the view (/views/index.ejs), converted to a JSON string, is made available to the AngularJS controller, which then manipulates the JSON object in the client.

As I go through the code line by line, I ask myself continually:

Where does the program get this from?
Where is the variable declared?
How does this part of the program have access to it?

In this way, I can always see, piece by piece, how it all fits together.

Unless of course I'm using Rails, in which case one must have faith in its sugary magic.

A Word of Thanks to Gleam.io

I wish to thank Gleam.io for the invaluable experience of working as a junior software development intern from August 2017 until January 2018.

When I started my internship, I had about seven months' self-study of Ruby and Rails, with a smattering of HTML, CSS, Github, etc.  During my time at Gleam.io, I got to learn the ins-and-outs of a large commercial codebase, and saw first hand how an excellent product is built, maintained, and supported with intelligence and empathy.

I navigated the choppy waters of dependencies and got a complex commercial application running on my local Linux machine.  (I also updated the README to make life a lot easier for the next person)

I got a bunch of pull requests approved.

I made mistakes, and learned from them, in using Github.

I kept on using Rubymine until it made sense to me.

I spent countless hours reading the code, hunting for clues; Google and Stack Overflow were my constant companions.

I wrote tests that failed, then passed, then failed again, then passed.

I went mountaineering on a learning curve of Ruby and Rails, especially Rails; now I understand essentially how it fits together and is used to build websites that serve the needs of customers. 

A fair representation of the ardour and the rigour of studying Rails.

I got to pair program a bit and work remotely a lot — I enjoy them both very much.

In short, I was given every opportunity to learn from seasoned veterans, the value of which is beyond measure, and was treated with tolerance and respect by everyone on the team.

Chief amongst the myriad things I am grateful for is the self-confidence I am imbued with.  When I started my journey into software development, self-belief was one part reason, two parts faith.  But now I can say that someone saw the potential in me, even though I didn't have the requisite skills and knowledge for the role, and gave me a chance to fail and succeed, fall down and pick myself up.  

The guys at Gleam.io didn't have to take me on, but they did; they didn't have to invest in me, but they did.  They allowed me to see how I measure up against people who have been working with software for half my lifetime, and what I saw (although daunting at times) gives me great hope for my own prospects as developer.

Now that I have been part of a commercial development environment, I know for a fact that I can become a genuinely good developer with a reasonable amount of study, regular practice, and some guidance.  I will apply for junior development positions confident that the requirements of the role are well within my zone of proximal development.

Every time I turn on my System76 laptop (currently running Ubuntu 16.04.1 with Gnome Shell, but I might switch to Arch), I am reminded of the countless kindnesses shown to me, and take heart that the Next Big Thing in my journey is just around the corner.

Coming Back from Disappointment: A New Chapter

Review: Putting it all in context

After 700 pomodoros of studying, coding, blogging, and job-seeking spanning five months, I am still without my first job as a junior developer.  The hardest part of it all is maintaining an optimistic outlook after repeatedly being turned down, especially after the excitement of performing so well in numerous interviews.

But that won't stop me.  There are identifiable reasons for my failure, and the good news is that all the things cited are eminently improvable and correctable:

1. Quite simply, the quality of my code, into which I have poured so much effort, is still not good enough in the estimation of the interviewers.  This is good news, for I can learn from their feedback and code to a higher standard.
2. After one poor performance in a pair programming interview, I handled myself well in very similar conditions three days later.  I know where I went wrong in the first one; I know what I did right in the second.  I can build on this.
3. I need to familiarise myself with the core competencies, frameworks, and tools of front-end development.  My plan was always to give myself a solid foundation of programming in Ruby and a basic sense of DevOps with Vagrant and Docker, and although there is room for improvement in that regard, the task of getting really good at HTML, CSS, Rails, Heroku, etc is now a lot easier.

Add to that, I have gained a lot of contacts, spent plenty of time at meetups, made good impressions on many people, and have a highly sophisticated approach to learning and time-management.

So all things considered, I am many miles further down the road than when I set out on this journey at the beginning of the year.

Where to from here?

Rails

I think I'll muscle through Michael Hartl's Rails tutorials.  Although there are many good ones, this one is updated to Rails 5 and seems to do a fair job of sticking to the core knowledge.  The Odin Project looks good as well, but there's no point in jumping around from course to course.

HTML/CSS

Many experienced developers tell me that most juniors today are pretty weak on HTML and CSS, having jumped straight to boilerplates, JavaScript, and plugins.

As with other endeavours, I believe wholeheartedly in mastering the fundamentals.  It is hard to make such a commitment to something seemingly outdated, but I believe it will benefit me greatly in the long run.

JavaScript

The debate between Ruby and JavaScript rages on, and I have heard it said from those in the front-end world that the only language you really need is JavaScript these days.  I am glad I chose to learn through Ruby, and having gained a grasp of the fundamentals, learning JavaScript will be less daunting from here on out.

Summary

As much as I'd love to have been picked up by a company already, I am not really behind schedule at all, all things considered, and having taken some time to relax, recharge, and review, I am now keenly looking forward to the next couple of months.

Back to Rails and Heroku

Getting started with Rails is not a lot of fun, but I'm up and running again.

Starting To Understand Static Pages in Rails

Just finished Chapter 3 of the Ruby on Rails Tutorial (Rails 5) by Michael Hartl, and after the umpteenth time going through "rails new app" and "rails scaffold this-that-or-the-other", I got on to static pages.  It's a bit to take in, but it's starting to make sense.

Rails Web Console

I am running Rails from within an Ubuntu Vagrant box:

Vagrantfile specifies ports to open during "vagrant up".

The HTTP address (localhost) is accessible.

However, I ran into this problem.

This solution worked for me.

Rails Day 5: VirtualBox It Is, Then

After a lot of fiddling with Docker, I have decided to stick with a simple development environment in a customised Ubuntu box in Vagrant.  I will get back to Docker, but for now I'll stick to what I know and get on with the business of learning Rails properly.

I find sometimes when I'm learning something new and difficult that I have to bash away at it, fail, and then come back a week later.  The concepts haven't quite come together in my head and my work blocks get chewed up without my having much to show for it.

In the meantime, I have a functional Rails development environment with Postgresql running in Vagrant/VirtualBox:

Rails Study, Day 4: Still Working on the Dev Environment

So far I have spent time on the following:

1. Vagrant
2. Docker
3. Digital Ocean Droplet
4. Heroku

However, I'm going to take a step back and reconsider what I'm trying to accomplish.

What is my deliverable?

I want to build a Rails site, hosted on Heroku, that showcases my solutions to puzzles from Advent of Code.

How is my work supposed to flow?

Images, containers, Atom, etc.

1. Development environment (DE) is separate from the host operating system. (Docker container or VM)
2. Text editor (Atom) has read/write access to the code in the DE.
3. The DE can be easily duplicated for a sandbox server.
4. Code from the DE can be pushed to Github; from Github, the latest code cloned.
5. Changes from the DE can be pushed to Docker Hub; from DH the latest version of the DE.
6. Production code from the DE can be pushed to Heroku; from Heroku, the latest production code, although that should be available in Github.

What are the specifications of my development environment?

1. Version control of all relevant packages.
2. Read/Write access to development environment from host.
3. Access to online platform (Github, 
4. Available locally, without a constant internet connection.
5. Totally accessible by Atom text editor on my host machine.
6. Can upload code to Heroku, pull the latest code from Heroku, and push updated code to Heroku.
7. Can push updates to the environment to a repository.

What shall be my development environment?

1. Docker container for the DE, with all the necessary packages installed.
2. Atom text editor installed on host.
3. FTP access between DE and host.
4. Github access from DE.
5. Docker Hub access from DE.
6. Heroku access from DE.

Rails Study, Day 4: Docker and Vagrant

I came for Rails, I'm working on DevOps.

The purpose of this post is to give an account of setting up my development environment in order to study Ruby on Rails.

I am already familiar with Vagrant, and initially thought I would spin an Ubuntu 16.04 box and work in that.  However, the obvious and numerous disadvantages of working in a virtual machine on a local hard drive demanded that I find something better.

So I decided to finally invest some time on Docker, and I have to say, once I wrapped my head around the concept of containers, getting started seems fairly straightforward.

Initial Steps:

1. Install Vagrant on my host
2. Install Docker on my host
3. Spin up an Ubuntu box in Vagrant
4. Install Docker on my VM
5. Create an account on Docker Hub
6. Download the Heroku Cedar 16 image
7. Create a private docker repository on my host
8. Run the Heroku Docker image
9. Push a modified Docker image to my own repository
10. Pull the modified Docker image to my VM

And so forth.

As I want my development environment to mirror Heroku's settings as closely as possible, I decided to see what the Heroku website itself has to say on the matter.

My inclination was to keep it simple by using Vagrant, but Heroku's Cedar stack is available as a Docker image, so I will go with Docker instead.  I've been meaning to familiarise myself with Docker for a while, so this works for me.

Official Notes for Docker are available from Gist.

This videos helps to demystify Docker.

I'm now looking into simplifying it further and using a Droplet from Digital Ocean.

Rails Study, Day 2: Rails Install Fest

I have started a demonstration blog on Rails according to the instructions on the Ruby on Rails Install Fest, my first proper attempt at building something substantial on Rails.  My goal is to build a website that showcases my solutions to Advent of Code, but the first step is to have a site running on Rails, and in my case, hosted on Heroku.

Wish me luck!

Update:

Update:

Had to solve problems with installing the following gems:

• json
• pg

The json gem was set to 1.8.3, but I solved it by forcing the version to 1.8.5.

The pg gem was able to install after I properly re-installed Postgres on my machine.

Update:

Now running into problems with Postgresql.

Rails Study, Day 1

Not much to report, got my Rails up and running, and worked through two chapters of Rails 4 in Action.

Rails Up and Running

There's nothing like the hum of a mint Rails installation starting up for the first time.

Fresh Installation of Rails 5.0.1 on Ubuntu 16.04

I had to tinker a bit and re-install mysql, but otherwise it wasn't too bad.

State of the Mission, Monday 13th February 2017

The last two weeks have been quite productive:

As you can see from the abundance of black cells (each cell is one pomodoro), I have been busy studying.  I completed Learn Ruby the Hard Way, and got to work studying rails.  I am also deepening my knowledge of Ruby in a way that will look completely alien to a millennial, but which will stir nostalgic memories in some older readers:

First Steps in Ruby on Rails