Below are my must-have extensions for anyone doing web development. There are many more magnificent extensions, but I feel like the following are not only useful but required to augment your web development experience with VS Code.
Prettier is an opinionated code formatter. It enforces a consistent style by parsing your code and re-printing it with its own rules that take the maximum line length into account, wrapping code when necessary.
To ensure that this extension is used over other extensions you may have installed, be sure to set it as the default formatter in your VS Code settings. This setting can be set for all languages or by a specific language.
A Visual Studio Code extension that provides CSS class name completion for the HTML class attribute based on the definitions found in your workspace or external files referenced through the link element.
That’s all, folks! I invite you to try other extensions, but make sure not to clutter your VS Code experience by installing extensions you might not need or use.
Also, remember to adjust your VS Code settings to make sure you get the most productivity and the best experience when using VS Code and these extensions.
If you know of any other VS Code extensions for web development, please feel free to share them in the comments below. Cheers.
So you have a static website and need to host it somewhere, there are many places to host your site but since you also want your site to have a security certificate, and you want all of this at a reasonable price, your options are limited.
This time I decided to give AWS a try, and it turns out, hosting a static website using AWS’s S3 storage service works really well for static websites.
AWS also has a somewhat simple way to set up your new static website with a free security certificate. Below I will show you the steps to accomplish this.
These are the services you’ll need to configure to host your static website and an SSL certificate with Amazon’s AWS:
The instructions below assume that you’ve already signed up for a AWS account.
S3 – Create and change the properties of your static website bucket
After you login to your AWS Console, search for S3 and create a new bucket for your static website. When creating the new bucket, you only need to give it a unique name, and then uncheck the Block all public access options under permissions. Don’t change any of the other default values or options.
After you’ve created a new bucket to hold your website files, click on the bucket name and then on the properties tab. From here, select the Static Website Hosting, it should look like the screenshot below.
In this window, you want to put the name of your main page (i.e. index.html), an optional error page, and any redirection rules, also optional.
Before you move on to the next step, copy the Endpoint value from the Static website hosting window and save it, you’ll need it for the CloudFront Distribution section below. In the example above, the endpoint is the URL: http://solopractica.s3-website-us-west-2.amazonaws.com
Make sure the Block all public access option is unchecked. Now go to the Bucket Policy option and click on Policy Generator.
Select the options as shown above, make sure the Amazon Resource Name (ARN) follows this format: arn:aws:s3:::YourBucketName/* and replace YourBucketName with the actual name of your newly created bucket.
Finally, click on Add Statement and then Generate Policy, a new window will open with your new bucket policy in JSON format. Copy the JSON document, and paste it into the Bucket Policy space back in the bucket properties page.
If you get the following error message after saving the new policy: Policy has invalid resource, make sure the bucket name value is correct, and save again.
You’ll see a warning informing you that your bucket has public access, that is fine, the bucket needs public access to host your static website.
CloudFront Distribution – Create and configure
A CloudFront distribution is required if you want to host a static site and distribute media files using HTTP or HTTPS.
To create a CloudFront distribution, go to the AWS console, and type CloudFront in the search box. When the CloudFront Service page opens, click on Create Distribution, and then select Get Started for the Web option.
CloudFront distribution properties
Do not be overwhelmed by the many options in this window, you only need to change a few of these properties. Below are basic instructions on how to fill out the Create Distribution form.
Origin Domain Name: Select your bucket endpoint from this list.
Origin Path: Leave it blank.
Origin ID: It gets filled automatically when you select the origin domain name above.
Lambda Function Associations: Leave default/blank value.
Price Class: Use Only U.S., Canada and Europe (the cost of it will change based on what you select here. Click on the information icon next to this setting and make the right choice for you).
AWS WAF Web ACL: None.
Alternate Domain Names (CNAMEs): Type your domain name and any subdomains you have for the bucket hosting your static website. For example, for my site solopractica.com, I entered the following values here: solopractica.com http://www.solopractica.com
SSL Certificate: Custom SSL Certificate. This is where you’ll also be clicking on Request or Import a Certificate with ACM (see section below).
Choose the DNS validation option, it’s the fastest and easiest. If you don’t have access to your domain DNS settings, then you can try Email validation instead. Click Review, and then Confirm and request.
Once you go through the steps to validate your domain(s), you’ll see a window with your Request in progress and the instructions to add a CNAME record to the DNS configuration for your domain. Click Continue.
This page will show the status of your certificate request, you can refresh the status of your request to get the status updated. The time to get your domain verified depends in part, on your domain registrar.
After your certificate has been approved, go back to your Distribution and click on it to edit it. From the edit page, make sure you have the Custom SSL Certificate option selected and then select your brand new SSL certificate from the list.
Route 53 – Create and configure
This is the last step, it will allow AWS to route your domain name and certificate to the appropriate resource.
Go to the AWS console and type Route 53 in the search box, click on the Route 53 link, and then on Hosted zones.
Create a new hosted zone, enter your domain name, make sure the Public Hosted Zone is selected and click Create.
Two record sets are created by default when creating a new zone, a NS (Name Server), and SOA (Start of authority).
While selecting the newly created Hosted Zone, click on Create Record Set.
Use the following settings and values when creating the new record set:
Name: Leave the name box empty.
Type: A – IPv4 address.
Alias Target: Select it from the list, you should see a value available if all of the steps above were completed successfully.
Routing Policy: Simple.
Evaluate Target Health: No.
After this, you can add another record set of type A for any additional domain names you might be using, for example, http://www.yourdomain.com.
That’s it, by now you should be able to open your browser and go to your domain, it should be available with the https protocol.
Lately, I have been trying Visual Studio for Mac as this version of Visual Studio has evolved significantly. However, something I noticed is that since I don’t use it often, the local SSL certificates created by dotnet in the Mac get a bit screwy.
There is a possibility that you might end up with a conflicting certificate for localhost from creating or setting up applications in the past.
If you work with the Mac version of Visual Studio, and you ever get the following error, run the commands at the bottom to clean up the existing certificates for localhost and create new ones.
Failed to authenticate HTTPS connection. System.IO.IOException: Authentication failed because the remote party has closed the transport stream.
Open the terminal window, browse to your dotnet project and execute the following commands:
Both Bitbucket and Github are excellent choices to store your code; this isn’t a post about which one is best. Instead, the goal of this post is to document the steps I followed to move one of my projects from Bitbucket to Github, and what I did to wire up Github to Azure to automate the deployments of said project.
When I first started working in this project, I needed to use a cloud-based repository as a backup and to have it accessible from any computer at any time. I’ve been using Bitbucket’s free private repositories for a while now, and most of my projects are still there.
“Bitbucket is more than just Git code management. Bitbucket gives teams one place to plan projects, collaborate on code, test, and deploy.”
The text below is the description from bitbucket’s website. It is, in fact, a complete solution for code management. Just like Github, it does offer an easy-to-use interface and workflows to make building and deployment of your code a breeze.
However, one of Bitbucket’s advantages until recently was the unlimited free private repositories. For individuals with many projects like myself, paying for an external repository for each software experiment I create it’s just not feasible. Bitbucket understood this from the start, and this is the reason many developers, and probably small companies use their free private repositories.
“GitHub is a development platform inspired by the way you work. From open source to business, you can host and review code, manage projects, and build software alongside 31 million developers.”
The paragraph above is from Github’s website. While Github became very popular among the open source community, it just wasn’t a feasible solution for individuals or small companies looking to use private repositories and without resources to pay for them, at least not until now. You see, Microsoft acquired Github on October 2018 and this, perhaps, allowed them to expand their offerings and offer free private repositories. Regardless of the reason, it was a great move by Github, and I’m sure some people have switched to Github from other places now that they are offering free private repositories.
How do you move your code to a different remote repository?
Moving your code from one cloud repository to another is in fact, very simple if you are only moving a self-contained application like the one I moved. Technically, you don’t move your existing repository; you change the settings in your local repository to point to a new remote repository. For example, my project’s source lives in my laptop, under a folder labeled c:\repos\iai and since this folder is already set up as a Git repository, all I had to do is execute the following Git command:
That’s all, after you execute the command above, your local repository will be connected to the new Github remote repository.
Setting continuous deployment in Azure with new Github repository
Fortunately, this was also very easy, and Azure enables you to set up your application with continuous deployment by connecting to one of the following source control options:
Since I had already connected my web application with Bitbucket in Azure’s deployment center, all I had to do was disconnect it from Bitbucket, and then connect it to Github. To do this, you have to log in to the Azure portal, click on the App Services you want to change, and then go to Deployment Center under Deployment. Once you are there, you disconnect any existing repositories and then go through the steps to connect a new one.
After re-connecting my application to a new remote repository (Github), continuous deployment was again active and set up to automatically run every time I merge any code to the project’s Master branch in Github.
Below is a screen shot of the log after finishing the move and merging new changes to my project:
If you try browsing to the Github URL shown in the screenshot above you’ll get a 404 (Page Not Found) error, this is because this is a private repository.
The application for which code I moved from Bitbucket to Github is called Interns and Internships, and while it isn’t 100% complete yet, you can visit it here:
Before becoming a software developer, I had no clue what this job required or what did a developer did through the day. Many years later, I have a pretty good idea about the workload and can share some advice on what the ideal workspace for someone that writes code is.
First of all, let’s get something clear, software developers do not write code all day, it isn’t the same as writing a blog post or anything else. Working as a software developer is something like 20% code writing and 80 problem-solving. This 80% involves thinking about a problem or a new feature. Sometimes this is a back and forth exercise where the input of other developers or other collaborators might be needed. It isn’t until you have a pretty good understanding that what can be done that you actually get to write software. And because of this, a quiet place with little or no distractions is needed to be productive.
A quiet and distraction-free place
A quiet place is preferred and often required if you want to focus on a problem and a solution. Many companies have resourced to open office spaces with the idea that this sparks collaboration and communication between employees. I can tell you from experience working for years at an open plan office, it doesn’t work for thinking, focusing, or getting things done. When you walk into an open plan office the first time you’ll notice is people wearing headphones, and if you look closely, many of them will be wearing noise-canceling headphones. Software developers need a quiet place to work, private offices, a spacious cubicle, or a desk at home are ideal places for this type of work.
A distraction-free work area is also important, this isn’t to minimize or avoid collaboration, the idea is to not let co-workers or other people or situations have access to a software developer unless there are a clear need and an intention to do it. And don’t worry, people can still just chat or hang out at times when walking on a hallway or via an electronic communication channel.
A comfortable chair and a good size desk
While it is OK to use any coffee shop chair or your couch at home, any longer-term seating setup needs to include an ergonomic chair and a stand-up desk preferably. Anyone who spent hours in front of a computer screen will benefit from a good ergonomic chair and a stand-up desk. The right size desk should fit at least two large computer monitors and a laptop, this is a very common setup for software developers.
If you are looking for a good quality desk and chair at a reasonable price I recommend the Autonomous.ai standing desk and chair. I’ve owned both for a while, and I’m pleased with it.
When working from home
If you are a remote worker, having a quiet and distraction-free place is also necessary. This isn’t difficult to achieve, most people working from home will enjoy from a quiet home during working hours as kids go to school and spouses will be at an office, or working at home and focus on their own tasks.
If you work from home and don’t have a spare room or office to work from, find a quiet corner away from the front door and the kitchen (which tends to be a place for families to hang out). Your bedroom might be the perfect place for it, that is if your partner allows it and you are disciplined about working and non-working hours.
When working from a coffee shop or other public space
Ideally, you’ll find a place with comfortable seats, good internet connection, and great coffee and reasonably priced snacks. This isn’t always possible, but if you spend enough time to find the right place(s), you’ll be surprised at how accommodating public spaces can be for you to get stuff done. You’ll need to be prepared to work at these places and to do it successfully I recommend you read this blog post which includes tips and advice about working successfully at coffee shops, etc.
The ideal workspace for software developers continue to be a private office and having the option to work remotely whenever needed. This gives the software developer both a quiet place and a chance to work the hours that are more convenient for her/him. The private office can only help so much avoiding distractions, the best thing to avoid distractions is to form a culture of independence where people collaborate when necessary, without interrupting a co-worker, especially if it isn’t without a purpose
The advice above is by no means a recommendation to isolate software developers. However, to do their job and do it well, software developers need the time and space to focus and work on hard problems and to create solutions. Software developers will always be able to interact with others whether in person or online when needed to collaborate or just to socialize. What’s important here is to have that quiet place when you need it.