Global variables are dead… Long live databases! This week we worked with much the same technologies as in week 3, Ruby, Sinatra, Rspec and Capybara, but there's been a huge change in that we've shifted from persisting our data within global variables (generally considered bad practice) to databases (good practice).
After using purely Ruby (and its related libraries) for some time, working with databases initially required us to begin learning a new language in the form of SQL, or Structured Query Language. SQL is initially notable to me because by convention much of it is written in upper case, so it looks like it's always SHOUTING AT YOU. There are many syntactical and conventional differences between SQL and Ruby, it's just a very different language that serves a very different purpose. We spent some time learning to set up databases using the PostgreSQL database management system, learning how to put data in those databases, and how to access and amend that data. While this was perfectly manageable, the necessity to learn both SQL and the practicalities of database management at the same time made for some slow progress.
Thankfully not long after discovering SQL and getting acquainted with some of its intricacies, we were introduced to an ORM (Object Relational Map) called DataMapper, which simplifies things greatly. DataMapper is a Ruby to SQL ORM, meaning that once implemented within our Ruby code it enables us to communicate with our databases using familiar Ruby syntax, which DataMapper translates to SQL in order to communicate with the database. DataMapper also takes the SQL returned from the database and translates it back to Ruby before passing it to our code. While it will be useful to become more familiar with SQL in the future, it's a real help that we can communicate with databases at this stage without having to know SQL intimately. Adding this persistance layer in the form of a database means that we now finally have the ability to produce full stack web applications. We've been told that once we move to the popular Ruby on Rails framework we'll be using its own ORM called Active Record rather than DataMapper, and presuming that it does an equally good job of abstracting away the underlying SQL code, it'll be more than welcome at the moment.
This week a group of us congregated in a new Slack channel with the specific intention of learning to use an arcane text editor called Vim. I named the group #vimClub, which so far seems to have stuck. Vim draws its roots from a similar editor named VI, which was released in 1976. Vim, or Vi IMproved, still looks like a text editor from forty years ago, which is a big part of its charm. Vim's behaviours feel very 1970's too, it runs directly on the command line (there's no Graphical User Interface), and it doesn't recognise the mouse or even basic interface conventions that we now take for granted. To navigate around the document the cursor keys offer no assistance, you need to use the H, J, K and L keys, which correspond to the right hand home position of the keyboard, useful if you're a touch typist. To quit Vim, there's no visible solution, no menu bar to try. To quit you must type either
:wq depending on the circumstance. Vim does offer a select few modern touches, for instance the ability to open and switch between multiple files in separate tabs, however you'll have to use the
gT commands to navigate between them. A huge part of Vim's infamous difficulty curve is in trying to remember all of these often unintuitive keyboard commands. The consensus from seasoned users is that Vim can make you incredibly productive once you're able to use it well, because for one thing there seems to be a keyboard command for almost any conceivable action that you care to take, so you never need to take your hands away from the keyboard to reach for the mouse. A common complaint that we're hearing among experienced developers is that they wish they'd learned Vim earlier in their careers, because it can be difficult to justify learning it while working as a professional coder due to the inevitable decrease in productivity at the start. Those of us who make up #vimClub have decided that by starting to learn now we should feel confident enough to use it productively by the time we're looking for a job.
Some concerns from the cohort
Each week our work load consists of one large challenge, which is broken down into several smaller tasks, confusingly also called challenges. Nobody that I know of from my cohort seems to have completed a single week's large containing challenge yet, partly because there are just so many sub-challenges to get through in a given week, and partly because the pair-coding system we use often requires one partner to drop back a significant way to work with their partner. This system has started to become a bone of contention amongst the cohort. Our coach Sam assures us that it doesn't matter how far we manage to progress through the week's work, because the important point is that we're always learning, rather than trying to hit an arbitrary point in the work load. The trouble is that while this makes sense to a point, most of the concepts taught during the week's work will be required again for the weekend's solo challenge, so surely we'll be at a disadvantage if the weekend's work requires skills that we haven't seen yet. In previous weeks this hasn't been a huge issue, we've mostly managed to catch up with the week's work at the start of the weekend before attempting the weekend challenge.
This week however there was a huge amount of new information and a very large challenge, and many of us only reached the halfway point by the end of the week. When the weekend challenge arrived a lot of us felt lost, because we were now expected to use some advanced database features from the latter parts of the week's challenge, which we hadn't even seen yet. The only way for many of us to complete the weekend challenge was once again to complete the remainder of the week's work first, which this time was a huge task. It was achievable, but so demanding that it required my presence at the computer screen for a solid sixteen hours on the Saturday. Makers Academy are well aware that there are shortcomings in their relatively new curriculum, and are actively working to rectify these kind of situations. This week has highlighted a big problem that does need to be addressed, and as a group we made that point very clear during the end of week retro meeting.
Chitter and peeps
The content of the weekend challenge itself was as usual enjoyable and challenging. We were tasked with creating a basic clone of Twitter (to be called Chitter), as usual using the same technologies that we used throughout the week. Once the basic functionality to write peeps (Chitter's version of tweets) was in place we were given the choice between two further objectives; either to implement the ability to reply to somebody else's peeps , or instead to use HTML and CSS to improve the visual appearance of the site. Since the beginning of the course we've paid little-to-no attention to the appearance of our creations, because the implementation of the functionality has been the learning objective. I'm equally interested in the front end of web development and the back end, so I opted to work on the site's appearance this week.
Interestingly HTML and CSS have been almost entirely absent from our course, we haven't had to use them very much at all, in fact other than briefly mentioning them once or twice it's not actually taught at all. Even though it's a vital skill to learn, it seems that it's considered simple enough to be easily picked up alone with little guidance. Sam suggested that our choice of further objective this week is often an indication of whether we're better suited to working on the front end or the back end, so it'll be interesting to discover if that's true.