[JavaScript] Introduction to JavaScript

This is the second in a planned series of introductory articles on JavaScript. It is not an introduction to programming, but rather a quick crash course on what makes the language unique.

Tl;Dr Takeaways:

• JavaScript is a scripting language for the web, and more recently, the web server
• JavaScript is loosely typed, with one variable able to store many kinds of data over its lifetime
• JavaScript is prototypal, not classical, and handles object-oriented goals slightly differently
• JavaScript functions are first-class citizens, making JavaScript very expressive and unusual to read for programmers new to it

What is it?

JavaScript is a multi-paradigm interpreted language that is an implementation of the ECMA-262 standard for ECMAScript, currently in its fifth iteration. Because it was designed to be used primarily as a scripting language, it contains a high level of abstraction and no direct means of managing memory.

For example, having the JavaScript engine handle all the memory management means that we can do things with variables that would otherwise be more complex:

var a; // This line creates a variable "a"

a = "this variable now contains a string";
a = 12; // This variable now contains a number
a = function thisVariableNowContainsAFunction() {};

JavaScript has some other distinct differences from classical (or class-based) languages like C++ and Java. Because JavaScript is prototype-based, it handles the object-oriented concept of inheritance differently.

Rather than instantiating a class, of which instances may or may not already exist, each object in JavaScript must inherit directly from an existing object – which becomes the prototype it is cloned from. This will be covered in detail in a later post, but here’s a quick visual example:

var q,
    Obj1 = { ... }; // Object declaration syntax
                    // pseudocoded for brevity

    q = new Obj1(); // Clones Obj1

A second major difference is the inclusion of functions as first-class citizens of the language. First-class citizens are types that are able to be assigned into a variable, passed as a parameter to a function, and returned as the return value of a function.

As a result, it is very common to see function calls like this one:

var q = someFunction( "a string", function( booyah ) {
  if ( booyah ) {
    alert( "woo!" );
  }
});

At this point, most JavaScript n00bz have a similar, and quite confused reaction. If you look closely, the second parameter of the call to the function called someFunction is another function, complete with the function syntax you’ve already seen.

Why do we use it?

Originally, JavaScript was used entirely for client-side (read, web-page) based programming in Netscape and these days it basically is programming for the web. More recently though, other technologies have provided virtualized browser environments that run in other settings.

NodeJS is an excellent example, allowing server-side programming in JavaScript. Combined with how expressive the language is, it’s quickly become a favourite in the web development scene and is becoming a valuable skill.

Conclusion

I’m going to stop here. Next up will be a discussion of types, and what an object really is in JavaScript.

Please feel free to leave comments if you have questions or any feedback!

Welcome to Open Source Development! A Student’s Perspective

Hi!  If you’re like I was a couple of weeks ago, you have very little knowledge about, or experience with, how Open-Source development really works.

I mean, really works!

Even if you aren’t completely new to the concepts, you may find this blog helpful.  I’ll be overviewing the ideas behind the movement in this article, and as I post more about the workflow and tools needed to succeed in an open-source environment, you will find them linked in this paragraph and the following lists:

TL;DR

Open-Source development:

1. …relies on clear, effective (location agnostic; read digital) communication
2. …is iterative, preferring incremental improvement over initial polish
3. …directs conversations and meetings into the open, forcing individual accountability
4. …is decentralized, meaning we work with people all over the world! (see point 1)
5. …is distributed, meaning different people are working on different tiny parts of the same project all the time.
6. …is interconnected, meaning other people’s contributions directly affect what we are working on, sometimes on a minute-by-minute basis
7. …is inherently difficult, requiring a diverse interpersonal and technical skillset
8. …is inherently rewarding, giving us skills, experience and a portfolio you would never get elsewhere

Open-Source Development requires:

1. Excellent time management
2. Flexibility, for when requirements rapidly and successively change (and they will, even as you work)
3. Courage, to ask the questions you need answered to move forward
4. Focus, because there’s a lot to learn.
5. A suite of productivity tools, because we’re only human

Now for the full version:

Free as in freedom.  As in free speech. As in free hugs.  As in…

Open-source is really a philosophy first. And, as with any system built on a philosophy, it’s much easier to understand the system if you can wrap your head around the principals it rests on.  The core open-source principals seem to be expressed in slightly different terms depending on where you look.  I’ll be exploring them [DISCLAIMER: I don’t know it all!] on my own terms, and I think they boil down like this:

1. The Principle of Purpose (or, Community)
2. The Principle of Openness (or, Transparency)
   
3. The Principle of Contribution (or, Meritocracy)
4. The Principle of Participation (or, Collaboration)
5. The Principle of Iteration (or, Rapid Prototyping)

Each of these builds on the idea that came before it, and I’ll explore each of these in this post.  Remember that these are just my thoughts on the subject, so feel free to comment if you think I’ve overlooked (or misunderstood) something.

The Principle of Purpose (or, Community)

At its core, open-source is about achieving a goal together.  But in order for us to do it together, there has to be a goal we all can agree is worthwhile. This, in turn, leads to the initiatives that become open-source projects.  Each project’s goal resolves issues the community suffers from.  So, as common needs arise, the open-source response is: “Let’s fix the problem together, because together we can accomplish more!”

The Principle of Openness (or, Transparency)

Hand-in-hand with community driven action is the need for every member of that community to be able to understand everything about an open-source project if they have the time – from its deadlines, to the technology being used and even who is working on the project.  Without this level of transparency, people are unable to contribute fully because they end up missing information that, if they had possessed it, might have allowed them to contribute even more!

Openness leaves us vulnerable, with all of our mistakes and weaknesses on display for everyone involved to see. It demands a level of integrity and honesty that is difficult in modern life, but ultimately servers a greater purpose in a team.  After all, if everyone knows our weaknesses, they can then use us to our strengths.  (And accomplish more!  A pattern emerges…)

The Principle of Contribution (or, Meritocracy)

I mentioned integrity, and honesty, and strengths and weaknesses and all sorts of character traits.  I did this because, at its core, open-source only respects one thing: competency.  If you can do a job, that no one else can do, you should do it.  If you can’t do a job, then you should pass it on.  If you can but you need help, you should be honest about that, and see what people with more experience than you will suggest.  These are the common-sense consequences of focusing purely on the final result, and it tells us two things:

1. Honesty about your level of ability is never punished, and
2. Those that contribute to what needed to be done are the ones that get the credit and the responsibility.

Why those conclusions? The first one was described in the last principle but appears again because part of a meritocracy is sticking to your strengths (areas of competence).  This says nothing about our ability to learn new skills, but rather that if we can’t do the job, and someone else can, we should let them do it and be honest about it.  The second point is important, because it keeps our egos in check.

If you couldn’t/didn’t/wouldn’t contribute to something, your name simply will not be on it (credit) and you shouldn’t expect to be consulted about changes or congratulated on a job well done (responsibility).  The dark side is, those that do things have to clean up the messes they made if things go wrong.  But thats a topic that should be saved for the last point.

The Principle of Participation (or, Collaboration)

With all this talk about ability, and a brutal respect for competency, you might think that open-source development is elitist and exclusive – but you couldn’t be further from the truth.  The fact is, that when a group of people work towards a goal according to the last 3 principles, a fourth naturally emerges: that no one is without value, and without the ability to contribute.  In the end, there’s always something that can be done, no matter what your ability is.  If your motivation is to help and not to get bragging rights, then you’ll always be a valuable (and valued) member of any open-source community.

Let me give you an example:

A man wants to build himself a house.  He is very good at coming up with crafty ways of solving mechanical problems, and so has come up with a blueprint.  However, he is frail and unable to build any of it himself.  At the local church/community center, he asks for help on this project and receives a flood of support.  Before he knows it, he has 10 people ready to help him, all asking what they should be doing.

If it was your house, how would you decide on each person’s role in the process?  Chances are you would find out what everyone’s strengths and weaknesses were, and assign tasks from there.  The man is good with mechanical design, so he writes the plans.  The first volunteer is excellent at managing teams of people, so the man delegates this part of the job to her.  The second volunteer is burly and strong, but not too bright.  The man, being weak and frail, is relieved and assigns him the task of hauling all the lumber they’ll need.  Eventually, the 10th volunteer says,

“I’m not very good at anything sir, I just wanted to help :)”

Would the man turn them away?  Would you?

In open-source, at the end of the day, the job must get done! If the person organizing the volunteers also has to write the blueprints, or the person hauling lumber also has to chop trees, the task will take longer.  But for every person without a distinct strength, there is a job that will allow others to do the job only they can do.  And that’s the point.

The Principle of Iteration (or, Rapid Prototyping)

Finally, we come to the most concrete of the principles.  This one says that a job well done doesn’t need to be well done right now.  To go back to my previous analogy, if it’s the dead of winter, the volunteers won’t be so fussed about the colour of the veneer trimmings in the man’s new kitchen.  Better to get the house up!  And veneer is so last season anyway…

When contributing to an open-source project, goals must be small and time-oriented.  Read: Deadlines! Like it or not, they’re here to stay and, secretly, deadlines are your friends.  ESPECIALLY in open-source!

Why?  Because open-source contributors don’t ever care about making something polished the first time.  Just get it done on time!  If it works properly, and doesn’t sacrifice good code for quicker delivery, it doesn’t need to have all the bells and whistles.   In a sense, the iterative process is the most helpful restriction you’ll ever run across and can be compared to a similar time-management truism: The 80% rule.

The 80% rule says that, if you’ve done roughly 80% of the work, it’s time to move on to the next task.  Clearly this is a guideline, but the point is the same.  Too much time can be wasted chasing perfection.

Get it done!

Conclusion

This should be enough to chew on for now.  Keep in mind that open-source development is not a straight-line, and can be very demanding.  To that end, as I post more content, this article will be updated.