Exploring Modern Web Development As a Noob

Learning in reverse

Trial by fire in my opinion is the best way to be exposed to a new skill. I don't mean that you will suddenly become the best at something by diving into an abyss recklessly, but you will at least force your head into an uncomfortable position and adapt to new concepts.

This was my case over the last year, I was so overwhelmed by the desire to become the best at development that I chose to do what I deemed "learning in reverse". I threw myself into the cogs of modern web development, I was writing React, Redux and Express applications before I even knew what Javascript was fully capable of.

Every minute I had free at my electrician job, I was studying docs, writing code that was akin to a Frankenstein monster of stack overflow answers and just submerging myself in this world that I felt ever behind and lost in. But I kept at it.

After pumping out several projects using this methodology, it was time to ask myself "What did I really know?" After showing people all of my projects and getting positive feedback, I couldn't stand the thought of someone asking for my help in a basic Javascript context and not being able to provide answers. I was becoming reliant on these frameworks and that did not sit well with me.

So I forced myself to uphold a promise while starting to work on my latest project Coloursel.io. I would not use any of these francy frameworks or libraries that I didn't absolutely need.

Work started on Coloursel.io and I was standing true to my promise, vanilla Javascript, no HTML or CSS preprocessors and no build tools. It felt liberating. I wrote the first module for Coloursel.io and was parading around the lack of tools that I used to build it.

Then came the day I wanted to build upon my application, I wanted to flesh out Coloursel.io into a wide variety of tools and modules that showcased p5.js in all its glory. The minute I wrote the next line of code, I knew I had a problem.

I looked down at the plethora of logic I used to write one single component and it dawned on me that writing the state managing logic for these two components was going to be nightmareish. And what happens when I want three components? Or four?

I was stuck, I was not about to mix the component logic into an inseperable mass of ugliness, there has to be a better way. It was time to employ React.

It made sense, this is what React is used for. It would be incredibly unreasonable to not utilize this amazing opportunity to make my app better!

Before I knew it, I was using all my tools again that I swore I wouldn't touch. Violating my purist oath.

The takeaway is this, learning in reverse didn't hinder my ability to use basic tools like I thought it would, but not allowing myself to use these tools when I need them would end up making my app not as great. Learning in reverse gave me the opportunity to see what problems these tools are made to solve.

3 Things I Learned Working With React Native

November 26, 2016

I would admittedly be the first to buy into the hype of react native since its release in 2015. React is a solid tool for building user interfaces and I use it with nearly all my projects.

The thought of building native applications in client-side javascript sounded almost too good to be true, let alone implementing the reusability and flexibility of the React framework.

Here are 3 things I've learned during my first experience with React Native

You have to learn the React Native component system.

In order for reusability between platforms, React Native uses components that translate into their native equivalent.

For example, there is a "View" component that must be used any time you wish to render anything on the screen, and "Image" components for displaying images and so on.

This will take a bit of studying the docs to understand the quirks and implementations of each type of component, and don't even get me started on the ListView component

You still have to get your hands dirty with native code.

If you want certain features such as camera access, you better pray that someone has taken the liberty to write a package for your respective React Native platform target.

Otherwise, you will have to dig into the source of each platform and figure out how to implement it yourself, like entering the Android Manifest or MainActivity java files. This discrepancy ultimately defeats the Javascript abstraction layer React Native attempts to provide.

The bridge between platforms is still broken.

Some features require split component implementations from React Native, like the ProgressBarAndroid and ProgressViewIOS. Meaning that you will still have to develop for each platform individually to some extent which is a ding to React Native's "write once use anywhere" pitch.

As mentioned in the 2nd item, some kind people take it upon themselves to write third-party packages to access hard-coded native features that React Native doesn't support out of the box.

However, you cannot count on 3rd party packages being available to both target platforms, as of writing this article 3rd party package support is unfairly skewed in favor of iOS for desired packages like fs attachment support.

In conclusion, React Native is still very early in development and its premise is very ambitious, but nothing about it at this very moment suggests that it is a viable platform for developing anything more than simple prototypes or fleshing out a side-project.

Building a Word-Search with Node JS

January 14, 2017

Lets discuss a project I put together last month to generate word searches using JavaScript in Node.js

I am not claiming this to be the most efficient way to generate a word-search, this was just the way that made the most sense in my head. This is a great little project to familiarize yourself with non-DOM JavaScript.

Node's Readline Interface

Node gets input via a readline library, this is native to Node and only requires importing to use.

readline takes a configuration object that we specify to use standard in and out for our interface (keyboard and screen).

We initialize a constant to every lowercase letter in the alphabet. For filling in the grid at the very end.

Initialize a grid variable to a list, declare a gridSize variable, initialize an array of words and an array representing possible word configurations.

Getting the Words.

We call a function getInput() which will execute our readline interface

This function loops and gives readline a question which prompts the user for a word. Upon entering a word and hitting enter. We add the word to our list we declared earlier.

If the word is a blank string, we quit the loop. We then sort the list by longest word first, make that our gridSize and execute our next function makeGrid()

The reason we sorted the list by longest first is so we have a good base size for our grid. The grid must be able to contain the longest word in width, height, and diagonal configurations.

Making The Grid

Now we make the grid. We simply call a nested loop according to our gridSize, this will give us a row | column layout where the row contains an array of blank strings. Each blank string represents a column.

Now we will call a function mapConfigs().

Mapping the Words

Now it gets involved. We have to find the places a word can fit into the grid.

There are more efficient ways to determine available spaces (like keeping a copy of free spaces in another variable and only using that) but for this purpose we will just choose a random row and column to check.

For every word the user entered, we make an empty row, column, configuration, incrementor, and options variable.

The options variable is an array of configurations or 'choices' we have for the current word. Our loop will keep executing as long as we have no options.

The row and column are chose randomly (thats what the getRandomIntInclusive() function is doing, nothing magic).

logging the word, config, row, and column with give you the 'solution set' to your word-search at the very end.

Then the row, column, and the configuration string are passed into a function called getAvailConfigs(). This function will return an array of booleans that we assign to our options array.

If a loop fails at getting a true option, the loop executes again, trying a new one and incrementing the i variable. If i gets bigger than gridSize*gridSize, we assume we have tried every possible option for our current gridSize and we make the grid bigger by 1 and restart the list of words.

When we get a true option, we go to our if statements. Each index in the options array is a boolean with a corresponding configuration that returned 'true' (the word can go there).

We simply change our configuration string to represent what was in the options array in a more readable form.

What the options array means.

options[0] represents a horizontal configuration, if this is true, the word fits horizontally spelled forwards.
options[1] represents a reverse-horizontal configuration, if this is true, the word fits horizontally spelled backwards.
options[2] represents a vertical configuration, if this is true, the word fits vertically spelled forwards.
options[3] represents a reverse-vertical configuration, if this is true, the word fits vertically spelled backwards.
options[4] represents a diagonal configuration, if this is true, the word fits diagonally spelled forwards pointing down-right.
options[5] represents a reverse-diagonal configuration, if this is true, the word fits diagonally spelled backwards pointing down-right.
options[6] represents a mirrored-diagonal configuration, if this is true, the word fits diagonally spelled forwards pointing down-left.
options[7] represents a reverse-mirrored-diagonal configuration, if this is true, the word fits diagonally spelled backwards pointing down-left.

This list of options is what is returned from the getAvailConfigs() function, lets see what it actually does.

getAvailConfigs() simply acts as an abstraction to two criteria. A word must match these rules to be considered eligible to fit into a space in a configuration. If one fails, the position doesn't work and false is returned for that configuration back to our options array.

The word must literally fit, it cannot extend past the grid size in the given configuration. This is checked by calling fits().
The word must not conflict with other words, one of its letters cannot occupy a column that is occupied with a non-matching letter. This is checked by calling availSpaces().

Lets look at what fits() is checking for.

fits() checks the configuration string and does a simple calculation to see if the length of the word can comfortably occupy the space in the given row and column.

If the config is either horizontal or reverse-horizontal the gridSize - (desired column) should be at least as big as our word.
If the config is either vertical or reverse-vertical the gridSize - (desired row) should be at least as big as our word.
If the config is either diagonal or reverse-diagonal BOTH gridSize - (desired row) AND gridSize - (desired column) should be at least as big as our word. Because each letter will be taking up both 1 row and 1 column.
If the config is either mirrored-diagonal or reverse-mirrored-diagonal our word will be pointing down left, so our (desired column) - word.length cannot be less than zero (because there's no -1 column) and gridSize - (desired row) should be at least as big as our word, so that we don't break out the bottom of the grid.

If a configuration passes its assigned rule, then it will return true, and half of our corresponding options boolean will be true.

But remember both criteria have to pass and fits() is only the first, lets look at the next which is handled by availSpaces().

7th inning stretch everyone, take a minute and pop your backs and walk around a bit, you deserve it!

You good? Okay lets continue.

We're first checking if the config string starts with 'r' because that means it is a reversed configuration, so we need to reverse the word.

Next we need to loop over the letters of our word and check every row and column that the letter is expected to occupy. Remember we're not only affecting a single row x column intersection, we're checking everything the word is going to touch once it's spelled out.

If the config is either horizontal or reverse-horizontal check next column in the same row to the right as it's spelled out to ensure either there is a matching letter or an empty space.
If the config is either vertical or reverse-vertical check next row below in the same column as it's spelled out to ensure either there is a matching letter or an empty space.
If the config is either diagonal or reverse-diagonal check next column to the right AND row below as it's spelled out to ensure either there is a matching letter or an empty space.
If the config is either mirrored-diagonal or reverse-mirrored-diagonal check previous column AND row below as it's spelled out to ensure either there is a matching letter or an empty space.

If a configuration passes its assigned rule, then it will return true, and the final half of our corresponding options boolean will be true.

This means that both tests passed, the word fit and had available spaces in the given configuration.

This info is relayed back to getAvailConfigs() who sees fits() === true && availSpaces() === true and that index in the options array now equals true.

Lets look back at our mapConfigs() who started this goose chase.

Now that one of our indexes in our options array is true, we simply choose the first true one (for randomization sake probably not the best method but when word lists are longer it's unnoticable).

Then we call a function insert() and enter the home stretch.

Inserting the Words

We pass insert() the word we want, a config string that passed our tests and the appropriate row and column.

Again we check if the config starts with an 'r' that we reverse it.

We are essentially implementing the same logic as our availSpaces() check, but this time we are actually inserting the letters at their appropriate space in the grid.

A horizontal or reverse-horizontal only needs to increment the columns as it gets inserted
A vertical or reverse-vertical only needs to increment the rows as it gets inserted
A diagonal or reverse-diagonal needs to increment BOTH the rows AND colums as it gets inserted
A mirrored-diagonal or reverse-mirrored-diagonal needs to increment rows and decrement colums as it gets inserted

Printing the Grid

At the very beginning we made a constant called 'possible' with every letter in the alphabet. We are going to use this to fill in the blank spaces in our grid.

Using good ole' functional programming we have the grid mapped with every character that is a space filled by a random choice from our possible string.

Just for debugging sake I also kept in the gridSize and the length of the longest word just to see how many times the grid needed to be resized before finding a home for every word on the list.

I am not claiming this to be the most efficient way to generate a word-search, this was just the way that made the most sense in my head. This is a great little project to familiarize yourself with more non-DOM JavaScript.

Recent Posts

Projects