Let's Learn Code Together

I have a question about what type of languages do you use? html or javascript?

thanks O-O

Oh wow, how long has this been sitting there? Sorry.

In my current job, we use mostly TypeScript. React and Node. But when the need arises, we will use something more appropriate, like Java or Kotlin.

There is a common trap people fall into. It's like the old saying "when you have a hammer, everything looks like a nail". While most programming languages can accomplish almost the same things, there are a lot that have unique advantages to solving specific types of problems. That comes with a lot of time, and experience.

When you decide to start learning programming languages, the best thing to do is focus on how to learn. Literally, learn how to learn. Break things, experiment, compare. Nothing in tech stays the same. Even languages themselves evolve over time, so you are constantly learning and evolving with them.

Over the weekend, a question came in about Promises. I haven't worked much with Promises, nor have I done the NodeSchool module, so this will be a learning experience.

So first off, what is a Promise? A Promise is a way to make async calls neater and cleaner. Instead of having to nest functions inside of functions, you just make a series of .then() calls. This tells the code "once this one finishes, then do this other thing" and you can keep piling on "and then" as much as you want.

So let's take a look at Promise.

A funny little thing happened. After along period of silence, my post about Java vs Javascript got a little push. It made me think that the inherent differences of strong vs weak typed languages is a bigger deal than I would have thought. So instead of moving on to Express, let’s detour a second to Typescript.

First off - what’s Typescript? It is a language that adds types to Javascript. So remember that post, where I showed how Java declares “this is a string” or “this is a number”? Typescript does that for Javascript.

We can thank Microsoft for Typescript. But because it is a MS product, it means it does not look like Java. I hear it looks like C#, but honestly its been a long time since I have done anything in C#, I can’t really comment on that. I personally find Java much more intuitive and friendly, but I still appreciate the ability to add types.

So let’s dig in and look at an example. To play along, you will need to install typescript. It is an npm package, so just use this command:

npm install -g typescript

Typescript files have a .ts extension, and the typescript compiler will turn these .ts files into .js files. The .js files won’t have any of the typing still associated with it - but thats ok. The .js file is meant for the browser, or the application. The .ts file is meant for you.

We always start with a hello world. You can see there is really only one difference here between the .js version and this version -- we have added “: string” after the variable name to tell us what kind of data we are expecting. This says “I have a variable named test, and it will be a string”.

First I am showing the only thing in my directory is my hello.ts file. Then I am compiling it using the tsc (type script compiler) command, and I can see that I have 2 files - the .ts version and a newly generated .js version.

We can open that .js version and see the non-typed hello world that you have probably written before.

So we run the .js version just like we ran every other .js file, and we see our hello world message.

And what about other data types? Let’s look at a number example.

Now I am saying “I have a variable named testInt. It will be a number”.

As you can see, I can declare the value on the same line or a different line. This time, I set my variable to 5, and I can print that number to the console.

I recompile and run the file and I get the number 5 printed out.

But who cares? Does this really buy us anything? Let’s see how it deals if I try to put in the wrong data type after declaring it.

Already we can see the red swiggly that tells us that something is wrong. But is it only my IDE that is smart? Let’s try to compile and see if it works.

So the compiler is smart enough to tell you “hey, that is not the data type I was expecting”. If this was plain Javascript, you may have intended for that var to be a number, but nothing in JS will stop you from putting in a string. We would have seen “hello!” print to the console. 

So we can see that Typescript will enforce matching data types as you are working. This is a BIG improvement from the Javascript world of getting a very vague error that you need to track down.

But that isn’t everything that Typescript can do for you. How about Object Orientation? Do you like using classes? Now we can use classes in Javascript, thanks to Typescript.

I have a user class, with some properties. I declare the type alongside the properties, and in my constructor. Then I can create a new instance of my User class almost just like you would in Java/C#. Let’s compile and look at the result.

Ok, so there are a few things going on here. I kept it all in one image because I am hitting the image limit, but I will talk it through line by line. 

First things first, you can see that when I try to compile this, I get an error. The error is about the ECMAScript version. So I check the version of my TS Compiler, and I see I am on a good version. I do a little Googling, and I find out that the TS Compiler will default to compiling against ECMAScript version 3. So all I have to do to fix this is tell the TS Compiler to compile against 5.

I am not covering ECMA, what it is, and what the versions are in this post. I can do that in a later post, if you’d like - it isn’t critical, but it is good to know. Otherwise, you can just accept that if you see this error, this is the solution.

Once we compile with the right ES version, it compiles, and I have a user.js in the same folder. Once I run the js, I can see my User class printed out, with the values I created it with.

Hey there.

The difference between synchronous and asynchronous (sync vs async) is if tasks wait and are executed in a row or as they can be done.

Thats kind of confusing. So let’s think of an example, that I think everyone should be fairly familiar with - food.

Let’s have Chipotle represent an example of synchronous tasks. You stand in line behind other people waiting to get their food. When you get there, you perform a series of steps and you cannot jump ahead. You order burrito, bowl, or salad. Then rice. Then beans. Then meat. Then toppings. Then you can pay. If you get stuck behind someone ordering for their entire family it can be a slow and painful process, and you are stuck waiting for them to finish all of their tasks so you can begin yours. Ugh!

Let’s use a typical sit down restaurant as an example of asynchronous task. You go in and a waiter comes up to you. You can order appetizers or your meal. Maybe you want a salad, and your dining partner only wants an entree. Maybe you order a soft drink, while your dining partner orders something from the bar. The waiter can ask you if you want to wait for everything to be ready before delivering the food, but you don’t have to. You can have the food delivered to you as soon as it is ready. So you can get your salad before the entrees are delivered. You can get your soft drink before the bar makes the alcoholic beverage. Tasks are completed and results are delivered as they are ready. You don’t need to wait for everything to finish before having the end result.

So to go back to code - sync tasks are those that have to wait on preceding tasks before they can continue. Async tasks serve you the content as it is ready. In general, you want to design your code to be async as much as possible so it can be as fast as possible. Because as we saw at Chipotle, waiting for other things to finish just so you can take your turn is annoying.

Let me know if this helps, or if I should explain the code aspect further :)

EDIT

You know what, I do want to explain the code part of this just to show how it works.

So here we have a synchronous function

It executes three tasks in a row - print out before, the return value, and after.

If we write a similar function but put in a callback, we make it asynchronous.

but if I execute this, it is going to go really fast because it is a very simple function and the results will basically be the same

So I need to show the difference by “pretending” that getValue is some costly function -- maybe it makes a call to a DB and then runs some process on that data before it is ready to return. I am not going to write all that nonsense right now, but I can put a delay on the code returning.

Now that we are forcing getValue to wait a second before it returns, let’s see the order of the results we get.

As I was writing the post about array filtering, I felt like something was missing from the explanation, but I couldn’t figure out what. But I think I might understand the missing explanation - at least for someone like me who has a background with Object Oriented programming.

There is a fundamental difference between a strongly typed language (like Java) and a weakly typed language (like Javascript). And working with strongly typed languages can make it hard to switch to weaker typed. 

The difference can be seen when dealing with simple variables. The “strong typing” of Java says you have to tell the code what kind of data you are expecting -- a String or a Date. While in Javascript there is no typing in this way. You just say it is a var (variable), and give it a value. It can be hard to make this switch. I still find myself typing “int x = 0;” and I will get an error saying “whats this int thing?” so I have to change it to “var x = 0;”

Methods also differ. In Java, we have to give it a return type and optionally we can give it specific visibility. In Javascript, you just say “hey I have a function, it will give you something back, hope it is the right type. Good luck!”

And when you want to pass parameters into methods, in Java you tell it what type of data is allowed to be passed in. In Javascript, there is no typing, so you just say “hey, I am getting some data, so I will refer to it by this alias”. 

Hopefully seeing a side by side comparison helps see how doing basically the same thing in one language works in another, and helps anyone else doing the switch from OO to scripting understand the idiosyncrasies of js a little more.

Ok, I got a question about array filtering, which is in the javascripting module. We were able to talk it through and get it working, but not get to the “how” or “why”. I am not gonna lie, sometimes in programming you have to take some things on faith (”no idea how that worked, but it works, so let’s move on..”) but since this is a learning exercise, I want to try to explain it a little better.

First, let’s take a look at this exercise and the example they give.

The point of this is to introduce us to the .filter() method available on arrays. The documentation tells us the syntax for this method is this:

arr.filter(callback[, thisArg])

So we pass the filter method another method that will process “thisArg”. Your function will return a boolean, where ‘true’ will add the item to the return array, while a ‘false’ will leave the item out of the new array. This is how it “filters” out data.

And this can be kind of confusing. One of the questions I got yesterday was “where is the for loop?” and the answer is “within the filter function”. Basically, the filter function will run your callback function on each and every item in the array and remove the ones that don’t pass your filter function. 

Do we have to use .filter()? No. We can write our own loop to take care of the processing.

So here I have the same array of pets, and my new array that I will put the results in. Then I loop over the array and check to see if the item meets my success criteria. Only the items that match true will be placed into the filtered array. My return on this is

But we want to compact this, because maybe we want to filter out non-pets in other places. So we write a function that can be reused.

Here I moved the item !== ‘elephant’ into a different function called checkPet. And if I have other non-pets, I can add them to this one function and reuse it anywhere I want to weed out non-pets. 

But do I really need to write this for loop all the time? Nah. Because they created a utility method directly on the array called filter, which will do this looping for me. And I can reuse the checkPet() function if I would like.

Now you can see that I am passing in the function as a variable to checkPet, and the filter method itself is smart enough to pass in each individual value in the array as a parameter to check. It takes care of that looping for us.

Finally, I can compact it down even further (which is only a benefit if you never want to reuse this checkPet logic) into one filter call, where I create a function as I pass it in as a parameter.

When I run this, I get the same output as I did when I wrote my own for loop.

Ok, so before jumping into the NodeSchool module on Node, it is important to first understand what MongoDB is. Obviously, it is a database (the "DB" kind of gives that away). But it is different from Oracle, MySQL, SQL Server, etc. It is a non-relational, "NoSQL" solution instead of a traditional RDBMS (Relational Database Management System, often referred to just as "relational").

So what makes something relational vs non-relational? And what makes something SQL vs NoSQL? The answer to both of those are one in the same.

Hey there.

So I have tried to keep this blog free of any noise, so hopefully it is short enough that the easiest way to find the beginning is to keep scrolling until it starts :) But I want to take this opportunity to just recap what has been covered so far.

First there was the intro to NodeSchool and the first basic javascript workshop, javascripting. You can find it here.

Then there was a workshop on functional javascript, which introduces some important organizational concepts such as modules. You can find it here.

Then the last workshop I have done so far is the actual workshop for node, which hopefully feels mostly like a review of the first two, but adds on the fun of a JS-based HTTP server. You can find that here.

There have been two other posts along the way that might help if you get stuck.

One explores the “scopes” concept covered in the first javascripting workshop, which can be a tricky concept to grasp at first. I had to break it up into two posts because of images limits First one here. Second one here.

Then this one that covers process.argv[i], which is how one reads variables from the command line. I know the workshoppers sometimes give you the direction to use it, but I wanted you to see it in action and have a little more explanation. That one is here.

Ok, if you have played along so far, you should be in good shape for the workshop called learnyounode. In fact, lesson 1 and 2 should seem like simple review from the other workshops, and you won’t see anything even remotely new until lesson 3. 

On we go then, install the workshopper by running this:

npm install -g learnyounode

Once it is done, call the command learnyounode and get greeted with this screen.

Once you rip through lessons 1 and 2, you will notice that you cannot do lesson 3 without reading the documentation. This is great. Because reading documentation to figure out how to use modules is really important. The lesson will give you a link to the documentation. Follow it. Read the different ways to do things. And come up with your own.

The real fun kicks in around lesson 7 with HTTP. This is when you start to see the power of Node as a webserver. This is all still just an intro. After this, we will detour slightly to Mongo (gotta have a db) and then head into ExpressJS - the most popular Node server framework.

Before I get into the actual node workshopper, I wanted to cover something that will help you.

The node workshopper will ask you to take variables passed in as parameters and use them in some way. And the way we get these variables is by using process.argv.

So first, what is "process"? It is just a global object that you can use without including it in your file. If you remember a prior post, I made modules to include them in another files. But in order to use them, I had to include them in the file like this:

var greetings = require("./helloworld.js");

And this is true of any library that you want to include, be if your own module, or those that are already available to you for use (like http, path, etc - although the include syntax will be slightly different). But process is special, and doesn't need to be included in any way. It is just available, because it is part of the core framework.

And using it can be simple. You just need to understand how it works and where the parameters will come in. The simplest way is just to use it like this:

process.argv[i]  

where i is the index of the array you want to fetch. The 0 and 1 indexes will always be populated - the 0 index will always be the path to the node installation, while the 1 index will always be the path and filename of the file you are executing. Then the variables from the command line will start from the 2 index and continue on. Let's see it in action.

Ok, so this code is doing 2 things -- first, it is iterating through all of the params in process.argv to show everything it has (with the exception of full path and file, since I purposefully took that out). Then I am calling the variables independently to show how they would typically be called in an application if you were told "we will pass you xyz as the first parameter".

This is our output.