DEV Community: madison-stankevich

We Are All Guilty: Commonly Neglected Health Tips in Tech

madison-stankevich — Wed, 17 Apr 2019 04:55:06 +0000

Before my to transition to tech, I was a registered nurse. This gives me a unique perspective on the health impact a career as a software developer has on one's body. I personally have found programming to be shockingly physically stressful considering its sedentary nature.

This blog post sets out to bring attention to the little things that we all do on a daily basis that can have long-term impact on our health. Small changes in the way you work can have a huge impact on your overall well-being.

Here are five things that everyone in tech is guilty of...

1. We Sit More Than We Should

This might seem trivial, but it turns out that sitting for extended periods of time can actually be incredibly dangerous in the long run.

An analysis of 13 studies of sitting time and activity levels found that those who sat for more than eight hours a day with no physical activity had a risk of dying similar to the risks of dying posed by obesity and smoking.
-Edward R. Laskowski, M.D.

Eventually, too much sitting can deteriorate your cardiovascular system, cause you to gain weight, increase your cholesterol, and raise your blood pressure. Sitting for long periods of time also causes varicose veins.

What you can do to avoid this: Stand. Frequently. Around every 30 minutes is recommended. If you are unable to stand regularly, doing 60-75 minutes of moderately intense cardiovascular exercise daily can negate the setbacks of excessive sitting.

2. We Stare At Screens All Day

CVS isn't just your neighborhood drug store, it is also a condition called "Computer Vision Syndrome" also called "Digital Eye Strain", and its symptoms are all too familiar.

The effects of too much screen time include blurred vision, dry/red eyes, headaches, neck/back pain.

How can you avoid this: Following a 20-20-20 rule is recommended. Every 20 minutes look away from your screen for 20 seconds at something about 20 feet away. If you wear glasses to see far away, take them off while working on your computer. Turn down the brightness of your screen. Reduce glare in your work environment. Rest your eyes for a full 15 minutes after two hours of computer use.

3. Our Posture is Awful

You probably straightened up a little as you read that.

In addition to neck and back pain, bad posture can lead to poor digestion, decreased circulation, reduced lung capacity, and increased fatigue.

What you can do to avoid this: Be aware of your posturing. Set timers to remind yourself regularly to pay attention until good posture becomes a habit. Make sure you have the tools you need to have good posture, including an ergonomically designed chair and a movable monitor that you can adjust to avoid neck strain.

4. We Do Not Hydrate

To be fair... no one does. Approximately 75% of Americans are chronically dehydrated.

Water is your body's principal chemical component and makes up about 60 percent of your body weight. Your body depends on water to survive.

Symptoms of dehydration include fatigue, irritability, reduced concentration, increased anxiety, hunger, and foggy memory.

What you can do to avoid this: Drink more water (and fewer caffeinated beverages). Approximately 12-16 cups of water daily is recommended by the National Academies of Sciences, Engineering, and Medicine.

5. We Use Repetitive Hand Movements

Until everything becomes voice-controlled, our fingers will have to keep on putting in the grunt work. Unfortunately, this regular, unnatural movement has poor implications for our health.

Those most at risk for RSI include:

Use a computer for over 2-4 hours a day
Do not take breaks often
Have a stressful or sedentary lifestyle
Do not sleep well enough
Those who ignore their risk factors

In simple medical terms, repetitive strain injury (RSI) is defined as a cumulative trauma disorder (CTD) stemming from prolonged repetitive, forceful, or awkward hand movements.
-Dr. Emil Pascarelli and Deborah Quilter

What you can do to avoid this: Follow the rules for ergonomic typing... elbows at 90 degrees, floating fingers, sit up straight. Avoid using a mouse when possible. Only type as much as you need to. Stretch regularly.

Hopefully you have found some useful health reminders within this blog and will find ways to incorporate them into your daily routine.

~~Happy~~ Healthy coding!

Big O Notation: A Brief Overview for the Beginner

madison-stankevich — Wed, 03 Apr 2019 05:57:49 +0000

Big O Notation is a concept that has been incredibly intimidating for me during my transition into programming. I had this preconceived notion that Big O Notation involved complex math and knowing a multitude of algorithms. As it turns out, Big O Notation is not all that scary, in fact, it makes a lot of sense once you do a little bit of research.

This blog post is meant as a high level overview for someone who has basic coding experience, but no exposure to Big O Notation. It serves to explain the conceptual basics of Big O in an abstract way.

What's the Big (O) Deal?

Big O Notation is a descriptive tool that is used by developers in order to communicate how well their program handles an increase in input. It can be a measure of how fast a program runs ("time complexity") or how much storage it stakes up ("space complexity").

Essentially, if a program is able to handle an increasingly large amount of input in the same amount of time as a small amount of input, then it will rate well according to Big O Notation.

Measures of Complexity

Suppose we have a function that returns the string "Hello World". This function takes user input in the form of an array. It does not matter if the array that was entered is empty or whether it is thousands of numbers long, the program will still have the same runtime. This is called "constant time" and is considered ideal.

What about a function that performs a task for each item in an array? Perhaps now our same function was altered so that rather than returning "Hello World" once regardless of the input, it returns "Hello World" once for each item in the array that is entered. This type of function has what is called "linear growth". This means that there is a direct correlation between the size of the input and the runtime of our program.

Now let's say that instead of returning "Hello World" for every item in our function, our program has been rewritten to return "Hello World" as many times as the array is long for each element in the array. In this example an array of size 1 would return "Hello World" once, an array of size 2 would return "Hello World" four times, an array of size 3 would return "Hello World" nine times, and so on. This is considered "exponential growth". You can imagine how increasing the input has the capability of drastically impeding the speed of our program.

Why Does It Matter?

Big O Notation is important because we want our code to be "scalable". Scalability is a program's ability to remain efficient when exposed to a large amount of input or data.

So...Does this mean that there is one algorithm used by every program that is the perfect Big O Notation solution that will make our code efficient and scalable?

In short...no.

There is no one-size-fits-all algorithm for writing code. The type of code you write will be dependent on the issue you are solving. Different problems will have different requirements and therefore make use of different methods.

It is important that, as a developer, you be cognizant of your program's complexity and cut out unnecessary bulk so that the code will run as efficiently as possible. Big O Notation is one of the tools you can use to express the complexity of your code.

Resources

http://www.corejavainterviewquestions.com/idiots-guide-big-o/
https://rob-bell.net/2009/06/a-beginners-guide-to-big-o-notation/

What Is an API? (Hint: It Is Not a Sandwich)

madison-stankevich — Wed, 20 Feb 2019 16:17:29 +0000

If you had told me two weeks ago that in one week's time I would be proudly presenting a project that centered around the use of an API, I would have been dubious to say the least.

Less than two weeks ago was the first time I had encountered the term API.

As my project partner and I worked on our program, we accessed the Ticketmaster API through something called a “key”, which essentially unlocked data for us to use. We created a program which allows a user to search events on Ticketmaster. The user can refine this data by various options including city, performer, and date. You can view a video demo of our project on YouTube here and see our code on GitHub here.

I fully understood all of the steps we were taking as we developed this product, but somehow I could not detect which part of this process could be labeled as the actual API.

Image and quote from "The Princess Bride" (1987)

The purpose of this blog post is to challenge myself to simply and effectively describe what an API is in order to cement my understanding of the subject. In this post, my use of the term API is referring specifically to a web API. Hopefully this post will be useful to developers who are looking for an explanation of web APIs from the perspective of someone who is new to the subject.

Before I define what an API is, I would like to identify what an API is not.

An API is not the data you are seeking. In the case of my project, the information we extracted from Ticketmaster for various events (e.g. artist, venue, date, time, etc.) did not constitute an API. Those data points are part of the expanse of information that makes up the Ticketmaster database we were accessing, and not the Ticketmaster API. This was a misconception that I harbored during this project, so I want to clear that up before diving in.

So… What exactly is a web API?

An API is a bit of code that allows two programs to interact. It is essentially an “access point”. The best way I am able to understand this concept is through an analogy in association with my personal real-world experiences.

It is no surprise that my favorite analogy for APIs involves food—specifically sandwiches. The ordering process at the sandwich shop Which Wich? provides a tangible representation of API use.

At Which Wich? to make an order, you fill out one of the available sandwich forms at the front of the restaurant and submit this form to the cashier. The sandwich forms involve various check boxes for the type of bread, meat, toppings, etc. and are printed on brown paper bags that are eventually used to hold the sandwich. Once your form is submitted, the kitchen then crafts your sandwich according to the specifications you requested and puts the finished sandwich into your paper bag sandwich form. At this point, your name is called and you may collect your masterpiece from the cashier.

If you are not familiar with ordering at Which Wich?, this YouTube video has a brief overview of the process:

Video by Marina Amdream, 2014

In this analogy, the business’s sandwich forms are playing the role of the API, and the sandwich supplies are the data that you wish to access. You (as the customer) are playing the role of your program. Just like the sandwich forms, an API has a set of rules you must abide by in order to access the desired information. If you follow the rules, you are likely to get what you ask for.

So this should mean that if a customer asks for a turkey sandwich on rye with avocado, tomato, pickles, and lettuce, then that is what she should get...right?

Not necessarily. What if the shop happens to be out of tomato today? It is not uncommon for APIs to have incomplete or missing data. This is something that my partner and I learned as we interacted with the TicketMaster API. At this point, it is your decision as a developer how to handle missing information. In our case, we elected to essentially label the sandwich with a note that said “No tomatoes available today”.

In a similar scenario, you could imagine a customer asking for something that is not only 'out of stock', but is simply not an available option. This can happen with APIs as well.

For example, if the Which Wich? customer adds in an additional box selection asking for chocolate sprinkles, the kitchen is not going to process this request because the option for chocolate sprinkles does not exist. By requesting an unavailable option, the customer risks not receiving a sandwich at all. As a rule of thumb, both in APIs and at Which Wich?, examine the available options and do not request things that are unlisted. Otherwise, it will be a recipe for disappointment.

If you watched the above video or have been to a Which Wich? before, you may have noticed that avocado is an additional charge. This is similar to an API.

Some APIs only allow public access to certain features and additional features are available for purchase. The API we used for Ticketmaster allowed us access to most of the information we set out to include. One thing that was not included was ticket prices; access to this information could be purchased from Ticketmaster. As an alternative, you could simply visit the TicketMaster site (the url for Ticketmaster was available in the free database we were accessing). For our project, we elected to redirect our users to the Ticketmaster site. In sandwich terms, we elected to skip the avocado "feature" to save a few bucks.

You might be asking yourself why the customer does not just access the sandwich materials directly?

If you try to access the sandwich supplies directly, you will likely get kicked out of the restaurant and possibly face legal action. When a customer enters Which Wich?, she agrees to follow their rules in order to obtain their product. Imagine how difficult it would be to make your own bread, grow your own vegetables, and raise livestock every time you wanted a sandwich. As customers, we agree to follow the rules to access the desired product because the amount of time and effort required to produce the same results on our own would be monumental. It is the same for APIs. We follow the rules because we do not have the ability to develop a similar resource on our own (not without a tremendous amount of time and effort).

In conclusion...

An API is a bit of code that allows one program to communicate with another program to expose something that is useful. One does not “access an API”, but rather, one “accesses a ______ through an API”. This blank space can be any number of useful things: a database, a product, part of a webpage, etc. In my personal example, my partner and I used the Ticketmaster API to access event information from Ticketmaster's database.

I hope that this post helped to distinguish what an API is, and did not make you too hungry in the process.