In my early experiments using AI for coding, I’d often get stuck in a spiral of it just hammering away adding more and more code to try and work around a problem that it didn’t understand. Once they start tunnelling, they think the only way out is to keep going through.

Now I’m getting better at using these tools, I find it easier to spot when they’re going off track and get them to change course. But I realised that if I was in situations where I needed to nuke my whole feature branch to get back on track, I probably wasn’t using Git effectively.

So what I’m doing now is maintaining a temporary working branch off of my feature branch. For example, if I have a feature branch user-auth, I branch t/user-auth off of that. I commit to the temp branch after every meaningful change. Then when I know something’s working, I review the code, tidy it up and squash all those commits into the feature branch.

If everything goes wrong, I either undo a few commits from the temp branch and try again, or trash it and pick up where I left off on the feature branch.

This feels liberating because I don't have to worry about how many commits I’m making or how good my commit messages are. I’m the only person who sees the temp branch, and I make sure whatever I merge into the feature branch is of good enough quality to later do a PR into main.

It's incredible how quickly the past few months have gone. When I started the course and joined the demo day for the cohort who were just finishing, I couldn't believe I'd ever produce anything as good as what they'd built. And yet here we were!

The final project is completely self-driven, from ideation to deployment. It's an opportunity for us to put into practice everything we've learnt over the previous four months.

I was in a group with Eugene, Jessica and Joe. We decided to make a location-based app that finds your five nearest tourist attractions, uses AI to give you a brief history of them, and then generates an audio guide using text-to-speech so that you can listen to it on the move.

Getting started

From the outset, we all agreed that we needed to clearly define the features we wanted and be quite opinionated about what our app is there to do. We realised it would be easy for it to become a bit of a Google Maps clone, and we were clear we didn't want that to happen.

Once we'd decided on the core purpose and features, we started diagramming and wireframing and arrived at a user flow that we were all happy with.

Building it

We decided to use the MERN stack as we wanted to get more practice with each of those technologies. Although for the features we implemented, we ended up not needing Mongo.

We created:

• A React frontend. It makes an API call with the user's location to our backend. We used useQuery to handle the requests and caching.
• A Node/Express backend which handles all the API calls and processes the data so it can be used by the frontend.

We used Jest and Cypress for testing.

Of the services that we researched for generating the place descriptions, we thought Bard would work best as it has access to real-time data, but we couldn't get access to its API at the time. We went with OpenAI for the purposes of building a prototype, but we're planning to switch that once Bard is available.

We also used Google's TTS service as it had the best balance of cost, usability and quality.

The finished product

Overall we were really happy with the finished product. We delivered what we'd planned to build, on-time and well-tested.

Towards the end of the project, I worked on deploying it online. I tested out a few different services, and decided to deploy both the backend and frontend to Railway. It's a fantastic service, and I'll probably do a separate post about how to deploy an Express/React app with it. (I also loved Vercel and am planning to build something in Next.js to try it properly.)

Friday of the second week was Demo Day and we had to present our apps to the rest of our cohort, other cohorts, and prospective bootcamp students. It was fantastic to see everyone's projects, and really motivating to see how far we've all come in four months.

And with that, the Bootcamp is done! Now begins the equally hard work of job hunting (and also finally getting to work on the ever-expanding list of side projects I've been desperate to get going with).

Links

• GitHub repo
• Production version is live at trailapp.net

Time for another group project! I was in a team with Arbnor, Heather, Jessica, Khuslen, Osman and Shoaib.

The brief was to create a simple social networking site, allowing users to register, log in and out, create posts, upload images and view a feed of other users' content.

We were asked to use the MERN stack (MongoDB, Express, React, Node), and Makers gave us some basic code (mainly for parts of the authentication, routing and testing) to get started.

Getting started

We made a collective decision to spend the first couple of days learning and planning, and didn't start actually coding until day three.

We started by diving into the existing codebase, writing some tests to understand how different bits of it work, and creating some sequence diagrams and wireframes.

Tech insights

There were lots of interesting technical aspects to this project, but I'm going to focus on three specific parts: authentication, image uploads, and the database.

Authentication

In the basic code that Makers gave us, there was already a JWT token generator and checker implemented as middleware in the Express server. We decided to stick with that as it worked pretty well, and we built our registration and login functions around that.

I'd spent some time learning about authentication for the Chitter challenge and I was familiar with how to hash and validate passwords with BCrypt, so I led on implementing most of this functionality.

Although it worked well, we had to debug quite a few issues with tokens not being properly invalidated when they expired, and components not re-rendering properly when a user logged out. For future projects, I'd try to either use a third-party authentication service, or investigate what good libraries are available to handle some of it.

Image uploads

We wanted users to be able to attach photos to their posts, and also upload profile photos when they registered. None of us had much experience with handling file uploads, and Heather took the lead on investigating what options were available.

We ultimately decided to use Multer as middleware in our Express server to handle the uploads. We were planning to then store and serve the images from Firebase, but we ran out of time and ended up just storing them in our server's filesystem instead. Definitely not an approach we'd roll out to production, but it worked fine for demo purposes.

MongoDB

None of us had used MongoDB before, so I took on the task of figuring out how best to use it for this project. Shout out to this excellent tutorial which gave me enough information to get going with it.

Although it was tempting to retreat to our comfort zone and try and make Mongo work like a relational SQL database, we all agreed that we wanted to try and do things the Mongo way and get the most out of the way it worked.

One example is how we set up our Posts collection. In a relational database, we'd have created separate tables for posts, comments and likes, and then linked them all together. Instead of that, our Posts collection ended up having comments and likes fields which are just arrays, and we push new comments and likes into those (and they each have user fields which reference our Users collection).

There are definitely pros and cons to both approaches, but for our purposes and given the rest of the tech stack we were using, MongoDB worked fantastically well (and I was grateful to have a couple of weeks off from figuring out how to construct massive join queries in SQL!).

The finished product

We were really pleased with the end product. It had all the functionality we'd set out to include, and it was well tested on the backend with Jest and on the frontend with Cypress.

The code we produced was clean and well planned, and I'm pretty sure I'll reuse some of it in future projects whenever I need to implement social functionality.

GitHub - snptrs/bootcamp-acebook

Contribute to snptrs/bootcamp-acebook development by creating an account on GitHub.

GitHubsnptrs

Having focused mainly on learning the basics of JavaScript and running it in Node last week, this week we started to focus more on the frontend. The learning objectives for this week were:

• Test-drive a simple Javascript program running in a web browser, using modern JS build tools.
• Use the DOM API to build a web user interface for this program.
• Build a single-page web application fetching and updating remote data using JS.

I've been using HTML and CSS for a long time, so I was already pretty comfortable with concepts like the DOM, events and how to use the browser's developer tools. Where it got trickier though was having to create both a backend and a frontend and have them interact with one another. I could really feel all the knowledge I've picked up over the course so far coming together to help me with that.

TDD was also a lot more challenging this week. We still used Jest for everything, and I'm pretty comfortable with it now, but it felt like there were a lot of plates to keep spinning when switching between mocking API interactions, testing DOM elements, and then producing integration tests.

News headlines project

The final project for the week was to create a news app that fetches the latest stories from the Guardian API and generates a summary of them using AI.

Although the Guardian API documentation looks like it hasn't been updated for several decades, it was surprisingly easy to get up and running with it and pull in the latest headlines.

To generate summaries of the articles, I tested out a few different options. The one that gave the best results was Kagi's Universal Summariser (as a sidenote, Kagi is a fantastic search engine that I happily pay for). I really struggled to get it working when calling the API from the frontend though (another good reason for creating a simple backend for my app - see takeaways below for more on that). So in the end I used OpenAI. The quality of the summaries isn't great, although I could probably improve them by spending some time tuning the prompt.

The most challenging part was getting the layout working. I had very little experience with CSS layout, so I spent a lot of time learning Flexbox. Once I knew what I was doing, it was really simple to create a grid of cards for the headlines.

It was a really enjoyable project, and one I plan to return to and develop further.

GitHub - snptrs/news-summary-challenge

Contribute to snptrs/news-summary-challenge development by creating an account on GitHub.

GitHubsnptrs

The final challenge for week five was to create a bowling scorecard program. Conceptually, this was the most difficult project so far and it required a lot of research and planning.

The requirements were:

• Count and sum the scores of a bowling game for one player.
• Create it as a terminal app using Ruby.
• No database backend needed.

Why is bowling scoring so tricky?

I'd never thought about how bowling scores are calculated, but when I saw this challenge I assumed it must be fairly straightforward. It isn't. A lot of the complexity comes from the fact that when you get a strike or a spare in a frame, the  score for that frame isn't calculated until the next one or two balls have been bowled. That means you're often going back to previous frames and updating their scores.

To add extra complexity, the first nine frames basically work the same way (two bowls per frame, or one if you get a strike), but the tenth frame can have up to three bowls.

I started by watching some YouTube videos about bowling scoring. (As a result, my  feed is now full of bowling content. Gotta love the algorithm!) I then diagrammed the first couple of frames of a game to help me understand the logic.

Designing the application

I initially thought I'd use an array of hashes to store the ball, frame and bonus scores. I started sketching that out, but it was clear that it would quickly get difficult to manage. It also didn't feel right to separate the data from the methods like that. The essential unit of the game is a frame, so it felt more logical to take a properly object-oriented approach and create instances for each frame.

I designed a class system that separated the various elements into:

• Frame which is a model class and holds the score for each frame, along with methods like .strike? that can be called by the other classes to determine if a particular frame contains a strike.
• Application which creates 10 Frames when the application is first run, and contains a run loop which calls the Gameplay methods.
• Gameplay contains various methods to prompt for and process terminal IO, and determine whether the game is over.
• Scorecard has various methods to calculate frame and game scores, and apply frame bonuses after strikes and spares.

Final product

I tried a few different ways of displaying the output, but I wasn't happy with any of them. There's surpsingly high information density in a traditional bowling scorecard, and it's hard to replicate that in a different format. So I decided to figure out how to draw a proper scorecard template in the terminal.

I started by drawing a single frame in ASCIIFlow, then broke that down into template methods. There's some slightly clunky code in there, and if I get a chance to go back and refactor, I'd look at making better use of map to re-sort the array elements into the correct order. Overall though, I was surprised and pleased that I managed to get the formatting to work.

GitHub - snptrs/bootcamp-bowling-challenge

Contribute to snptrs/bootcamp-bowling-challenge development by creating an account on GitHub.

GitHubsnptrs

This week we did the first group project of the course. The learning objectives were:

• Learn to work and communicate effectively as part of a team to build a web application.
• Learn to break down projects into tasks and assign them to pairs.
• Learn to use agile ceremonies to organise your work and improve your processes.
• Learn to use the developer workflow to plan, implement and peer-review features.

I was in a group with four great teammates: Arbnor, Heather, Osman and Shoaib. Our project for the week was to build a ‘MakersBnB’. We used Ruby, Sinatra and PostgreSQL for the backend, and some fairly basic HTML and CSS for the frontend.

Workflow

On Monday, we all got together to review the guidance from Makers and agree how we were going to approach the project.

We decided we’d have a standup every morning at 10am, and a retro every afternoon at 5pm. We also broke the week up into three tiny sprints to try and get a flavour of the Agile workflow.

The first tasks was to take the requirements we’d been given and turn them into user stories. We then broke those stories down into tasks and added them to a Trello board.

Once we’d agreed the tasks, we split into pairs and rotated the groups for each sprint. I focused slightly more on the backend, as a lot of what I’d done the previous week for the Chitter challenge (like authentication, session management and some of the database tasks) meant I could help get the basics up and running fairly quickly.

I paired with Osman for most of the week. We made a great team, bouncing ideas off of each other and suggesting alternative approaches whenever we got stuck.

The finished product

We managed to implement all the core functionality by the end of the week: hosts could list properties and approve bookings, and guests could find somewhere to stay and submit a booking request.

Given slightly more time, the next steps would have been to improve the design, implement better UI features (like a proper avaiability calendar), and add email and SMS booking confirmations.

Overall, we were really pleased with the final product and learnt a lot about effective ways of working together on projects like this.

Everything we've learnt so far came together this week and we finally got to create some actual web apps! 🥳

Topics for the week included:

• Understanding the basics of HTTP requests and responses.
• Using Sinatra to create routes and serve webpages.
• Writing unit and integration tests for web applications.
• Deploying database-driven apps to cloud hosting platforms.

Everyone seemed to enjoy this week more than last week, and the workload was more manageable. It's been a definite morale-boost to get a glimpse of what all this learning and endless hours of testing and debugging are training us be able to do.

Chitter project

The final project for the week was to build a basic Twitter clone. The requirements were for users to be able to:

• Register and log in.
• Publish ‘Peeps’ and view a timeline of all the posts.
• Tag other users who’d then get an email notification (this was a stretch requirement, but I managed to implement a basic version of it).

The database for this project was more simple than for last week's Shop Manager app. I just needed users and peeps tables, with a one-to-many relationship between then. If I were to implement proper threaded replies, I'd re-think the database schema as I think it might be more efficient to add a join table.

I used the bcrypt gem to hash and check user passwords, and Sinatra sessions to keep track of user login status. If a logged-out user tries to post a Peep, they’ll be redirected to the login screen.

Once I’d got the MVP up and running, I created a branch to work on the email notification feature. I really wanted to try and implement it, but didn’t think I’d have time to complete it over the weekend, so I developed it in a branch so that it wouldn’t affect my main app.

I used Mailgun to send notifications, and wrote a very (very) basic method to match @mentions at the start of a Peep. I then updated my Peep creation method to pass all new posts through this.

I was really pleased with the final product. I even added a proper README with deploy instructions. I can’t imagine anyone would want to use this (slightly clunky and fairly flaky) app, but it’s there if anyone wants it!

This week we started learning about databases. Using Ruby and PostgreSQL, we completed a range of modules and challenges starting with simple single-table designs, right through to more complex multi-table joins.

It felt like a step up in difficulty, and most of us found it challenging to get through all the content. But working through the many (many!) errors I encountered during the week really helped develop my testing and debugging skills, and by the end of the week I was feeling fairly confident about creating schemas, seeds and SQL queries.

There were also plenty of opportunities to practice skills I started learning over the previous couple of weeks, including analysing user stories, creating design documents, and making diagrams to visualise how all the components fit together.

Shop Manager project

The final project of the week was to create a basic retail stock and order management system using Ruby.

I started off by designing the tables, classes and methods. For the Postgres database, I created orders and items tables, and an items_orders join table.

I used the colorize gem to spruce up the terminal output. I also created a Format class to handle output. It's something I started thinking about in the previous week's challenge, and it seems sensible to separate out all the repetitive spacing and tweaks needed to try and make the terminal output more reabable.

class Format
  def string(text = "", color = :default, spacing = "")
    return if text == ""
    text = text.colorize(color)
    text = "\n#{text}" if spacing == :pad || spacing == :before
    text = "#{text}\n" if spacing == :pad || spacing == :after
    return text
  end
  
  def currency(price)
    return sprintf("£%.2f", price)
  end
  
  def header(text)
    return string("====== #{text} ======", :red, :before)
  end
end

This lets me do something like Format.string("Lorem ipsum", :cyan, :pad), which will return “Lorem ipsum” in blue with linebreaks before and after.

Overall I was pretty pleased with the finished product. I put a lot of effort into the RSpec tests, and was happy to get 95% test coverage. Given more time, the next steps would be to implement error handling and better input validation.

Now we’ve completed the first four weeks of introductory content, the bootcamp got properly underway with the ‘Golden Square’. This is a pathway of content and challenges that introduced us to four of the central concepts we’ll be focusing on during the bootcamp:

• Test-driven development (TDD)
• Object-oriented design (OOD)
• Debugging
• Pair programming

We started off learning the basics of TDD in Ruby using RSpec. Then we moved onto designing multi-class systems, and learnt how to apply various debugging techniques. There were pair programming sessions every afternoon, and it was great to get to work with different teammates, figure out different people's learning styles, and try out different approaches to pairing.

Takeaway project

The weekend project at the end of week 2 was to create a takeaway order management system. The requirements were to:

• Show a menu of available dishes
• Allow the user to place an order
• View an itemised receipt
• Send the user an SMS confirmation.

I used the colorize gem to make the terminal output a bit nicer. For sending the SMS confirmation, I used Twilio. It was really easy to set up an account, and the API is free for testing purposes (you have to pre-define recipient phone numbers, which was fine for this project). There's an official twilio-ruby gem which I used to handle the API interaction.

It's a really simple application, but I was quite surprised by how much I've already learnt, and was really excited when I received my first order confirmation text message.

GitHub - snptrs/gs-solo-project

Contribute to snptrs/gs-solo-project development by creating an account on GitHub.

GitHubsnptrs