I won’t be closing or redirecting this site because this was where I originally documented my time at Makers Academy. For prospective and current students, it’s helpful to know that I got up and running with a bit of help from WordPress before deciding to take more ownership of my blog. I want to show what my blog looked like before I knew how to code, the beginning of the learning curve.
That said, I will suggest that everyone follows the rest of my learn to code journey at my new site!
Thank you to everyone who has supported me so far!
Going to your first hackathon is a bit nerve-wracking. It was for me at least. I had absolutely no idea what to expect. It was an awesome experience, one I hope to repeat soon, but next time I want to be able to use what I learnt to help me get the most out of the next opportunity that comes my way.
So you want to build an Atom package. Some aspects of Atom make this an absolute joy, but some resources on the internet are seriously lacking, and this is my attempt to summarise all of the things I found out and learnt about building an Atom package.
This week we were introduced to Ruby on Rails! The magical steam train! The web app framework that you can have up and running in no time! In my makers journey so far, it’s probably the closest to magic that I’ve seen. You wave your wand and hey presto! It’s done a bazillion things for you already. Dare I say that was exactly what I didn’t like about it to begin with. I felt like I didn’t have to do any thinking. I came to realise however that the advantage of Rails is not in finding satisfaction in difficult debugging and planning, but in being able to put together a project quickly and accomplish more in a shorter time frame as a result.
Before we could even get started on the app, we needed to work out how we were going test our code. TDD is one the pillars of the Makers education after all. Despite using a string of testing libraries over the last few weeks, RSpec, Capybara, Jasmine, Mocha, Chai, I’ve never actually taken the time to look at the code and figure out how it works. So this is my attempt at breaking down a very elementary testing framework.
Week 6 arrived at Makers and finally we started working in groups! I’ve enjoyed pairing, but now that we’ve learnt just enough to take on all aspects of web development, working in groups feels so much more efficient. I had a lot of fun this week and was fortunate to be grouped with great coders, who I knew I would enjoy working with.
We were set with the challenge to build ‘Makers BnB’, an Airbnb clone, and we were free to use whatever technology we wanted. We had two choices really – Rails or Node.js. Airbnb is actually built on Rails. It’s suited to it. So why did we end up choosing Node?
“AJAX is a way to have a ‘conversation’ with the server and display the results without reloading the page.”
CRUD stands for Create, Read, Update and Delete and these four functions make up the basis of persistent storage in the land of computers. By storing a state as data, we can ensure that this state will remain even if the process that created it does not. For example, I developed a web app at the weekend where you could play rock, paper, scissors, and I used a singleton class to store my game. As soon as I stop running the app though, that data vanishes. I can’t recall the game history. It’s gone and that’s not ok. There’s an obvious need to store information. This is where CRUD comes in.
Dependency injection really isn’t as complicated as it sounds. Last week, a massive influx of new terminology and being introduced to new concepts, without having much time to digest them, sent my brain into panic mode. New concepts and phrases kept getting thrown around, ‘dependency injection’ being one of them, and somewhere along the way I got a bit lost in the crossfire. But that was last week, and now it’s time to explain what it is, why you do it and show you how it’s done.