As I became more frustrated with not being able to read my script and keep my eyes on the camera, a genius idea came to my head: why not use the <marquee> HTML tag?!

I quickly opened up a W3schools TryIt Editor, adjusted the font and speed settings, and BAM! Instant Teleprompter!

If you want to try it out yourself, I encourage you to do so!

Here's all the code it takes (yes, really):

<marquee direction="up" scrollamount="13" height="100%" width="100%" style="font-size: 100px;" >
Here is a makeshift teleprompter. 
I've set it to be slow enough to read, but fast enough to keep pace with how I speak.
This helped me when I needed to record a video!
</marquee>

direction sets the scroll direction of the marquee. I set it to up, which is the easiest for me to read, but you can also set it to down, left, or right.

scrollamount sets the speed of the scroll. I had to experiment and find the right speed: fast enough so it sounds natural when filming, but slow enough that I don't get overwhelmed! For me, that number was 13. I encourage you to play around and find the right speed for you!

That's really it in terms of <marquee>-specific attributes. The remaining height, width, and inline style was just to make my script legible to read on my other monitor! And between the <marquee> tags, I pasted in my script.

I got so excited about this silly solution, I shared it on twitter:

Of course, as some have brought up, please remember that the <marquee> tag has been deprecated and is not recommended for use in production! But in the context of this sandbox and for this purpose, the <marquee> HTML tag saved me!

In case you're curious, this is the video I filmed using this teleprompter:

What do you think?

Anyway, thanks for reading this quick post. Just wanted to share this silly, but genius solution that we as devs sometimes come up with every now and then!

Thank you!

Thank you so much for taking the time to read through my article. If you enjoyed it or have a question, please let me know in a comment below. Or even better, if you feel this article would be helpful to other devs, please share it/tweet it to spread the knowledge and love. ♥️

For more from me, be sure to follow my blog! And to see what I'm currently up to, follow me on Twitter!

Yes and no (although, in the present day, we do use them interchangeably with the confidence that the other person knows what we're talking about)!

I get these terms mixed up quite a bit, so I wanted to dive deeper into what they are, why we use them interchangeably, and what the true differences are (at least the ones that matter).‌ ‌

TL;DR Breakdown:

What is a Terminal?

At it's core, any input/output device. Our keyboards and mice are terminals. So are our ears and eyes. They are like terminals for sound.

What is a console?

A physical terminal; a physical mechanism by which input can be collected. Thinking about it this way, it's easy to see how we share this word across industries: video game consoles in gaming, mixing consoles in music, and command consoles in aviation/space.

What is a CLI?

CLI stands for Command Line Interface. A CLI is a distinct type of interface that accepts input commands and then executes them once you hit the Return/Enter key.

What is a shell?

A shell is a specialized command line interface; this is what actually recognizes the commands you enter and then tells the operating system to execute them. There are many flavors; cmd is the default shell on Windows, Bash is the default shell on most Linux distributions, and just recently, zsh became the default shell on macOS Catalina.

My mind's blown. Is yours? Mooncake's definitely is.

Terminal, Console, CLI, and shell: The (Quick!) History Behind the Words

Yes, in order to understand why these terms have morphed into an interchangeable mess, we need to go back to the beginning. Back to the days of mainframes...

IBM 360 Mainframe - Source: System 360 IBM's History

You've probably seen pictures of these things. They took up entire rooms. And they were usually found in large businesses or universities. In fact, I think my college still uses one (because if it still works, why replace it?!).

Mainframes were meant to be used among many different users. Today, we would achieve this by just handing everyone their own personal monitor, keyboard, and mouse. But back then, users shared access through a common endpoint: the terminal. These were specialized stations that had a display (usually a small cathode ray tube TV screen) and a built-in keyboard. They were connected to the mainframe by a cable or phone line.

Woman sitting at Unimatic terminal for United Airline's competing system. Source: ComputerHistory.org

Speaking of connections, we get the term console from the actual console port on the mainframe that terminals would connect to. This is how users controlled the mainframe digitally, through these connected terminals scattered around the building.

Ok, so now we're connected. How did users actually interact with the mainframe? If you have seen any "hacker" scene in a movie, you usually see something like this: ‌

‌(And if you have a minute and 47 seconds to spare, watch this hilarious Ode to Mainframes 😂)

Notice how there are no fancy graphical interfaces just yet? That's because most interactions with mainframes were via simple commands, entered one at a time. And this is where the term and concept of the command line interface (CLI) comes from! Users would supply a command to the mainframe through a terminal. ‌

Alright, home stretch...‌ ‌‌

‌It's important to note that the terminal has nothing to do with the actual processing or interpreting of the command. They are simply a means for the user to input commands (hence the hopefully antiquated term "dumb terminal"). It's actually the shell that accepts and recognizes these commands, sends them to the mainframe to execute, collects the results, and sends it back to the terminal!

Here's the kicker: the shell is really just a wrapper around the kernel. And in an operating system, the kernel is "a computer program that is the core of a computer's operating system, with complete control over everything in the system. On most systems, it is one of the first programs loaded on start-up..." ^1

This is why we call the shell a "shell" as it acts similarly to the piece of material around a corn kernel!

What happened?

Today, most terminals and consoles are represented virtually through software, but as we've learned, they used to be physical, tangible objects. Pairing this history with the fact that they are heavily intertwined with the origins of the command line interface, it's easy to see how the terms "terminal" and "console" have become muddled together! And by the time we reach present day, the use of all of these terms "terminal", "console", "shell", "CLI" eventually became synonymous with the end goal we as developers are trying to achieve: to interact with an operating system and execute specific actions through commands!

Cover Photo by bert brrr on Unsplash

Thank you so much for taking the time to read my blog post! Hopefully these terms aren't so confusing anymore!

If you enjoyed it, please let me know in a comment below. Or even better, if you feel this article was thorough in a good way, please share it/tweet it to spread the knowledge and love. ♥️

For more from me, be sure to follow my blog!

To see what I'm up to, follow me on Twitter!

It's fascinating, extremely fun, and EXHAUSTING. You all know the perks of travel and how rewarding it can be to explore the world. I think we'd all much rather be doing more of it right now! But until then, I'll tell you what most don't about traveling for tech conferences. Here are the major CONS of traveling this much:

Traveling itself

Conferences usually pay in full for my airfare (or reimburse me afterward), but that doesn't mean I'm flying first-class! Conferences have budgets too, so when that's the case, especially if it's a community-run, non-profit conference, I'm usually flying economy. That may not be so bad for domestic flights, but anything longer than 6 hours or flying to Europe is real tiring. Add onto that the usual annoyances of airports, people with no travel etiquette, etc. and traveling so much is suddenly not so glamorous!

Dealing with jet lag

In-person conference season is on hold for a while, but phew! did it take a toll on my body when I was in full swing back then! Going back and forth between Europe and even the East Coast messes with my internal clocks so much, it takes a while to get over it! I stay up til 3 or 4am even though I need to sleep and I don't wake up until 11 or 12 the next day, effectively making me feel like I've wasted valuable time. Additionally, my appetite is all funky.

Depending on when I land at my destination, I either have an awesome selection of new food to try or am stuck with whatever the hotel can serve when everything else is closed. Many times, it's ordering pizza from room service 😂 See exhibit A:

Once I get home, I eat A LOT (think normal local dining hours, but also every other hour in between) but feel like I haven't eaten anything at all. It takes a while for everything to sync back to normal and going through those effects are not much fun.

Living out of a suitcase

Despite learning what my TRUE essentials are (😂), it can get annoying to be living out of a suitcase. This is exacerbated if I don't have a free washer to make use of and I'm staying for longer than a week. At this point, it becomes a value proposition game. Do I pay more to check in an extra bag that's larger (with the disadvantage of having to wait for it and travel with it)? Do I spend the atrocious $4 a garment to use the hotel's laundering facilities? If I forgot something, do I buy another one? These are all issues that became more prominent for me as I started to travel to more tech conferences.

Mostly exploring alone

This may not be a con for many of you (and I do enjoy exploring on my own every now and then), but there's just something about exploring the world together with someone. In my case, that's my husband. I get to make memories with him, experience something new, and enjoy the hustle and bustle of exploring a place with someone I love. Traveling to lots of tech conferences means I don't get to do that. This also means I spend less time with him overall and I miss him a lot.

Exhaustion

There are itineraries that have me jet setting from one place to another in a short span of time and that really burns me out. This happened with my conferences in Berlin, Germany and Richmond, Virginia; I had to visit both places within the span of a week! Sometimes, it's so bad that I end up skipping some speaker dinners or events because I just want to fall into my hotel bed and SLEEP! I hate this, though, because I miss out on meeting other speakers, enjoying exclusive events prepared especially for us, and just feel like I "waste" time in a new place instead of spending every second enjoying and exploring!

And there's the truth!

These rarely talked about cons make me yearn for weeks of just doing NOTHING...though, I am now painfully reminded to be careful what I wish for! 😂 While we wait for travel to become normal again, let these realities be a reminder that not everything is picture perfect!

Thank you so much for taking the time to read my blog post! If you enjoyed it, please let me know in a comment below. Or even better, if you feel this article was thorough in a good way, please share it/tweet it to spread the knowledge and love. ♥️

For more from me, be sure to follow my blog!

To see where I'm speaking next (virtually) and when I'll be living out of a suitcase again, follow me on Twitter!

Want to use Azure DevOps for continuous integration and continuous deployment but Google Cloud for Vision AI? Possible! Need higher availability in Canada but only have a single region available in your current cloud provider? Add additional nodes from another Canadian region on a different cloud provider! These kinds of scenarios are what multi-cloud was made for!

In this post, I won't be telling you why multi-cloud is useful; there are several articles (like this one or that one) and a Twitch stream that do a great job of that already! Rather, in this post, I'd like to:

• Show you how to set up a multi-cloud cluster in MongoDB Atlas.
• Explain what each of the new multi-cloud options means.
• Acknowledge some new considerations that come with multi-cloud capabilities.
• Answer some common questions surrounding multi-cloud clusters.

Let's get started!

Requirements

To go through this tutorial, be sure to have the following:

• A MongoDB Cloud Account
• To create an M10 cluster or higher (note that this isn't covered by the free tier)

Quick Jump

• How to Set up a Multi-Cloud Cluster
• How to Test a Primary Node Failover to a Different Cloud Provider
• Differences Between Electable, Read-Only, and Analytics Nodes
• Choosing Your Electable Node Distribution
• Multi-Cloud Considerations
• Multi-Cloud FAQs

How to Set Up a Multi-Cloud Cluster

1. Log into your MongoDB Cloud account.

2. Select the organization and project you wish to create a multi-cloud cluster in. If you don't have either, first create an organization and project before proceeding.

3. Click "Build a Cluster". (Alternatively, click "Create a New Cluster" toward the top-right of the screen, visible if you have at least one other cluster.)

4. If this is the first cluster in your project, you'll be asked to choose what kind of cluster you'd like to create. Select "Create a cluster" for the "Dedicated Multi-Region Clusters" option.

5. You are brought to the "Create a Multi-Region Cluster" screen. If not already in the ON position, toggle the "Multi-Cloud, Multi-Region & Workload Isolation" option:

6. This will expand several more options for you to configure. These options determine the type and distribution of nodes in your cluster:

💡 What's the difference between "Multi-Region" and "Multi-Cloud" Clusters?

The introduction of multi-cloud capabilities in Atlas changes how Atlas defines geographies for a cluster. Now, when referencing a multi-region cluster, this can be a cluster that is hosted in:

• more than one region within one cloud provider, or
• more than one cloud provider. (A cluster that spans more than one cloud spans more than one region by design.)
• multiple regions across multiple cloud providers.

As each cloud provider has its own set of regions, multi-cloud clusters are also multi-region clusters.

7 . Configure your cluster. In this step, you'll choose a combination of Electable, Read-Only, and Analytics nodes that will make up your cluster.

💡 Choosing Nodes for your Multi-Cloud Cluster

Electable nodes: Additional candidate nodes (via region or cloud provider) and only nodes that can become the primary in case of a failure. Be sure to choose an odd number of total electable nodes (minimum of three); these recommended node distributions are a good place to start.

Read-Only nodes: Great for local reads in specific areas.

Analytics nodes: Great for isolating analytical workloads from your main, operational workloads.

🤔 Still can't make a decision? Check out the detailed differences between Electable, Read-Only, and Analytics nodes for more information!

As an example, here's my final configuration (West Coast-based, using a 2-2-1 electable node distribution):

I've set up five electable nodes in regions closest to me, with a GCP Las Vegas region as the highest priority as I'm based in Las Vegas. Since both Azure and AWS offer a California region, the next closest ones available to me, I've chosen them as the next eligible regions. To accommodate my other service areas on the East Coast, I've also configured two read-only nodes: one in Virginia and one in Illinois. Finally, to separate my reporting queries, I've configured a dedicated node as an analytics node. I chose the same GCP Las Vegas region to reduce latency and cost.

8 . Choose the remaining options for your cluster:

• Expand the "Cluster Tier" section and select the "M10" tier (or higher, depending on your needs).
• Expand the "Additional Settings" section and select "MongoDB 4.4," which is the latest version as of this time.
• Expand the "Cluster Name" section and choose a cluster name. This name can't be changed after the cluster is created, so choose wisely!

9 . With all options set, click the "Create Cluster" button. After a short wait, your multi-cloud cluster will be created! When it's ready, click on your cluster name to see an overview of your nodes. Here's what mine looks like:

As you can see, the GCP Las Vegas region has been set as my preferred region. Likewise, one of the nodes in that region is set as my primary. And as expected, the read-only and analytics nodes are set to the respective regions I've chosen:

Sweet! You've just set up your own multi-cloud cluster. 🎉 To test it out, you can continue onto the next section where you'll manually trigger an election and see your primary node restored to a different cloud provider!

🌟 You've just set up a multi-cloud cluster! If you've found this tutorial helpful or just want to share your newfound knowledge, consider sending a Tweet!

Testing a Primary Node Failover to a Different Cloud Provider

If you're creating a multi-cloud cluster for higher availability guarantees, you may be wondering how to test that it will actually work if one cloud provider goes down. Atlas offers self-healing clusters, powered by built-in automation tools, to ensure that in the case of a primary node outage, your cluster will still remain online as it elects a new primary node and reboots a new secondary node when possible. To test a primary being moved to a different cloud provider, you can follow these steps to manually trigger an election:

1. From the main "Clusters" overview in Atlas, find the cluster you'd like to test. Select the three dots (...) to open the cluster's additional options, then click "Edit Configuration":

2. You'll be brought to a similar configuration screen as when you created your cluster. Expand the "Cloud Provider & Region" section.

3. Change your Highest priority region to one of your lower-priority regions. For example, my current highest priority region is GCP Las Vegas (us-west4). To change it, I'll drag my Azure California (westus) region to the top, making it the new highest priority region:

4. Click the "Review Changes" button. You'll be brought to a summary page where you can double-check the changes you are about to make:

5. If everything looks good, click the "Apply Changes" button.

6. After a short wait to deploy these changes, you'll see that your primary has been set to a node from your newly prioritized region and cloud provider. As you can see for my cluster, my primary is now set to a node in my Azure (westus) region:

💡 In the event of an actual outage, Atlas automatically handles this failover and election process for you! These steps are just here so that you can test a failover manually and visually inspect that your primary node has, indeed, been restored on a different cloud provider.

There you have it! You've created a multi-cloud cluster on MongoDB Atlas and have even tested a manual "failover" to a new cloud provider. You can now grab the connection string from your cluster's Connect wizard and use it with your application.

⚡ Make sure you delete your cluster when finished with it to avoid any additional charges you may not want. To delete a cluster, click the three dots (...) on the cluster overview page of the cluster you want to delete, then click Terminate. Similar to GitHub, MongoDB Atlas will ask you to type the name of your cluster to confirm that you want to delete it, including all data that is on the cluster!

Differences between Electable, Read-Only, and Analytics Nodes

Electable Nodes

These nodes fulfill your availability needs by providing additional candidate nodes and/or alternative locations for your primary node. When the primary fails, electable nodes reduce the impact by failing over to an alternative node. And when wider availability is needed for a region, to comply with specific data sovereignty requirements, for example, an electable node from another cloud provider and similar region can help fill in the gap.

💡 When configuring Electable nodes in a multi-cloud cluster, keep the following in mind:

• Electable nodes are the only ones that participate in replica set elections.
• Any Electable node can become the primary while the majority of nodes in a replica set remain available.
• Spreading your Electable nodes across large distances can lead to longer election times.

As you select which cloud providers and regions will host your Electable nodes, also take note of the order you place them in. Atlas prioritizes nodes for primary eligibility based on their order in the Electable nodes table. This means the first row of the Electable nodes table is set as the highest priority region. Atlas lets you know this as you'll see the "HIGHEST" badge listed as the region's priority.

If there are multiple nodes configured for this region, they will also rank higher in primary eligibility over any other regions in the table. The remaining regions (other rows in the Electable nodes table) and their corresponding nodes rank in the order that they appear, with the last row being the lowest priority region.

As an example, take this 2-2-1 node configuration:

When Atlas prioritizes nodes for primary eligibility, it does so in this order:

Highest Priority => Nodes 1 & 2 in Azure California (westus) region

Next Priority => Nodes 3 & 4 in GCP Las Vegas (us-west4) region

Lowest Priority => Single node in AWS N. California (us-west-1) region

To change the priority order of your Electable nodes, you can grab (click and hold the three vertical lines of the row) the region you'd like to move and drag it to the order you'd prefer.

If you need to change the primary cloud provider for your cluster after its creation, don't worry! You can do so at any time through your Atlas dashboard.

Read-Only Nodes

To optimize local reads in specific areas, use read-only nodes. These nodes have distinct read-preference tags that allow you to direct queries to the regions you specify. So, you could configure a node for each of your serviceable regions, directing your users' queries to the node closest to them. This results in reduced latency for everyone! 🙌

💡 When configuring Read-only nodes in a multi-cloud cluster, keep the following in mind:

• Read-only nodes don't participate in elections.
• Because they don't participate in elections, they don't provide high availability.
• Read-only nodes can't become the primary for their cluster.

To add a Read-only node to your cluster, click "+ Add a provider/region," then select the cloud provider, region, and number of nodes you'd like to add. If you want to remove a Read-only node from your cluster, click the garbage can icon to the right of each row.

Analytics Nodes

If you need to run analytical workloads and would rather separate those from your main, operational workloads, use Analytics nodes. These nodes are great for complex or long-running operations, like reporting queries and ETL jobs, that can take up a lot of cluster resources and compete with your other traffic. The benefit of analytics nodes is that you can isolate those queries completely.

Analytics nodes have the same considerations as read-only nodes. They can also be added and removed from your cluster in the same way as the other nodes.

Choosing Your Electable Node Distribution

Deploying an odd number of electable nodes ensures reliable elections. With this in mind, we require a minimum of three electable nodes to be configured. Depending on your scenario, these nodes can be divided in several different ways. We generally advise one of the following node distribution options:

2-2-1: Two nodes in the highest-priority cloud region, two nodes in a lower-priority cloud region, one node in a different lower-priority region

To achieve continuous read and write availability across any cloud provider and region outage, a 2-2-1 node distribution is needed. By spreading across multiple cloud providers, you gain higher availability guarantees. However, as 2-2-1 node distributions need to continuously replicate data to five nodes, across different regions and cloud providers, this can be the more costly configuration. If cost is a concern, then the 1-1-1 node distribution can be an effective alternative.

1-1-1: One node in three different cloud regions

In this configuration, you'll be able to achieve similar (but not quite exact) read and write availability to the 2-2-1 distribution with three cloud providers. The biggest difference, however, is that when a cloud provider does go down, you may encounter higher write latency, especially if your writes have to temporarily shift to a region that's farther away.

Multi-Cloud Considerations

With multi-cloud capabilities come new considerations to keep in mind. As you start creating more of your own multi-cloud clusters, be aware of the following:

Election/Replication Lag

The larger the number of regions you have or the longer the physical distances are between your nodes, the longer your election times/replication lag will be. You may have already experienced this if you have multi-region clusters, but it can be exacerbated as nodes are potentially spread farther apart with multi-cloud clusters.

Connection Strings

If you use the standard connection string format, removing an entire region from an existing multi-region cluster may result in a new connection string. Instead, it is strongly recommended that you use the DNS seedlist format to avoid potential service loss for your applications.

Host Names

Atlas does not guarantee that host names remain consistent with respect to node types during topology changes. For example, in my cluster named "multi-cloud-demo", I had an Analytics node named multi-cloud-demo-shard-00-05.opbdn.mongodb.net:27017. When a topology change occurs, such as changing my selected regions or scaling the number of nodes in my cluster, Atlas does not guarantee that the specific host name multi-cloud-demo-shard-00-05.opbdn.mongodb.net:27017 will still refer to an Analytics node.

Built-in Custom Write Concerns

Atlas provides built-in custom write concerns for multi-region clusters. These can help improve data consistency by ensuring operations are propagated to a set number of regions before an operation can succeed.

Custom Write Concerns for Multi-Region Clusters in MongoDB Atlas

Multi-Cloud FAQs

Can existing clusters be modified to be multi-cloud clusters? Yes. All clusters M10 or higher can be changed to a multi-cloud cluster through the cluster configuration settings in Atlas.

Can I deploy a multi-cloud sharded cluster? Yes. Both multi-cloud replica sets and multi-cloud sharded clusters are available to deploy on Atlas.

Do multi-cloud clusters work the same way on all versions, cluster tiers, and clouds? Yes. Multi-cloud clusters will behave very similarly to single-cloud multi-region clusters, which means it will also be subject to the same constraints.

What happens to the config servers in a multi-cloud sharded cluster? Config servers will behave in the same way they do for existing sharded clusters on MongoDB Atlas today. If a cluster has two electable regions, there will be two config servers in the highest priority region and one config server in the next highest region. If a cluster has three or more electable regions, there will be one config server in each of the three highest priority regions.

Can I use a key management system for encryption at rest with a multi-cloud cluster? Yes. Whichever KMS you prefer (Azure Key Vault, AWS KMS, or Google Cloud KMS) can be used, though only one KMS can be active at a time. Otherwise, key management for encryption at rest works in the same way as it does for single-cloud clusters.

Can I pin data to certain cloud providers for compliance requirements? Yes. With Global Clusters, you can pin data to specific zones or regions to fulfill any data sovereignty requirements you may have.

Thank you!

Thank you so much for taking the time to read through my article. If you enjoyed it or have a question, please let me know in a comment below. Or even better, if you feel this article would be helpful to other devs, please share it/tweet it to spread the knowledge and love. ♥️

For more from me, be sure to follow my blog! And to see what I'm currently up to, follow me on Twitter!

I did too.

Ideally, and essentially, all I needed was a function to accept a target end date and return the remaining time until that date. That’s exactly what I built using only pure (vanilla) JavaScript. I’ll show you the code and then explain, line-by-line. :)

Let’s explain what’s going on here:

function countdown(`endDate`) {

Ok, softball line of code here right? We’re declaring our function countdown which accepts a parameter endDate. So far, so good, yeah?

let days, hours, minutes, seconds;

Now we’re declaring several variables that we’ll need. These will be the units of time that will be calculated and displayed. Note: These were the specific units I needed; You can add/remove other units of time as needed for your purposes.

Here, I chained two methods to transform endDate into a usable format that we can perform operations on.

First:

endDate = new Date(endDate)

converts our passed in endDate parameter into a JavaScript Date object.

Second:

.getTime();

returns our newly converted JavaScript date into milliseconds…Specifically, the number of milliseconds that have elapsed between 1 January 1970 00:00:00 UTC and the given date.

Great! Now our endDate is in milliseconds and ready to be used in calculations. Before we start calculating though, I added a simple validation check:

if (isNaN(endDate)) { 
    return; 
}

After our conversions, we want to make sure the resulting number is, in fact a number. If not, we end the show right here. Ok, now we’re done setting up the basics, now we can start having fun.

setInterval(calculate, 1000);

Since we are evaluating how much time is remaining every second, we’ll use setInterval to repeatedly execute some function we decide to give it. So in the code above, we pass in our calculate function as the first argument and 1000 as the second argument to denote one second (1000 ms = 1 second).

Now we can declare our calculate function…

function calculate() {  
  let startDate = new Date().getTime();

…and then grab the exact date as of this moment, converted into milliseconds, and place it in variable called startDate.

Then we can determine the time remaining between the current date and our end date:

let timeRemaining = parseInt((endDate - startDate) / 1000);

To do this, we subtract startDate from endDate to get the remaining milliseconds between the two. Then we divide by 1000 to get seconds, which will be an easier unit to work with for calculating our other units of time. We store this in a variable called timeRemaining.

Now we check to see that there is, in fact, still time remaining between the current date and our end date:

if (timeRemaining >= 0) {

If there is, we move into this block and calculate the unit specific measurements of time we want to display. Let’s start with remaining days:

days = parseInt(timeRemaining / 86400);

To calculate the days remaining, we divide our remaining time by 86400, the number of seconds in a single day. This result is then parsed within the parseInt() function to ensure we work with whole numbers.

Before we continue calculating the other units, we need to subtract the days we’ve already calculated:

timeRemaining = (timeRemaining % 86400);

Once we do this, we assign the remaining time to our timeRemaining variable.

We can now continue calculating the other units of time in the same manner:

hours = parseInt(timeRemaining / 3600); // 3600 seconds in one hour
timeRemaining = (timeRemaining % 3600);

minutes = parseInt(timeRemaining / 60); // 60 seconds in one minute
timeRemaining = (timeRemaining % 60);

seconds = parseInt(timeRemaining);

Almost done! We’re now ready to update our DOM elements with our newly calculated units of time!

I made things easier for myself and created an element per unit of time I was going to display. For reference, check out my GitHub repo to see the page I built utilizing this countdown timer. In essence, my timer would be displayed in a div that looked like this:

<div class="countdown">
    <p class="timer">
        <span id="days"></span> Day(s)
        <span id="hours"></span> Hour(s)
        <span id="minutes"></span> Minute(s)
        <span id="seconds"></span> Second(s)
    </p>
</div>

With that in mind, I simply get the element I need and set its innerHTML to the appropriate unit:

document.getElementById("days").innerHTML = parseInt(days, 10);

For remaining days, I parse my days variable and explicitly set the radix to 10 before assigning it to my element. This is to ensure the resulting display is set in the decimal numeral system.

Continuing on with the other units of time, I adjust the resulting calculations to display a leading zero before assigning it to its corresponding element:

document.getElementById("hours").innerHTML = hours < 10 ? "0" + hours : hours;

First, I check if the remaining hours are below double-digits, which start at 10. If it is, I append a "0" before the remaining hours. Otherwise, I just return the remaining hours as-is.

For example, if hours = 4, the ternary operator would evaluate to true as it's less than 10. Adding the leading zero would return "04".

Alternatively, if hours = 23, the ternary operator would evaluate to false, so adding the leading zero would be unnecessary. So, I just return the hours as-is.

I do the same thing for minutes and seconds:

document.getElementById("minutes").innerHTML = minutes < 10 ? "0" + minutes : minutes;

document.getElementById("seconds").innerHTML = seconds < 10 ? "0" + seconds : seconds;

Just need a few more closing curly bracket and remaining code to end function execution if there is no time remaining:

        } else {  
          return;
        }
    }
}

And that’s it!

In the context of my maintenance page, I wanted this countdown timer to start on page load. So I decided to place my countdown function within an iife, or immediately-invoked function expression:

(function () {  
  countdown('04/01/2018 05:00:00 PM');
}());

Our scheduled platform upgrade was slated to end on April 1st (no joke!) at 5PM, so this was the date I passed in.

This worked perfectly and was just what I needed. As promised, no external libraries or extra packages were used. JavaScript really is a wonderful language. :)

Thanks for reading! If you enjoyed it, please let me know in a comment below. Or even better, if you feel this article was thorough in a good way, please share it/tweet it to spread the knowledge and love. ♥️

For more from me, be sure to follow my blog! And to see what I'm currently up to, follow me on Twitter && Instagram!

Kumusta! My name is Adrienne Tacke. After almost 8 years as a developer in the US, I have gathered some insightful advice that I’d like every developer to know, especially those who are just starting out.

Here’s to helping the next wave of developers!

Insight 1: You’ll need to fail fast and fail often if you want to get ahead.

Failure is inevitable. Embrace it.

Failure is inevitable in a software development journey. Just look at how many concepts, frameworks, and tools there are to learn in web development alone! I’m willing to bet that most new web developers have gone through the agony of trying to set up Webpack for the first time or were deathly afraid to run a git command or two.

Learning web development in ${year}.

The point is, when something is overwhelming or new for someone, there is a great chance that person will make a mistake. And when that something is also ever-evolving and quickly changing (like software development!), you can be sure that the chances of making a mistake are guaranteed to increase.

The fear of failure is also something that hinders a lot of new developers. I remember when I was an intern for my university's software development department, I rarely asked questions and always tried to portray that I knew what I was doing. I didn’t.

Not really. Not thoroughly.

By allowing this fear of failing and looking stupid consume me, I never asked how a certain piece of code worked or why we implemented a certain solution over another. I spent hours trying to piece together StackOverflow answers and other parts of our codebase to try and make sense of things instead of just asking for help or a pair programming session. These are the questions and learning opportunities that, had I encountered them sooner, would have made me a much better developer in a shorter amount of time. Instead, I spent an exaggerated amount of time learning things superficially rather than fully experiencing and building a solid foundation of core development concepts and best practices. Bummer.

So what do we do if all of this failure is inevitable?

Embrace it.

Don’t be fearful of it. Acknowledge it. Use it as a catapult in your journey, not as a ball and chain that drags you down. This is probably the most important piece of advice every new developer should know and is the reason I listed it first.

By experiencing failure at a faster rate, you are inevitably catapulting yourself to the top of the steep learning curve that seems to discourage a lot of people.

When you fail fast and fail often, it likely means you are learning things at a significantly faster rate than someone who does their best to avoid failure. The sooner you learn how to deal with merge conflicts, run into console errors while setting up Webpack, or experience what happens when you forget a WHERE clause in your SQL query, the greater your growth as a developer.

Insight 2: Imposter Syndrome is normal at every stage.

There will be points in your career where you’ll feel crippling doubt. It can come when you bomb a technical interview, are stuck on a bug for longer than a few days, or start several side projects that never get completed.

It can also creep in when you start comparing yourself to other developers who are in different fields, seem more accomplished, or generally seem like they know their shit. This happens to me sometimes. Even though I have eight years of experience, made key contributions to several production-level applications, and have a pretty accomplished career if I look at myself objectively, I suddenly feel irrelevant the moment I see another Boston Dynamics video.

Boston Dynamics, if you read this, I will quit my job and totally intern for you ❤

I mean, look at how much progress they are making in the field of robotics!

infatuated sigh

What you and I need to keep in mind, however, is that every example and moment of comparison I just mentioned can happen at ANY point in a developer’s career. From interns to architects and self-taught to formally educated, every developer I have ever met, including myself, has felt imposter syndrome at multiple points in their journey.

And you know what? That’s ok. What’s important to remember is that if you feel these pangs of imposter syndrome, it absolutely does not mean you are a bad developer. In fact, I like to think that it actually means one of the following things:

• You don’t understand some fundamental concept, a language’s syntax, or a new tool well enough yet
• You don’t know or fully understand the scope of the problem/task that is before you
• You don’t know the entire depth and breadth of hard work and circumstances the person you are comparing yourself to has faced to get to the point they are at now
• You did not prepare || study || learn something new as well as you think you did
• You may be lacking a good night's sleep or be under other stress.
• You've set unreasonable expectations for yourself when it comes to learning and becoming skilled in something new.
• You did not have enough || any coffee before starting your day.

You know what’s awesome about all of these potential causes of Imposter Syndrome? They are all actionable things that you can control! Things you can work towards, improve upon, and change. Most importantly, they are all things that are hardly indicative of being intrinsically bad at software development.

So the next time you are banging your head on your desk because the same console error is appearing in DevTools for 4 hours, take a break and get some more coffee. Then remember that just because you are caught in a snag today DOES NOT mean you are a “fake” developer.

Insight 3: There is no developer “uniform”.

The following insight and advice applies to everyone, but unfortunately feel it will be more relatable to women in tech.

There is still a large misunderstanding regarding what a “real” developer is and what they’re “supposed” to look like.

Essentially, when asking an average person to describe a software developer, the stereotypical example of a white male that’s socially awkward, poorly dressed, and poorly groomed is usually brought up.

Of course, most of us know this is fundamentally incorrect. Or do we?

If you follow my Instagram, you’ll know that I like to wear what others consider feminine/body-conscious outfits. Nothing too drastic or revealing as my job requires a business-professional dress code. Unfortunately, with the internet being the predictable beast that it is, I found that one of my Instagram posts suddenly became a semi-popular meme on Facebook one day:

Cool, I’m a meme! Wait, what do the comments say?!

That’s cool. Until you read the comments…

"Real" developers, as described by some Facebook comments 🙄

What was even more disheartening were the comments from other females:

Yay for women supporting women. :(

When we are already battling the same fear of failure as everyone else, trying to overcome regular Imposter Syndrome as well as Imposter Syndrome Because You Are A Woman ©, and constantly working a little bit harder to prove ourselves and our skills, is it really necessary to add “appropriate” attire to the list of things we need to worry about? sigh

Now don’t get me wrong. This IS Facebook, and I’m not saying that everyone holds these prejudices. In fact, there were a few brave souls that were speaking out against the misogynistic comments and even defending my existence:

Michael is awesome. Try to be like Michael.

Esa is also awesome. Be like Esa too.

Someone even linked my Instagram profile, but that wasn’t enough. I was a unicorn:

Nah, that can’t be a real profile! 🙄 (FYI, my IG handle is now @adriennetacke)

Salamat!

Ultimately, I’m just trying to show that there is still a large majority of society that maintain this mentality and continue to perpetuate the stereotype; that, in my 8 years of experience thus far, there is still work to do in terms of women supporting other women instead of tearing each other down; that this exact post is a clear example of why so few women enter software development in the first place or continue to stay in it.

Despite all of these factors, what I want everyone to know and take away from this is that it truly doesn’t matter what a person looks like or chooses to wear. And it certainly plays no part in determining whether or not someone is a developer or is a good one for that matter. Typing that out and reading it sounds a bit silly, doesn’t it? A little too common sense? And yet, I take the time to dedicate my third insight of this article for it because it is still a stereotype we need to break.

For me, a “real” developer is someone that likes building things and solving all kinds of problems. It’s someone that enjoys learning new things, constantly challenging themselves, and is inquisitive. And that’s it.

There’s no dress code, official operating system, or master programming language that you need to have or use to be a developer.

So what does this mean and how do we deal with the existing situation? We do everything we can to break the stereotype. Wear what you want to wear. Reach out to fellow developers and learn things together. Support others who are more knowledgeable than you and mentor those who know less than you. And probably the most significant thing we can do is to keep sharing our individual stories so that we can see different perspectives and show society that developers are more than just white, male, and casually dressed.

That’s why it’s so important for me to continue sharing my journey on Instagram and to keep wearing the outfits I wear. I don’t need to dress down, switch to a MacBook, have 10K followers on Twitter, or post every line of code I write to prove my skill or worth as a developer. Why? Because these things don’t bear any weight in my skill as a developer!

Sharing my story inspires other women, and anyone else, to continue wearing what they want to wear and worry less about the things that don’t matter. Volunteering to speak to school children shows that jobs in tech aren’t limited to boys. And sharing my insights to you all hopefully provides the guidance I wish I had while navigating through my software development career.

Thank you so much for taking the time to read through my article. If you enjoyed it, please let me know in a comment below. Or even better, if you feel this article would be helpful to other devs, please share it/tweet it to spread the knowledge and love. ♥️

For more from me, be sure to follow my blog! And to see what I'm currently up to, follow me on Twitter && Instagram!