DEV Community: Alan Solitar

Webpack Aliases in Vue JS

Alan Solitar — Tue, 05 May 2020 13:47:21 +0000

This article is going to be a quick tutorial on how to set webpack aliases in a Vue JS project. This article is going to assume that your project has been created using Vue Cli. If it makes sense for your project, I highly recommend using it.

Webpack aliases are a great way to simplify imports in your Vue JS projects. Instead of specifying long paths, we can instead use a short alias and webpack will generate the full path when we build/run our project.

How To Set Up Webpack Aliases in Vue

To start, open up the vue.config.js file in the root directory of your project. If this file does not exist, create it.

Then, post in the following snippet:

const path = require('path');  
 module.exports = {  
 configureWebpack: {  
     resolve: {  

       alias: {  
           //aliases go here  
       },  
     },  
 }

Take a look at the alias property of the configureWebpack object. This is where we are going to put all of our aliases.

A webpack alias looks something like the following:

'@c': path.resolve(\_\_dirname, 'src/components')

What we can do now is fill out this alias object with a few paths that we want to alias. To create an alias, simply create a property which will be the name of your alias. In this example, all of the aliases will be prefixed with the @ symbol, but you could pretty much do whatever you want. The value must be set to the path for the directory you want to alias.

const path = require('path');  
 module.exports = {  
 configureWebpack: {  
     resolve: {  
       alias: {  
         '@c': path.resolve(\_\_dirname, 'src/components'),  
         '@m': path.resolve(\_\_dirname, 'src/mixins'),  
       },  
     },  
 }

Awesome, we have aliases. How can we use them in our Vue components?

import MyComponent from '@c/MyComponent.vue'  
 import MyMixin from '@m/MyMixin'  
 export default {  
   name: 'Home',  
   components: {  
     MyComponent,  
   },  
   mixins: [MyMixin],  

 };

Wow, isn’t that awesome. Look at how short those import statements are. No we don’t have to worry about typing out a bunch of long, unmaintainable paths.

I hope you enjoyed this content. If you liked this, considering checking out my article about How To More Efficiently Pass Down Props in Vue JS or this other article about How To Import All Vuex Modules Automatically.

Have fun!

The post Webpack Aliases in Vue JS appeared first on Remote Dev Daily.

Search Git Commit History

Alan Solitar — Tue, 28 Apr 2020 02:45:06 +0000

Here’s a quick guide on how to search for commits in a repository’s git commit history.

Git logs, particularly for large teams of developers, can get get massive. In such situations, scrolling through logs looking for a specific commit doesn’t really work. Here are a few ways to easily search through a repository’s git history.

Search By User

git log -i --author="<user>"

This command will get all the commits for users that match a specific pattern. -i will do a case insensitive search, which usually is the behavior that I want. If you are doing a search where case is important, then simply omit -i.

For example:

git log --author="Alan"

commit z14tz0ez2324251gsff5769gg67a42d543255333 (HEAD -> master, origin/master)  
 Author: Alan-S <myemail@something.com>  
 Date:   Tue Mar 31 00:44:29 2020 -0400  

     Update README  

 commit 44ea613zzdde8b132423cczzz76abcaz9aa444gg  
 Author: Alan-S <myemail@something.com>  
 Date:   Tue Mar 31 00:43:59 2020 -0400  

     Fix issue that prevents data from loading on first page load.  

 :

Search By String

git log --grep="<string>"

This command will search the commit logs for this a specific pattern and return all of the matching commits. For example, this could be useful if you want to search for a commit messages that mention a specific term or phrase.

For example:

git log --grep="fetch" -i

commit z32a231zef218R5af46ffadf253c11f40zpl7383 (HEAD -> master)  
 Author: Alan-Solitar <myemail@something.com>  
 Date:   Mon Apr 27 22:34:53 2020 -0400  

     Fetch data on page load

This will grab all the logs that include the word fetch.

And that’s all. Now you should be able to more easily search through your git history. If you are interested in reading more about Git, consider checking out my article about quickly deleting all local git branches that I wrote.

Have a great day.

The post Search Git Commit History appeared first on Remote Dev Daily.

Python: Handling Exceptions in List Comprehensions

Alan Solitar — Tue, 11 Feb 2020 05:16:42 +0000

This article will cover how to handle exceptions in python list comprehensions.

I really enjoy using list comprehensions. It feels amazing to construct a nice list comprehension to make my code more readable and concise.

However, one thing that’s always annoyed be about list comprehensions is error handling.

The Problem With List Comprehensions and Exceptions

In particular, error handling can be a real pain when using functions inside list comprehensions.

Consider the following example:

You have a list of strings that each represent a percentage.

values = ['1.1%','2.0%','NA%','3.1%','5%','7.45%',]

Your task is to extract only the number from each string. We can do this with the following piece of code:

rates = [float(rate[:-1]) for value in values if rate]

But wait! As you can probably tell, NA is not a number, and because the float function has no way to handle this, it’s going to throw an exception.

Bummer.

So what are the options?

We could use a normal for loop with a try except block. And a lot of time time that can be a good choice. But for the purposes of this example, we want to see how we can handle errors using a list comprehension rather than a more traditional for loop.

OK, instead, we can filter out the unwanted values. And in this case, because we know that the list can contain a value of “NA%” , that will work. However, even though it works in this case, you won’t always know your values beforehand.

So, how can we tackle the case where you don’t know what values your input list will contain?

Fear not, there is a way to get both clean, concise looking code and robust error handling.

Catch function to the rescue!

def catch(func, *args, handle=lambda e : None, **kwargs):  
     try:  
         return func(*args, **kwargs)  
     except Exception as e:  
         return handle(e)

The credit for this nifty little code snippet goes to the user Bryan Head who shared this snippet in an answer to a question on stackoverflow. Thank’s Bryan.

This snippet is pretty sweet. This catch function accepts a function, args, kwargs, and optionally a custom exception handler.

You can now use this catch function as a wrapper to call whatever function you want.

You can also specify a custom handle function that will deal with any exception. By default, this handle function will just return None. In this case, that’s really useful since None can easily be filtered out in your list comprehension.

Here’s how we can apply the catch function to the previous example.

rates = [catch(float,rate[:-1]) for rate in rates if rate]  
 # [1.1,2.0,3.1,5.0,7.45]

And that’s all there is to it. Now you can handle exceptions in list comprehensions.

I hope that was helpful.

If you like python and want to check check out more awesome python content, consider checking out some other interesting python articles. For example, I have articles about common topics like How To Convert a string to A Datetime Object to more involved articles like how How to Upgrade from Django 1 to Django 2.
Enjoy!

The post Python: Handling Exceptions in List Comprehensions appeared first on Remote Dev Daily.

Python Django 2 Upgrade Tutorial: Common Problems

Alan Solitar — Sat, 24 Aug 2019 19:27:43 +0000

This tutorial will cover some of the common errors that you encounter when upgrading your Python Django application to Django 2.

I recently upgraded a project from Django 1.11 to Django 2, and after upgrading I was bombarded with a number of different errors. I thought I’d provide a record of the errors I encountered and how I fixed them.

1. No module named ‘django.core.urlresolvers’

In Django, it’s pretty common to use the reverse function to get the path of a url from it’s name.

The problematic line was the following:

from django.core.urlresolvers import reverse

The urlresolver module was removed in Django 2 and can no longer be used. Instead, you can use the resolve function from the urls module as such:

from django.urls import reverse

Awesome! One down. Let’s continue.

2. missing 1 required positional argument: ‘on_delete’

Django 2 now requires the on_delete keyword to be specified for foreign key fields that are used in your models.

Previously, it would default to models.CASCADE.

In order to resolve this problem, you’re going to need to add the on_delete keyword arguement to every foreign key field. You also need to specify on_delete for the OneToOneField as well.

Your options for the on_delete keyword argument include:

models.CASCADE
models.PROTECT
models.SET_NULL
models.SET_DEFAULT
models.SET()
models.DO_NOTHING

You can read about the values you can pass to on_delete in the Django documentation.

Here’s an example of what specifying the on_delete keyword looks like:

my_field = models.ForeignKey(MyModel, on_delete=models.CASCADE)

OK, moving on to the next error.

3. Specifying a namespace in include() without providing an app_name

This error is caused by a change in the api for Django’s include function. We need to make sure the include function is being passed the correct arguments.

First, you need to go to the urls.py file you are trying to include and add a variable called app_name. You can add it anywhere in the file, but I’d recommend putting it at the top after your imports.

# my_app/urls.py  
#... your imports  

app_name="my_app"  

# ... rest of your code

Now, go to the urls.py file that includes the other file. You can now add the app_name you specified as the second parameter to the include function.

Here’s an example:

# urls.py  
re_path(r'^api/my_path', include('my_app.urls','my_app' )),

4. There are duplicate field(s) in ‘fieldsets[][]

In my case, there was an issue with my custom ModelAdmin class. It seems Django used to allow duplicate fields before, but now it does not.

Simply remove the duplicate fields from your custom admin class and you shouldn’t have any issues.

5. JSONField default should be a callable instead of an instance so that it’s not shared between all field instances.

This is an issue you will only encounter if you are using PostgreSQL along with the PostgreSQL JSONField.

Basically, Django only wants you to pass a callable as the default value for this field. This is to avoid the default being shared among all objects which could lead to problems in the case of modification.

If your default is {} , replace that with dict.

If your default is [], replace that with list.

6. request.user.is_authenticated() TypeError: ‘bool’ object is not callable

In Django 2, is_authenticated can no longer be called as a function. It is a boolean property and you need to call it like a property as follows:

request.user.is_authenticated

7. Optional Changes

You are probably using the url function from django.conf.urls. Your code probably looks something like the following:

from django.conf.urls import url  
url(r"^books/$", views.BookList.as_view()),

The url function is an alias to django.urls.re_path() and it’s likely to be deprecated according to the Django documentation.

I highly recommend changing to import re_path to avoid future issues when the function is in fact deprecated.

Rewritten with re_path , the example from above would become:

from django.urls import re_path  
re_path(r"^books/$", views.BookList.as_view()),

And that about sums it up. Hopefully this helped you upgrade to Django 2.

If you liked this and want to see similar content, here are some other python articles I wrote.

Perhaps you are using heroku to host your Django project. If so, check out my article on how to change your python version in heroku.

Also, if you are interested in reading more awesome articles about being a remote software developer, please consider subscribing to my mailing list.

Keep on coding!

The post Python Django 2 Upgrade Tutorial: Common Problems appeared first on Remote Dev Daily.

How To Explain A Technical Problem To Non Technical People

Alan Solitar — Fri, 29 Mar 2019 15:00:11 +0000

One thing that I think a lot of developers struggle with is with how to explain a technical problem to a non-technical person. Developers often work all day with other developers where they can bounce around ideas, talk about bugs, and use technical language without fear of confusion or being misunderstood. However, there are times where developers must attend meetings with potential customers, explain a new feature to a non-technical boss/employee, or converse with any other potential number of non-technical individuals.

This type of communication can often be overlooked by developers, particularly if you are an introverted person, like myself. However, the more you are involved in the software industry, you realize that being able to explain technical issues is extremely important. It doesn’t matter whether someone has technical knowledge or not — no matter who you talk to, you want to treat them with respect and conduct the conversation in a way that is beneficial and easy to understand for both parties.

For example, put yourself on the other side of the table for a minute. Let’s say you are having a private meeting with your lawyer. You have an issue, and you are looking for clarification, advice, and potential resolution. As such, you wouldn’t want them to start throwing around a bunch of legal jargon or start citing really obscure sections of some complex legal document. You want to know in plain, direct language, what the law says, how it affects your situation, and what the proper course of action is.

Likewise, as a software engineer, you need to be aware of who your audience is and what the best way to convey the information they are seeking. How can we do this?

Solutions

1. Show The Problem!

As software developers, the products we work on often have visual components. Subsequently, most of the problems that we encounter in development affect user experience in some way. This may be that an end user is seeing incorrect data, certain features are broken, a page hangs, etc… Problems such as this are something that can be seen. As such, we can use tools such as screenshots or screen sharing in order to demonstrate these issues.

This allows you to show the problem in a more universal way that doesn’t depend on knowing certain technical words or understanding any design/implementation complexities. For example, let’s say you have a bug where a modal doesn’t close. This could be due to a problem with an api route, a bad event handler, or any other number of things. But when you demonstrate the problem by doing a live run through of the feature, no matter what the cause, your audience will generally understand what’s wrong. Somebody may not know the word “modal,” but they will certainly be able to see that the “big floating box with a button in it” doesn’t close properly

2. Explain the problem in business terms.

This is really useful if you are talking to an investor or a non-technical boss. A lot of the time, non-technical people don’t necessarily want an in-depth understanding of the problem. What they really want is to understand a few basic things:

How does this affect our customers?
How long is this going to take to fix?
Are there going to be any costs associated with this?

Rather than explain the technical details, you can boil down the issue into these core components.

For example:

“There is a problem with the code and thus the user is not able to perform Action A. I have located the problem, and it will take approximately X Days to fix. We will also need to upgrade to the next tier of aws which will cost Z Dollars more a month.”

This is great. It cuts through the technical level and gives these people the information they truly want.

3. Explain Your Terms

It may be that the above situations do not apply. There may be a situation where a non-technical person really does want a relatively in-depth understanding of the problem at hand. In this situation, what I find is helpful is to take a step back and really think about your words.

Since you are explaining a technical problem, it’s okay to occasionally throw in a technical word. But when you do, be sure that you explain that word. Don’t be ashamed or feel hesitant to explain terms that might seem a bit basic to you. Either you’re audience will nod in affirmation of something they already know, or they will be happy to receive an explanation of an unfamiliar word. Further, don’t take for granted that your explanation was understood. You should try your best to encourage questions and make sure that you can clarify any potential points of confusion.

I think that about covers it. Hopefully this information was helpful in understanding how to explain technical problems to non-technical individuals.

The post Explaining A Technical Problem To Non Technical People appeared first on Remote Dev Daily.

How To Protect Your Eyes As a Software Developer

Alan Solitar — Wed, 12 Dec 2018 21:45:18 +0000

As someone who has battled with eye issue in the past, I thought I’d provide the developer community with some tips on how to protect your eyes as a software developer.

As a software developer, your eyes are extremely important. All of those long debugging sessions scanning for that impossible to find bug, pouring over online documentation to see how to implement a certain feature — all of that intense work requires your eyes to be in good working order. And unfortunately, most people don’t realize the strain that these activities put on the eyes. I know I didn’t.

A few years ago, due to a combination of poor habits and past decisions, I had some pretty severe issues with my eyes. I’m not going to bore you with the details, but I will just say that at one point, it was so bad, that I could only really look at a computer screen for about 5 to 10 minutes at a time. As a developer, that is simply unacceptable.

After a few years of trial and error, online research, and behavioral modifications, I have found a number of tools, environmental changes, and behaviors that have allowed me to improve and maintain my eye health. Here’s what I have found:

Here’s what I have found:

1. Use Pen and Paper:

Extended amounts of time at the computer can be extremely tough on the eyes, but since most of our work requires the use of screens, it’s a necessary evil. However, as software developers, not all of our time is spent coding. Much of what we do is architectural — planning and designing the systems/interfaces that we are going to build out. During such stages, I’ve found that I don’t really need to use my computer. Instead, I grab my trusty old pen and do my work on a piece of paper. This allows me to take a break from the computer and my eyes always thank me.

2. Use f.lux:

f.lux is a program that adjusts the color temperature of your monitor. Blue light can be a large source of eye strain, especially as the day goes on and the sun goes down. Flux helps with this problem by intelligently managing the temperature of your monitor, slowly reducing the amount of emitted blue light as the day goes on. For me, f.lux was a real game changer. The difference in eye comfort was immediately apparent and I was able to slowly increase my amounts of screen time.

How f.lux works:

Provide f.lux with your location and what time you wake up in the morning — it will try it’s best to match your circadian rhythm, reducing monitor temperatures slowly as the day progresses and your bed time approaches. You can also manually adjust the colors or choose from presets.

3. Adjust Your Monitor’s Brightness Level:

Do you find yourself getting fatigued quickly when in front of the computer screen? It’s possible your monitor is too bright. It’s hard to say exactly what level of brightness is appropriate, since brightness of a device(often measured in Nits) will vary depending on the specific product and panel type. A good method I’ve seen used to find an optimal brightness level is to turn it down to the lowest level you can while still being able to read everything on screen. As someone who is very light sensitive, turning down the brightness on all my devices helped increase my comfort level massively.

Note: If you are doing any color sensitive work, flux and your monitor’s brightness level may distort colors. For f.lux, you can temporarily adjust the color temperatures, or choose a preset like “color fidelity.” For brightness, you can delegate different custom profiles(if your monitor supports them) for different tasks.

4. Use a dark theme extension:

This one was really important for me. Obviously, most web pages are white. However, this white background, particularly when your eyes are tired or irritated, can become a real bother. At my worst, looking at a site with a blindingly white background was almost impossible. I had always used a dark theme on all of my code editors, so I started to wonder, wouldn’t it be nice if something similar existed for web browsers?

The solution to this problem is a browser extensions that can alter every site’s css. On Firefox, I use Owl. For chrome, I use Dark Reader.

Though it can vary depending on the site, with both of these extensions, you will usually get white text on a dark background.

I can’t say a lot about Dark Reader other than “it works.” Firefox is my daily driver, so I will focus the discussion on Owl.

Owl was truly life changing for me. All of the above techniques helped a lot, but using a dark theme extension is what really allowed me to start working on a computer again. I went from barely being able to browse the web, to actually being able to look at a screen and do work for a couple hours at a time.

Owl is a great extension — you can enable/disable it for certain sites and it even works on pdfs.

In fact, I like Owl so much that I even contributed to the project on github a few months back.

5. Consider Lighting:

Any direct light is really tough on the eyes. I always make sure that my light source is behind me, illuminating my work space. Another important thing I’ve found is to make sure the light is filtered by either a lamp shade or other object. In my room, I actually use two lamp shades, because one wasn’t enough to properly filter the light.

Another good option is to have accent lighting. In the past I would sometimes place a light directly behind my monitor, for example.

6. Use High Contrast Mode(Windows 10)

This one is only really applicable to windows users. One problem I’ve had is that win32 apps, like file explorer, don’t have a dark theme like uwp apps.

To solve this I have mapped high contrast mode to a programmable key on my keyboard. Whenever I need to use a win32 app, I enter high contrast mode. When I switch to another app, I exit high contrast mode. It’s sometimes annoying, but it works.

*Update* – Windows actually did just release a dark theme for file explorer in the latest 1809 update. High Contrast Mode is still useful though when dealing with other win32 apps or parts of the os that can’t be skinned dark.

7. Dark Theme Everything

This may overlap with some of the above techniques, but it’s an important thing to mention. Whenever I consider using a new piece of software, I always look to see if it has a dark theme. This goes for my code editors, my operating system, or any piece of software I use. Even in my own personal projects I always make sure to use a darker color scheme. Sometimes I have to employ some weird hacks to apply dark themes, but in the end I’ve always found it to be worth it.

Other Things I’ve Found Useful:

1. Be Aware of AC/Heat:

This is something in the past I really overlooked. AC reduces humidity, while heating raises the temperature thus decreasing relative humidity. This dries out your eyes, starving you of much needed moisture. For this reason, I almost never use heat or air conditioning.

2. Blink:

Making sure to blink was really important for me. A main culprit for eye irritation while on the computer is decreased blink rate. Blinking is how your eyes get that much needed moisture. My blink rate in the past was really terrible — well below the average of 1 blink every 4 seconds. It’s taken a long time and a lot of conscious blinking and behavioral change, but my blink rate seems to have somewhat returned to normal levels.

3. Take Breaks:

I always making sure to give my eyes a rest when I can. In the past, I was a pretty serious about maintaining the 20-20-20 rule, which state “every 20 minutes, look at something 20 feet away, for 20 seconds.” However, normal breaks and occasionally looking away from my computer screen have become habits, so it’s not completely necessary anymore. Though it was certainly very useful in the past.

4. Work Remotely:

When you work remotely, you get to have full control of your environment. That makes it easy to control factors like the amount of light in the room, the internal temperate, and what software you install on your computer. If anyone out there is curious about remote work, please check out my article where I talk about The 5 Reasons Why I Love Being a Remote Software Developer. I love remote work and I would not be able to protect my eyes the way I do without it.

Well, that covers most of it I think. If I forgot anything or discover anything new, I’ll be sure to update this article. Also, if you are interested in reading more awesome content like this, please consider subscribing to my mailing list.

Please keep in mind that this is not advice and I am not a doctor. If you have any eye issues, be sure to consult a medical professional.

Let’s all keep our eyes healthy and keep on coding.

The post How To Protect Your Eyes As a Software Developer appeared first on Remote Dev Daily.

Getting Experience Without Attending Hackathons

Alan Solitar — Thu, 18 Oct 2018 15:11:53 +0000

Hackathons – they’re awesome — or so I hear. I’ve actually never been to one.

Hackathons and lovers of the remote lifestyle don’t mix all that well.

That said, hackathons do have many positive aspects. For example, you can do some networking, build stuff with data/hardware that you don’t have access to/can’t afford, and in some cases companies will even recruit at these events.

For CS students applying for internships or their first job out of college, hackathons can be very helpful. They give you something to talk about during interviews and if you happened to have placed or outright won at one of these events, companies may even try to recruit you.

However, there are definitely people, such as myself, whose personalities and mannerisms aren’t a good fit for hackathons. For example, if you can’t sleep in places that aren’t your bed, get uncomfortable in certain social situations, don’t work well with distractions, or just don’t like the idea of having to deal with a stressful all-nighter, hackathons may not be for you.

And to those like-minded individuals, I would say “Don’t force yourself to attend a hackathon.” I’ve never attended a hackathon and I am very content with that decision.

However, if you don’t attend hackathons, you could potentially be at a disadvantage when applying for jobs.

Any potential job seeker needs to think about the following:

How am I going to appeal to employers?

What will I put on my resume?

What am I going to talk about in an interview?

Hackathons are nice because they require a very low time investment for something that can potentially really pay off.

However, if you are an anti-hackathoner such as myself, there is no need to fret — you do have options.

Just know that you’re going to need to be a grinder.

1. Self Learning

You probably are going to want to spend a good amount of time learning new technologies. Since you are trying to get your foot in the door and get your resume noticed, it’s probably a good idea to perhaps learn a popular frontend or backend framework. Though just learning whatever frameworks/technologies that genuinely interest you is fine as well.

2. Personal Projects

Learning in and of itself is fine, but it would look really awesome if you had some projects to put on your your resume and perhaps even demo during an interview. Building something interesting and useful that you care about, rather than just something generic would be great. Still, any projects you have would be better than nothing at all.

3.Take Useful Electives

Taking something like graph theory is fine, and if that’s what you’re interested in, that’s great. Just know that it may not get you noticed. If you want to stand out, taking something like machine learning, ai, or computer vision, which are highly desired skillsets in today’s marketplace, are great choices. And of course, if your school offers courses in subjects like web development, database design, app development, or similar practical courses, those are also fantastic.

4. Contribute to an open source project

Maybe there’s a piece of open source software that you really like and you want to contribute to the project. For someone with little experience it may seem daunting to contribute to a existing piece of software, but just give it a shot. Even if it’s just removing a semi-colon, adding some comments, or making a fix to the documentation, any contributions will look good. Take a look through feature requests and reported issues. If you see anything that catches your eye, give it a shot. Even something as simple as documenting issues is fine. The point is to just start contributing.

Those are just a few ways that you can get some experience without attending hackathons. So if you aren’t the hackathon type of person, don’t worry. There are plenty of non-hackathon methods for gaining experience and building up your skills to impress future employers.

If anyone else has any good tips for young devs or has something to say about what I’ve written here, please leave a comment.

Also, if you are interested in reading more awesome software developer content, please subscribe to my mailing list.

The post Getting Experience Without Attending Hackathons appeared first on Remote Dev Daily.

Use a Standing Desk To Boost Your Health and Productivity

Alan Solitar — Tue, 11 Sep 2018 19:13:48 +0000

If you sit in a chair all day, as most software developers do, a standing desk might be a good option for you.

Any software developer should be familiar with what’s like to sit all day. You know the drill.

After a few hours, or perhaps sooner, your body starts to get stiff. The day continues and you are still in your chair. Your butt starts hurting. You might get some neck and shoulder pain — perhaps even some back pain. Your fidgeting, your body’s uncomfortable, and worst of all, you just can’t focus on work.

That’s a feeling that I knew all too well. It sucks and it was affecting my ability to perform as a software developer.

The Problem

A big problem is that most chairs lack flexibility — you are essentially locked into one position. What does this mean?

5 hours in a chair == 5 hours your body isn’t moving. And that’s a problem.

No movement, no blood flow — it’s no wonder so many software devs get into bad shape.

The Solution

I first learned about standing desks a few years ago from a Linus Tech Tips Youtube Video. In that video, Linus and his team talked about their impressions of a certain standing desk.

“Wow, these things are cool!”, I thought to myself.

They go up, they go down — that’s awesome!

I knew that I wasn’t exactly living a “healthy” lifestyle, and I thought this would be a great way to become more active. A standing desk was something I planned to get eventually, but I didn’t prioritize it.

Well, fast forward a few years:

I was having a ton of pain all over and sitting in a chair all day just wasn’t helping.

I figured now was the time to make the switch.

So, I did some research, found a desk that I liked, and I took the plunge.

And… I love it.

Standing desks are great, but you need to know how to use them properly.

What Not To Do

I highly recommend that you do not get one of the non-adjustable standing desks.

A common trend is to regard sitting as “the new smoking”. Seriously — and if you don’t believe me, here’s the google search results page.

Taking this argument to it’s logical conclusion, a lot of people will tell you to throw out your chair and get a pure standing desk.

I don’t agree.

If you’ve ever worked a retail job, standing for 8 or 9 hours a day isn’t exactly kind to your body either.

The idea is to have a nice balance of standing and sitting. That is why getting a sit standing desk is key.

My Workflow

Both standing and sitting can be comfortable or uncomfortable depending on the situation.

Just like programming languages, frameworks, and libraries, sitting and standing are just tools.

And like tools, you need to know when to use them.

I start the day by standing. It wakes me up, gets my body moving, and it just feels like a nice, refreshing way to start the day.

Once my feet or lower back start to get tired, I switch to sitting. Sitting acts as a nice change of pace, and I’m able to be productive once again.

Once I get tired of sitting or feel like my concentration is waning, I stand back up and stretch a bit as I work.

Throughout the day I monitor my body and mood, and will sit or stand depending on what I need to keep myself an alert, well-oiled, software developing machine.

I consider my standing desk to be an indispensable part of my home office set-up and I have no intention of ever going back to a traditional desk.

I feel so much better every day and my health has definitely improved.

If you happen to be interested in software developer health, you can also check out my article How Diet Made Me a Better Software Developer.

If any of the problems I mentioned in the article resonate with you or you just want to try living a healthier lifestyle, getting a standing desk might be a good option. Of course, I am not a doctor, and if it’s a health issue you are having, don’t forget to consult a physician first.

Conclusion : standing desks are awesome!

If you have any questions or thoughts about my sit standing desk experience, please comment below.

The post Use a Standing Desk To Boost Your Health and Productivity appeared first on Remote Dev Daily.

5 Reasons Why I Love Being a Remote Software Developer

Alan Solitar — Thu, 30 Aug 2018 02:15:15 +0000

I am a huge remote work enthusiast and want to share 5 reasons why I love being a remote software developer.

Being a remote software developer is something I always found alluring. You wake up and that’s it — you’re already at work. Time to get down to business and code!

How awesome is that?

It kind of brings back memories of the envy I always had for those few lucky kids that lived across the street from school.

Well, now I’m basically one of those kids!

Here’s 5 things I love about being a remote developer.

1. No Travel

When somebody talks about working remotely, this is probably the first thing that comes to mind. And yes, it’s as great as you think it would be.

Morning Rush ? Gone.

Crowded Trains ? Gone.

Bad Weather ? Who cares — you’re not going outside.

Not having to travel is simply awesome.

Using Your Own Setup

Being able to use my home computer set up for work is great. I don’t have to put in any equipment requests or worry about whether or not I’m going to have a comfy chair that can properly support my body.

At home I have all the tools I need to keep myself a well-oiled machine. I get to use my mechanical keyboard, dual monitors, sit in my nice chair, and not worry about being subject to a non-ergonomic setup or any of the typical nonsense.

3. You don’t have to use headphones

When I used to work in an office, my only escape from the noise was to slap on my headphones and put my head down. This is an OK solution, but wearing headphones all day has some serious downsides. One in particular is that it can cause “Listener fatigue.” No, I didn’t make that one up. You can view the Wikipedia entry on it here.

And in the first place, I only want to listen to music for fun and relaxation –not to drown out the sound of colleagues making a huge fuss over shooting a suction cup bow and arrow at a whiteboard (I know, that does sound like a blast — but it’s not fun at all when you aren’t the one participating).

When working from home, I don’t have to worry about the same type of distractions. If I want some music or I need to listen listen to a youtube video tutorial, I can just turn on speakers at a modest volume and proceed on my merry way.

4. Make your own lunch

When you work in an office, there’s always the temptation (especially when you work in a big city), to go out for lunch. This either gets really expensive, or you end up snacking down on salty chips or whatever other junk food you have in your office. And if you do pack a lunch, whatever your bring is always soggy and unappetizing by the time you actually do eat it.

When working from home, I’m able to go to my kitchen and make myself a nice fresh meal in no time. It’s cheap, keeps my midsection from getting round, and gives me a nice little break in the middle of the day.

If you are interested in what kind of foods I eat and how that has impacted my remote life, check out my article How Diet Made Me a Better Software Developer.

5. Feeling At Ease

On some level, when you’re in a public place, no matter how familiar you are there, you can never truly feel at ease. There is always some level of stress — at least that’s how I feel.

Maybe that feeling is particular to introverts? I’m not sure.

What I do know is that when I’m working remotely, I feel considerably more relaxed. I don’t have to worry about someone looking at my screen, nor do I have to feel guilty about taking a break to surf reddit.

In fact, it’s particularly this feeling of “being at ease” that allows me to fully focus on my work. Just being in a comfortable environment and knowing that I can easily takes breaks when I need to, makes me a better and more efficient worker.

That’s just a few of the things that I love about remote work. Now I’d like to hear from you. Please leave a comment and let me know what you think about remote work.

Also, if you are interested in reading more awesome articles about being a remote software developer, please consider subscribing to my mailing list.

Thank you for reading.

The post 5 Reasons Why I Love Being a Remote Software Developer appeared first on Remote Dev Daily.