Handmade Code

I've been really bad with my blog, but hopefully I'll be able to inject some new life into it when I start my new job on Monday! I really cannot believe it!

The whole Makers Academy experience has been incredible...what an unexpected journey. Four months ago I was completely lost in what I wanted to do with my life and saw Makers Academy as an opportunity to perhaps open some new doors for me and see what else I could offer the world. I read about graduates going on to find great jobs but I never once thought I would be one of them. I didn't really know what to expect to be honest. I just took each day as it came whilst at Makers, learned as much as I could, and kept an open mind.

The support from Makers Academy, post-graduation, has been phenomenal. Particularly the placements team and one of the tutors, Alex. Knowing full well that Alex's priorities are his current students, he's someone who really makes you feel as though he has all the time in the world for you. Whether it's reviewing my code or answering any questions that I've had about interviews and tests... he's been so generous with his time. I also cannot thank the placements team, Ruben and Sam, enough. They put me forward for some amazing jobs at some truly great companies, I was so overwhelmed! Their advice and encouragement was also incredible and really helped me get through some tough weeks and vulnerable times. I remember whilst at Makers in the 10th week they started planting the seeds in our mind about preparing for job search and this really stuck out for me:

When it comes down to looking for your first dev job, fresh out of Makers you really don't have a clue about what you want or what you'll like...and so if you absolutely must, pick one: Location, salary, industry or language.

This really got me thinking hard about what kind of company I wanted to work at. I thought I wanted to work in a cool industry - music, fashion, movies etc... but then I thought again, do I really want that?? Is it a priority for me to be in that industry? What do I actually care about? I spent 2 years working in music and while it was a hell of a lot of fun on a social level, I hated the actual work I was doing. I decided then and there that I would be completely open to anything as all I wanted was to be in a productive and stimulating work environment, somewhere that encourages personal growth, learning and development. I allowed the placements team at MA to put me forward for everything without any limitations and I promised myself that I would follow up on everything.

Turns out the next 5 weeks straight out of Makers were as busy as ever. Interviews, tech tests, pairing exercises...it was intense. I met some great people and great companies - some looked like a good fit for me, others did not. It was eye opening and made me realise what kind of role I wanted. This was only possible through interviewing because its only when you talk to people that work at the companies and go into their offices and actually see for yourself that you will actually know if its the right place for you.

Anyway, I start my new job on Monday! It will have been 6 weeks since I graduated, and a new cohort will be beginning their journey at Makers Academy. Goodluck to them :-) I hope they will find it as fulfilling and rewarding as I did.

I've been looking for a way to merge multiple git repositories into one while preserving all of the commit and file histories. I tried out several 'recipes' and finally found the one here and wanted to share.

The idea is to make one directory inside of which all other directories will be merged into and exist as sub-directories.

Heres's how to do it:

Step 1 - creating the master directory

mkdir master_repo

cd master_repo

git init

touch README.md

git add .

git commit -m "initial commit"

Step 2 - pull in the first repo

git remote add first_repo <[email protected]:username/first_repo.git>

git fetch first_repo

Check it out into a temporary branch and move over all of the contents into the sub-directory

git branch merge_first_repo first_repo/master

mkdir first_repo

copy/paste files into this sub-directory

git add .

git commit -m "moved over files from first repo"

Step 3 - merge the two repositories into one

git checkout master

git merge merge_first_repo

Step 4 - clean up the repo

git branch -d merge_first_repo

git remote remove first_repo

Never buy a good looking bootstrap template without researching how it will integrate into your rails app.

NEVER.

before do

    clear_emails # (╯°□°）╯︵ ┻━┻

Day 2 has finally come to a close and the project is moving forward really nicely. This morning there were a few more issues with the database migrations and the various associations between the models. But after ironing out some details as a group we managed to achieve a hell of a lot with our day.

A topic of debate today was centred around the payment system and how we were going to keep track of what users owe what amount to what event. This all came about through the realisation that we needed to generate a whole new model to store a list of invitees to an event. This list is generated on the creation of an event when an organiser adds his friends. When he hits submit, this will shoot off an email inviting them to the event. If an invitee consents to being part of the event by clicking a link in the email, the invitee is then taken to the site to complete the registration process by entering a password. This then creates an instance of a user and thus adds him into our Debts table. We know that the event organiser, when filling out the event details, needs to input some kind of monetary value that he needs to chase down. The questions that came out of modelling the invitees was whether or not to input the total amount the organiser requires to make an event happen, or whether he should input a single amount that represents what each individual invitee owes. For this, we would be working under the assumption that each invitee owes the exact same amount. The flip side to this was whether we should actually be working under the assumption that the organiser is owed a fixed amount and as invitees join and drop out of the event, the total amount dynamically distributes itself amongst the remaining users. This seemed to be a much more riskier model as there were a lot of edge cases to consider. This is definitely where we would like the app to be, but we came to the consensus that for the first iteration we will focus on building the most simplest, basic form of our app on which we can improve on in future iterations.

This idea of working through iterations has been a really interesting way of thinking about development. It completely removes the pressure that comes with the expectation of delivering a finished product by a certain date. Through fast deployment and really short sharp work cycles, the site is revealed through regular iterations starting in its most simplistic form. It enables us to demonstrate its core functionality from the very beginning, which we wouldn't really get to do when diving head first into tackling the most complex version of our features for final delivery months down the line. It wouldn't really be an efficient use of time if, after spending months of work developing the idea of a perfect product, it turns out to be a load of crap. Getting a working prototype out there quickly allows us to determine whether or not this really is a good idea and whether it's something worth investing our time in developing.

We hope to have our first iteration of Angry Kitty complete by the end of the week. A WEEK. It seems really achievable at this stage and it's an awesome way of working. We will end up constantly revisiting our code and improving it. Bugs will be fixed as fast as they are flagged, and the chances of randomly breaking the site and the subsequent time spent trying to fix it is eliminated. It's just an overall cleaner way of working and its great that the team has naturally adopted this way of developing.

Anyway that was a tangent! Today we managed to get our emailing system set up and wired to the database. A peer to peer payment system has also been set up via Stripe and, on successul payment, triggers the sending of a confirmation email to the participant and a payment notification to the organiser. Tomorrow we'll need to get the triggers sorted for sending out an event invitation and the harassment emails.

The scheduler is also pretty much sorted now. We've created various time buckets that represent the number of remaining days left till the payment deadline. The frequency of emails being sent out are defined inside of each time bucket. This now needs to be wired up to an automated rake task that will trigger the send of the harassment emails (a task for tomorrow). We haven't explored how to make a rake task at Makers Academy yet so tomorrow will be interesting.

The event creation is also pretty much there. We have an organiser_id inside of our Event model which grabs the user_id from a user that creates an event. We've done this so we can query organisers directly on an event if we need access to this information, and to ensure that they don't get added into our Debt table.

This is it! The final two weeks at Maker Academy!

For context: We will now be working on our final major project, the end product of which will be the result from months of hard work :-) I have an awesome team of seven people and today was Day One. The website we will be developing is Angry Kitty - an app designed to chase down money you're owed from your friends when you've footed the bill for a group event.

It's kicked off to a pretty decent start. The repository is up on github; we have a list of "must have", "should have" and "would be nice to have" features; we've decided on the fewest and simplest features necessary to complete our first iteration of the app; we've paired off and assigned a feature per pair and mapped out every scenario for each feature; we have a task management system up on the white board; we've decided on and generated all of our models; and we've written all of our Cucumber feature tests.

[image1]

These are our models so far:

Event

User

Debt

Payment

We also have our three classes to represent the three different types of emails we will be sending:

The event invitation

The chaser/harassment

The payment confirmation

We also need a scheduler to determine the date and frequency of messaging based on the time remaining till the payment due date (set by the organiser of an event) and the time a participant (a friend of the organiser) last received an email (the harassment). The scheduler then communicates with a rake task that then triggers the sending of messages based on these two variables.

A topic of debate today was deciding how we were going to determine where the scheduler obtains its information from. It was unanimously agreed upon that we would be creating a join table between Events and Users: An event could have many users, and a user could be part of many events. But then we also needed a table identical to this one that contained more information to feed into our scheduler: the due_date and the last_harassment date. We also recognised that we needed some kind of model to represent a single Debt. That is, a list of users associated with an event with a payment status of 'false'. A debt belongs to a single user but a user could have many debts. Similarly, a debt belongs to an event but an event could have many debts. It is through this association that a User could have many Events and vice versa. The diagram in my notebook illustrates this concept. In this sense, our join table could also double up as our Debt model and so we went with this design by adding some additional columns "due_date" and "last_harassment". Here's a page from my notebook:

[image2]

Within the context of my Instagram-Clone project at Makers, I'm going to tell you how to extract the code that generates a single post into a partial and render it into various views. Here's a simplified version of what my code looks like in my index (I'm only displaying a caption to keep this short):

<% if @posts.any? %>

  <% @posts.each do |post| %>

     <%= post.caption %>

  <% end %>

<% end %>

To create a partial for my posts, I'm going to extract the code inside of my @post.each block and paste it inside a new file called _post.html.erb located inside of my posts directory which is in my views directory. Then I am going to delete <% @posts.each do |post| %> and its corresponding  <% end %> as the partial SOMEHOW knows to keep iterating through all my posts. Then to render my posts back into the index, just place in this line to call on the partial I just created: 

<%= render @posts %>

The instance variable @posts refers back to the Posts controller:

def index

@post = Post.all

end

Today I was continuing work on my Instagram-Clone application, making some good progress and slowly getting to grips with Rails. I wanted to have the functionality where a logged in user could 'like' peoples posts. This was fairly straightforward until I then thought a bit more about who could have access to this feature. I wanted to restrict the 'like' feature to signed in users only. So when a signed out user tries to like a post, they would see the error message "You need to be logged in to do that!" flash up on the screen. I also decided at this point that I wanted to use the raise and rescue combo to solve this problem. A simple fix could have been to just hide the like button from the view of signed out users, but it didn't seem secure enough. I wanted to completely cut off this functionality from within the back-end of the application, and then hide it from the front-end view for good measure. This is where things got interesting!

Here is my solution in the create action of the Likes controller:

def create

    @post = Post.find(params[:post_id])

    @like = @post.likes.new

    @like.user = current_user

    @like.save!

    flash[:notice] = "Thanks for the like!"

  rescue ActiveRecord::RecordInvalid

    flash[:notice] = "You need to be logged in to do that!"

  rescue ActiveRecord::RecordNotFound

    flash[:notice] = "Record has been deleted already"

  ensure

    redirect_to('/posts')

  end

end

I've thrown in a bunch of flash notices to make things a little obvious about what's going on. What I found interesting was the use of save! (with a bang) rather than save (without a bang).

In order to rescue an application, the application needs to crash. In order for the application to crash, I need to somehow kill it and this is where the behavioural differences between @like.save! and @like.save is paramount. While the former kills my application, causing everything to terminate (thus setting itself up nicely for my rescue), the latter returns a boolean value. In this case, it returns the value false. I suppose this kind of return could also be interpretted as a kind of shrug or 'meh', as it recognises that a current_user doesn't exist before continuing on to the next step and producing the flash notice "Thanks for the like!". This is weird behaviour because the user is not logged in and their like isn't being saved to the database. I know that it isn't being saved to the database because of the following line in the Like model: 

validates_presence_of :user

If this line was not present, then a signed out user would be able to like a post. The 'like' would then be added to the database, but without a user_id assigned to it leaving an empty cell in the join table. If I was trying to render the user's information on the front-end like this...

<% post.likes.each do |like| %>

  <%= like.user.name %> likes this

<% end %>

..Then, my application would eventually crash because it doesn't have access to any user information for that particular like. ActiveRecord would probably complain about something to do with Nil.

I've just committed and pushed a README.md up to github. Two seconds later I notice a small typo. I don't want to fix it and then push it back up to github as a second commit because, well, it just seems untidy to me. I wish I had spotted the typo sooner before I committed and pushed the whole thing up. I would rather that something as tiny and insignificant as this could just be joined together in one commit.... here's how!

git commit --amend

"Write your commit message"

press the esc key

:wq

git push --force

The above steps allows you to add an additional commit message to your previous one. If you want to overwrite the last commit message entirely:

git commit --amend -m "the new commit message"

* { box-sizing: border-box; }

Right now I have created a database (one for testing, one for development), and I have one model for the Cheeps. I am able to write a cheep and save it into the database and have it visible on the screen. I have a database cleaner gem installed and setup for my testing environment so I'm not filling up my test database every time I run cucumber. The core functionality of Chitter is done. So far so good.

In this part, I want to start thinking about user management. I want to be able to get users to sign up, sign in, and sign out. And I only want signed in users to have access to the Chitter application (that is, reading and writing cheeps). So let's start with signing up brand new users.

Create a new file called user_management.feature inside of the features directory and write the first feature:

Feature: User can sign up to Chitter In order to use Chitter As a brand new user I want to be able to sign up

Scenario: Open the homepage Given I am on the home page Then I should see "Sign Up!"

This is a really basic test but this gets me thinking about creating a Sign Up button in my index.html, and that I want it to redirect the user to a sign up form.

<form action="/users/new" method="GET"> <button type="submit">Sign Up!</button> </form>

Cucumber should pass this test once the button has been added. The form action tells us that it will redirect the user to the /users/new path where I would like my sign up form to be. This file hasn't been created yet. Let's write a test.

Scenario: Signing up for Chitter Given I click on "Sign Up!" When I fill in "name" with "Bob Test" And I fill in "email" with "[email protected]" And I fill in "password" with "123" And I fill in "password_confirmation" with "123" And I press "Go!" Then I should be logged in

This test outlines the steps a user has to take in order to Sign Up. Run cucumber, copy/paste the snippets into a new file in your step definitions directory called user_management_steps.rb and fill out like so:

Given(/^I click on "(.*?)"$/) do |button| visit '/' click_button(button) end

Then(/^I should be logged in$/) do expect(page).to have_content("Welcome, Bob Test") end

Cucumber is still very much red right now because the form does not exist. So lets create the form to pass most of these tests.

Create a directory called users inside of views, and a file called new.erb

<h1>Sign up to Chitter</h1>

<form action="/users/new" method="POST"> Name: <input type="text" name="name"> Email: <input type="text" name="email"> Password: <input type="text" name="password"> Password confirmation: <input type="text" name="password_confirmation"> <button type="submit">Go!</button> </form>

The next thing that has to be fixed right now are all of the route requests on our chitter server page. Head over to chitter.rb lets write them to make sure everything is linked up.

get '/users/new' do erb :"users/new" end

post '/users/new' do User.create(name: params[:name], email: params[:email], password: params[:password], password_confirmation: params[:password_confirmation]) if user.save session[:user_id] = user.id redirect to('/') else flash.now[:errors] = @user.errors.full_messages erb :"users/new" end end

So, the "Sign Up!" button on the homepage sends a get request to the server where erb :"users/new" is required. This is our sign up form. The user fills out the information and hit's "Go!". The button sends a POST request to the server where the information input by the user is saved to the database with the parameters name, email, password, password_confirmation. When the user is saved to the database, a session is assigned to the user's id (generated by datamapper), and the user is redirected to the homepage. The else statement is for when the user inputs incorrect information that will create an error message. I will discuss this in Part 5 but for now lets skip over this.

When a user has successfully signed up and is back on the homepage, I would like them to greeted with a personalised welcome message. I am going to put this Welcome message in layout.erb, but I only want it to be visible when a user has signed in:

<% if current_user %>

Welcome, <%= current_user.name %> <% end %>

current_user is a method inside of a helper method on the server chitter.rb file:

helpers do def current_user  User.get(session[:user_id]) if session[:user_id] end end

Here, I have defined the current_user as someone from the database that has been assigned to a session. Therefore if a user visits chitter and is not signed in, they won't see the welcome message. When they sign in, they will see the message!

Now what happens when you run Cucumber?

uninitialized constant Chitter::User (NameError)

This is exactly the error I want to see. I have so far been working under the assumption that a User model exists. Obviously I haven't created a table in the database to store any Users, so right now we aren't saving any user information anywhere.

I guess I should have known this from day 1, but I've had this piece of code in my layout.erb page in all of my projects since I started playing with sinatra and didn't know what the hell it was doing:

<%= yield %>

Then I realised it was requiring various pieces of code from other erb files. But how does it know what code to yield? Magic? Essentially, yes.

I keep getting confused about params and when to refer to it in my application. In fact, what does params even mean?! 

Well, today I learned that from the application, params request data from the BACKEND. And the reason for my confusion? The back-end is very different from the DATABASE.