Categories

Author: Thomas

I’ve worked for many clients with many ideas of what makes a secure environment. Some use simple FTP servers, and some don’t trust anyone but their own employees. Others use multiple, nested levels of remote desktop connections, RSA tokens, and specialized software. But is there such a thing as too much security — so much that it actually becomes insecure?

Secure Password Requirements

To make a strong password, experts tell us it must include upper- and lower-case letters, numbers, and special characters. Remembering it will likely be difficult. Entering it will likely result in typos. If this is what you believe, you’re wrong, as illustrated by this popular XKCD comic.

Because many systems require these complex passwords, you need to write them down. If you’re a good developer, you use a secure password database. If not, maybe you just attach sticky notes to a monitor. The problem is that when remembering a password is hard, people often store it insecurely. All that complexity is worthless if someone accidentally sweeps that sticky note under the door and into someone else’s hands.

Many people use online password storage services, like LastPass. These services are convenient, but also problematic. It is increasingly common for online companies to announce that someone hacked their server and leaked passwords.

Avoid this by using long, memorable passwords. It’s much more secure in the long run.

Frequent Password Resets

Password complexity is bad enough, but businesses also require passwords to be reset far too often. When systems require frequent password resets, most users create easily guessable variants of a password. For example, MarchPass123$ is followed up next month by AprilPass123$. If someone finds those old passwords, then figuring out the current password requires little effort. Passwords shouldn’t last forever, but requiring users to change them frequently only results in more security holes.

File Transfer Restrictions

Another common security feature I’ve noticed is the disabling of copy/paste or file shares while remotely connected to a machine. Rarely do I work on a project that requires remote access where I don’t need to transfer some files or copy and paste a large chunk of code.

When these features are disabled, users find work-arounds — usually insecure work-arounds. Typing by hand is tedious and usually impractical. More likely, you’ll upload the files to an online service or save them to a USB stick. I’ve even seen cases where companies block access to sites like Google Drive and Dropbox, which forces users to find less reputable online services. As more security is added, systems often become less secure.

Two-factor Authentication

Security experts eventually realized that complicated, oft-updated passwords were not working, so their solution: make things even harder for users. That’s right, in addition to the password nightmare, many systems now require users to enter a string of digits from a key fob or piece of software that changes every minute or so.

How does this lead to insecurity? Well, I’ve actually seen people write their username and password onto the fob itself. In cases of RSA software apps, they keep a plain text file with all the information needed to access the system right on the desktop.

The point I want to make is that when you make security harder for the user, the user will make the system less secure. The answer isn’t to add more complexity, it’s to change the security. If the only barrier to entry is a simple fingerprint scan or an easily remembered password, then users have no need to make notes or to circumvent the system.

In case you weren’t aware, there has been a long-standing debate on the pronunciation of the GIF file format. The “G” is actually pronounced like the “g” in “giraffe.” But, most people read the word before hearing someone actually say it, and they assume it is pronounced like “gift.”

Being a nonconfrontational person, I generally avoid correcting others — although my wife would disagree — but I find it amusing when some people try to justify a flawed position. Here are some of the reasons I’ve come across for continuing to say GIF incorrectly and my rebuttals to those reasons.

If the creator wanted people to pronounce it like a “J”, he should have called it JIF.

The creator can name and pronounce it however he wants. If my name were Todd but it was spelled like Toad, people would still call me Todd, because they would respect my wishes (hopefully). The point is, when you create something — whether it be a child or a file format — you get to decide the spelling and pronunciation. That’s your privilege.

The “G” stands for graphics, so it should be a hard “G”.

Scuba stands for Self Contained Underwater Breathing Apparatus, so by your logic, it should be pronounced with a short “u”, as in “scrub,” because we say “underwater,” not “oonderwater.” Acronyms aren’t pronounced based on the words their letters represent.

Everyone else I’ve heard pronounces it with a hard “G”.

And everyone thought the sun orbited the earth for thousands of years. This is an appeal to popularity logical fallacy. To be honest, in the graphics and design industry, the “J” sound for GIF is more popular; it’s the common, layman pronunciation that gets it wrong. Unfortunately, commercial media isn’t helping, as seen in this ad by Kmart.

People were saying GIF with a hard “G” before the creator publicly corrected them. He should have said so sooner.

People don’t seem to understand that Steve Wilhite, GIF’s creator, has always pronounced it with a “J” sound and was known to often correct those that said it incorrectly. I suppose that the French also should have said that the correct pronunciation of the word “voilà” is not “wallah” before everyone started saying it. The truth is that the creator of the word doesn’t assume that everyone is going to get it wrong; therefore, there isn’t a need to make such public announcements.

I’ve always said it that way and I’m not going to stop now.

That’s your perogative. I would of spent more time on this rebuttal but, it’s a doggy dog world, and I imagine you’re the type of person that probaly makes all kinds of pronounciation faux pas. Irregardless, finish your expresso and go about your bidness.

Sadly, we live in a world where many people won’t get the irony in the previous three sentences.

Experis Web Framework 2, or EWF 2, is a front-end web development framework that provides organization and structure without adding a lot of file bloat. It makes use of many popular technologies, such as Compass and Sass, RequireJS, Grunt, and more. If you aren’t familiar with these useful tools, don’t worry – setup is simple, and before long, you’ll be wondering how you lived without them.

There are a myriad of things you can do with Node.js, but we’re going to use it primarily because it’s a prerequisite for using Grunt. Don’t let that stop you from learning more about it, though – if you’re a JavaScript app developer, Node.js is an essential tool.
Installation is easy. Just click the “Install” button on the home page. You can’t miss it. Run the installer when it finishes downloading, and keep clicking “Next” until you’re done.

You can’t talk about Compass without understanding Sass first. Sass is basically CSS on steroids. It allows you to make use of variables, nested CSS selectors, and programmatic features that save time and effort. But what’s really amazing is that you don’t need to know anything more than standard CSS to start using it. That’s right – just start writing plain, vanilla CSS, and start gradually mixing in some of the Sass extras as you learn them.

So, what exactly is Compass, then? Well, it’s basically a library of common Sass functions – sort of like how jQuery relates to JavaScript. For example, instead of writing your own Sass linear gradient function, you can rely on the linear-gradient() mixin that Compass provides (a mixin outputs CSS when called). In case you’re wondering, the linear-gradient() mixin allows you to easily specify the conditions of a background gradient. The browser-specific vendor prefixes and syntax differences will be taken care of automatically.

Compass installation relies on the command line, but it’s only a couple lines of typing. On Windows, press the Windows key on your keyboard and the letter R. Then type “cmd” (without quotes) and press Enter. This will open the command prompt. You can use the Terminal application on OS X and Linux or other similar command line applications.

Next we need to make sure your Ruby gems are up to date. A gem is an application written in Ruby. By telling Ruby to update its gems, we can be sure we’re getting the latest version of Compass. Type the following and press Enter.

gem update --system

After a short while, the update should complete. To install Compass, type:

gem install compass

Hopefully, there weren’t any issues, and you’re good to go.

That’s it! No more software required. But… You should also consider installing LiveReload.

LiveReload makes it possible to write code and have it immediately update in your browser without the need to refresh. This is really amazing when used with Sass, RequireJS, and Grunt.

Downloading EWF 2

The framework files can be downloaded from GitHub at https://github.com/thomashigginbotham/ExperisWebFramework2. If you aren’t familiar with Git, feel free to click the “Download ZIP” button on the page for a simple ZIP file. The advantage to using Git is that you can easily pull in the latest updates and even contribute to EWF 2 if you so desire.

Either way you go about getting the files is fine. Just remember to unzip the files if you went that route. Now, open the folder in your editor of choice, and let’s take a look at what we have available.

About the File Structure

You’ll notice that there are two top level directories (javascripts and stylesheets) and some other files. Here’s a quick overview of the files in the root directory.

.gitattributes and .gitignore: These files are specific to Git and can be ignored or deleted if you aren’t interested in contributing to EWF 2.

Gruntfile.js: This file is used by Grunt to tell it what tasks it needs to run. We’ll talk more about Grunt later.

index.htm: EWF 2 includes this starter HTML page. Modify it to meet your needs when you’re ready to start.

package.json: Grunt uses this to tell it what packages it will need to download.

readme.htm: Here we have a quick tutorial as well as a self-serving example of something built with EWF 2. If you open it now, you’ll notice that there isn’t a CSS file for it to use. We need to compile the Sass first.

README.md: This file is a basic readme file in Markdown format. It is used by GitHub for a description. Go ahead and delete it.

If you open the javascript and stylesheets directories, you’ll see that they have a specific structure. Style sheets are organized into modules (Sass files that are used by other files, but don’t output anything on their own), partials (Sass files that make up the various pieces of your website), and vendor (third-party style sheets).

The javascripts directory has an app subdirectory (for JavaScript files specific to your website only) and a lib subdirectory (for third-party or reusable libraries and plugins).

While this is the recommended directory structure for working with EWF 2, you may change it to your liking, moving or deleting files as you find necessary. If you aren’t familiar with Compass and RequireJS, you should probably keep the files as they are, since the configuration for these technologies is tied to the directory structure.

Compiling CSS and JavaScript

As you should be aware, it is best practice to minify and combine your CSS and JS files. Unfortunately, this process takes time and has to be done every time you make an update. If you’ve worked with Compass before, you’re familiar with the compass watch command, which tells Compass to look for changes to your Sass files while you update them. And if you’re familiar with RequireJS, you may have used the r.js optimizer. There are many other tools – such as image optimizers and sprite generators – that are essential to building great websites, but they add time and complexity.

Fortunately, Grunt makes it possible to run all of these tools at one time, and only when they need to run. So if I make a Sass update, Compass will compile the CSS, and if I update one of my jQuery plugins, the RequireJS optimizer will kick in and generate a minified JS file. Additionally, if I’m using the LiveReload browser plugin, my browser will automatically refresh as I make these changes, showing my updates as I make them.

So how does all this magic happen? It only takes a few simple commands. Open your command prompt, and navigate to your project’s root directory. This is done with a command such as the following.

cd path/to/my-project

Now, run the following command to download all the packages we’ll be using:

npm install

The previous command reads your packages.json file and pulls in all the other files that you need for Grunt to work correctly. When it’s done, you need to install the Grunt CLI (Command Line Interface). You can do that with one more command:

npm install -g grunt-cli

That’s all. Now we can use Grunt to automate our tasks for us. Let’s start by compiling the CSS and JS that we need to view the readme.htm file in our browser. Run the following command:

grunt

When finished, you should get a “Done, without errors” message. Now open the readme.htm file in your browser. It should now appear as expected.

Working with EWF 2 in Real Time

We’ve seen how we can use the grunt command to compile our CSS and JS in one step, but it would be even better if Grunt automatically ran when we updated our files. If you look at the bottom of the Gruntfile.js file in the root directory, you’ll see three grunt.registerTask() calls. These are profiles that can be used to run certain tasks. The first profile, “default,” is the one used when we use the grunt command by itself. As you can see, it runs compass:dev and requirejs. Further up in the file, you can see the settings associated with these tasks.

Let’s run the “server” profile, which makes use of the “watch” and “connect” packages. The “watch” package causes Grunt to continue running and watches for file changes. The “connect” package creates a very basic web server for us so that we can take advantage of things like paths that don’t work well on file systems or Selectivizr, a script that allows older versions of Internet Explorer to use CSS 3 selectors. To start this profile, type the following in your command prompt:

grunt server

When it finishes compiling the CSS/JS and starts up the web server, it should say, “Waiting…” In the “connect” settings, we’re using port 9001, but you can change it to whatever you want. Open the index.htm file in your browser, but do it by navigating to http://localhost:9001/index.htm. If that doesn’t work, try http://127.0.0.1:9001/index.htm.

If you have the LiveReload plugin installed in your browser, go ahead and activate it. If you didn’t install it, you’ll still need to refresh your browser after making updates. Go ahead and make some updates in the index.htm file, Sass files, and JS files. Notice that after saving your changes, Grunt will automatically detect the changes and run the appropriate tasks.

When you’re finished, press Ctrl+C in the command prompt. Then press Y and Enter to confirm that you want to quit.

Conclusion

I hope that this was useful to you and that you’ve found a new, convenient way to work on front-end Web projects. As this was a “getting started” tutorial, I didn’t go in depth with my descriptions of the technologies, but please post in the comments if you have any questions or issues that you ran into.

We only scratched the surface of what you can do with EWF 2, and I plan on creating more tutorials to showcase some of its incredible features.