Craft Academy Week 1

This blog is going to keep track of my journey through the Craft Academy Bootcamp over its 12 weeks runtime, this first blog is a little late, as Week 1 is Complete! So this one could be a little long…

Having this blog will be a good way to track my progress through the course and I think writing down what I’ve been up to will help cement what I learn. I’m going to try and keep this updated as much as possible going through the course, not just a weekly look back. I’ll add small blogs here and there whenever I get stuck on a significant blocker and then find a solution, keep track of things and features I find interesting in the course, and anything I think would be better written down.

Week 1 is complete, so here is a look back on what we did.

Starting off the course (not counting the prep-course) we began the week with the usual get to know you activities when you join a new group, which I think worked really well, with everyone in the class now knowing each other much better. There was a little more book keeping and then we got straight into the good stuff and started with with Ruby.

Ruby is a object oriented language built from the ground up for use in front-end and back-end applications. Comparing Ruby to JavaSctipt, the other language we will be using, it is incredibly easy to read, and can almost be read as simple English.

Straight out the gate we were paired up and given a challenge to create a virtual ATM. At Craft Academy we are really being instilled on the idea of Agile working and Test Driven Development (TDD). Agile is a way of working where the goal is to be very flexible with your work, create lots iterations of your work, and a whole bunch of jargon and buzz words, but it seems a pretty good way of getting things done.

TDD is an important part of the Agile method, it means before we right any functioning code we must create a test that will check the code were about to write to ensure its doing the correct thing. For testing Ruby we will be using RSPEC to check our code.

For the ATM Challenge we were given course material to follow, but as the project progressed the course material became less and less, and changed into a state of in-completion so that students could not copy it verbatim. This defiantly got us thinking on our own, and made us a bit paranoid of following the course material towards the end.

Using Ruby would mean we will not have an actual web page for this project as there is no User Interface(UI) with Ruby, so it will all be tested/running in the terminal. The aim of the project was to have an ATM, create an account on it that could be accessed via a pin number, and as a user of the ATM be able to withdraw and deposit to your account. So that meant creating three different classes to save all the attributes and methods required.

Without getting too much into the code, here’s the out put from all our test, as you can see there are a lot of them and some pretty basic ones in there, but they get more detailed as we get further through the class.

This took most of the week to complete, with a fair amount of hand holding all the way through, come the weekend we would have a new challenge and have to figure it all out on our own.

I imagine if I come back to this code in a few weeks time I will see an excess of mistakes and simple improvements that can be made to it. For now however it does everything that is required, plus a little more so we are happy.

Finishing the ATM Challenge on Friday afternoon we went straight into the next, the Library Challenge. Still using Ruby, but this time we had a database of books stored in a YAML file. We spent fair amount of time figuring out how to navigate around and search through the new file format to get what we needed. Definitely a lot of cross over with the ATM Challenge, but we still had to figure out some new techniques.

As we were again working in Ruby there’s not much to show in terms of UI, and looking through terminal outputs isn’t all that interesting, so I’ll save you from that. Talking of terminals though I have definitely improved my ability to read the error messages they spit out at you when you break something.

The Library is built up of two classes, the Visitor and the Library. We needed the visitors to have the ability to search for books via title or author, receive a list of available books, and checkout and return any of the books they like the look of. As a librarian we needed a few different feature, namely seeing all books in possession of the library and who currently has a checked book.

A couple of late evenings and we were getting green across the board on our tests. Had a few panics when I thought things were broken and not even remotely doing the correct thing, but ended up being false alarms. I really enjoyed puzzling out how to get everything working correctly and linking together all the different methods.

Some of the key takeaways from these projects were:

If you want to checkout either of these projects you can find them here:

and here:

Stay tuned for more, in the future I plan to go into a bit more detail on the code I write, and will try to keep it a bit shorter than this one.

Related posts:

This is my 176th article on Medium. I have started writing on this platform last year. However, I started writing regularly at the end of March 2020 — during the pandemic lockdowns. So, it has been…

Cryptocurrencies have now entered our lives, but one of the things people wonder about is how to make these money tangible, that is, spendable. Cryptocurrencies have no distinction from real money…

How well do we know the right customer for our marketing needs? Marketing without knowing the targeted customer needs is not easy. We need to be aware of the product needed by our customer, their…