Forem: Jill

Data Royale: [SQL] vs noSQL

Jill — Sat, 21 Mar 2020 00:49:41 +0000

This is Part One in a two-part series about the differences between relational and non-relational databases.

It's been a productive year to say the least, and after having built multiple apps from the bottom-up, up-to-bottom, sideways, diagonal, to criss-cross apple sauce, throughout all these methods, there is one thing that stays the same across the board.

Spoiler Alert: It's the act(read:art) of planning.

Whether in a notebook or a digital document, best practice is to plan a project all the way down to the nitty gritty, then, plan up from there. It only took a few and a half failures for me to realize that jumping headfirst into a project not only makes it more difficult to manage in the long run, but also it's more likely that I won't finish it.

Now, whenever I have an idea, before I draw up a wire frame or choose a tech stack, the first thing I always do is figure out how I'm going to divvy up my data.

Battle Royale: Relational vs. Non-Relational

Beneath the surface, there is a deeper divide than the semantics of SQL(Structured Query Language) vs. noSQL, and that's really how, and also if data in the app is related.

The beauty of both SQL and noSQL methodologies is that they're both perfect for persisting data, the method used just depends on the needs of the app.

Relational: SQL

Relational databases are made up of a network of tables, these tables hold columns and fields and in many cases, hold references to each other.

Data Modeling

Whether relational or non-relational, It's always helpful to be able to see a physical representation of these connections to really grasp what our information is doing in the background. To achieve this, we should draw up a model of our data, but of course, even that should be planned first!

I find that it greatly helps to flesh out all of the data on paper or whiteboard, typing can be almost mindless at times whereas the act writing (especially in cursive!) requires some additional thought, and therefore, more mindfulness goes into the work, which in turn can cut down on the amount keystrokes and production drafts.

Plan each table, then, plan them again!

images via FileMaker

Relational databases are highly structured which makes them quickly scalable, and follow an ACID (Atomicity, Consistency, Isolation and Durability) theorem. Using SQL to query a relational database can be restrictive, but it also proves to be incredibly useful and is extremely powerful when performing complex operations.

Due to these restrictions, it's important to resolve these interactions early on as to avoid rework and overhaul disasters during building and production.

Once tables with columns and their corresponding fields are fleshed out, we can see each table's connection to another in the database, and which fields in each table are related.

As soon as the hard copy is finished, I recommend creating a digital one using a design tool, my favorite is DB Designer.

Which One?

Once the data is relatively (no pun intended) structured, this is the time to choose which Relational Database Management System(RDBMS) to use to perform operations on the database. The amount of RBDMS's are many and of course some are more popular than others but again, and some are very similar to others. For example, the stark differences between MySQL and mariaDB can be vague, mariaDB just happens to be a fork of MySQL. Choice can and really should be made base on what's best for the app.

In Conclusion

Relational databases are great when you have information that, surprise, is related in some way. These structured systems are adept at storing data in a manner that makes retrieval methods a breeze, relatively speaking(har-har).

A little bit of a downside to this structure is that without thorough planning early on, it can be a pain trying to account for unexpected inputs later, which is why it's a great idea to do multiple early drafts to avoid these pitfalls.

However, I find the greatest pro to be that RDBMs can be chosen strictly based on what an app needs, so a lot of the guesswork can be removed and tech can be decided on objectively.

Stay tuned for next week when I go through the ins and outs of a Non-relational database. In the meantime, what's your favorite RDBMS? It's PostGreSQL for me!

Planning a relational database? Check out this helpful resource from FileMaker for additional insight.

Thanks for reading!

All hail HTML

Jill — Tue, 17 Mar 2020 18:55:42 +0000

These last few months, I've gotten deeper into programming and due to my unexpected intrigue of server-side architecture, I often forget how much I enjoy (and sometimes miss) the straightforward simplicity of working with HTML & CSS.

From my initial introduction to HTML in the early 90s and self-driven surface exploration on my part thanks to sites like Geocities and Xanga, I think it's safe to say that by the time I was eight years old, I understood HTML as a concept, even though I didn't know what it was called or what it was "really" for.

Regardless of my ignorance of the semantics, I was able to make meaningful (to me at least) changes to the code in text editors and understand exactly what was happening because of the clear nature of HTML's structure.

In short, as a child I was able to write in this language even before I even understood the specifics of it, which is pretty amazing. It was this introduction to the World Wide Web's original language that started my tech journey and bolstered my love for front-end work.

HTML can be simple and gratuitously straightforward, but I still find myself learning new things about it all these years later. It's my hope that this post will lead to someone else's interest being piqued and maybe even be the launch point of their tech journey as well.

HTML, or Hypertext Markup Language, was introduced in the early 90s and to this day continues to be the backbone of the vast majority of sites on the internet.

Even early on, the best thing about HTML wasn't it's incredibly straightforward style (even though it's still tops), but how it's made better by it's better half, CSS.

Often when we see the acronym 'HTML', it's fellow 'CSS' (Cascading Style Sheets) usually isn't too far behind. They're basically the Bert & Ernie of the internet. When HTML is used in conjunction with CSS, the internet really comes alive.

Because of this timeless relationship, Devs are able to create interactive, dynamic web pages and applications that expound prolific manner that far extends the 'simplicity' of HTML.

Tags & Structure

HTML elements tell the web page how to behave and are expressed between a set of tags. HTML elements are declared between the <and `> and are structured like the following:

For example, these lines:

javascript <!DOCTYPE html> <head> <h1>My First Heading</h1> </head> <body> <p>My first paragraph.</p> </body>

will render the following to the screen:

The "Hello World!" of HTML

As we can see, the tags themselves are not displayed on the screen, however, their position in the document tells the browser where and how the contents, AKA the attribute value should be displayed.

javascript <!DOCTYPE html> <head> <p>The 'head' location is a great place to import CDN links like jQuery or Bootstrap. Also, a quick aside about head vs. header. Head tag includes information about the document while 'header' contains introductory or navigational aids. </p> </head> <body> <p> We can utilize a variety of tags within the body which will display their contents on the screen. We can also write code within the body by using 'script' tags! Either directly: <script> alert('Hello World!'); </script> Or by importing an entire JS file: <script src="/path/to/script.js"></script> </p> </body>

Again, there's a huge variety of tags that can be used in the body, commonly 'style' tags are used to incorporate CSS to modify the page or even just a single element on it. If HTML is the skeleton of a web page or app, CSS would be the muscles, tissues, and skin.

However, because CSS can get incredibly lengthy, and best practice is to maintain and import an external CSS file within a script tag in the head of the document.

In Conclusion

Sometimes it really is a great idea to take a break from building in frameworks and routing in the server, just to play around with what you could call the "basics" of the internet. For me it's therapeutic, and it takes me back to all those late nights I spent creating with HTML/CSS just for fun, not even realizing how I would be utilizing that practice years later in life.

For your convenience, here's a quick sheet to reference when building out your next project with HTML/CSS

Even after all this time, I'm still learning new things in CSS so it never gets old, what are some of your favorite CSS tricks to couple with HTML?

Uploading Audio to Cloudinary in Expo

Jill — Mon, 10 Feb 2020 00:05:23 +0000

Recently I worked on a project that utilized live recorded and uploaded audio as a core feature. While the Expo SDK made working with React Native a far more streamlined process, the secondary operation of uploading the audio to a cloud database proved more of a challenge.

There is a wealth of information regarding performative actions on image, video, and text files across the internet, however in my journey to complete this feature, I found that examples of audio operations were far less common.

I tried all sorts of things to work around this, and in many of those attempts I'd managed to successfully upload images and videos but consistently, my attempts to make audio snippets appear in my cloud media database all failed.

Additionally, because we were working with the Expo SDK to build a native Android app, mobile file system access as well as file types(android is .m4a whereas iOS is .caf) had to be taken into account as well. This precedent added an additional layer of complexity in the process to seamlessly integrate this uploading feature without incorporating HTML, as seen in Cloudinary's Quickstart guide.

The following Cloudinary POST method works perfectly in the browser, however attempts to run this code in a mobile app will result in an error in regards to how the app accesses the file system of a mobile device, the event.target.files will return a property error of undefined, and that's not the behavior we're expecting.

 const CLOUDINARY_URL = 'https://api.cloudinary.com/v1_1/CLOUD_NAME/upload';
          const defaultHeaders = {
            'Content-Type': 'application/x-www-form-urlencoded'
          };
          const file = event.target.files;
            const formData = new FormData();
            formData.append('file', file);
            formData.append('upload_preset', CLOUDINARY_UPLOAD_PRESET);
            axios({
              url: CLOUDINARY_URL,
              method: 'POST',
              headers: defaultHeaders,
              data: formData
            })
            .then(res => console.log(res))
            .catch(err => console.log(err))

note: all of my attempts to work with the React Native WebView API fell short as well, as accessing computer files are a little different than accessing mobile files.

Finally, I hit a wall. With my deadline looming and the pressure rising, I threw my caution to the wind and created my first Stack Overflow question. I'd initially not done this (even though there were no other SO posts that answered my questions) for the sheer amount of time I thought it would take to merit a response.

Feb 1 '20 Comments: 2 Answers: 1

this is my first Stack Overflow post so please go easy on me!

I'm building an audio recording app using EXPO as the SDK with React Native. One of the main features of the app is to be able to to record live audio as well as uploading audio from…

Open Full Question

But for once, I got lucky and within an hour I'd received some advice on how to alleviate the situation. I couldn't [redacted] believe it.

My SOS was responded to in the most helpful manner, and in turn I wanted to write this to help anyone else who might be struggling in a similar situation. There are a few key things that need to happen to successfully upload audio:

Permission enabled access to a device's file system
Matched MIME types
Base64 encoded local uri path

Let's jump into some code

Create a New Asset

If you're just uploading audio from a device, you can skip to the next code snippet, if you're uploading live audio, the walkthrough starts here.

On a side note, there may be other, more eloquent ways to do this, but this worked for me. This is also implemented in after creating a recording component with the Audio API in Expo. Once a recording is created it's file path is immediately generated from the promise it's function call returns. The getURI() method is a way to utilize the recording's information for immediate use with other APIs and services.

First, we will utilize the MediaLibrary API to work with the newly generated recording:

Create a new recording(asset) that can be stored on the device
Create an Album for the assets to be stored in
Save the asset to the album in the device's Media Library

//create a new recording
async createAudioAsset() {
    let newAsset = await MediaLibrary.createAssetAsync(this.recording.getURI())

//create an album on the device in to which the recordings should be stored, and pass in the new asset to store
MediaLibrary.createAlbumAsync('Recordings', newAsset)
    .then(() => console.log('Album created!'))
    .catch(err => console.log('Album creation error', err));
    }

    async saveToPhoneLibrary(){
//call the function that creates a new (if not already existing) album 
      this.createAudioAsset()
//then save the created asset to the phone's media library
    .then(asset => MediaLibrary.saveToLibraryAsync(asset))
    .catch(err => console.log('media library save asset err', err))
    }

Next, we'll access the file using the FileSystem and DocumentPicker APIs, this is also the place to start if you plan on uploading previously saved audio only.

    async uploadRecFromPhone(){
      //Access the phones files, making sure all file `type`s are available to upload
      DocumentPicker.getDocumentAsync({
        type: '*/*',
        copyToCacheDirectory: true,
        base64: true
      })
      .then(succ => {
        console.log(`Recording Information -- path: ${succ.uri}, 
type: ${succ.type}, 
size: ${succ.size}`)
}).catch(err => console.log('error uploading from phone', err)
};

To Upload the Audio File: First convert the audio's uri into a base64 string, here's a working base64 object to help the encoding:

 var Base64 = {
          // private property
          _keyStr : "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/=",
          // public method for encoding
          encode : function (input) {
              var output = "";
              var chr1, chr2, chr3, enc1, enc2, enc3, enc4;
              var i = 0;
              input = Base64._utf8_encode(input);
              while (i < input.length) {
                  chr1 = input.charCodeAt(i++);
                  chr2 = input.charCodeAt(i++);
                  chr3 = input.charCodeAt(i++);
                  enc1 = chr1 >> 2;
                  enc2 = ((chr1 & 3) << 4) | (chr2 >> 4);
                  enc3 = ((chr2 & 15) << 2) | (chr3 >> 6);
                  enc4 = chr3 & 63;
                  if (isNaN(chr2)) {
                      enc3 = enc4 = 64;
                  } else if (isNaN(chr3)) {
                      enc4 = 64;
                  }
                  output = output +
                  this._keyStr.charAt(enc1) + this._keyStr.charAt(enc2) +
                  this._keyStr.charAt(enc3) + this._keyStr.charAt(enc4);
              }
              return output;
          },
          // public method for decoding
          decode : function (input) {
              var output = "";
              var chr1, chr2, chr3;
              var enc1, enc2, enc3, enc4;
              var i = 0;
              input = input.replace(/[^A-Za-z0-9\+\/\=]/g, "");
              while (i < input.length) {
                  enc1 = this._keyStr.indexOf(input.charAt(i++));
                  enc2 = this._keyStr.indexOf(input.charAt(i++));
                  enc3 = this._keyStr.indexOf(input.charAt(i++));
                  enc4 = this._keyStr.indexOf(input.charAt(i++));
                  chr1 = (enc1 << 2) | (enc2 >> 4);
                  chr2 = ((enc2 & 15) << 4) | (enc3 >> 2);
                  chr3 = ((enc3 & 3) << 6) | enc4;
                  output = output + String.fromCharCode(chr1);
                  if (enc3 != 64) {
                      output = output + String.fromCharCode(chr2);
                  }
                  if (enc4 != 64) {
                      output = output + String.fromCharCode(chr3);
                  }
              }
              output = Base64._utf8_decode(output);
              return output;
          },
          // private method for UTF-8 encoding
          _utf8_encode : function (string) {
              string = string.replace(/\r\n/g,"\n");
              var utftext = "";
              for (var n = 0; n < string.length; n++) {
                  var c = string.charCodeAt(n);
                  if (c < 128) {
                      utftext += String.fromCharCode(c);
                  }
                  else if((c > 127) && (c < 2048)) {
                      utftext += String.fromCharCode((c >> 6) | 192);
                      utftext += String.fromCharCode((c & 63) | 128);
                  }
                  else {
                      utftext += String.fromCharCode((c >> 12) | 224);
                      utftext += String.fromCharCode(((c >> 6) & 63) | 128);
                      utftext += String.fromCharCode((c & 63) | 128);
                  }
              }
              return utftext;
          },
          // private method for UTF-8 decoding
          _utf8_decode : function (utftext) {
              var string = "";
              var i = 0;
              var c = c1 = c2 = 0;
              while ( i < utftext.length ) {
                  c = utftext.charCodeAt(i);
                  if (c < 128) {
                      string += String.fromCharCode(c);
                      i++;
                  }
                  else if((c > 191) && (c < 224)) {
                      c2 = utftext.charCodeAt(i+1);
                      string += String.fromCharCode(((c & 31) << 6) | (c2 & 63));
                      i += 2;
                  }
                  else {
                      c2 = utftext.charCodeAt(i+1);
                      c3 = utftext.charCodeAt(i+2);
                      string += String.fromCharCode(((c & 15) << 12) | ((c2 & 63) << 6) | (c3 & 63));
                      i += 3;
                  }
              }
              return string;
          }
          }

Now that we have a Base64 object, we can use it to encode the uri path to send across the internet.

      //Call the `encode` method on the local URI that DocumentPicker                returns
          const cloudUri = Base64.encode(succ.uri);
          //This line will let cloudinary know what MIME type is being sent
          let base64Aud = `data:audio/mpeg;base64,${cloudUri}`;
          //attach the recording to the FormData object
          let fd = new FormData();
          fd.append("file", `${base64Aud}`);
          fd.append("upload_preset", process.env.UPLOAD_PRESET);
          fd.append("resource_type", "video")

          fetch('https://api.cloudinary.com/v1_1/${process.env.CLOUD_NAME}/upload', {
            method: 'POST',
            body: fd,
            })
            .then(async (response) => {
              let recordingURL = await response.json();
              console.log('Cloudinary Info:', recordingURL);
              return recordingURL;
            })
          .catch(err => console.log('cloudinary err', err))
          })

If you already have a Base64 object or string and just want to test that your audio transmissions are working, the kind soul that responded to my initial request for help previously created a working JSFiddle to test that your Base64 is also generating the results you expect, it was incredibly helpful in debugging so I'm happy to share it here as well.

Just replace the Base64 string with the one that you're generating as well as putting in your Cloudinary API information. It was really easy to use this tool and is a great way to test your code quickly!

Down the Rabbit Hole: An Intro to SDKs

Jill — Mon, 03 Feb 2020 04:34:48 +0000

Typically when I see acronyms in docs I do one of two things: either "ignore complexity" like I've been learning to do with most concepts, or just altogether dissociate.

Honestly, I checked out hours ago

Neither of these actions are really helpful, and the second option is usually pretty disruptive of my workflow so recently, I've started allowing myself a strict, alarm-set 5 minutes to google something, and then make assumptions as to what it could really mean. It's not that I don't want to know what literally every single one of these acronyms means, but when I'm on insane deadlines, stopping active work to take on Zelda-like side-quests is a sure-fire recipe for an Alice-like rabbit hole.

Welp, here we go again

But sometimes, just like in Alice's case, some of these (acronym) side-quests are absolutely worth going on. Take "SDK" for an example, a perfectly good acronym in which I was more than happy to ignore the complexity of, but little did I know I would be completely immersed in it for a project that I was about to begin working on.

After a click or two around Wikipedia, I was happy to discover that I didn't actually have to go that deep into the rabbit hole to find out what SDKs are all about, and was even more psyched to learn that they're really not all that complex or scary as I thought.

During an app's planning stages, one of the first things to consider is what platform it will utilize. Whether it's an mobile or web application, the development requirements will be different and will require different tools to implement functionality. Luckily, when utilizing an SDK in development, a lot of these concerns are abstracted away by the out-of-the-box functionalities that SDKs provide.

A Software Development Kit, better known as an SDK, is a collection of tools that allows programmers to build apps for specific operating systems or devices. Regardless of what operating system or device an SDK is for, all the best ones come equipped with the same base ops that include:

Documentation
Code examples
Libraries
Tutorials
API's
IDE capabilities
Tools for testing and debugging

These kits aid developers throughout an app's construction and provides a way to utilize a number of languages, services, and functionalities that developers would typically have to pull from external API's and other services across the web. Most applications include a number of SDKs, with the average being between 15-18. Similar to npm, SDKs also have management systems that keep packages organized like "NVIDIA" or "SDKMAN!"

A few examples of SDKs are:

Expo
Flutter
Windows SDK
iOS SDK
Android Studio

note: Android Studio is interesting because it is actually an IDE for developing Android apps, but actually comes with the SDK built in.

In the aforementioned project above, my team and I used the Expo SDK build a native audio recording app with React Native. Expo is a great SDK to utilize when first starting out. It has a lot of built in API's that can be accessed and once the I got the hang of it, I found myself really enjoying the experience.

Another huge benefit of Expo is that it's a multi-platform SDK, meaning underneath the hood, it's handling the functionality for developing in both Android, which is written in Java, and iOS, which is not. Either way it's complexity we can ignore, which is awesome.

Expo handles both iOS & Android functionality in one package

Like a good SDK, there was clear and up-to-date documentation whenever platform differences needed a tweak here and there, as well as a plethora of built-in API's to choose from to suit our app's needs.

Also, like all SDKs it was easily installed in one package:

//make a new directory to create an expo project
mkdir my-expo-project

//cd into the project
cd my-expo-project

//install the expo client with npm
npm install -g expo-cli

//initialize an expo project
expo init

//follow the directions that appear in in the console to create your project!

Expo is just one of many SDKs to choose from, and choosing the "right" one is solely built on the needs of the app. Occasionally, SDKs
may prove to be not the right fit for development, and this can happen early on our even in the middle of development. While Expo provides the ability to "eject" from the SDK to revert to native code from any standpoint without extreme overhaul, others may not, and therefore it's important to read any initial documentation before settling on an SDK for your app.

In conclusion, SDKs are just a collection of software development tools that are used to build apps for specific platforms or operating systems.

What are your best and worst experiences working with SDKs?

Thanks for reading!

Mac commands in VSCode: A requiem for Windows

Jill — Sun, 26 Jan 2020 18:08:32 +0000

Recently I made the switch from a Windows operating system to a macOS, and while it's probably contrary to popular opinion, I still love and prefer Windows! I grew up on hand-me-down Dell's so I admit, I'm completely biased. I've worked with Macs on occasion for jobs in the past so the switch wasn't a total culture shock, but I never really took to mac's interface, and therefore have never worked with one personally or extensively until a few weeks ago.

Now, in a learning environment riddled with apple products and their seasoned users, I find myself in unfamiliar territory, and showing off my noob-ness when I accidentally still try to use Windows commands out of muscle memory. The most common mistake I make in running commands in Mac is pressing the control button to when I intend to press the command button. In the pressure of the moment, (because of course it always happens when I'm pair programming) I often forget which one actually works for which operating system.

So I came up with a little alliteration to use when these moments happen, to remind me what goes where:

co[n]trols are for wi[n]dows, co[mm]ands are for [m]acs.

Sure it's simple and silly but when I'm trying to think and work fast, this little reminder helps me out! The list of pure mac commands is extensive and of course I still haven't mastered it but to be honest, I do most of my work in VSCode anyway and find myself using keyboard shortcuts (sometimes Windows ones, doh) in that environment all the time, so for my fellow windows users who may have also recently made a switch, I've drummed up this abbreviated list of some of my favorite commands.

wink

VS Code Command Cheat Sheet

⌘

This symbol denotes the use of the mac's command button, again, for the seasoned mac user, this is probably obvious and second nature at this point, but after 20+ years of working on PC's, this is something that trips me up often.

Code Editing

⌘X: Cut (+ Shift for individual character/ line control)

⌘C : Copy (+ Shift for individual character/line control)

⌘S : Save

⌘/ : Comment out an entire line or create a line comment
(+ Shift over multiple to comment out multiple lines at once)

⌘L : Select an entire line

⌘D : Select every word in the file that matches current line input

File Navigation

⌘F : Pops open a text bar to (F)ind the searched text in a file

⌘X + Up Arrow / Down Arrow : Jump to the Top/End of a file

⌘ Backslash : Hide/Show Side Explorer Navigation

control + BackTick : Hide/Show Terminal

⌘P : Quick Navigation (Drop Down Nav that lists all files)

⌘ + Shift + P : Opens the Command Palette

⌘K: This one is really cool because it's designed to wait for a second command called a chord.

These are some of my favorite ⌘K combos:

⌘K⌘T : Opens the theme list to allow for a quick change of editor view

⌘K⌘X : Trims all the trailing white spaces. I love this command. If you're like me and struggle with formatting, this one is super helpful when linting your files.

⌘K⌘Z : Toggle Zen Mode

⌘K⌘S : If all else fails and you still find yourself using Windows commands, this handy shortcut lets you change commands to be what you want!

I wrote this because I often work with Mac users who I chuckle with when I stumble over keyboard shortcuts. While I may be incredibly fond of PC's, I also consider it a wonderful skill to be able to utilize a myriad of tools as a fullstack software engineer, shortcuts being one of them.

Keyboard shortcuts are important for productivity on any operating system, by leveraging them we optimize our own performance which in turn can even have an impact on the quality of our code. The longer we can keep our hands on the keys, the more successes and failures we can work through in a shorter amount of time.

Do yourself and your fellow co-workers a favor and get comfortable with keyboard shortcuts, (even if it means 'importing' some commands from another OS!) doing so will help ease the iteration towards the final goal.

Thanks for reading!

What are some of your favorite keyboard shortcuts to aid in productivity?

Routing: The Express way!

Jill — Sun, 19 Jan 2020 22:35:41 +0000

Initially, the concept of routing was easy for me to grasp:

A user clicks on a DOM element
That element triggers a request of some sort
The server responds to the request appropriately

In a sentence: A click routes you to anywhere you want to go.

Simple.

I think we can all agree that that's not too difficult of an idea to grasp, however when it came to the implementation of these routes, I was completely lost.

The software development program I've been in the past few months initially taught us to write routes using raw node, (senior developers: let that sink in) and because I was completely immersed in code at that time, it was just another sprint in which I grasping at straws to understand and complete in an allotted time. Through my anxiety, exhaustion and being so wrapped up in the details, I couldn't tell which "route" to follow.

My senior partner already had this concept down to a science, but in time, with more practice (and less studying!) I've finally come to understand this important technique, and also why we initially wrote these request routes without the help of Express.

I can still feel empathy for my former less-enlightened self and can understand even now how the concept of middleware, routing, and endpoints can be tricky AF to grasp, especially when I had only just recently learned what API's are, but hopefully this post will provide insight and be a point of reference for you in the future.

Routing in Node

Express is a lightweight framework for Node that abstracts away a lot of code that we would initially have to write to respond to requests from the client. Take a look at this little snippet of a GET request written in raw Node:

const defaultHeaders = {/*...*/};

const requestHandler = (req, res) => {
  let statusCode;
  if (req.method === 'GET') {
  if (req.url === '/classes/messages') {
    res.writeHead(200, defaultHeaders)
    res.end(JSON.stringify(data))
    }
  }
}

While we can very easily see exactly what happens on each GET request to the 'classes/messages' endpoint, we can also probably see how easy it could be for this method to become exponentially extensive once other request types are accounted for.

This method didn't feel helpful or important early on, but it is! It's the only way we can really appreciate all the work Express does for us under the hood.

Our sprint that required using this antiquated method mercifully only needed responses for a few routes, but again, what if we had to deal with route requests on a much larger scale? Check out this graphic that displays the structure of Facebook's routes:

Having to route with Node in such a massive code base would be...punishment.

Thankfully, Express steps in to abstract away much of the code that is needed to respond to client requests, which in turn provides the ability for us to keep our code modular and DRY.

Routers / Middleware

Express allows for additional abstractions via its use of application-level middleware. The standout feature here is a Router (service), a function that has access to the Request and Response object, and routes the requests from the client to the appropriate handler. We can clean up our code by using routers, and make logic easy to understand for future contributors who may want to iterate on our legacy projects.

Express handler functions are written in correspondence to the HTTP object, so the methods should appear familiar and be pretty intuitive as to what they do.

Each handler takes a path and a callback as arguments, and must be written in sequential order due to Express' chain-like scope.

//index.js

const express = require('express');
const app = express();
const port = 3000;
//Keep routes in a separate file for maximum modularity
const router = require('./routes');

//register the middleware [file] in the app
app.use('/', router);

app.listen(port, () => console.log(`Express app is listening on port ${port}!🛸`))

Now, instead of having to jam all of our routes in the index.js file, we can simplify and separate out the logic to store all of our handling functions in a routes.js file.

//routes.js

var express = require('express')
var router = express.Router()

/*Not necessary but a great way to keep track of what's happening on each request*/

router.use(function timeLog (req, res, next) {
  console.log(`Starting a new route to ${req.method} resources: ${req.url}`, Date.now())
  next()
});


router.get('/', function (req, res) {
  res.send('Hello World!')
})

router.post('/', function (req, res) {
  res.send('You're logged in!')
})
module.exports = router;

When we run the server using node index.js and navigate to localhost:3000 in the browser, we see the message 'Hello World!' appearing on the DOM, even though the function that handles the request to GET the home page is in a different file.

Not only has the request object responded to our client's request as we expected, but by using the timeLog function, we also see helpful information in the console for each request.

Starting a new route to GET resources: / 1579450161070

Express helps us ensure that our clients get the information they're asking for with the expected response as well and not just :

The Router in routes.js responds to each request and calls the next() function in the chain that needs to respond to this request.

Endpoints

When constructing routes, remember that the standard naming convention is that endpoints should follow the rules of REST and be named relative to whatever the resource at that endpoint returns.

For example, if you're working with users, the endpoint would be /users, for a specific user, the endpoint would be /users:userId with the colon denoting a variable.

The common construct for denoting the home or index page is simply by using /.

Endpoints ensure that our users wind up in places we've actually marked in our path for them, and that they also receive the information they expect, otherwise, they can run into 400 and 500 as a result.

In Conclusion

Save yourself some keystrokes and route using Express. Abstract away additional logic and separate your concerns by using the Router middleware service, and keep your naming conventions relative when it comes to creating endpoints.

If you make things even more productive, do yourself a favor and install the express-visualizer tool. Via this helpful, interactive graphic, we can see exactly how our routes break down, the requests they respond to, and what each of them may need in addition to what they already have.

I hope this post is helpful and helps you get on the right path when it comes to routing:)

Thanks for reading!

Failure, a Follow-up

Jill — Sat, 11 Jan 2020 15:38:30 +0000

Before starting to code, I honestly couldn't remember that last time I really felt like I had failed at something.

I mean really failed.

When was your last time? College? High School? This morning when you failed to make it to work on time? I left college after a year and to this day I don't consider that a failure, it was a choice that I made and was and still is the right choice for me. No, I think the last time I really felt the sting of failure and disappointment was when I didn't make the Varsity Cheerleading squad in 9th grade, but was delegated JV captain.

You might be thinking: "well what's wrong with JV?", and the answer would honestly be "nothing", but I hadn't achieved my goal and I remember feeling absolutely crushed.

I'd worked so hard on my craft but I still had just missed the mark. My friends congratulated me on my new title of team captain, but most of them made Varsity, so it was bittersweet.

Skip to the end of the season: during my time as captain, our squad earned the reputation of being a strong, competitive unit. We won the title of 'Camp Champs' during our summer session, beating out 30 other squads, and the following season saw more minority girls than ever trying out for the team. (That last part meant the most to me.)

At that time I couldn't see it, but looking back I know now that my coach saw something in me that, with additional time and polishing, could prove to be something special. She extended my time in training, and in turn provided an opportunity for me to achieve something even greater than my original goal.

Years later I've put down the pom-poms, and have put my spirit fingers back to work on the keyboard, and ten months into learning full-stack software development, I find myself failing almost every day.

¯ \ (ツ)/¯

Don't Be Afraid to Fail

Regardless of this fact, I feel that the most important thing I've learned on this digital journey is not even really learning how to code, but truly, how to fail and not take it personally.

I grew up in the whole "Failure is not an option" era, so the concept of learning how to fail fast and hard was initially very distressing for me, and asking a lot of questions felt like a trap setup to expose me as an imposter.

I'm so glad to have finally gotten both of those chips off of my shoulder. This year has taught me that asking questions doesn't show a lack of intelligence, but an interest in additional insight.

Additionally, and maybe even more importantly, I've learned that failure doesn't mean incompetence, and it can even be a mechanism for further research and testing.

Let's be brutally honest, failure is the perfect tool for formulating innovative hypotheses. (You definitely know what doesn't work at least!)

Don't Be Afraid to Be Wrong

Develop a fearlessness of being wrong, and practice the patience to get through and follow-up on failure, because in this realm of creativity, it is guaranteed to happen.

Just the same as it is with any other instance: failure isn't the part to get hung up on, it's what happens after failure that dictates finality or revival.

When learning to code don't be afraid to be wrong, don't be afraid to fail, and don't feel ashamed or discouraged by it when you do. Narrowly missing success doesn't mean that one is not cut out for this work, it has no bearing on one's intelligence or ability.

By learning how to rebound from these instances we actually prove our ability to ourselves if no one else.

I've had to overcome a lot of failures and losses this year to bask in what feels like only sparing moments of success, but those moments feel absolutely incredible and well-deserved when they do come, just because of the amount of effort that went into iterating towards it.

In Conclusion

Next time you face failure, remember to rebound. By getting past the tough moments, we get to the truly rewarding ones. Don't doubt your abilities, just trust yourself and ask for help!

Put your pride aside and don't be afraid to be wrong, and remember to ask questions! We create safe spaces in the work place when we can be open with our team members about the things we don't know and can build healthy work-relationships that encourage questions, ideas, and input from everyone.

Finally, if failure does lead to a setback, don't quit! Stay resilient and keep moving forward, the solution is out there just waiting on your arrival, sometimes it just takes a little longer. The marathon continues, so don't give up before you reach the finish line.

I'm cheering for you!

Database Indexing

Jill — Sun, 15 Dec 2019 01:50:59 +0000

If you've ever read a book, you absolutely know what indexing is. Whether you love fantasy, fiction, or science-fiction(guilty), all of these genres typically have one thing in common: they all have an Index! Often this index is called a "Table of Contents" but it's the same thing: at least one page of information in regards to what the book contains.

This table is also very much structured like a table in our database, with at least one key/value pair. The key usually being the chapter's title, and the value is the page the chapter starts on.

If it weren't for these indices, we would have to flip through every page in the book until we find the chapter we're looking for.

Even worse, what if were just looking for an excerpt from that chapter but the book had no chapters? No page numbers? It would be terrible! Luckily for us that's not the case, and the book's table of contents allows us to easily find the chapter we're looking for and the exact page that it's on.

Indexing a database serves that same purpose: to help developers retrieve information they're looking for with minimal input/output(I/O) operations and a fast sub-linear time complexity.

Data Basics

Indices in databases are amazing in the power they harness but the small amount of space they take up. They can be any data structure that helps improve a database's performance.

Very commonly, developers use B+ Trees to index. B+ Trees are self-balancing data structures that store information in keys in a condensed a manner that allows for a rapid retrieval rate.

An alternate, equally as powerful index structure is the B-Tree(above), which is also self-balancing, but stores information in key/value pairs.

Indices are created by using at least one, if not multiple columns in a table. Indices are also incredibly flexible because they don't follow a standard structure, therefore, implementation techniques can be left up to the developer.

There are a few syntax specifics in regards to their construction but overall, fewer semantics involved as well (looking at you AJAX).

Benefits & Trade-offs

Indices are a snippet of the database called the Key or Database Key. This miniature version of the database is it's own entity that keeps a shallow copy of the disk block address, or a direct link to the queried field.

Because of the space this 'mini-base' also takes up, we trade-off a rapid retrieval time with the amount of records our database can hold, as well as additional memory. One could also consider the initial time it takes to set up the index in development as a minor drawback, but frankly, I find this to be quite a fair trade in the end.

While it is possible to retrieve a specific field using only the first column in the index, it is not possible to retrieve a field only using the greater indexed columns, this is why it is important to keep the columns in order when indexing.

By keeping ordered columns in our index, we are able to use parallel processing algorithms that have guaranteed results and keep a sub-linear time complexity. What we wind up with is a useful tree-structure that cuts down our I/O operations.

Constraints in Construction

A lot of us absolutely crave structure (even if we don't realize or admit it), especially in work. Indexing is perfect for developers who need to translate their jumbled thoughts and data into a well-organized system. By policing the constraints we set for our database, the index keeps structure and order. Let me reiterate, indices are not the actual constraints, they just moderate and enforce them.

These constraints are placed on the database in creation and implemented using a Database Management System(DBMS) like mySQL, mongoDB(schemaless), or mariaDB.
My favorite is mongoDB because of it's readability and use of javascript functions, so let’s check out an example of what setting some of these constraints would look like:

 //create a new mongoDB schema using mongoose
 const artistSchema = new mongoose.Schema({
 //set the constraints for the index to moderate the artistId and name
 id: { type: Number, index: true, unique:true },
 name: { type: String, primary: true },
 hasVocals: Boolean,
 hasMoves: Boolean,
 hasBags: Mixed,
});



//create models for the db
const Beyoncé = mongoose.model('Beyoncé', artistSchema);
const Nicki = mongoose.model('Nicki', artistSchema);
const Rihanna = mongoose.model('Rihanna', artistSchema);

Great! We've built out our database schema and added some records, and now we can see (even with this incredibly basic example) how much easier it would be to find specific fields even in a sea of data. If we want to find Rihanna's information, all we have to do is type in her name or id to get her field's address. Indices are immensely helpful by providing fast, guaranteed results given a correct input.

In Conclusion

It's easy to turn a standard database into a super-base just by adding an index data structure! While my example was simple, imagine a search through thousands of documents and how difficult it would be to find one piece of specific information without an index to locate exactly where it is.

Without an index, we fall into a slow linear time complexity and also increase the amount of input and output operations we would have to do, like breaking out of or continuing a loop once the data is actually found.

Next time you're constructing the schema for your database, make sure to set some constraints and create an index using the data structure of your choice to match. To every developer, everywhere: you'll be glad you did!

Thanks for reading!

Deep Impact with Dependency Injections

Jill — Sun, 08 Dec 2019 17:44:30 +0000

If you've ever filled out a tax return, the concept of Dependency Injection should be fairly easy to comprehend, even if the semantics are vague.

On US tax forms, there's a section to fill out for "dependents", people (usually children) that rely upon the tax payer for their own livelihood. This is an excellent example of how dependency injection works and why it's so important to use in our applications.

Dependency Injection (DI) is simply when one object supplies the dependencies of another object, and a dependency is just an object that can be utilized throughout an app.

CLASSES

There are three very important parts classes in the DI pattern. The service object, to be used, the client object that depends on the service, and the injector, which is responsible for constructing the service and injecting it into the client.

By creating objects directly within the class that requires the objects, our code becomes tightly-coupled and inflexible. Because the class is dependent on specific objects, it becomes impossible to change any instantiation later without having to refactor the entire class.

The class then cannot be reused if other objects are required, finally making it hard to test because of it's heavy reliance on real objects that cannot be mocked.

DI provides a solution to these many issues by creating objects, understanding which classes require those objects, and then providing those classes with the objects.

Wikipedia provides a helpful analogy:

"Service - an electric, gas, hybrid, or diesel car
Client - a driver who uses the car the same way regardless of the engine
Injector - the parent who bought the kid the car and decided which kind"

Why DI

Stay DRY

By following the principles of DI we effectively can reduce boilerplate code since all work to structure and initialize the dependencies is handled in a single component.

Separation of Concerns

One of the most important pros of using DI is the separation of concerns when building components. The biggest trade off here would be that DI can make code difficult to trace because it separates client behavior from construction. However, with good variable and file names, module co-ordination will be far easier to navigate than one file with hundreds to thousands of lines of code.

Parallel Programming & Unit Testing

When components create their own dependencies, there is no way to effective way to test their functionality. In the example below, the Coupe object depends on both the Engine and Wheels Object, while the Engine object is dependent on the Pistons object. This is called "Tightly Coupled Code", and can become very problematic.

function Wheels() {
  this.action = () => log("We're rollin' now!");
}

function Pistons() {
  this.action = () => log("Pew! Pew! Pew!");
}

function Engine() {
  this.pistons = new Pistons();
  this.action = () => {
    this.pistons.action();
  };
  log("Hummmmmmmm.");
}

function Coupe() {
  this.wheels = new Wheels();
  this.engine = new Engine();
  this.action = () => {
    this.wheels.action();
    this.engine.action();
    log("Nice car lady!");
  };
  log("Fresh off the lot.");
}

Should any of Pistons object happen to fail, both the Engine and the Coupe would fall apart, this can lead to spaghetti code and hard to find bugs.

The solution is to loosen the couplings of the code and pass the dependency as a parameter to the client object.

function Engine(pistons) {
  this.pistons = pistons;
  this.action = () => {
    this.pistons.action();
    log("Hummmmmmm.");
  };
  log("Fresh off the lot.");
}

function Car(wheels, engine) {
  this.wheels = wheels;
  this.engine = engine;
  this.action = () => {
    this.wheels.action();
    this.engine.action();
    log("Nice car lady!");
  }
  log("Fresh off the lot.");

While the code above is a better method, it can still lead to coupling and scope issues. To truly separate our concerns, the best way is to isolate them completely, and keep our clients from knowing anything about eachother, which can be achieved with Inversion of Control.

Inversion of Control (IoC)

DI is a broad technique used to achieve IoC, which a concept that operates on the belief that an object should not configure its dependencies statically, but should be configured by some other class externally.

To make it relatable, let's say you're going on vacation and plan to stay at a nice hotel or resort. It's not your responsibility to bring towels, sheets, the phone in the room etc.

The hotel provides the amenities so you can do the one thing you came to do: enjoy your vacation. IoC follows this same principle to decouple our code, by isolating the dependency and then passing it to client objects on demand. This method maintains those important connections between service and client objects, and effectively extend the app's functionality.

Containers

The use of a service within a DI or 'unity' container is popular in many frameworks, and Angular JS utilizes this method extensively. This method effectively implements IoC by separating the construction concerns and use concerns of this video player app by creating a service, and then passing it to the instance, which uses it throughout the app as props.

angular.module('video-player')
  //create a new service to act as an DI container
  .service('youTube', function ($http) {
    this.search = function (query, cb) {
      //utilize the $http object
      return $http({
        //specify the request method
        method: 'GET',
        //request the proper endpoint
        url: 'https://www.googleapis.com/youtube/v3/search',
        //params required for angularjs https requests
        params: {
          key: `${YOUTUBE_API_KEY}`,
          q: `${query}`,
          part: 'snippet',
          maxResults: 5,
          type: 'video',
          videoEmbeddable: true,
        }
      }).then(function successCB(response) {
        console.log(response, 'here's that video you asked for!');
        cb(response.data.items);
      }).catch(function errorCB(response) {
        console.error(response, 'sorry, couldn't get that video for you');
      });
    };
  });

DI Containers are so useful because dependencies are defined in a single place instead of throughout your app, and the components that depend on them can easily request data from them without knowledge of any other dependents.

angular.module('video-player')
  .component('app', {
    //pass the youTube service to the app controller to pass down it's response
    controller: function (youTube) {
      //mock videos 
      this.videos = window.exampleVideoData;
      //this selects the first video from the response
      this.currentVideo = window.exampleVideoData[0];
      //onSearched will call the youtube search function on a queried string
      this.onSearched = (query) => {
        //the youtube search takes a query and a callback
        youTube.search(query, this.afterSearch);
        //console.log('video queried!');
      };
      //helper function to re-render the video player and list to the updated queried item's top 5 results
      this.afterSearch = (videos) => {
        //reassign the queried video results to the videos attribute
        this.videos = videos;
        //reassign the first video to the current video in the player
        this.currentVideo = videos[0];
      };
      //select video will grab the index from the array and render selected video to the main player
      this.selectVideo = (index) => {
        //updates the current video to the plucked index video;
        this.currentVideo = this.videos[index];
      };
    },
    templateUrl: 'src/templates/app.html'
  });

In Conclusion

allow us to stay DRY, separate our concerns, extends and uncouples our code while still effectively passing data to our client objects that need them. Use the DI principle whenever you want to implement parallel programming in your code and look forward to better and more successful unit testing in your next application!

Thanks for reading!

R&R with REST API's

Jill — Mon, 02 Dec 2019 04:17:12 +0000

Application Program Interfaces(APIs) are the unofficial language of the internet, and allow servers to successfully transmit data back and forth.

While APIs are the common tongue of the net, a Representational State Transfer(REST) API would be a specific dialect, or as I personally like to think of it: the love language of servers.

REST APIs use the HTTP object to communicate various requests and responses, and though it's guidelines and pattern may seem strict, it is this structure that makes resource access easy and consistent.

This system is similar to that of reading a document that uses proper grammar, indentation, and punctuation vs. reading one that does not. Even with complex content, documents that follow English Language standards are far easier to decipher than those littered with poor grammar, spelling errors, and improper or missing punctuation.

By setting up this backing structure, the flow of an API request runs smoothly and we are able to utilize it's resources in a number of ways. When a REST API is called, the server will transfer a representation of the state of the requested resource from the API, to the client.

Because REST APIs follow their own style standards the more familiar you are with the prototype pattern, the more success you will have when attempting to retrieve resources.

Let's break down the style and structure of this incredibly useful format with some help from my favorite constantly reincarnated, eternally ageless, world-saving hero:

"Wake up, Link!"

Six Rules of REST

The goal of a REST API is to have a completely modular web server, which can be achieved by following these guidelines:

Client-Server Separation

REST APIs require that the retrieved state be stored on the client and not on the server, which improves the portability of the app by separating the concerns of the client, like the view, and the storage concerns of the server.

Stateless

The server sending the request should also be stateless, meaning the server remembers nothing and knows nothing about previous or other calls made to the API. It's only concern is the data contained within it's request body.

Stateless calls can be made independently and each call must contain everything needed for the API to send a successful response.

Cache

Responses from the server send documentation on whether or not the requested resource is cacheable. If so, the resource will be saved to the client cache and wont have to be requested again to retrieve that same results repeatedly.

Uniform Interface

Uniform Interfacing ensures that every request, no matter the client language(chrome, linux, python, etc)is structured in the same manner.

Layered System

The concept of a layered system builds on the idea of the separation of concerns between the client and the server. Between the client request and the API's response, there should be a layered system of independent components.

This is where middle-ware software like 'Express' is use and allows us to create routes from individual components to the API, further separating an application's business logic from it's application logic.

The number of layers don't matter, and they should have no affect on the API's resource request or response; they just must be present.

Code on Demand

Code on Demand is not an actual requirement and is executable code that is sent from a server to a client in a request.

R & R

Requests and Responses are made easy when working with REST API's and the HTTP Request Object, once we finally decide which API best suits our project, we can open the lines of communication to get what we need for our app.

Methods

In any Legend of Zelda game, different quests require Link to use different tools to be completed; the same is true with the REST pattern. Each request requires a different method to access resources. In order to get what we need, we must make sure we're using the right method and structure when making client requests.

Similarly, each Legend of Zelda game, while different in design, landscape and style, all retain the same overarching structure: sleeping hero awakens to a quest, hero battles monsters, hero saves the princess, hero saves the day.

REST API's may vary in the style of how the request should be sent, but the backing structure is always the same: URL, End Path, Headers, and sometimes a Body.

Root Endpoint

Every request from a client must include a root endpoint as well as it's method type. By using the Command Line Interface(CLI) in any terminal, we can practice interacting with REST API's. The curl command sends GET requests by default

                       curl https://api.github.com

Path

The Path follows the end-point and is composed of a relative adjective determined by the developer. This pattern of REST also makes it easier to find exactly what we're looking for, and colons denote the use of a variable.

                 curl https://api.github.com/users/:username

Headers

Headers are optional and often used for authorization methods, Cross Origin Resource Sharing(CORS) and identifying other important information the API might need to process the request. A common use for headers is identifying the content type of a request, when using the CLI, -H denotes the use of a header or series of headers.

curl -H "Content-Type: application/json" https://api.github.com/users/:username

$#Body

Like Headers, a request body is optional, but beneficial in many cases, such as POST requests which are used to create a new resource on the server and save it to the database. The -X denotes the use of a custom HTTP method and the -d identifies the data that is going to be saved.

curl -X POST -H "Content-Type: application/json" -d '{"thisIs: "theBody"}'https://api.github.com/users/:username

Follow these guidelines and request structure and you wont wind up having to deal with this side quest:

In Conclusion

REST API's are just API's styled with a standard. Because they follow a pattern, data access and retrieval via requests and responses are a convenient and consistent way for developers to build out applications with the backing power of websites like Google and Youtube.

GET some REST and thanks for reading!

The Bey in B-Trees

Jill — Mon, 25 Nov 2019 14:09:48 +0000

My first year of code has really (self)taught me a lot about the caveats that come with writing JavaScript. Often as developers, when learning a series of new methods and soon-after confronting a task we think to ourselves: "What's the best way to do this? and even more often we soon after find ourselves responding: "Well, it depends."

This same question often comes up in our decision-making about how we store and utilize our data. Managing small amounts of data is usually a fairly easy task to accomplish, and with the use of Abstract Data Structures like Trees, Binary Search Trees(BSTs), Linked Lists, Graph, and Hash Tables, we can easily access data and perform retrieval and alteration methods, often meeting our needs with a linear or constant time complexity.

But what happens when we begin generating massive amounts of data and need to be able to sort through it quickly and efficiently, but without negatively impacting the time complexity?

Luckily we can answer this question easily; the writing's on the wall: The B-Tree.

Say My Name

It's still highly ambiguous what the 'B' in 'B-Tree' actually stands for (Binary, Balanced, Rudolf Bayer who invented them...?), but for the sake of this lesson in real-life relatability on just how special B-Trees are, from here on out, the 'B' stands for Beyonce. A gifted, unique, and incredibly powerful figure in modern society.

Upgrade U

Bey-Trees are superior data structures that are similar in their construct to Binary Search Trees, but with some upgrades. Like BSTs, Bey-Trees have the the ability to add, search, and remove nodes, but also have the super power of being able to self-balance.

Bey-Trees maintain sorted data in condensed child nodes, and changes to the tree are made in relation to the root as opposed to just being appended on to the end of the branches.

Also like BSTs, Bey-Trees contain two children, but that is the absolute minimum number of children they might have, and if one is really harnessing the power of Bey-Trees, the minimum number of children should increase exponentially.

Formation

The amount of children a Bey-Tree can have is determined by the loosely named properties called the degree, which is the minimum number of children on a branch, and also the order; the maximum amount of children can have until it must be re-balanced.

When a Bey-Tree is initially constructed, the order is simply generated as an empty array with an allotted amount of space for children to eventually be pushed in to.

Children of the key are sorted based on their numerical value in relation to the parent key. For example, a Bey-tree with an order of 4 can have at most 4 children before it is re-balanced.

Children with a value less than that of their parent key are pushed to the left of the parent, while children with a value greater are pushed to the right.

By decreasing the height of the Bey-Tree via use of sorted data through parent keys, Bey-Trees easily store and retrieve data using the indices at the parent key. Therefore while a Bey-Tree can have at minimum number of 2 children, the more data, or records it holds, the faster it can perform it's task, i.e., sorting, maintaining, and organizing data in logarithmic time.

Here's a little snippet of what a Bey-Tree instance might look like:


const formation = 3;
//the maximum num. of children before a function is called to rebalance the tree

const BeyTreeNode = function (keys, dChildren, parent) {
const beyNode = Object.create(BeyTreeNode.prototype);
beyNode.keys = keys || [];
//parents to determine less than, greater than, or in between

beyNode.dChildren = dChildren || new Array(formation);
//creates an empty array with spaces for children --> [ , , ];

beyNode.parent = parent || null;
Return beyNode;
}

//classic Methods
BeyTreeNode.prototype.insert = function(){};
BeyTreeNode.prototype.find = function(){};
BeyTreeNode.prototype.remove = function(){}

//B-Tree Unique Method
BeyTreeNode.prototype.handleOverflow = function(){}

In Conclusion

The next time you're looking for truly the best way to store all of your data, look no further, as the Bey-Tree provides a reliable, succinct method for ccessing super bowl amounts of data all while maintaining speedy logarithmic time.

Thanks for reading!

Import, Exports, and Require(it) Too!

Jill — Sun, 20 Oct 2019 20:59:22 +0000

We've all ordered something from the internet right? Whether the shipping was domestic or international, at one point in time you've more than likely had to wait a few days for something to come in the mail from somewhere nearby, or more often, from some far away place where the shipping cost was $20+.

We could probably find the same item domestically of course, and it could even be better quality, but the caveat is usually that while domestic shipping takes less time and costs less, the price of the item is typically more expensive than an imported item.

Once we've reached this point in our on-line shopping cart, the age old internal battle of wits begins:

"Do I pay the local cost, and save on wait time but pay more for the item? Or do I pay the international costs and save on the overall expense but spend more time waiting on it?"

It usually boils down to one very simple solution:
However we're feeling at the time! ¯_(ツ)_/¯

We know we're going to pay either way, so it truly just depends on what we want, how soon we want it, and how much we're willing to pay to get it, right?

Well, that thought process is really the same when using ES5's module.exports/exports and require( ), and the update to those methods in ES6 to import from and exports.

I recently did a presentation on this subject and the details of the specifics of this topic are broad and vary, but, there are definitely some very helpful, solid principles to remember when importing and exporting...well, there is really just one MAIN principle to remember:

That's it! As long as you stick with a singular concept and only use module.exports/require() OR import/exports, you won't get tripped up in code conflicts.

Imports, Exports, & Conflict Resolution

The idea behind importing and exporting was an ES5 collaboration between CommonJS & Nodejs as a resolution to various issues software developers were facing when building out modular programs.

Often times, the DRY principle was broken to use the same functions in different parts of the program, and
of course, before long, this became increasingly problematic. Luckily, CJS and Nodejs came
up with a simple solution: Confine these declarations in their own file, then, require the desired
code snippets for use in another.

Now, instead of rewriting the same lines of code over and over and possibly overwriting previously declared variables, the same piece of code could be used multiple places throughout a program without any additional conflicts! Programmers rejoice!

module.exports / exports

Module.exports or sometimes just exports is a special default object that comes built-in to Node. This special object is used to ease module creation and encapsulation, the result of which is cleaner, more organized code and access to specific properties that would not be typically available due to the individual scope of each module in a program.

Exports can be any data type and exported in a variety of ways, such as directly as an object, a named variable, and even dynamically as a function. Now, with just a little effort, we can get the code bits we want out of confinement, and drop sprinkle them into the new scopes where we want them, without causing new conflicts in the program.

seinfeld.js

module.exports = {  
   firstName: 'Elaine',
   lastName: 'Benes'
}

//exports is just a method on the special module object
exports.SoupMessage = 'No soup for you!';

module.exports = function(cerealName){
   console.log('I love ' + cerealName +'!');
}

require( )

It's just as easy to require pieces of code in separate files as it is to export them. By using require( ), code snippets can jump safely out of their scope and brought into another. Not only can an individual's code be exported and required, but so can package files.

seinfeld.js

const crpyto = require('crypto');
const axios = require('axios');
const faces = require('cool-ascii-faces');

These snippets are loaded via their file paths or package names and can also be done so in a variety of ways:

showAboutNothing.js


const Elaine = require('./seinfeld');

//grab a utility library while you're at it
const util = require('underscore');

//as a deconstructed object or array
const { George, Jerry} = require('./seinfeld');
const [ Kramer, Elaine ] = require('./seinfeld');

import from / export

Following the success of the module.exports object and require method, this process was kept in, and updated with the release of EcmaScript2015(ES6).

Additionally, in ES5 syntax the file is evaluated from top to bottom. Once the interpreter sees the call to require( ), it jumps to that file to retrieve the exports, and then jumps back to the current file.

This can cause a lag in the program and was updated in ES6. Now, the program is read before it is evaluated and is immediately prepared to run, optimizing the program's overall performance.

The ES6 update also dropped the use of the keyword 'module' and adjusted the command to just export. Functions, Objects, and primitive data types are still available to be developers as Named exports, which include 0 or more per module, as Default exports, including only one export per module, or as Hybrid exports, which is a combination of both.

seinfeld.js

//as deconstructed object
export { George, Jerry } = theGuys;

//a regular object
export default function ({
    firstName: 'Elaine',
    lastName: 'Benes'
};

//variable
export const seinFeld = aShowAboutNothing();

//function
export function helloNeighbor(){
    console.log('KRAMER!');
//classes
export class VandelayInd{...}

//via list and alias

export { george, jerry, elaine, kramer };
};

//aliases help to avoid naming conflicts
export {jason as george, julia as elaine};

Keeping in the same spirit of development ease, importing from a file is just as easy as it was to require( ) a file. Properties can also be imported dynamically, individually or in groups.


//it's as easy as letting the interpreter know where to import from

import { getVandelayEmployees } from'/modules/seinfeld.js';

//importing can be done dynamically as well

import('/modules/vandelay.js')
.then((jobTitle) => {
    console.log(`I'm the ${jobTitle} at Vandelay Industries`);
});

In Conclusion

Whether we use module.exports and require or import from and exports, developers have the peace of mind of knowing that whatever our choice, the possibility of conflicts is reduced exponentially by using these helpful commands in our code. By sticking to the "One" rule and only using one version at a time, projects will be cleaner, more modular, and expertly organized.

What more could a developer ask for?

I advise you to do some deep exploration in the MDN docs for a wealth of additional information on this topic, as it is incredibly broad, and one syntax may better suit your needs than the other depending on your project.

Now get out there and export/import something!

Thanks for reading!
"✌(-‿-)✌"