DEV Community: arindavis

5 Keys to Succeeding In Any Coding Bootcamp

arindavis — Thu, 20 May 2021 20:37:04 +0000

Having just completed an intensive coding program, I've found that I've accumulated quite a lot of advice that I wish I could retroactively give to my younger self when she was just starting out. Since the Elon Musks of the world refuse to seriously invest in time travel any time soon, I'm gonna give all that advice to you, the reader, instead.

So listen close and follow along with the points below. You may have some idea of what you're about to get into, but chances are you probably don't.

1. Utilize your instructor's help (really though)
This one helped me so much, and is probably the most important tip you should take away from this blog post. So often we are afraid of asking stupid questions for fear of being seen as inferior, but we need to learn to move passed this instinct if we are to succeed in a high stakes environment. I posit that stupid questions are the most important questions, because they will always clear the air and foster greater group understanding after having been answered.

Notice I used the word group there, because most of the time when you have a stupid question, someone else is probably also wondering something similar (if not the same exact question). One of you needs to be brave enough to ask, and it might as well be you!

Even if no one else is wondering it, though, and someone does think lesser of you for asking what might be obvious to them, I think it's still worth it to ask. You're paying good money to be here and taking a huge risk by setting a ton of time aside to learn this skill, get your money's worth and ask that question! Temporary embarrassment is worth a skill you'll have for a lifetime.

2. Find resources outside of your course
Whether its technical documentation, youtube videos, or an entire online course, outside resources are going to help you go the extra mile. I know this sounds daunting, because your workload is already going to be insane, but I'd encourage you to basically say goodbye to most other parts of your life and dive head first into working after hours. Obviously you are going to want to stay ahead of your assigned workload(see tip 4), but when you can find the time you need to be practicing even more.

The idea is that you need to be getting as many hours in coding as humanly possible, as this will make you more competent throughout the program as well as make you a more attractive candidate during your eventual job hunt.

If you're looking for recommendations, there was a free React Scrimba course that my entire cohort swore by. Scrimba is an excellent tool, and probably has a course on something you're studying.

3. Get to know your cohorts
This one may seem obvious, but it's still worth mentioning. You're going to run into a problem relatively soon where you feel burnt out, uninspired and like you aren't getting anywhere with your work. When you go to explain this to anyone outside of your cohort, you'll get some support, sure, but more often then not people won't know how to relate to you or what you're going through.

But you know who does? Literally the rest of the cohort. We are social creatures, and knowing that someone else is struggling in the same way you are can help contextualize your mental state and make you feel less alone. We all struggle with imposter syndrome at one time or another, and the best cure for it is simply talking about it with those who understand. As you progress throughout the program, these strangers will eventually become friends. There's a strange phenomenon that happens when a group of people are all put under the same stress at the same time, a sort of bond that will last well beyond the program itself.

Even beyond that bond, these peers of yours are the first stepping stone for your professional network. Not only is it merely beneficial to befriend them, it can often be crucial.

4. Strive to stay ahead on your workload
This may seem like another obvious one, so I'll keep it relatively short. You're going to have a lot of work to do, there's no getting around it, so I encourage you to instead get ahead of it. Nothing ensures success like having everything turned in 10 minutes early, and no early bird every complained about not getting a worm.

There's not much else to say on that front, just make sure you hold yourself accountable to this goal.

5. Take Care of Yourself, mentally and physically
This one is everything. Just because you're going to be sitting down at a computer for most of your time in the program doesn't mean you have to resign yourself to a sedentary lifestyle. Take walks when you can, drink tons of water, go to sleep on time. There is scientific evidence that a better body leads to better learning.

You will need to take care of yourself mentally, as well. As previously discussed, reach out to your peers, but don't rely on them for your sanity. They have enough on their plate already and probably can't handle whatever you're throwing at them at every single moment. Go outside. Get away from the screen for a bit. Call up a friend for 10 mins and talk about anything other than coding.

Sometimes taking a break and recognizing your fallibility as a human is exactly what you need, and you'll end up coming back to your problem with a fresh set of eyes, ready to solve whatever road block that was just driving you up a wall.

Burnout is real, and will be your worst enemy. Get on top of it before it happens by being aware of it as a threat.

And that's the list. I hope it helped someone out there, and if you're currently struggling through a similar program then I'd like to remind you that you got this, and what you're doing isn't impossible. It's just really, really difficult.

And that makes it worth doing!

Follow the Data: Interplanetary Edition

arindavis — Tue, 11 May 2021 03:39:14 +0000

Heres one of the best pieces of advice that I could give for any aspiring software developer: follow the data. When in doubt, trace the path of your information through the course of your application and analyze it at every step of the process. If you follow this advice, you will without a doubt begin to see the larger context of your program and eventually gain the understanding you need to move forward.

That being said, let's have some fun with it.

I want to "follow the data" on an insane interplanetary scale. At the end of this blog I'm going to post a picture taken by Ingenuity, NASA's newly deployed helicopter drone. Between now and the moment you see that photo we are going to follow it all the way from the surface of the Red Planet straight to your personal device.

Ingenuity has been equipped with two cameras, each with its own purpose. The primary navigation camera is downward facing, black-and-white and a mere 0.5 megapixels. The secondary camera, sometimes referred to as the "terrain camera", is full color, 13 megapixel and horizon-facing. Thankfully this is the one our picture was taken on.

Now that the picture has been taken we just need to send to Earth, right? Easy peasy.

Not so much. Ingenuity is equipped only with a short range communications antenna located in the middle of it's solar array, so it actually needs to route the data through a Helicopter Base Station (I'm not making that name up, it's super cool) on Perseverance. Here's a short blurb from the official NASA press documentation about Ingenuity and the base station's relationship:

Ingenuity and the base station use a UHF telecom link (900 MHz) to communicate with each other. The system can relay data at up to 250 kilobytes per second over distances of up to 3,300 feet (1,000 meters). During flights, a one-way data stream will be sent in real time from the helicopter to the rover for storage and subsequent retransmission to Earth. After landing, the helicopter will re-transmit the inflight data stream and additional data from the flight.

Now the data is on Percy, but where does it go from here? Well, depending on the time of sol (Martian day), Percy will send it to one of the several Mars orbiters waiting just outside the atmosphere. It could be the European Space Agency's Trace Gas Orbiter, or perhaps it's NASA's MAVEN orbiter. For the sake of continuing our journey, lets just say Percy happened to catch MRO, the Mars Reconnaissance Orbiter, which was placed into martian orbit in 2006.

It's important to note what kind of technology is being used for these data transfers. Percy is most likely transmitting from a low gain antenna, which basically means it's a wide and weak signal. What MRO is about to do, transmit from Mars to earth, will be done with a high gain antenna, which is a highly concentrated and narrow signal meant for long distances. Here are the stat's on MRO's transfer rates straight from NASA's own documentation:

The X-band communication system on the orbiter uses a 3-meter-diameter (10-foot) high-gain antenna and a 100-watt X-band radio traveling wave tube amplifier to transmit signals to Earth. Each of these devices is more than twice as powerful as those used by most Mars missions. As a result, Mars Reconnaissance Orbiter is able to send data back to Earth more than 10 times faster than previous missions.
At its maximum distance from Earth of about 250 million miles, the orbiter sends data at a rate of at least 500 kilobits per second. At closer ranges, the signal strength is greater, making higher data rates possible. For several months when Mars Reconnaissance Orbiter is at its closest range of about 60 million miles, the orbiter sends data to Earth at 3 to 4 megabits per second.

Depending on how close Earth is to Mars at the time of the data transfer, it can take anywhere between 3 and 22 minutes to get that signal from one planet to the other.

So here we are, arriving at Earth. One would assume that our photo is heading straight to NASA HQ, which you probably assume is somewhere in Florida, right?

You'd be wrong on both counts (NASA's HQ is in Washington DC, duh). Because our signal has traveled anywhere between 33.9 million and 196 million miles to get to us, chances are it's now pretty faint and hard to pick up via ordinary means.

That's where the Deep Space Network(DSN) comes in. The DSN, another awesome name, is a network of three high powered antennas located at roughly equal distance of each-other all across the globe. It has been around since the 50s, and is the first point of contact for nearly all of man's communication to the stars.

The three antennas are located in California, Spain and Australia. This insures that no matter the time of day or position of Earth along its tilt, a signal from any direction can be intercepted. I don't know which of these three locations our photo really landed at, but let's say it was the one near Madrid, Spain.

Our photo only has a couple more stops. First it will most likely travel under the Atlantic via seafloor internet cables, through the heart of the continental US and straight to NASA's Jet Propulsion Laboratory in California. Here it will be processed, and eventually sent out to the public via a mixture NASA's own servers and word of mouth through the press.

It will sit around for a while before some presumptuous tech blog writer copies and pastes its URL into a middling DEV.to post, for you to now enjoy.

It's glorious, it's everything I dreamed, it's...

Some tracks in the dirt.

Well, I think it's neat! And now that you know how we got that picture you also know how we send data back to Ingenuity. That's right, if you reverse our steps throughout that entire process, you'd travel the same exact route that that first "deploy" command ran from the type of a keyboard on Earth all the way to our friendly little Helicopter buddy on Mars.

Follow the data!

So, You Want to Know A Little More About Video Game Sound?

arindavis — Tue, 04 May 2021 02:32:49 +0000

Sound design is one of those creative skills that, when done just right, will go completely unnoticed by the end user. If a sound calls attention to itself outside the realm of immersing you deeper into an experience, then the designer isn't doing their job right. That line between immersion and distraction is even more blurry and tenuous than you, the average game enjoyer, may even realize.

Quick Disclaimer: Although I have experience in sound design, musical composition for films and general full stack software development, I have not worked in the game industry. This week's blog is meant to be used as a stepping stone for someone who knows next to nothing about sound design in video game development and wants to be pointed in the right direction.

So where should we start with such an all encompassing topic? The history, of course.

When the first commercial games were being released in the seventies, most video game consoles had less sound rendering capability than a modern dishwasher. Take, for example, Pong. An all time classic.

All of the distinct sounds you hear here, the sound of the pong hitting a player's paddle, hitting the wall or even scoring a point, are all the same exact sound, simply stretched or squished to give a desired effect. Even with the strict limitations of the Atari hardware, the developers made it work. This is a great precursor to everything else we are going to talk about.

As the industry progressed into the 80s and 90s the tech got a lot better, especially with the rise of companies like Nintendo, but the same limitation that plagued Atari kept rearing its ugly head: memory. The average size of a game on the Nintendo Entertainment system (1983), often shortened to NES, was a mere 384kb. As if there wasn't already enough creative restraints, the NES was limited to a handful of audio channels.

All of that considered, here's what Koji Kondo, composer for Super Mario Bros, was able to do with it:

From wikipedia:

The game's melodies were created with the intention that short segments of music could be endlessly repeated during the same gameplay without causing boredom. Kondo's soundtrack to Super Mario Bros. gained worldwide recognition, and is the most well-known video game score in history. The main theme is iconic in popular culture and has been featured in more than 50 concerts, been a best-selling ringtone, and been remixed or sampled by various musicians.

The lesson we take from these two famously cherry picked examples? The limitations of the hardware can often lead to major creative innovations.

Fast forward to the turn of the century. The video game industry is growing at exponential rates. Releases like Doom(1993), Half-Life(1998) and Halo(2001) have continually broken financial barriers and video games are becoming mainstream.

With that rapid rise in popularity comes more standardization across the industry. As the high expectations continue to grow, game studios find themselves turning to already constructed game engines like Unreal Engine, and audio middle-ware like Wwise.

Which is still the widespread standard today!

Wwise acts as a sort of DAW(digital audio work station) for video game sound designers/composers, with a heavy emphasis on the logic and event based timing in the game world. It works with the game engine's event triggering systems to insure the right sound plays when it needs to, how it needs to, and in the correct place in relation to the player.

This tool is used by sound designers and composers alike, as musical timing can be the key to maintaining our suspension of disbelief when in a game world. One of my all time favorite musical queues in a video game can be found in Naughty Dog's The Last of Us:

And although it might seem like deceptively simple implementation, play the music when the cute animals appear, there's a lot of work happening behind the scenes to make sure the timing is just right. The player could choose to walk slowly or at a brisk pace, wait around before getting there or even try and speed through it as fast as possible and the music still needs to sound organic. No matter what. That means that the music itself, including the build up, execution of the leitmotif and resolution, need to dynamically change depending on the players input.

Without the player ever noticing. Seems like a tall order, right?

And even with all the fancy advancements we have made in the realm of game technology since Pong, memory is still the primary limiting factor for most developers. Modern AAA games often exceed 100 gigs, which could fit millions of copies of Super Mario Bros. with absolutely no issue. A big contributor to that bloated size is audio. Especially with open world games like CyberPunk 2077, Read Dead Redemption II or GTAV, where musical cues/sound objects/event systems become exponentially more complex as the game world expands outwards in all directions.

Like being a software dev, being a sound engineer/composer in the games industry seems like it can often be a thankless and tiring job with a few gleaming moments of resounding success. At best, the audience won't even notice you did anything, and at worst you will completely take them out of the experience. But when you get it right, like we've just explored, you are able to create a seamless magic act that leaves your player with something long after they put the controller down.

Understanding Hardware Makes You Better at Developing Software

arindavis — Tue, 27 Apr 2021 01:16:46 +0000

For most of us, a computer is an unknowable black box. We type in our social media statuses, our youtube searches and our recipe ideas and voila! It just works. Almost like magic.

Even we, the up and coming software devs of the world, will often know how our code works(maybe that's a little generous), but not much beyond that. We will build it, test it for bugs, and hit "run" when it is finished without a second thought, completely oblivious to what the funny little magic box is doing behind the scenes.

But it doesn't have to be this way. You don't need a STEM degree to understand the fundamentals of computer hardware, and taking the time to do so can actually make you a better software dev. With that in mind, let's go over the basic components of any computer, how they work, and a few real world examples that demonstrate how hardware effects the way users interact with our applications.

There are seven primary parts of any computer: the CPU(central processing unit), which acts like the brain of the machine, the GPU (graphics processing unit), which serves to handle any heavy video rendering, the RAM(random access memory), which provides our applications a place to store things temporarily in memory, a SSD(solid state drive) or hard-drive, which is used to store data in the long term, a network card, which serves to connect our machine to the outside world, the motherboard, which is a place to put everything so it can communicate with each other, and last but not least, a power supply, to make sure it all gets the electricity it needs.

Not all hardware components are made equal, however.

Not every computer has or even needs a GPU. A gamer playing any modern AAA game will need a pretty substantial GPU to even get past the main menu. But your dad running excel for his small business probably won't need something so dramatic. Most mid-tier laptops and phones comes with a duel CPU/GPU chip, referred to as integrated graphics in the industry.

Like the GPU, the network card, depending on your use case, is optional. If you don't need your machine to be connected to the internet at all (an admittedly rare phenomena these days) then paying for a network card is basically money wasted. Most motherboards come with a network card built in anyways these days, so don't sweat it too much if you're in the market.

Which leaves us with only the bare essentials: CPU, RAM, motherboard, power supply and storage. These are the basic necessities of any modern computer. I can guarantee with about 99% certainty that whatever you are reading this blog with has at least these five basic parts, phones included.

Seeing what is necessary to the machine can help us understand what is happening under the hood when users are breaking our programs. For example, if several users have all experienced laggy loading times on your site you can probably safely assume that it's a RAM or CPU issue on their end.

Maybe they have and ungodly amount of tabs open in chrome, or maybe they only have 2gbs of ram on a PC from ten years ago. No matter what the hardware issue might be, we can mitigate it (but not complete eliminate it) by taking some processes off the front end and moving them to the server side, insuring that all users, good PCs or not, get roughly the same experience and performance.

Unless it's a network issue on the user's side, which means it's completely out of our hands. You did everything you can. RIP.

Even if you aren't a PC user, knowing what kind of hardware your mac users are running can still make a world of difference when you are designing software for them to use, especially with the recent launch of apple's proprietary chip, the M1.

For a bit of background, apple has historically had partnerships with companies like intel to outsource their CPU's, that is until last fall when they sent shockwaves through the hardware world with apple silicon. Because they design the software and the hardware, apple is able to pack a big punch in a small package with the M1. I won't get too far into it here, because we will be here all night, but essentially they have streamlined the way your cpu, ram and motherboard all interact with each other to make one of the best performing chips of all time.

A brand new 700$ mac mini with a mere 8 gigs of ram can edit 8k video with little to no lag(with propiertary software), switch between multiple processes in a breeze and even render full scenes in blender better than a PC machine worth twice as much.

But you know what the M1's can't do? Play most modern video games. Or run any application in the adobe suite with reliable speed. In fact, theres a whole host of things the M1 can't do because with lightning fast proprietary hardware comes the limitations of a closed environment.

Yes, there are things like rosetta that can emulate environments for most non native M1 programs, but with it comes a lot of potential performance left at the door.

My larger point is simple: the hardware your client is running often determines the performance of the software. By understanding this and a few extra principles, you can better prepare for when they try and break your applications.

Operating Systems in space!

arindavis — Tue, 20 Apr 2021 04:05:57 +0000

NASA has just deployed Ingenuity, a lightweight helicopter sent with the payload of the most recent Mars rover, Perseverance. At exactly 3:34 AM (ET) Ingenuity successfully executed the first powered flight on another planet.

That wasn't the only first in space history today, though. As it turns out, it was also the first time a linux process has ever been executed on another planet. Which got me wondering, what other operating systems have we as a species hurled into the cosmic abyss?

Let's get into it.

In the early days of spaceflight, when programs like Russia's Sputnik and the U.S's Explorer were being rolled out, each new craft came with its own custom built OS. These were often tailored to those craft's specific needs, and extremely basic by modern standards.

Enter stage right: a man by the name of J. Halcombe Laning. Laning was a pioneer of his time who worked with engineers at MIT to create the first ever real time computer in the early fifties, among many other notable accolades. By the time the Apollo missions were being conceived, NASA knew it would need a state of the art guidance system for it's new generation of space-craft, so they turned to Laning to help build out the software for it. Years later, the Apollo Guidance Computer was launched with Apollo I, which included the same basic real time operating system designed by Laning that would dominate most of the rest of the Apollo Program.

But, as with the early days, there was no real standardization during this period. That didn't come until 1987, when NASA adopted VXworks as it's primary OS of choice.

Here's the crazy part: that standard hasn't changed in over thirty years, since it was originally adopted! Perseverance, the most recent rover that dropped off our little helicopter buddy from earlier, is running on the same OS that crafts in the late 80's and early 90's were.

Which, to be fair, is a bit of an oversimplification. While they haven't changed from VXworks in the last three decades, NASA has updated their proprietary version of it as time has gone on, so it's not like it is completely outdated.

VXworks itself was chosen because it was one of the leading OS's at the time, especially among government agencies and the military. According to wikipedia, VXworks is---

"... designed for use in embedded systems requiring real-time, deterministic performance and, in many cases, safety and security certification, for industries, such as aerospace and defense, medical devices, industrial equipment, robotics, energy, transportation, network infrastructure, automotive, and consumer electronics."

Which makes the choice of OS for Ingenuity even more interesting. It's packing a Qualcomm Snapdragon 801 Processor, which is a CPU you'd usually find in a run of the mill laptop. Running the CPU is a relatively standard linux environment that is utilizing an open source framework called "F Prime", that was specifically designed for powered flight using Ingenuity. This means that if you wanted to, you could go to NASA's website and tinker with it yourself! How cool is that???

Now, I understand no conversation about modern space-tech would be complete without a mention of Space-X, the renegade hot-shot of the international aerospace community.

Unsurprisingly, their engineers chose linux as their primary OS, which runs everything from their rockets to their onboard nav systems. Like the little mars helicopter who could, they are sporting modern x86 processors to run most of their processes. The interesting part to me, a web developer who is only just getting started in the field, is that they are using languages like Javascript, Python and C++ to execute the complex processes behind the scenes and tools like HTML and CSS to display information to their astronauts in the cockpit. Hell, they are using chromium and javascript for the touchscreen functionality on the main displays!

Which, in a weird way, makes me feel oddly closer to the cosmos at large. Like, one would assume that the kind of tech that helps put people into space is somewhat unknowable, left to only the smartest among us. But here we are, throwing CSS and HTML into the eternal nothing.

Of course these are all incredibly complex systems built by literally the smartest people in the world, but when it's all laid out into one brief overview you can notice that it's just one generation iterating into another, and is really no more unknowable than the first time you sat down to code javascript.

So raise a glass to the first linux process on the Red Planet. It will not be the last!

Content Delivery Networks and You

arindavis — Sun, 14 Mar 2021 20:04:15 +0000

Imagine for a moment that you are your favorite piece of media. You might be a song, a tv show or even Irving Kershner's 1980 all time classic, Star Wars Episode V: The Empire Strikes Back. As a popular piece of media existing in the golden age of streaming, you most likely exist on a server somewhere in the midwest United States (Don't @ me, Disney. I don't actually know where you keep your secrets).

So, what happens when someone wants to watch you in Tokyo, Japan? Do you travel the roughly 5,000 miles through the Pacific via seafloor cables, accumulating increasing amounts of latency along the way? In today's day and age, most likely not. Instead, your content provider probably has implemented a CDN to get you there a lot faster.

CDN is short for Content Delivery Network. It's a term used to refer to a global system of redundant servers designed with the purpose of cutting down on the latency between a domestic host and a client on the other side of the world by utilizing a unique form of caching.

Notice that I used the term redundant, which might set off more than a few negative alarm bells in your primal, efficiency obsessed programmer brain. But in this use case, redundancy is actually the primary advantage. It ensures that if one point of the network goes down, there is immediately another edge server to take its place.

By increasing redundancy, we are also decreasing the maximum possible load on the original server by avoiding network bottlenecks before they even happen. This will also present an obvious security benefit when configured correctly, as attackers from across the world would only have immediate access to their nearest edge server, and not the root server.

Another big advantage here is speed.

Content will load significantly faster if it's coming from a CDN within your own country, opposed to being laboriously beamed from halfway across the world. This makes a huge difference in combatting streaming latency and will always result in more responsive media, whether it's audio, video, or even just loading elements into a simple html site.

So how might you, the budding software dev, utilize a service like this? Well, it's actually a lot simpler than you might think.

For the sake of providing a practical example, I'll walk you through some of the basic steps of setting up your site with cloudflare, a CDN service with a pretty robust free option. First, you'll want to sign up for an account, then add your site when prompted.

Then, it'll take you through a series of steps including choosing your membership level, giving you a list of associated DNS records, then prompting you to link your account from wherever you registered your domain. It may take a day or so for this step to complete, so just be patient.

Finally, you'll want to dynamically link cloudflare to your site in the src script tag of your HTML file, which will probably end up looking something like this:

And voila! Your site will now be more secure, faster and more accessible to the world at large, all at no or little cost to you.

Before we part ways, here are a few videos that may help you understand CDN's in a broader context, as it is hard to explain everything in one short blog post. Simply put, CDN's are fast, secure and increasingly needed in modern web design.

Big O, The Confusing Stuff

arindavis — Sat, 06 Mar 2021 22:42:59 +0000

Time Complexity is without a doubt one of the most difficult topics to understand when you're first finding your bearings in computer science. I'm here to make the confusing parts a little easier. Specifically, any confusion you may still have regarding exponential, quadratic and logarithmic time complexities.

But before we jump head first into the deep end, let's make sure we are comfortable with the easy stuff.

Simply put, time complexity is a tool for analyzing the efficiency of our programs in relation to how they scale. A low time complexity will always result in faster programs, and a higher complexity will always result in slower programs.

Constant and linear complexities are represented in Big O notation as-

O(1) && O(n)

respectfully, and are easy enough to understand on their own. A constant time complexity will take the same amount of time to perform its operations no matter the size of the input, so we denote it as "1".

The time complexity of linearly scaled programs will always exist in direct relation to the size of the input, represented above as n.

Popping off an array will always be constant because the length of the array doesn't matter.

let arr = ["one", "two", "three"];
arr.pop() ---> "three"

And looping through that same array will always be linear, because the length of our operation is directly tied to the length of the array.

for(let i = 0; i < arr.length; i++)

It might help to conceptualize if you replace the 'n' with the length of the array itself. The time complexity of looping through our 'arr' array is technically O(3) before popping off the end, and O(2) after popping off the end.

But that's the easy stuff, and I'm explicitly here to demystify the confusing parts. So let's get into it.

Exponential

Before we talk about exponential time complexity, we should first strive to understand what the word itself means. 'Exponential' refers to 'an increase that is becoming more and more rapid'.

Another way to put that is that it's an increase that is increasingly increasing. We represent exponential time complexity as

O(2^n)

where n is, you guessed it, the size of the input.

As you can imagine, having your program take an exponential amount of time to complete its operations could be an absolute disaster in most use cases, especially when working with large sets of data.

For example, if you had a function with an exponential time complexity traversing over an array with a length of 20, you could calculate the potential maximum operations it would need to perform by filling out O(2^n) and analyzing the solution.

   2 ^ 20 = 1,048,576

That means our exponential function would, in its absolute worst case scenario, have a time complexity of O(1,048,576).

I've charted out below how the time complexity of our fictional program scales upwards to over a million as the size of the array scales upwards to twenty. This should help visualize what an "increase that is increasingly increasing" actually means.

Follow the number to the right, and see what you notice.

2 ^ 1 = 2
2 ^ 2 = 4
2 ^ 3 = 8
2 ^ 4 = 16
2 ^ 5 = 32
2 ^ 6 = 64
2 ^ 7 = 128
2 ^ 8 = 256
2 ^ 9 = 512
2 ^ 10 = 1,024
2 ^ 11 = 2,048
2 ^ 12 = 4,096
2 ^ 13 = 8,192
2 ^ 14 = 16,384
2 ^ 15 = 32,768
2 ^ 16 = 65,536
2 ^ 17 = 131,072
2 ^ 18 = 262,144
2 ^ 19 = 524,288
2 ^ 20 = 1,048,576

As the length increments the time complexity doubles.

This starts as steady growth at first, taking nine steps to even break a thousand, then five more after that to break ten thousand. But only another four steps from there is an increase by hundreds of thousands, and only two more steps after that we are at a million. There is more of a difference between 2^18 and 2^20 than there is between all of the previous results combined.

The most common practical example you'll see for exponential complexity is a function designed to obtain a fibonacci number.

let fibonacci = function(number) {
  if (number <= 1) {
    return number;
  }
  return fibonacci(number - 2) + fibonacci(number - 1);
};

The larger the input, the more and more operations it will take to get our output fibonacci number. Play around with this some and see if you can make a non-recursive version yourself. You know, just for fun.

Quadratic (polynomial)

Again, to first understand how it relates to time complexity, let's lay out what exactly quadratic actually means. In simple terms, it is a fancy word that mathematicians use to denote when something has been squared, which is why we represent it as-

O(n^2)

Simple enough, right? The maximum number of operations in a quadratic function would be the length of the input times itself.

Something like this:

let repeatArrayByLength = function(arr){
let newArr = [];
for(let i = 1; i <= arr.length; i++){
  for(let j = 1; j <= arr.length; j++){
    newArr.push(j);
  }
}
return newArr;
};

Scales quadratically because as the length of the input grows, the amount of processes our function must complete increases by a factor of the length of the array times itself, n^2.

Notice that if we pass in an array with the length of three, like so:

repeatArrayByLength([1, 2, 3])

We will get back-

[1, 2, 3, 1, 2, 3, 1, 2, 3]

Our function carried out 9 pushes into the array, from an input length of 3.

3^2, or 3 * 3, is 9.

If we were to pass in a similarly structured array with a length of 5, we would get back:

[1, 2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2, 3, 4, 5, 1, 2, 3, 4, 5]

Our function pushed into the array 25 times.

5^2, or 5 * 5, is 25.

Logarithmic

I like to think of logarithmic time complexity like the lawful good version of exponential complexity, represented in Big O as-

O(log n)

The number of operations in an exponential function will increasingly increase as the size of the input increases, whereas the number of operations in a logarithmic function will increasingly decrease as size of the input increases. The larger the set of data, the more efficient your program will run.

Here's a simple example:

let doubleStepper = (number) => {
  let arr = [];
  for (let i = 1; i < number; i *= 2) {
    arr.push(i);
  }
  return arr;
};

When we pass in 5, we will get back:

[1, 2, 4]

Which is only three operations. Now if we passed in 100, we will get back:

[1, 2, 4, 8, 16, 32, 64]

Which is only seven operations. Functions with logarithmic complexity will become exponentially more efficient as the input data grows larger.

Finally, let's go crazy and pass in 5000, getting back:

[1, 2, 4, 8, 16, 32, 64, 128, 256, 512, 1024, 2048,4096]

Which isn't really that much of a jump, only thirteen processes in total. Notice that, like I said before, it becomes increasingly efficient as the size of the input grows. There are more jumps between 1 and 32 than there are between 1024 and 4096.

I wasn't kidding about it being the lawful good version of exponential, here's the proof:

They share the same exact curve, just different directions.

Generally speaking, we should strive to keep our programs below exponential and quadratic complexity, and instead aim for constant, logarithmic, or at the bare minimum linear.

It's also important to keep in mind that you should only formulate time complexity based on the worst case scenario, and nothing more. Because even a ridiculous function like this-

-known as bogosort could, in theory, produce a correct result on the very first permutation. That doesn't make it constant though, far from it actually. The above function actually has a factorial time complexity, which is a discussion for another time.

Intro to Algorithmic Design

arindavis — Sun, 28 Feb 2021 23:20:00 +0000

Quick, off the top of your head, and without using a calculator or scratch paper, what is thirteen multiplied by two hundred and thirty eight?

You could try and solve this problem using mental math, wasting your valuable time and effort, or you could do what the ancient Egyptians did and make an algorithm that plots the answer into a simple to read data structure. The solution, according to one of the first recorded algorithms in human history, is three thousand and ninety four.

The methodology itself is deceptively simple, but incredibly functional. You start with two columns, the first starting with one and the second starting with thirteen, and for each new row you double the previous number in the column. Then it becomes an easy task of finding two hundred and thirty eight in the first column and matching it with its corresponding answer on the right.

Millennia after the ancient Egyptians used these kinds of basic designs to build the pyramids and construct elaborate effigies to their cats, a entrepreneurial woman by the name of Ada Lovelace would become what many scholars now consider to be the first computer programmer, inventing and reiterating complex mechanical systems that would later allow her to envision a world where machines perform much more than basic arithmetic for the general public. (check out a modern implementation of her Bernoulli Number Function here).

Another hundred years after her, Alan Turing would utilize the same kind of problem solving to crack top-secret Nazi encryption (pro tip, don’t end all of your secret transmissions with “Heil Hitler” if you want them to stay secret) and help end the second World War.

All three of these examples share a unifying commonality, and that’s a basic adherence to algorithmic design. Or, more simply put: they all approached their problems in the same way.

When you first go searching for information regarding algorithmic design in reference to computer science, you are more than likely to find an over-abundance of resources. Many well written articles and academic papers reference methods like divide and conquer, backtracking and dynamic programming. Any one of these paradigms is worth exploring in depth and applying to your own process, but I'd rather focus on the similarities you'll find between nearly all of them. In an effort to create a more approachable and generalized overview of practical Algorithmic Design, I've broken these similarities into three linear stages of problem solving:

Definition, Execution, and Reiteration.

First, the definition stage, or what I think of as the 'understanding' phase. This is where most people tell you to start, and can often be the place where you spend the most time. It's important at this phase to clearly lay out your IOCE's: Input, Output, Constraints, and Edge Cases. You want to focus clearly on what the problem demands in relation to these pre-determined parameters, and start thinking about what kind of steps it will take to get you to the solution. I lump the process of pseudo-coding into this stage as well, as it's a practical way of getting your understanding of the problem into writing. By adding comments and beginning to plan out the direction of our program, we make the next two stages much easier.

Which brings us to execution, or where we get to actually start typing out our code and putting our design into practice. Simply put, you want to follow the arc of your design from the definition stage, being sure to test and retest along the way until you have your first working prototype.

Finally, reiteration. This is where we "redo and review" over and over again until we are sick of it. Reiteration often comes either when basic functionality has been mastered, or your logic from stage one has proven less than sound. That's okay, though! This is perfectly normal and healthy to the process at large, and even encouraged! This is how innovation is cultivated, and where our algorithms become more streamlined. It's the perfect time to start seriously thinking about time complexity in relation to space complexity, the efficiency your algorithm, and what you'd still like to accomplish before it's "done".

Let's use a practical example to walk us through the process from beginning to end: Creating a simple factorial algorithm using JavaScript.

Definition:

A factorial is an integer that represents the product of all the numbers below or equal to n, or the original number. The factorial of 5 is 120 because:

1 * 2 * 3 * 4 * 5 = 120

So, now that we have a grasp of what the problem is asking, let's define our IOCE's.

//Input: Positive integer

//Output: Factorial of original integer

//Constraint: 

//Edge Case:

For now we will keep constraints and edge cases empty, as none have been imposed on us yet. Next, we need to pseudo-code out a plan. It first occurred to me that if we loop through everything from n, our given number, down to 1, we can multiply each iteration of the loop against the next and eventually get our factorial. So, now I put that plan into words.

//IOCE: Positive integer, Factorial of original integer, n/a, n/a

//declare function

//create a place to store our product

//loop from n down to 1

//on each loop, multiply each number by the next

//return our final number

Execution:

The fun part! So, let's put our plan into action:

//IOCE: Positive integer, Factorial of original integer, n/a, n/a

//declare function

const factorial = function(n){

//create a place to store our product

let factorial = 1;

//loop from n down to 1

for(let i = n; i > 0; i--){

//on each loop, multiply each number by the next

factorial *= i;

}

//return our final number

return factorial;

}

factorial(5)  ---> 120

And it works! But why stop now, there is still so much to improve!

Reiteration:

So, what could we do better? First, I noticed that stopping at 1 is inefficient because multiplying an integer by 1 will always result in that same integer, so that cuts down at least one loop.

for(let i = n; i > 1; i--){

It's also worth nothing that our time complexity is currently O(n), or linear. Meaning that the higher n is, the longer the loop will take to loop through to the end result.

Somewhere during this stage you might consider refactoring the entire thing away from a for loop and instead opt for recursion, like so:

//IOCE: Positive integer, Factorial of original integer, use recursion, n/a

function recursiveFactorial(n){

//if n is strictly equal to zero, stop recursing

if(n === 0){

  return 1;

//otherwise, keep multiplying n by the next call of 

factorial, decrementing n on each call

} else {

  return n * recursiveFactorial(n - 1); 
}

}

recursiveFactorial(5) ---> 120

Notice I changed the "C" in our IOCE to reflect the self imposed constraint of using recursion.

This version initially seems a lot more sleek. It takes up slightly less space on the page than our initial approach, and requires less characters to type. You would think this would translate into having a better time complexity, but it actually doesn't. It's still O(n) because the amount of time is still fully dependent on how large n is initially. Not only that, but there is some evidence to suggest that loops are faster than recursion in general, although that's a multi-faceted topic for another time.

At this point, I feel satisfied in my altered first approach, although if I really wanted to get an absolutely constant, or O(1), time complexity for any factorial from 1 - 9 I could just take a note from the ancient data structure that the Egyptians used to solve their problem, but in a modern context using a Javascript object.

let factorialObj = {
  1: 1,
  2: 2,
  3: 6,
  4: 24,
  5: 120,
  6: 720,
  7: 5040,
  8: 40320,
  9: 362800
}

factorialObj[5] ---> 120
console.log("Are you proud of me, ancient Egyptians?")

This is, of course, an imperfect solution, but shouldn't necessarily be beyond consideration. I mean, factorialObj[9] is gonna get you back 362,800 a lot faster than either of other approaches we implemented, I guarantee that.

Here, at the final stage of our implementation, we have crucial choices to make. Choices, mind you, that are provided and informed by all the work we have made up to this point.

This is what algorithmic design is all about though, discovery through understanding, implementation and reinvention. Lady Lovelace knew that. So did Turing and the builders of the ancient world. This process, when adhered to, is the perfect place to start thinking about the big picture design of whatever problem you're trying to solve.

By taking time to understand the fundamental steps between the inception and application stages of our algorithmic logic, we can not only improve our own code, but we also get the opportunity to iterate and improve on generations of prior knowledge that came before us. In summary, modern computer science owes a lot to the gays, women, and cats.

That’s just history.

So, Random

arindavis — Wed, 20 Jan 2021 01:03:34 +0000

Let's go ahead and rip this band-aid off: JavaScript's Math.random() number method isn't actually random. The number it calculates could, with enough pre-emptive knowledge, be predicted. This isn't a fatal oversight on the behalf of the language's creators, it's actually a problem with how our machines and the software we design for them are taught to think in the first place.

In order to fully understand how Math.random() works, we are going to have to talk about its basic use cases, what's going on behind the scenes when we call it, and the nature of chaos within a deterministic universe.

First, let's get to know the method itself before we expose it for the no good liar it is. A simple invocation of the base method, like so--

let random = Math.random();
console.log(random)

--will log a number somewhere between 0-1 to the console. Try it for yourself if you'd like, I got "0.3525815464578914".

If we add the Math.floor method with a little extra flavor, however, we can make the forces of chaos truly bend to our will.

let controlledChaos = Math.floor(Math.random() * 10 + 1);
console.log(controlledChaos);

I got 6!

We are specifying here that our random number should be strictly chosen within the range of one through ten. Math.floor() is doing some of the heavy lifting, as it's primary job is rounding to the lowest whole number. We then multiply our invocation of Math.random() by ten, setting the upper limit of our random call to ten. Then on to the final part, '+ 1', which is setting the lower limit to one. If we were to leave those last two off, like so--

let rando = Math.floor(Math.random());
console.log(rando);

we would get zero. No matter what.
Every. Time.

This is because as Math.random() generates a random number between zero and one on each invocation, Math.floor() is simultaneously taking that number and rounding it down to zero. You could do the same thing with Math.ceil(), the sibling of .floor(), and you'd get one instead because it rounds up to the nearest whole number. It's like the JavaScript equivalent of a rigged coin toss.

Using the bones of the controlledChaos variable, we can work to make our JavaScript programs more dynamic by creating random-number generating variables that depend on/refer to other parts of our program.

Here's an example, it's a link to a rudimentary story generator I made using the above principles. Press run a couple times and see what kind of harrowing tales you get, then check out the code at the bottom that makes it all tick.

Did you notice that you can add to any of the three story sections because the upper ceiling of the random call is dynamically linked to the length property of the corresponding array? Of course you did, because you're smart.

And because I now know how smart you are, I feel comfortable getting into more of the technical side of things. Wanna know what's actually going on behind the scenes with Math.random()? The answer is complicated and would require its own blog to be properly explained, but for the sake of brevity:

Most browsers(yes, browsers implement this method, not JavaScript) use something called a "Pseudo-Random Number Generator" to simulate randomness in our code. One of the most popular PRNGs regularly implemented with JavaScript is called "xorshift128+", which you can read more about here and here.

In short, every PRNG needs a place to start, a seed number from which all the following numbers can be subsequently calculated. That's why most PRNG's rely on external means of getting a seed, like from your computer's internal clock, the current heat of your CPU, mouse movements, fan noise, or even the radiation levels in your immediate area. Alright, that last one was a little extreme.

I'd encourage you to do some more research on your own time starting with the provided links, because my brief explanations of the inner workings of these PRNGs only scratch the surface of what there is to know, and we aren't even touching on other topics related to randomization like HRNGs or whacky projects like this one.

But here's the run-down on PRNGS: There is nothing actually random about how most of them get their end results, even ones that are used as the standard, because every end value was calculated by a deterministic process. That's where the pseudo part of that really cool name comes from.

What most of them actually do is simulate randomness for us by starting with a seed and unloading a predetermined series of processes onto it. If one were to know the exact inner workings of that process and the seed itself, one could, theoretically, predict what the software will return before it returns it. This is immensely impractical and absolutely the most unnecessary flex imaginable, but it's also technically possible, which is the best kind of possible. It's also why I argue that Math.random() is inherently chaotic and not random. Because, given you have accurate information about the input, you could accurately predict the output no matter the complexity. This is how nearly all man made creations work, as deterministic systems.

But what does "random" even really mean, if not Chaos?

When you get together with your nerdy DND friends to tell stories and roll funny shaped dice, are the results from those funny shaped dice truly random? The dice's output may seem obviously randomized on the surface, but one could argue that the end value is determined by tangible conditions like density and balance of the dice, how the user consciously and subconsciously decides to throw it, which part of the table it lands on, the balance of the house and so on...

Which leaves us with no clear answer and one lingering question:

If it looks random when we see it, feels random when we use it, and acts random when we need it to then does it even matter if Math.random() is factually "random" or not?