If you didn’t see my numerous tweets about my awesome plugin, I wanted to write briefly about it here.

Why am I so excited about my plugin, Better Alert? Well it is the first plugin I’ve written. But also I really like the way it’s written. (I might be a little biased.)

It’s 15 short lines of JavaScript code, along with a little bit of CSS for styling. Let’s take a quick look to see what makes this so awesome.

exports.module = function betterAlert(text) {
  var alertDOM = document.createElement("div");
  document.body.appendChild(alertDOM);
  alertDOM.classList.add('alert');
  var contents = document.createElement("div");
  alertDOM.appendChild(contents);
  contents.classList.add('container');
  contents.innerHTML = "<h2 class=\"text\">" + text + "</h2>" +  "<button class=\"btn-primary ok-btn\" id=\"js-disableAlert\" type=\"submit\">OK</button>";
  var disable = document.getElementById('js-disableAlert');
  function removeAlert() {
    disable.removeEventListener('click', removeAlert, false);
    document.body.removeChild(alertDOM);
  }
  disable.addEventListener('click', removeAlert, false);
}

Firstly, I’ve written it in vanilla JavaScript – meaning you don’t need any specific libraries to run it. Just this code and the corresponding CSS.

I’ve attached everything to the body tag, so it doesn’t require any special syntax or corresponding tags. All of the required elements are generated from the module itself.

The module doesn’t add anything to your HTML unless you specifically call it, so it’s pretty lightweight. Also each of the elements have their own classes, so styling them to match your stuff is pretty easy.

Once your user clicks ‘OK’, all of the elements are destroyed, keeping your HTML from growing needlessly.

Now that my humble-bragging is all over, please let me know what you think!

You can see the repo here and a demo here.

Also I want to thank Devin Clark for his advice on this. Thank you, sir!

Questions? Tweet me!

Why would a JavaScript developer need to know about databases? Well, unless you are just creating static websites, you need to be able to access, manipulate, and edit data. So knowing a little about databases will come in real handy.

I’ll just go ahead and say right now, I’m focusing on SQL (structured query language). SQL and similar languages are used to interact with databases, which is why you’ll hear terms like “SQL-database.” SQL itself, however, is not a database.

I chose to focus on this language because it is very common and the concepts of it will carry over to different databases like MySQL or Postgres. If you’re interested in different types of databases, check out Seven Databases in Seven Weeks.

But, if you’re just interested in enough to get you started on an SQL-like language, you’ve come to the right place.

OK, so what will I use this for?

Let’s say you’ve been tasked with creating a computer system to track who all is onboard the new Death Star. Darth Vader has tasked you with doing this because he force-choked your boss – the guy who miscalculated the shields and left a small exhaust port vulnerable. You’ve been given a list of everyone who is allowed on the Death Star, and you need to devise a system that will check if someone is allowed on board or not. If they are allowed, they’ll be able to come on to the ship. If not – they’ll be blasted.

You want to do a good job for Vader so he doesn’t force-choke you. So you decide the first thing you need to do is put this whole list into a database. This allows you to easily update who is and isn’t allowed on board.

So, let’s create a database for this.

This can be done a few ways. If you are using a GUI tool, like Sequel Pro, there will be options in the menu that allow you to add a database. Most of what is covered here can be done through the GUI tool, but the commands listed below can be used in the command line once you’ve connected to your database server.

There will be times you’ll need to use these types of queries in your JavaScript code to test against items in the database, as well as edit and add items to the database, so it’s good to remember these commands for later.

create database death_star_personnel

Once you’ve created your database, you’ll need to connect to it. Once you’ve connected to your database, you’ll want to start with a table. Let’s build a table for all of the stormtroopers based onboard the Death Star.

create table stormtrooper(id integer, name text,
can_aim boolean default(false), is_alive boolean default(true));

Let’s look at a few things a little bit more closely. Notice the can_aim and is_alive columns are booleans, and to make things easier, I set defaults on them. Initially all stormtroopers are terrible aims, and they all start out alive. This way, I don’t have to type that every time.

But our database doesn’t do us much good without some data in it. Let’s go ahead and add some.

insert into stormtrooper (id, name)
values (1, 'bobby trooper'), (2, 'sally trooper'),
(3, 'tommy trooper'), (4, 'anita trooper'),
(5, 'edgar trooper'), (6, 'cathy trooper');

Oh no! You forgot to add the is_allowed column, to make sure people on the list are allowed on board. Better do that before Vader notices and force-chokes you.

alter table stormtrooper add column
is_allowed boolean default(true);

Now let’s take a look at what all you’ve done.

SELECT * from stormtrooper;

Look what all you’ve accomplished so far! You tell Vader how it’s going, and I’ll start on the next blog post. Good luck!

Note: Many thanks to Rob Sullivan, database extraordinare! Rob was so helpful with checking over this and helping me make sure these queries were exactly right. Thank you, sir!

Questions? Tweet me!

There’s nothing particularly flashy about standing in front of a whiteboard and planning out a program. It isn’t really fun. It’s way more fun to dive in and just start coding. But diving in can lead to unexpected problems – especially for someone without much programming experience. Without some planning at the beginning, it’s easy to get lost in the details. It’s harder to step back and define what you should be doing and, perhaps more importantly, how you should be doing it.

So even though it isn’t a flashy or fun topic, I wanted to right up a post and go over what planning out a program should look like. Here I am listing my steps to planning out a program. Keep in mind, these are official. I’ve linked to a few more ‘official’ links from universities at the bottom of this post. But like many strong opinions you’ll find regarding programming, this is only my opinion. If there’s a way that works better for you and allows you to complete your program faster and/or better – please, do it that way! (Also, write a blog post on it and send it to me.)

1. What problem are you trying to solve?

All programs come from a similar place – trying simplify something or solve a problem. If you don’t have a good idea of the problem you are trying to solve, you probably aren’t going to get very far. If you’re trying to solve a very complex problem, I recommend breaking it down into multiple smaller problems. This will make it easier to program in little chunks which is not as overwhelming as building an entire program.

2. How are you going to solve this problem?

I am a big proponent of sketching this part out. I’m very visual, so if I can see how it’s going to work, that really helps me. Basically at this point, I like to break down what should happen once the program is opened. I’ll use a game as an example of planning.

Let’s say that I’m tired of all these guys trying to date my sister. Because I am not prone to violence, I decide to make them a video game instead, in hopes of scaring them off. (I am actually working on something like this, and if you’d like to laugh at my first attempt, you can see that here.)

User plays game as me -->
  a guy tries to take my sister out on a date -->
    player uses the arrow keys to navigate to the guy -->
      player uses arrow keys and spacebar to beat guy up -->
        repeat until game ends

The important thing to notice here is that I have planned out the general idea of the program, from start to finish. I could also focus on each action and break that down into a plan as well, but for the sake of time, I’ll leave that out of this.

3. Special considerations

I am hesitant to give this one a number, because you should really keep considerations at the back of your mind for the duration of your project. Considerations include your user base, and which machine they will use to access this. Which browser will they use? What are their technical abilities? These are not things you want to consider when you’ve completed the program. Consider these at the beginning and allow them to guide development. After all, what good is a piece of software that your target users cannot use?

4. Build it!

This part should be pretty self-explanatory.

5. Testing 1..2..3..

I personally do not wait until the end to test my code. I am testing it as I add new features and functionality. I also test at the end to make sure everything works as it should. But that is more for polishing purposes. The ideal situation here is to have tested and planned thoroughly enough so that I am not stumbling across any major functionality issues at this point. I might notice one or two things, but they should be very minor.

6. Show off your code!

Put it on GitHub. Blog about it. Tell everyone!

Additional reading:

• The Programming Process

• Suggestions for writing computer programs

Questions? Tweet me!

So what’s up with hoisting exactly? Well hoisting is when JavaScript takes your declaration and moves it to the very top. This is what would allow you to use call a function before you’ve actually written the function.

shakespeare(); // Though she be but little, she is fierce.

function shakespeare(){
  console.log("Though she be but little, she is fierce.");
}

The code above will go ahead and run the shakespeare function, even though the function is defined below. This is because the defined function is hoisted to the top.

var play = "A Midsummer Night's Dream";
play = "Antony and Cleopatra";
play = "Richard III";

console.log(play); // Richard III

Another effect of hoisting is seen above. When you have one variable defined, and redefined multiple times, JavaScript will assign the last definition it finds.

Perhaps you are wondering why you might assign different definitions to the same variable like that. Let’s take a look at another example.

var backStabber = "Cassius";

function stabCaesar() {
  var backStabber = "Brutus";  
  console.log("Et tu," + backStabber + "?");
}

stabCaesar(); // Et tu, Brutus?
console.log(backStabber); // Cassius

In the above example, we have Cassius as one of Caesar’s assassins. While this is correct, in the play Caesar doesn’t say, “Et tu, Cassius?” So I went into the function and assigned “Brutus” to the backStabber variable. This way the quote is correct.

But here is where things get interesting. When I log out backStabber outside of the function, it is still equal to Cassius. I showed you in the example above that if a variable is changed, JavaScript will assign the last definition to the variable. So in this case, it would seem that backStabber should be equal to Brutus, right?

Well not quite. See what I did differently here was two-fold. First, I put Brutus in the stabCaesar function. Next, I used var for a second time when I was defining backStabber. This scopes var backStabber = "Brutus"; to the stabCaesar function. Because this is a local variable, it doesn’t affect the global backStabber variable at all.

This would change if I decided not to use var a second time, or if I moved the contents of stabCaesar outside of the function.

Hoisting can do some tricky things if you don’t know what you are looking for. Some things to remember:

1. Declared variables and functions get hoisted to the top, and are available for use even before they have been technically defined.

2. JavaScript assigns the last definition it finds to a variable that has been defined more than once.

3. Scope can affect the way hoisting plays out if the variable is redefined inside of a function using var.

There are ways to avoid hoisting pitfalls. Namely, be aware of hoisting.

When creating variables in a function, use var to scope them to that function, or leave off var if you are manipulating a global variable that has already been defined. Use unique variable names, and be wary when redefining your variable. This can have unintended consequences.

TL;DR

Hoisting can be confusing, but as long as you are careful in naming your variables, and scoping them to functions properly, you can avoid most issues.

Recently I stumbled across an awesome new learning tool, Appcamp.

Appcamp teaches the basics of Angular and Ionic, so that you can use what you know about JavaScript to build mobile apps. If you didn’t already know, I really love Ionic. My project, TwisterJS is built using Angular and Ionic.

Appcamp has four courses: ‘The Basics’, ‘Angular’, ‘User Interface’, and ‘Networking’. I wouldn’t recommend getting started on Appcamp without a firm JavaScript foundation. I would say finish Codecademy’s JavaScript and Angular courses first. (Those can be found here and here.)

‘The Basics’ is pretty simple. It just gets you started on the HTML you’ll need to use building Ionic apps. ‘Angular’ is very similar. It gets you started on Angular concepts, like scope and passing data.

‘User Interface’ is where things start to get really fun. This starts introducing Ionic’s directives, which allow you to create lists, buttons, side menus, popups and so much more. This is where the real meat of your app is going to be. The other two courses are really important, but up to now they are just laying foundation.

And lastly, there is the ‘Networking’ course. It’s the shortest course, but don’t think that means it’s the least important. This course goes over pulling data from an API, and writing data to JSON. This is going to be so important if your app saves any information, or updates any type of information. Think about the Facebook app updating in real time, and the user being able to upload a photo and see it not only on the app, but on the computer as well – instantly.

This is where the ‘Networking’ course will come in handy.

Appcamp is a really great jumping off point, but it is no substitute for practice. Definitely a good place to start before building your first Ionic app, though. I wish I had started off on a tutorial like this before building TwisterJS!

Personally, I would like to see a references section on Appcamp, for newer coders who need to learn more about HTML and JavaScript before jumping into something like this.

If you are getting started on Appcamp, be careful in the ‘Angular’ course. Their courses use chaining on services and controllers, as opposed to just attaching these to an app variable. If you are used to chaining, you’ll be fine. But if you’re used to attaching controllers to your app variable, this might be confusing for you.

Using chains

angular.module('app', ['ionic'])

.controller('Page1Ctrl', function($scope, $state, formData) {
  $scope.user = {};
  $scope.submitForm = function(user) {
    if (user.firstName && user.lastName && user.comments) {
      console.log("Submitting Form", user);
      formData.updateForm(user);
      console.log("Retrieving form from service", formData.getForm());
      $state.go('page2');
    } else {
      alert("Please fill out some information for the user");
    }
  };
})

Using a variable

var app = angular.module('app', ['ionic']);

app.controller('Page1Ctrl', function($scope, $state, formData) {
  $scope.user = {};
  $scope.submitForm = function(user) {
    if (user.firstName && user.lastName && user.comments) {
      console.log("Submitting Form", user);
      formData.updateForm(user);
      console.log("Retrieving form from service", formData.getForm());
      $state.go('page2');
    } else {
      alert("Please fill out some information for the user");
    }
  };
});

If you aren’t used to chaining, this can definitely throw you off. It certainly confused me at first. But once I got the hang of it, I did just fine.

The important thing to watch here is your semicolon. When you use chaining, you’ll only have one semicolon at the very end, as opposed to when you use a variable and each controller ends with a semicolon.

If you have a stray semicolon in your chained version, things will break. (You can take my word for it!)

Overall, I am really happy with Appcamp, and I hope you enjoy it too!

For more info on chaining vs. variables, check out this very informative blog post.

Questions? Tweet me!