Posted on

Tools to get started with

The bare minimum to get started writing HTML, CSS, and JavaScript are a web browser and a super simple text editor like notepad or simple text (one that’s likely included with your computer). You don’t want to use a word processor because all that formatting leaves behind garbage that can cause you issues.

However, using something just a little fancier for writing code or markup is really worth it. You can find decent free or low-cost options without too much trouble. There are even some in-browser web page development options.

Browser

A browser is what renders your HMTL markup, and Cascading Style Sheets, and JavaScript into the webpage you are looking at. You are likely reading this page in a browser window.

Generally, this refers to one of the big 4, although there are others available.

  • Google Chrome
  • Firefox
  • Apple Safari
  • Microsoft Edge/Internet Explorer

I tend to primarily work in Chrome, but when testing I do open the others. There are services like Browser Stack that can offer you virtual testing environments with not only the different browsers but also different versions of those browsers.

Text Editor

Sure you can just type in plain text, but it’s nice to get a little help and color coding along with some auto-completion to get the job done a little faster and more accurately.

I’ve really been enjoying Sublime Text. It does cost $80, but technically the evaluation version doesn’t expire. I really get a lot of use out of it and was happy to support them by purchasing my license which I can use on as many machines as I’d like.

Code Anywhere is also pretty interesting as it gives you a coding environment as a web app, iOS, and Android.

References

You can find oodles of content on the web for describing how all this works. Here are a few I tend to reference quite a lot.

Asking Good Questions

Asking good questions is a skill you develop as you proceed down the path of programming. I’m constantly having a conversation with myself asking questions in my head as I proceed down a programming path.

When I run into a problem, I know it is likely someone else has already run into it and has written something about it. Asking a good question in a search will get you to your answer faster. Restructuring your question, taking out details, adding in details, pasting the error directly into the search, these are all ways to dive in and research the best answer for your problem at present.

Getting started with all of this isn’t a huge deal. Really it’s just about asking good questions and spending your time reviewing the details.

Posted on

Hello World is merely the start

When learning a new computer language, quite often the first example is to create a “Hello, World” type application. “Hello, World” is something we tend to take for granted now, but it wasn’t always the defacto starter example.

Learning a new computer language can be daunting. There are new ways to do things, many details as to how to organize and define your code, ways to package up your code, then to deploy your code to where it needs to go in order to function.

“Hello, World” was first used in an internal memorandum for Bell Labs back in 1974 by Brian Kernighan, and later widely released in his book for the “C Programming Langage” published in 1978. At this time computers were still typically large office machines taking up quite a lot of space, nothing like we have today. Brian Kernighan used this “Hello, World” example as a way to quickly show the basics of program structure and workflow, to get the programmer’s feet wet, and feel like they accomplished something.

So, “Hello, World” is a great start, but the story can’t end there. Learning a new language means you have to buy into its story, how it’s useful for you, what it can do for you, and how it can enable you to help others. When we learn any new language, a big reason why we learn is to help others. To help them communicate, to enable them to do less work, to make things easier.

After this great introduction, we need to keep things moving – and the best way to facilitate this is through story coupled with technical details. So often when learning a new language or API (Application Programming Interface) you are presented with dry stale details. Without a compelling reason to continue past “Hello, World”, a user learning will only do the bare minimum to get by.

If someone is learning your language or API, don’t you want them to dive in deeper. For them to advocate using your product rather than someone else’s? Creating documentation that is compelling, that tells a story, to get your users not only interested, but advocate for it’s usage to their peers – shouldn’t that be your goal?

Story is important.

What are you saying after “Hello, World”?