Recently I have been looking more and more into plain old Ruby, no Rails framework, just trying to better understand the language behind it. Having built projects using pure Ruby and Rails, I have come to find I have some questions about what goes where. Which is good. Curiosity makes you want to dig deeper, which means you are intrigued by what you are finding / not finding and want to better understand what you are building.

Recently playing around with some Ruby, I found I was repeating certain methods. Let’s take a trivial example. …

I have taken a bit of a step back on blogs for front-end and React-based projects/skills to also focus on Ruby. After doing a take-home exam a week ago, I realised I was adept enough at making my own RoR project but creating a Regex, plain Ruby setup from nothing… I was not. It felt weird knowing the workings of Rails and yet in a plain Regex file, forgetting to use require ‘path_name’. I think that’s one thing that is good and bad about Ruby. So much of the work is done automatically for you in the background thanks to the stability and longevity of the Ruby community and language, but at the same time, knowing x does y, doesn’t necessarily help you understand why x does y. During the take home exam, I found myself learning new and simple things, both for testing with rspec and better use of Ruby enumerables. …

I almost felt guilty not doing camel casing for the title!

Having based my last blog around the basics of setting up a redux project, I wanted to build a simple app with this blog to showcase a full example of Redux, including the use of Redux Thunk. Building simple projects is a great way to learn, writing about them is a great way to test your memory and knowledge and feedback is a great way to see errors / learn some more!

I decided to build this Counter app because writing my blog last week made me realize my memory of building out a project with all the boilerplate Redux was a little bit too hazy for my liking. …

This is a slight diversion on what my next blog was meant to be about. Context API and testing it with Jest + Enzyme. Why? Because I have done some more reading around Redux and wanted to aim something potentially at Bootcamp students who were getting into their final projects, or having some trouble managing their state and props in a project.

This is something that I definitely struggled with in my final project and since wish, I had the confidence to have implemented Redux. My project involved a lot of components with plenty of different level components. This meant that passing data from one component to another became difficult to track and made my components look… clunky. No one wants clunky. …

My last blog was all about context API and how to set it up plus some benefits to it, as well as a couple of good links to comparisons between Context and Redux.

Now in this blog, I want to talk about setting up Enzyme, the use of it and a couple of tests. THEN I will do a blog on testing Context API in React.

Now Jest is a Javascript testing framework that was created by the developers of React. But, Jest is not actually limited to React, however, Enzyme is specifically designed to test React components.

To setup Jest please refer to one of my previous blogs — found here. …

In my final project of my Flatiron Bootcamp, I felt encumbered by the number of components and containers. Mapping out the highest component to store state so that it could reach all the necessary components was painful, tracking the props down to the necessary components was equally difficult as the project became more layered.

So, I wanted to learn Redux to be able to have better state management, it was difficult to keep track of the props you were drilling down, so having something like Redux was perfect. I set off to learn more about Redux from my Flatiron Bootcamp and bought a Udemy course as well to teach me the best and latest use of hooks. Here, I stumbled across one interesting brief part of the course. No more than 15 minutes in total out of a course that spanned 41 hours. I was introduced to a new way to manage prop drilling without having to pass props down through every component. …

Algorithms. A beautiful sounding word that immediately makes you sound like you know what you are doing. A word that used to strike fear (or joy) into school children. Yet an algorithm is simply a function that a programmer writes. A two-line function is technically an algorithm. A simple sum function is an algorithm. Algorithms allow us to use all types of data structures to perform actions on that data. As your company grows larger and larger and the data you handle gets bigger and bigger, using algorithms effectively in your code becomes more essential to the scalability of your company. …

I have been going down a journey of learning some computer science since finished my Bootcamp. I think it is integral to know what you are using whilst writing your code. It is great to know when to use an array and when to use a hash table, two topics I have covered in previous blogs.

With static arrays, we only have a certain amount of data or memory that can be allocated next to each other. However, dynamic arrays and static arrays can increase their memory and double up. However, doubling up an array will have a performance issue of O(n). We also remember insertion or deletion on an array for any element that is not the first or the last being O(n). Why? …