Sharing Handlebars Templates on Both Server & Client in Node.js / Express with Webpack

Whilst React and Angular have become more or less ubiquitous in developing Node.js web applications, Handlebars often gets overlooked as an effective templating engine.

It’s very simple to use, isn’t overburdened with features (and code) you don’t need and is very flexible with the ability to write custom helpers.

In my last job it was used as the main templating engine and had been tooled very effectively to make it easy to use. However after leaving that organisation and doing a little project for myself I was struggling with how to best set up handlebars templates that could be used on the client as well as the server.

Google wasn’t particularly helpful – lot’s of precompiling and script tags, whereas I was keen to use Webpack to bundle up the client side assets. So once I’d figured it out I thought I would write this blog post to remind myself in future and perhaps help others.

File Structure

I’m going to assume that you have set up your node.js / express app, so will just highlight the areas that impact the handlebars and webpack set-up. This is not a complete structure, but focuses in on the key elements that I’ll be covering.

├── client
| └── src
| └── main.js
├── views
| ├── layouts
| └── main.html
| ├── partials
| ├── shared
| └── my-shared-template.html
| └── home.html
├── app.js
├── package.json
└── webpack.config.js

Packages Required

You’ll need to install three packages via your package manager (NPM or YARN etc.).

Setting Up The Handlebars Instance For Server Rendering

In app.js you should set up express and handlebars as follows;

Key elements here are that a handlebars instance (hbs) has been created with some configuration options;
defaultLayout: this is an express-handlebars concept of a page wrapper, see express-handlebars documentation for more detail.
extname: have set this to html rather than use the default of handlebars. This setting needs to be followed through in the set-up of the view engine.
partialsDir: it would have defaulted to views/partials, however as I want to share one or more partials on the client, I have created a views/shared folder to store shared partials, so have registered both directories with the handlebars instance.

Then the view engine is set up, using html as our file type and our handlebars instance’s engine (hbs.engine).

So now when the server is started and we navigate to the base url, the views/home.html template will be rendered, within the views/layouts/main.html wrapper.

Setting Up Webpack For Client Side Templating

to enable the handlebars shared templates to be used on the client side, a loader is needed in the webpack configuration.

The webpack.config.js should be set up like this;

The entry and output is set up to webpack the main javascript bundle, in which the shared handlebars template is referenced (more explanation on this below).
The handlebars-loader has been added to take .html files from the views/shared directory and make them available to the webpacked javascript.

Using the Handlebars Template on the Client

So now that the configuration has been done, the template can now be used on the client in the following way in the client/src/main.js file;

This is a very basic example to demonstrate rendering the template into the page with some data. It is more likely that the template data would be retrieved via an api for example, but hopefully you get the idea.


Whilst this isn’t covered very effectively in various documentation, it is very straightforward to do. From there on you can take advantage of the full feature set of handlebars. Drop me a line if you have any questions or leave a comment below.

Learning to Code – Week Twelve

Finding Work is Hard Work

After the adrenaline buzz that was weeks 10 and 11 working on our final projects, an easy week 12 would have been very welcome. However that’s not the Makers’ way!

Week 12 was hiring week where the code coaches take a step back and the career and hiring side of the team (Ruben and Will) to kick us into shape for the job market.

Personal brand, tips on tech tests, CVs, personal career 1-2-1’s, cleaning up your GitHub, interview preparation, how to find companies and roles and lastly a mini-’employer fair’ with 7 recruiting organisations pitching to us as to why we should work for them.

An absolutely packed week with the employers pitches on the Friday morning being a real buzz to hear the enthusiasm of the speakers about the industry and their enthusiasm for Makers’ alumni.

Our ‘Unfair’ Advantage

The employers enthusiasm for Makers alumni seems to stem from three key areas;

  • Test and Behaviour Driven Development, which is the cornerstone of Makers Academy.
  • A desire within Makers students for continuous learning.
  • The wealth of experience that Makers students have from their careers and experiences pre-Makers.

These three things I hope will give myself and my fellow Makers cohort a real advantage in the job market. It’s not really an unfair advantage, we’ve just been dedicated and driven to put ourselves in that position.

Code On The Beach

After a more subdued Friday night, with a few beers with some fellow graduating colleagues, I was fortunate to be more worried about packing for the beach as my wife and I got away for a week’s relaxation after a non-stop 3 months.

It was a great experience on landing to fill in the immigration form and for the first time under occupation put ‘Web Developer’!

But it’s difficult to turn off from coding. Not only did I take along books by Sandi Metz, Jon Duckett and Martin Fowler, but I also woke up on Monday morning to find out that I needed to get a tech test done for of the companies from the employers fair that I was interested in working for.

Coding on the beach was a new experience, but I found it an environment where I was able to focus with few distractions (except for the heat, turquoise sea and beach bar). So if anyone has any Junior Developer roles in beach locations then let me know how to apply.

Life After Makers

So now begins my post-Makers life. It has been a truly awesome experience, life-changing and intense.

My intention now is to find the right role and organisation where I can continue to learn my code craftsmanship and contribute to the development of truly great experiences and products on the internet.

In the meantime I will continue to learn, practice and engage with the industry to help me on that journey.

Thanks for reading this far and for following my posts as I’ve gone through the experience.

If you’re inspired to take the same journey then take the first step and put in your application!

Learning to Code – Week Eleven

What’s a Beacon?

On Monday morning of week 10, the teams for our cohort’s final projects were announced. I was in a team with Matteo, Jack, Hannah and Marcin. We’d all expressed an interest in working with beacons, but to be honest, none of us actually had much idea what a beacon was.

It says something about the what and how of the Makers Academy experience that we didn’t just want to consolidate things that we’d learnt but carry on learning new things, even in our graduation project.

So project task number one was to Google what is a beacon. Once we’d worked out that it was a device that emits a bluetooth signal (and we’d tracked one down in the Makers office), we spent the rest of the day brainstorming ideas of what to  do with it.

We thought of plenty of ideas, such as;

  • Providing an added layer of security for Uber, so passengers can ‘authenticate’ their ride before getting in.
  • Creating collaborative location based digital art installations, where you can only contribute / view when in range of the beacon.
  • Providing a ‘promotion and communication platform’ for independent stores, to enable them to target passing shoppers and battle back against internet shopping.

TurnUp TuneIn

The idea we settled on was to improve the experience of collaborating with friends on a party playlist of songs. Hannah came with an insight from a Karaoke bar where at the end of the evening there were lots of songs still to play that were chosen by people who had left. The idea we had was that songs should come and go with the people (hence the name TurnUp TuneIn) and we would use the beacon to marshall this operation.

There were lots of challenges with this;

  • How would we know that people arrived / left a party? So we built a mobile phone app that recognised the beacon at the party and knew when it was in and out of range. (we’d not built a mobile app before)
  • How would we give the party organiser access to the songs? We used the API (Application Program Interface) for Spotify to create playlists and add / remove songs. (we’d had a little experience with APIs before, but not this one).
  • How would we get party goers to choose their songs? We created a lightweight Mongo database to store song choices along with party details. (we’d never used this type of database before – quite different to PostgreSQL).
  • And then a NodeJS / Express server to pull the whole thing together, with a front end for party planners and party goers, and interaction with the database and mobile app. (We’d done some Node before but not on this scale).

You can see that we gave ourselves plenty to do and after spending the first day choosing the proposition and knowing that we had to freeze feature development the next Wednesday we only had 7 days (and the weekend) to build it. Challenge on.

Graduation and a Live Demonstration

On the Friday of week eleven it was our graduation. There was a packed audience as it also coincided with Makers Academy second birthday celebrations and the evening started off with a few previous alumni talking about their experiences after Makers and passing on hints and tips on how to survive and thrive as a developer.

Then the presentations for the final projects. We’d elected to go last as our’s was a party project we wanted to give a live demo to get the party started. So we had to nervously watch the other teams present their work. Their was a real diversity in the projects that other teams had worked on;

Meshee: a project that ‘rebuilt the internet without the internet’  using Raspberry Pi’s to generate a secure wireless chat application not connected to the internet.

I am me:  A really visual way of personalising a what’s on calendar to individual tastes and preferences.

Horsell Snow Angels: Providing an automated solution to managing volunteers and task allocation for a groups that assists older people during poor weather.

One Day:  An application that links young people searching for employment with professionals who can offer a day of mentoring / work experience.

Then it was our turn. As well as showing a video demonstration of how our website worked we’d decided to do a live demonstration that would bring the concept to life. Always a risk to do it live, but we felt confident  and had even loaded the app on to the phones of a number of fellow students and staff at Makers and at the end of our presentation we got them to also ‘TurnUp and TuneIn’.

It was great to see the songs joining the playlist in real time as people opened their apps and joined the party. Success. And then the party started.

Reflecting on the project, it was great to work in a team with such a mix, who all brought a lot to the project, and it was amazing to have achieved something that we didn’t know how to do at the start. A real testament to the process at Makers and the drive of our team.

Now it’s on to week twelve with a focus on how to turn the skills we’ve learnt into a career.

Learning to Code – Week Nine

Railing Against The Machine

This week we’ve been focused on Rails, a framework for Ruby development, that builds on our previous experience with Sinatra.

The initial impressions were that this is full of magic, that it ‘scaffolds’ the developer, albeit with a huge directory structure that seems akin to learning the ‘knowledge’ for a London cabbie.

However once you get to grips with it you get to understand that the magic is just rather clever programming based on ‘convention rather than configuration’. This leads to it being described as opinionated, ie. You have to do it the Rails way.

But once you get over that, you get to understand the power it gives to the developer to create great products with a minimum of heavy lifting in the set-up allowing you to focus on the real guys (or business logic) of your concept.

Thinking On Your Feet

Next week we start the two week sprint to our graduation projects. Which meant on Wednesday we had our Jamboree’s where ideas get pitched that we get to choose from.

It started with a few charity projects. A couple based on youth opportunities, an unfortunately growing issue, and one based on organising community volunteers.

Then it was the turn of the Makers community to do their pitches. The format is you join the queue and have a maximum of a minute to pitch your idea. At the last Jamboree, as a Junior, I only pitched one idea.

This time I joined the queue and after pitching rejoined the back of the queue until it was over. I did this even if I didn’t have an idea, using the queue time to come up with something. There’s nothing like thinking on your feet, great practice for the real world of work. I can remember 6 of my pitch ideas (though there could have been more);
Rubik’s Cube meets Countdown Conundrum – solve anagrams rather than colours.
Inactivity Tracker – inspired by hearing 2 pitches about activity trackers just before I got to the front of the queue – rewarding in activity – could be great for parents with over active kids
Manage Your Round – Pub app to remember what you were supposed to order at the bar and whose round it is next.
Drone Coffee Delivery System – from the coffee shop across the road to a third floor window with a dual authenticated NFC “air lock” to accept the delivery limiting it to trusted suppliers (I don’t think it’s as crazy an idea as it first sounds)
Business Networking ‘Grab A Coffee’ App – to extend the LinkedIn Mentality into quick, low cost opportunities to expand your knowledge and business relationships
Makers Academy Video Playlister – stores links to all the useful videos of lectures, webcasts etc. with easy keyword search, ratings from students and the ability to create an individualised ‘to watch’ playlist.

Ideas, Technology & Customers

The value of ideas really came home to me towards the end of the week after the Jamboree and a talk from Makers Academy CEO Evgeny about the Makers journey from cab ride idea to first cohort (in only a few months) and celebrating their 2nd birthday this week.

During the week we’ve been using Rails to build a version of Yelp and our weekend homework is to build a version of Instagram and have previously done a Twitter clone.

These are all technologically relatively simple to get to 1st base, but what sets a successful piece of development apart from the start-up graveyard is the quality of the idea, embedded in an understanding of the market you’re satisfying. Which explains the billions Facebook spent on What’sApp.

On Her Majesty’s Digital Service

One organisation that has already got a huge customer base and is investing in digital services is Her Majesty’s Government. On Thursday we had a lunchtime talk from a couple of folks from the Home Office.

They (and other government departments) are doing some great work in bringing the services many of us use and rely on into the digital era, making our lives easier, better connecting citizens with government, whether it be immigration, passports, jail visits or power of attorney.

Whilst they are not short of users, they in common with most organisations, are short on digitally skilled staff. So it was great to see them at Makers pitching, very convincingly, as to why we should consider the civil service as a great place to ply our newly acquired skills.

Learning to Code – Week Eight

Google – Thousands of Wrong Answers

One of this week’s guest speakers, Chris Bunnett CTO of Adgistics, said an interestingly controversial thing. To paraphrase, “Google is awful, it brings you back so many wrong answers and leaves the user to wade through them.” An astute observation, but not one many people thing about, given how ubiquitous Google has become in our lives.  Putting more hay on the haystack doesn’t make it any easier to find the needle.  When will the web be able to find the single perfect answer, rather than thousands of wrong ones?

This was also the type of problem that a team of us had a go at solving in our “Makerthon” this week…

Smart Twits

Our “Makerthon” project was Smart Twits, based on an idea I pitched to the cohort about having a solution to the problem of looking at Twitter’s trending list and not understanding why it’s trending – or as I described it, “is Stan Collymore dead?” which is usually the first reaction to seeing someone’s name trending.

With Richard, Marcin, Bibiana and Emily we created a single page web app (see image) that had two key components;

  • a scheduled refresh of top trends and latest associated tweets that writes summarised information to a set of flat files, every 10 minutes, as Twitter updates it’s trends.
  • a front end that reads the flat files and presents the information immediately to the user.

For a project that we started Tuesday lunchtime and presented back on Friday afternoon, it was a great piece of work, and a good trial for our final project (weeks 10 & 11) and a good introduction to team coding and project management (using a Trello kan ban).

From a technology perspective the core was Ruby, within a Sinatra framework, tested with RSpec, HTML 5 front end with a good measure of CSS (based on a grid model, but not Bootstrapped!), a D3 word cloud (with a bit of jQuery), plus a Unix based job scheduler and of course utilising the Twitter API.

Remembering Psion

Our other speaker this week was Charles Davies, CTO of TomTom. A couple of really interesting things stood out in his talk;

  • he was part of the initial Psion team, which brought back fond memories of my first handheld computing device, the Series 3c
  • the convergence and divergence of software / hardware. TomTom first gained prominence with selling their own hardware, but now sell their software for integration with others hardware – but as they push boundaries with new software (eg. fitness), there’s not necessarily the 3rd party hardware for it, which sounds like it could go along a similar cycle.

Learning to Code – Week Seven

Who’s Side Are You On?

This week we have been focused on Node.js, which is, according to Wikipedia, “an open source, cross-platform runtime environment for server-side and networking applications.” Right, it didn’t mean much to me either at the start of the week. But this has been a week when the architecture of the web has become slightly less blurred to me. It helps to understand that JavaScript was developed to make browsers work (it was developed for Netscape, remember that?).

But what Node.js does is enable JavaScript to run on the server in a similar way as Ruby does.

This differentiation between client side (browser) and server side (application engine) has really become clear this week (even though we’d already tackled both through Ruby & Sinatra), but still it’s an area I’d like to understand better to figure out what should go on each side.

JSON and the Cybernaughts

Also this week we’ve been learning to consume APIs (application programme interfaces). It’s interesting to see how JSON objects (JavaScript Object Notation) have overtaken XML as the responses to API requests. Lot’s of organisations offer API’s, including the UK Government Digital Service. APIs offer a fantastic way to consume data and create new value out of it, as the September cohort did with Twitter and Tesco.

Ruby, Ruby, Ruby

Our weekend challenge this week has been a series of around 40 small challenges back in Ruby. They have been great fun and a change from the larger scale projects and it’s been nice to go back to elegant syntax and wide vocabulary of Ruby as opposed to JavaScript.

Also this week the February cohort started. On Friday Ptolemy from our cohort took over running the “CodeJam”  and it had a good focus on puzzles the Juniors could do, with a “coach” from the Senior cohort helping out each Junior team. It was a fun experience and for me it was a good prelude to our weekend challenge.

Just to bring it back round to JavaScript, the photo is of my favourite coffee spot in Spitalfields – The Coffee Cup in the grounds of Christ Church Spitalfields, excellent flat white and extremely tempting ginger cookies…

Learning to Code – Week Six

You sank my Battleship!

This week was reading week, a welcome chance to catch my breath after five whirlwind weeks, and to consolidate some of our learning.

One thing I got around to was finishing my web version of the Battleships challenge from week three which I have written about previously.

It’s great to have a properly working full end to end two player game, plus I think it looks pretty good in battleship grey with a militaristic courier new font. (see the image above), or play the game.

I completed it in Ruby / Sinatra, which after a week of JavaScript, wasn’t too difficult to get back into the swing of.

However, I’m still not happy with the Battleships game – in completing it, I ended up with a ‘spike’ approach rather than the test driven approach that is drummed into us at Makers. So I felt a little dirty after doing it.

It’s a bit of a dilemma now as to whether to go back and do the tests or not. If I do them, it won’t be test driven development, but if I don’t I’ll have an untested codebase which will be difficult to maintain properly.

fOOD For Thought

I’ve written before about SOLID principles and Object Oriented Design. I’m still frustrating myself with trying to get this right across my projects. It’s not simple as the objects in programming aren’t always the same as the objects we’ll experience in real life. So you have to abstract the processes and think more about responsibilities and dependencies.

I’m embarking on reading Sandi Metz’s Practical Oriented Object Design in Ruby which has been strongly recommended, so hope to be out of the wOODs on this in the near future.

Senior Citizens

Friday evening saw the graduation of the October cohort who started six weeks before us. They had the opportunity to present their final projects, which included;

HipSpot – a mash-up of twitter and restaurants, cafes and bars to help identify where the hipsters hip spots are.

LightBox – a secure messaging systems designed for doctor to doctor peer communication with the highest levels of encryption.

Solr – a project for the 10:10 charity that enables an easy site survey of how good your roof would be for generating solar power.

It’s amazing to see how much can be achieved in such a short period of time (the final projects are completed in less than 2 weeks).

But it also means we have to say goodbye to our seniors, who have helped mentor us through our pre-course and the first six weeks of our course.

This also means that our cohort become the seniors on Monday when the February 2015 cohort start. Quite a responsibility.

Learning To Code – Week Five

Cascading Style Sheets (CSS)

“Working with CSS is like having a small child hitting you – it’s painful and there’s not much you can do about it”.

As our coach Roi this week described it. After learning Ruby and some JavaScript, working with something which is seemingly unpredictable has had it’s challenges when it doesn’t respond the way you expect.

There were a couple of positives;

  • being able to play around with the elements through the developer tools built into the browser.
  • being able to create designs that are responsive to the screen size (see the example in the picture which is controlled purely through the CSS.

I’ll be looking into developing my own ‘grid model’ which is a recommended way to harness CSS and help you create the design you’re after. It’s the principle that many frameworks like Bootstrap are based on. But there’s no substitute for real understanding, even if you do use these frameworks in the future.


Also this week we got stuck into JavaScript. Coming after having spent the previous four weeks focused on Ruby, I was slightly hesitant to start with a new language. However within a couple of days (and a number of times of writing the wrong syntax (eg. thermostat = instead of = new Thermostat();) it was relatively painless, though conscious there’s a lot more to it that the loops and if / else’s I’ve focused on so far.

Though it is less tolerant

One thing that was frustrating, but now feels helpful, is that JavaScript is a lot less tolerant on syntax than Ruby. Ruby has it’s ‘poetry’ mode where you can dispense with brackets and the like to make it more seem like  more natural language. But it does mean that individuals have a variety of styles of writing. Whereas in JavaScript it’s more strict which brings more conformity.

Ocado – Delivering Ground Breaking Technology

This week we had a talk from Paul Clarke, the Chief Technology Officer (CTO) of Ocado. It was fascinating to learn that half of Ocado’s head office is technology focused with most of it being developed inhouse – mainly because no-one else had done it before – from routing vans, managing the warehouse picking (more automated than Amazon apparently), before even considering the customer website.

The amount of data available from the vans, understanding speed, gear selection etc. enables them to optimise their business.

This idea of sensor networks (fashionably called the Internet of Things (IoT), was also something touched on by another of our guest speakers – Inma Martinez, a serial entrepreneur and business advisor.

Soon to be Seniors

Also this week many of the new cohort, starting in February, came in for an open evening. It’s scary to think that we’ll soon be the senior class, but I am feeling more confident in my abilities, both in knowing more about coding, but also knowing more about how to learn to code that will continue long after the course.

Reading Week

This week sees us experiencing a ‘reading week’. After five really high speed weeks, I’m looking forward to having this week to consolidate where I’ve got to so far – revisiting some unfinished projects, tackling some challenges in my weaker areas and doing some wider learning around the edges.


Learning To Code – Week Four

For my first four weeks studying at Makers Academy I’ve been consistently working harder than I can recall during any similar period during my twenty year working career – and I’m loving it.

After the difficulties I encountered during week three with adding a web interface layer to previously written business logic, the weekend challenge (a rock, paper, scissors, game) gave an opportunity to get it right. I was very happy with the code I’d developed and following my code review on Monday afternoon, I got a few more tips to polish it up .

Following that, and  as an extra challenge to myself I went back to the battleships game and pushed through all the issues we’d come up against and managed to get the front end to work all the way through to sinking a fleet. It wasn’t pretty, but is now in a state that I can go back to it (if I have some free time!) and tidy it up.

Web Security – Hashing and Salting

This week has extended our experience with Sinatra, adding databases into the mix – so now truly full stack from web front end, through business logic engine into databases.

A key part of the learning focused on web security. I hadn’t understood too much about this topic before, but having learnt  about the processes, it is simple and secure. The key to it is that a website should never store your password. If you want to know more this article is a pretty comprehensive overview.

Adding a database into the mix has been reasonably straightforward, early in my career I had been an analyst and had experience with Structured Query Language (SQL) (a language for relational databases that is older than me and still very much in use today).

Mastering Time Travel

An added bit of challenge was to time travel this week. In our test driven methodology Huy (my pairing partner and fellow blogger) and I  needed to validate that our code would prevent a password reset url from working an hour after it was sent. Instead of just sit back and wait for an hour, we found a code gem (Timecop) to immediately travel an hour and a second ahead within our test to ensure it went green ( passed) and then back again with no ill effects.

It’s Not Just About Coding

There’s much more to the Makers experience than just the coding. This week we’ve had a couple of great talks from companies for whom coding drives their value proposition; (see article photo) and Rockabox. As well as talking about their businesses they’ve all been open to answering many varied questions, with a particular focus from the Makers students on what they look for in new hires (which I’d summarise as; good code on GitHub, consistent coding style, constant learning, engagement in the coding ‘community’ – eg. blogs, stackoverflow – and passion).

The ‘Seniors’ (the  cohort that started 6 weeks ahead of our cohort) are starting their final 2 week project next week, so on Wednesday it was the Jamboree, where everyone gets together and pitches (in no more than a minute) ideas for the projects. Everyone joins in, Seniors, Juniors, Lectures, Coaches, Alumni Helper and other employees of Makers. Around 60 ideas in total were pitched, though some were reasonably frivolous.

The seniors have now been going through the process of making their selections and forming their groups. Having seen two previous graduations where the final projects are presented, it’ll be interesting to see how they get on with what I expect to be a high pressure fortnight. Especially as it’ll be our cohort in five weeks time.

Fun Fridays

No two Fridays have been the same at Makers, and this Friday was no exception. Two fun activities were held;

  • CodeJam – a new concept to makers – small code challenges (often called Kata) in teams (Seniors and Juniors) against the clock and against other teams.  Whilst stressful with the clock ticking it was great to have the experience of working with some of the seniors and apply our brains to some random challenges. Hoping for this to become a regular event.
  • Pecha Kucha – Makers are keen to ensure graduates aren’t just great coders, but also give opportunities to work on softer skills. Friday’s Pecha Kucha presentations were one such example. I and 7 others took to the floor to present on topics varying from free skiing, dogs, camping, cycling across America and Grande Prairie Alberta. Plus two presenters had the task of talking to a series of random slides – a real challenge but highly amusing.

So onto the weekend challenge – building a ‘micro-blogging’ platform called Chitter!

Learning To Code – Week Three

Monday saw our return to  Makers Academy after a two week Christmas break. As well as the challenges set by Makers I spent some time on Codewars. This was good exercise, not only does it challenge you to code some interesting topics, when you’ve got it working you get to see how cleverer people have also solved it – so you can scaffold you’re learning pretty quickly.

It was a bit daunting to refresh my knowledge of the code that I’d been working on two weeks previously, to prepare for the Challenge Review with the coaches.

Which is my first learning point…

Balancing code clarity vs brevity

One of our challenges was to write our own version of Ruby’s inject method. My initial attempt was slightly clumsy, somewhat brief, but really difficult to figure out what was going on it.

Much of a developer’s time will be spent reading other peoples code – whilst developing new features or fixing bugs. So being able to understand what is going on will be highly appreciated.

The other challenge was to write a small takeaway ordering programme (including sending a text confirmation).

This was a further chance to think about Object Oriented Design as I wrote about last time. The added aspect of this was having an user interface (just through the terminal / command line). I tried to ensure that the user interface object handled purely the capture and return of information to the customer, whilst all the logic of what to do with the information happened in other objects.

I was mainly successful in this, though along with the coach spotted a couple of opportunities to improve it.

Sinatra and Cucumber

This week were introduced to Sinatra and Cucumber. Sinatra is a language that enables you to quickly get Ruby programmes onto the web and Cucumber is a testing framework (which with Capybara) enables testing for web environments.

Our challenge was to put a web front end onto the Battleships game we’d built in Week 2.

It’s All About The Domain Design

From doing this exercise it reiterated the issues around design and interface separation. Whilst I’d had a good crack at it with the Takeaway challenge, the Battleships game that Josh and I had previously written (which worked perfectly well from the command line) wasn’t so suited to a web interface.

The web is stateless

The big issue was because of something we learnt early on in the week, the statelessness of the web.  This restricts how you can manage the required data and with a restriction on 4kb on session cookies, there’s not a lot you can keep in session.

Emily (my pairing partner for the week) and I kind of figured this all out by Thursday, but unfortunately that didn’t give us much time to get into HTML and CSS. However it really bolstered my understanding of domain modelling, so in retrospect was grateful for that.

It’s a bootcamp, you’re supposed to be uncomfortable

So whilst it was frustrating to get to the end of the week feeling behind, it’s a feeling I think I’ll have to get used to over the next few weeks, and it’s how the course is intended to work.

The difficulty with the pace is that nothing is going to be perfect, but perfection is not the point. It’s about getting better constantly.

At least we have a reading week scheduled for week 6, which will be an opportunity to do some learning consolidation and revisit unfinished projects.