Resource Roundup – Week of 1/4

This is just a dumping ground for articles/books/tools that stuck out to me over the last week.

Most of the articles I read come from some excellent newsletter sources: Javascript Weekly, HTML5 Weekly, Ruby Weekly, Node Weekly, Database Weekly, and the Code Project Newsletter. Books are from a variety of sources, including Achieve Your Goals podcast, Entrepreneur on Fire and the Ameer Rosic Show (among many others and random internet discoveries).

Busy week – so I did a little less reading than usual. I’m also finally reading “Think and Grow Rich” by Napoleon Hill so that should have some notes in an upcoming week.

Articles

http://blog.phusion.nl/2014/12/22/phusion-passenger-5-beta-2

Beta 2 release of Phusion Passenger 5 (previously called “Raptor”). If their speed claims are really accurate, the RC and 1.0 releases could be game changers for some apps. I tried it out and hit issues with beta 1, so I may wait until an RC is available to try again.

Read More

The impact of Strict Mode on “this” in Javascript

Last week in my post The context of “this” in Javascript, I gave an example to test the readers understanding of the topic:

In evaluating my post I realized a few things about that example. One, that it doesn’t work when in Strict Mode. Two, that there are impacts of Strict Mode which never occurred to me. Three, I probably shouldn’t encourage naming variables global.

Strict Mode

I write all my Javascript in Strict Mode because it helps to keep your code from falling into some common pitfalls, removes some of the bad parts of Javascript, and better reflects the way Javascript should/will work in future releases.

An example of imposing Strict Mode on your code is as follows:

In that example, variableWithoutVar is having a value set to it before being defined. This is invalid, and without Strict Mode can result in surprising behavior (variables getting attached to the global object). Check out the Mozilla Developer Network article for many other areas that Strict Mode affects.

Strict Mode and this

What didn’t occur to me when writing my example, is that with Strict Mode enabled this changed in the browser. My example breaks.

When I applied Strict Mode to my example, the this reference I was using in globalExample is now undefined. There are a couple reasons why this behavior makes sense.

First, it forces the developer to code their functions more intentionally. When you want an object context for a function, specify it. Javascript makes this easy to do, and it would be very rare that you’d even attempt the example I made (I only realized the possible error of it now, after writing in Strict Mode for years). You get it supplied for you when defining a method on an object, or when specifying an object when using call or apply.

Second, it removes best intentioned behavior only useful to beginners. According to the Mozilla Developer Network reference, the value passed as this was being coerced into an object (so this became a reference to the global object). Behaviors like this are often in languages to help beginners deal with unexpected behavior. “What if the user doesn’t know to perform a particular behavior? We’ll default it for them”. Making these kind of decisions often result in unexpected and insecure consequences, and other languages have had to deal with the repercussions of their helpfulness as well (see PHP’s magic quotes for example).

Sorry beginners

The only downside I see to the change in behavior is probably the reason it worked the way it did before Strict Mode. The way it now works is a little confusing to a new Javascript user.

I can set this properties at the root global scope, either by defining a variable

Or by setting it as a property of this.

But when in a function call, I can’t use it.

But then I can use it if I remove this

So is it a closure? Is it implicitly rewriting the definition to use the global object? Truthfully, I don’t know the specifics of that answer (but if you know how the js engine interprets it, please comment!). What I know is that it’s the unfortunate quirky looking consequence of introducing a more stable behavior into the language.

An aside about global as a variable name

In my example, I used global as a variable name to express the nature of the variable. It was being used globally, and was defined in multiple contexts with different values.

It was an unfortunate choice if you were to try that example in node.js, because it would overwrite the node.js reference to the global object. In the browser, window references the global object. In node.js, global does. So while global is a valid variable identifier, avoiding its use could probably be considered a best practice (at least when making Javascript examples).

For more on the global object, you can read about it in Speaking JS.

Conclusion

When writing Javascript, whether it’s production code, a toy example or application, or just writing a snippet in a blog post, there’s no practical reason not to write your code in Strict Mode. It’s the way Javascript should be written moving forward so all examples should comply with it.

Do you write all your code in Strict Mode? Feel there’s a reason not to? I’m happy to debate the topic if you want to post a comment!

Resource Roundup – Week of 12/28

This is just a dumping ground for articles/books/tools that stuck out to me over the last week.

Most of the articles I read come from some excellent newsletter sources: Javascript Weekly, HTML5 Weekly, Ruby Weekly, Node Weekly, Database Weekly, and the Code Project Newsletter. Books are from a variety of sources, including Achieve Your Goals podcast, Entrepreneur on Fire and the Ameer Rosic Show (among many others and random internet discoveries).

Articles

http://www.vanseodesign.com/web-design/html5-structural-elements

This is exactly how I feel about HTML5 elements. I’ve been reading about the benefits of a semantic web for years, but when will we actually see it being used consistently or being truly embraced by big players.

Read More

The context of “this” in Javascript

Understanding the different contexts of this in Javascript is an important step towards truly understanding the language. In addition to its importance, it’s also something that has been written about to death.

If you’re using Javascript, and don’t fully understand how the this keyword in javascript works, here are some great articles that will give you the understanding you need.

this Resources

A brief overview of different “this” scenarios, from a good general Javascript overview called “Javascript Garden”

http://bonsaiden.github.io/JavaScript-Garden/#function.this

A longer, but still higher level overview

http://davidshariff.com/blog/javascript-this-keyword/

Another long-form explanation, with some additional technical detail

http://unschooled.org/2012/03/understanding-javascript-this/

And a step by step, in-depth article

http://www.2ality.com/2014/05/this.html

Checking your understanding

If you think you understand this, make sure you understand why each of the following work the way they do. If the examples make sense, you probably have a pretty decent understanding! If after those articles you still don’t fully understand, leave a comment or contact me for more explanation.

Knowledge Roundup – Week of 12/21

This is just a dumping ground for articles/books/tools that stuck out to me over the last week.

Most of the articles I read come from some excellent newsletter sources: Javascript Weekly, HTML5 Weekly, Ruby Weekly, Node Weekly, Database Weekly, and the Code Project Newsletter. Books are from a variety of sources, including Achieve Your Goals podcast, Entrepreneur on Fire and the Ameer Rosic Show (among many others and random internet discoveries).

Articles

Nasa Wants to Colonize Venus

I feel like i’ve read and listened to this topic a few times recently – but this is the first i’ve heard of NASA talking about it. Not just talking about it – but having a pretty established plan for how they will do it, and what it means. It’s exciting that these endeavors could bear fruit in our lifetime.

Read More

Prototyping quickly with the PHP built-in server

Sometimes you want to get a server up and running as quickly as humanly possible. Whether it’s trying out a js library where the demos only work with a server, developing a static front-end (stand-alone or for integration with an API) or getting a PHP app up and running without setting up apache or nginx – being able to quickly start a local server is a nice convenience. Here’s one of my goto approaches for getting up and running quickly.

PHP Built-in Server

Since the release and general use/availability of PHP 5.4, there’s been a built-in PHP server available from the PHP CLI. To run it, from the terminal/command line all you need to type is

and boom, you’re done! You can now access anything in that directory or subdirectories as you would from a normal web server. Naturally, getting to this point has two main pre-requisites – your PHP version must be 5.4+ (php -v), and PHP must be on your path.

Command Explained

Breaking it down, this is taking advantage of the (very not-production ready) built-in server that PHP 5.4+ offers. If you were to type

in the terminal, one of the instructions provided would be

This specifies the structure of starting the built-in PHP web server. In reference to our example: the -S specifies that you’re trying to start the built-in server, localhost is the address and 8000 is the port. We’re not using the -t docroot option here, but when specified you could use it to create a routing script (for more information on that, see the PHP docs here).

Accessing the server remotely

If you want to access the web server from a remote machine (useful for trying it on your phone, or letting other people on your network access it using your IP), you can specify the address as 0.0.0.0 instead of localhost. For example

More Examples

For more one-line server starters, there’s a helpful Github gist here. It doesn’t provide any specifics or explanations of the examples, but it gives examples in multiple languages including node.js, ruby, and python.

Knowledge Roundup: Week of 12/14

This is just a dumping ground for articles/books/tools that stuck out to me over the last week.

Most of the articles I read come from some excellent newsletter sources: Javascript Weekly, HTML5 Weekly, Ruby Weekly, Node Weekly, Database Weekly, and the Code Project Newsletter. Books are from a variety of sources, including Achieve Your Goals podcast, Entrepreneur on Fire and the Ameer Rosic Show (among many others and random internet discoveries).

Articles

http://arstechnica.com/security/2014/12/critical-git-bug-allows-malicious-code-execution-on-client-machines/

The official git clients for Mac and Windows are vulnerable to an attack. Time to update. If you’re using homebrew, this article will help – http://artarmstrong.com/blog/2014/12/18/install-and-update-to-git-2-2-1-on-mac-osx-10-10-yosemite-using-homebrew/

Read More

Previewing your Github README

grip-example

When you’re deploying to Github, crafting a helpful and well-formatted README file is a great starting point for people interested in your project. There are lots of Markdown preview tools available (just check for plugins or bundles in your favorite editor/IDE, or an online tool like http://markable.in/editor/), but Github does things a little differently with their Markdown flavor and it can be difficult to get it the way you want it without pushing to Github and seeing what needs to be changed.

That’s where i’ve found a tool called grip to be really helpful. From their documentation, it is a “command-line server application written in Python that uses the Github Markdown API to render a local readme file”.

To install Grip you first need a python package manager called pip. If you are on Mac OS X or Linux, you probably already have Python installed and pip should be available. If on windows, you’ll need to install Python. If you’re having trouble getting setup, try the installation instructions here.

Once you have pip, it’s as simple as pip install grip.

Now that you have it installed, simply run grip in the same folder as your README and it’ll be served up and available in your browser. The default is http://localhost:5000. Now enjoy previewing your Github Markdown before pushing to the repo!