I was lucky to have made great friends during my time at General Assembly, and one of the running jokes in our class was the way our TA came out with some excellent one liners. I started collecting them, and towards the end of the course I made a kasun slackbot.
What I learned
kasunbot is the first project I created in node. It’s also the first application I’ve created that uses the slack API. This was an opportunity to play around with the botkit library, which I found to be a very neat and powerful tool.
I have a few more quotes that I haven’t figured out trigger words or events for. I’d also like to add a slash command where the bot suggests some of the things you could say to trigger a response.
When I’m not working on code, one of my other hobbies is cross-stitch. I often find myself losing track of what threads I have on hand, and what I might need to buy for a new project. I was looking for a project to make while learning ruby, and Thread Inventory (better name pending) was the result.
This project is a personal inventory management for embroidery threads, specifically DMC threads.
It has individual login, where a user can populate their personal inventory and a shopping list. They are also able to open projects and indicate what threads will be used by a project and it will then prompt the user to add threads to the shopping list - and indicates which threads (and how much) are currently in the inventory.
Threads can be marked as “purchased” from the shopping list which will then add them to the inventory. The inventory view will also show which threads are currently in use by a project - indicating that the amount may be out of date. When a project is complete, the user can close a project, which will prompt the user to update the amount of each thread left in the inventory.
What I learned
Thread Inventory is my first full stack ruby application, and represents a huge learning curve. I used Sinatra, which provided a solid basis to tackle Rails at a later date. This project really helped me to understand how OOP can be used. It also took me a while to understand the data structure I wanted to use - it was one thing to have belongs_to and has_many and join tables explained, but it took me a while to wrap my head around implementing them.
I also didn’t properly understand MVC when I made this, and I didn’t separate out model and controller functionality - opting to put it all in the ‘model’ directory.
Some of the features I’d like to add when I have time
- Mobile responsiveness - this project was born out of me getting frustrated about forgetting which threads I had and which threads I needed when I was at the store. To be able to check this it needs to look better on mobile
- User controls - such as the ability to change password, send a forgotten password request etc
- The ability to edit any open projects, and maybe archiving closed projects instead of deleting them.
- Expanding functionality to other crafting supplies, rather than just DMC threads
Helping Hands is the first of two group projects completed at General Assembly, as well as the first full Rails applications we built.
Helping Hands is an application that aims to connect people and charities online. The application allows charities to sign up and create a wishlist of items that they need. The wishlist holds information such as the item’s name, estimated price and a link to where it can be bought online. Donors are able to search through the list of charities in the application, view their wishlists and make a donation.
What I learned
There were several challenges in this project - one of those being group work! It was amazing to see how much we could achieve in a week, but I definitely could have been more careful with testing my code before I merged it. I can think of one instance where I broke another team member’s work (oops).
It was the first time I had the opportunity to pair program, which worked very well when figuring out an unfamiliar technology.
It was also my first time using AWS - which was used in conjunction with the carrierwave gem to host the logos that a charity would upload when they signed up. Configuring this took longer than expected - though subsequent forays into AWS have been easier.
We used Backbone.js as a front end framework - which presented a few challenges but was ultimately rewarding.
I’m also proud of how the charity profile page will load differently depending on if the logged in user is the charity in question (the profile will be editable), a different charity or a donor (a donor can’t edit but can mark items off the donor list). There are both front-end and back-end validations on this behaviour.
There’s a few things we’d like to implement when we have time
- Tidy up the way the wishlist looks on the charity profile page
- Add a shopping page where people are directed to buy the item rather than just saying they’ve bought it
- Responsive form validations
- Send emails to the charity and donor when a wishlist item is purchased
Our second and final group project was a website for a fictional WDI conference! This project was done as a class and was done as a single page of content - which can be viewed here and the github repo can be found here.
What I learned
Unfortunately, illness meant that I missed a day of work on the project - but there were still some important take aways
- Creating our own build system using gulp tasks was a lot of fun
- The importance of having a designated project leader - especially when managing a larger group
- The project worked off a single html file which meant that resolving merge conflicts took a significant amount of time. A better approach would have been to work on modular segments
- Integrate the chatbot better into the design. As it was developed separately it doesn’t integrate into the design well
- Fix up some of the CSS
When looking to make the code more extensible I realised that I could create Connect Four. In my Connect Four’s current iteration the number of rows, number of columns and number required to win are stored in variables, and only need to be adjusted once to change the game structure.
What I learned
It was quite an awesome experience to watch something come together and to ‘make the computer do the thing’. It was also a good feeling to realise that the concepts that I’d been learning were solidifying - there were concepts that had frustrated and troubled me during the pre-work that came together without any trouble.
I’m writing this as I approach the end of my course at General Assembly, and it’s an interesting experience to go back to code I wrote two months ago - thought it’s not as cringey as I thought it might be! I can see what I was trying to achieve - and while I could go back and make the code DRYer it’s still a warm fuzzy feeling to look back at the first thing I made.