    
|
|
|
|
|
|
|
As the browser has evolved the possibilities of what can be achieved on the web have greatly increased. Technologies like Flash have given way to newcomers like Canvas and WebGL. But as we create more complex applications for the web we also need to be mindful of performance. To provide truly engaging experiences our applications need to run smoothly, which means there’s a lot of testing to do during development.
In this blog post you’re going to learn how to test the performance of your applications using high resolution timestamps.
Unlike regular timestamps created with Date.now(), a high resolution timestamp is precise to a thousandth of a millisecond. Having this level of precision can be very useful when testing code that needs to run really fast. If you’ve ever developed games or animations you might understand just how useful this can be.
Note: If you read my previous post on requestAnimationFrame you may remember that all of the code used to draw a single frame needs to be executed within 16.67 milliseconds.
To generate a high resolution timestamp (DOMHighResTimeStamp) you use the now method that is available on the performance object.
performance.now()
Example result: 5081.6239999985555This performance object also includes other data that can be useful for testing, including a PerformanceTiming object that is accessible via performance.timing.
The performance Object
The PerformanceTiming object contains a property called navigationStart. The value of this property is a regular timestamp that represents when the browser started to load the page. The timestamps in the PerformanceTiming object are relative to the Unix epoch, however high resolution timestamps are not. Instead these timestamps are measured relative to the value of performance.timing.navigationStart.
Date.now() // 1387445119319
performance.now() // 7865.671999999904Note: Measuring relative to navigationStart is more than adequate for performance testing as your app doesn’t need to know how many milliseconds have passed since the Unix epoch. As long as all your measurements are taken relative to the same point, the results will be accurate.
Timing how long it takes for your code to execute is fairly straightforward. You need to create a variable before and after the piece of code you wish to test, and populate those variables with the value returned by performance.now(). Subtracting the first variable from the second variable will then give you the amount of time that your code took to execute.
The code below shows a simple example of how to do this.
// Take a timestamp at the beginning.
var start = performance.now();
// Execute the code being timed.
doTasks();
// Take a final timestamp.
var end = performance.now();
// Calculate the time taken and output the result in the console
console.log('doTasks took ' + (end - start) + ' milliseconds to execute.');Browser support for performance.now() is reasonably good among modern browsers, with Safari being the only exception. Paul Irish has put together a polyfill that imitates the behaviour of performance.now(). Be sure to read the comment at the top of the file if you intend to use it in your own projects.
| IE | Firefox | Chrome | Safari | Opera |
|---|---|---|---|---|
| 10+ | 15.0+ | 20.0+ | - | 15+ |
In this blog post you have learned how to use performance.now() to obtain high resolution timestamps, and how these can be used to test the performance of your code.
High resolution timestamps enable a new level of precision when testing the performance of JavaScript code. That’s not to say that regular timestamps are now obsolete. For a lot of applications a regular timestamp will do just fine. However, for those that work in environments that demand lightning fast code execution this new level of accuracy is incredibly useful.
The post Timing JavaScript Code with High Resolution Timestamps appeared first on Treehouse Blog.
]]>
The Internet has allowed us to work anywhere we want, giving us tremendous flexibility in choosing where we’d like to plant ourselves to build the next great app. Not being tied to an office desk has been a blessing to many who cherish the ability to work in varying environments and draw inspiration from their surroundings. But for the most part, we’ve needed to have a full-blown development machine to make this happen. What if we could leverage the cloud as a development environment itself, freeing us up to choose from a variety of devices to accomplish the same thing. That’s what we’ll explore in this article.
As I mentioned, until now, whether you were in an office or sitting at a coffee shop, you generally needed a development machine (a MacBook, Windows, or Linux laptop in most cases) which may have the following things:
And countless other tools that you rely on to get your work done. This typically requires that you have a beefy machine to work with so you can power all of these tools and be productive.
But with broadband becoming more prevalent, the requirements for having such a powerful device are becoming less stringent due to the number of cloud offerings available to developers. Services like Cloud9 IDE and Nitrous.io are bringing real-world development environments to the cloud and allowing developers to work remotely and offering more flexibility in terms of the devices they choose to work with.
These services not only bring IDEs to the web, they also provide infrastructure that gives developers:
Basically, these services are adding in the kitchen sink, making the move to the cloud much easier and enticing. Let’s explore these a little more.
My first exposure to a real cloud-based IDE was Cloud9. They had a very basic online editor with Github integration which was very cool and obviously very alpha at the time. Nonetheless, it was incredibly promising and along with the work Mozilla was doing on Bespin, it showed tremendous potential. Interestingly enough, the Mozilla Bespin project was later merged into Ace, Cloud9′s editor, which seems to have greatly contributed to the solid editing experience in the cloud-based IDE.
C9 takes a very similar pricing approach to Github, offering a nice baseline set of features via a freemium model with more unlimited functionality for $12 per month. The differences boil down to the type of workspaces you have, the number you can have and the features available within those workspaces. A workspace is where your project lives, including your project files and the tools and services you might use (such as Ruby or Python). So depending on how sophisticated your needs are, you may need to seriously consider the premium option which gives you:
The terminal options are especially important since C9 allows you to SSH and FTP into your own server, basically allowing you to use their service as solely a cloud-based IDE.
The fact that they offer a freemium option is great for kicking the tires to see if it’s a service you can get into.
You have a couple of options for sign-in, including a traditional email/password scenario or you can use OAuth via GitHub or BitBucket. Doing so with the latter two gives you access to the repositories you already have stored on those services, as evidenced here:
The workspace allows me to either clone an existing repo from the imported list, clone from a URL of my choice or create a new workspace based off a remote server (via SSH or FTP)
I decided to clone my “authy” Git repo which was the sample source code I wrote for an article here on Nettuts+ on two-factor authentication. The app server I used for that was ColdFusion and I was pretty excited to see the C9 recognized the ColdFusion files correctly. I honestly wasn’t expecting it since CFML isn’t as popular as it used to be:
Notice that my entire project structure is brought over intact and I have full editing capabilities on my files. In addition, I also have access to full terminal commands:
To drive this home a bit more, notice in the following screenshot I made a change to gettoken.cfm by adding a comment. Typing in git status in the terminal panel displays the changed status of the file just like you would expect:
Then following up with git commit -a -m "Added comment" and git push updates my repo accordingly:
A key feature that the C9 likes to hype is the JavaScript autocomplete capabilities and it makes sense since it’s such an invaluable resource in any editor.
I know there’s been a lot of debate recently about whether or not autocomplete hinders your ability to remember language features but with the growing level of complexity in libraries, frameworks and tools, I personally find tremendous value in having a little help remembering things. I do wish they offered more language support though.
One of the biggest selling points is the maturity of the documentation. It covers everything about the service from customizing the IDE to integrating with database systems and deploying your code. There are a number of video tutorials that you can leverage to get familiar with the service, which complement the solid documentation.
Lastly, if you’re adventurous, you could decide to roll your own version of Cloud9 IDE since it is an open-source project licensed under the GPL. The GitHub page offers good instructions on how to install it, both as *nix and Windows environments, so if you’d like to forego the cost, have at it.
Nitrous.IO (which I’ll just refer to as Nitrous from now on) is a new option that’s gotten a lot of praise from developers like Yehuda Kathz of the Ember.js project and Tobias Lutke, Rails Core alumni. It’s still in Beta, but works impressively well at this point. They’ve taken the approach of offering up a full virtualized stack that not only encompasses an IDE but also spins up what they call “boxes” which basically house your entire development stack. This includes your choice of Ruby on Rails, Node.js, Python/Django or Go.
Similar to C9, they offer basic services that allow you to kick the tires around. This is done by giving you enough “nitrous” points (155) to create a basic box which they say should be enough for most day-to-day tasks. Notice in the image above that the amount of memory and storage selected affects the amount of nitrous points you’ll have left. The standard basic box will leave you with five points and like many VPS hosting providers, you can dynamically choose more resources depending on what you need. I’m sure this will come at a cost once it’s out of beta but they make it incredibly easy to earn more points without opening up your wallet. Via a couple of different social outreach connections and tasks, you can earn more points towards your box features:
Notice that by choosing a couple of options, I was able to boost my N20 points from 155 to 180 and the more friends you invite the more points you earn. Just don’t be an annoying spammer though!
Setting up a box though is more than just selecting resources. An important part of this, in terms of performance, is to choose the closest geographic region to you to decrease latency. They actually key in on this during their intro video.
Once you’ve chosen your settings, provisioning the box is incredibly straightforward and even has a cool animated progress dial:
The IDE then shows up and you’re ready to begin your work:
Unlike C9 though, I didn’t find a way to visually see the Github repos available. I assumed that connecting to Github would also allow me to easily clone one of my repos into my box. I ended up following these instructions to add the SSH keys generated by Nitrous to my Github account and then git cloning one of my repos into the IDE:
I also could’ve used the upload functionality to upload my project files:
It just seems to me that getting direct visual access to your GitHub repo is a priority feature the Nitrous team should be looking at and something I think is a plus for C9.
With the files in place, it was time to see how the IDE worked and for all intents seemed to work very well, easily recognizing different file types and offering syntax highlighting according to the file type:
Unlike C9, though, there was no autocomplete so you’ll need to determine how valuable a feature that is to you. But like C9, keyboard shortcuts for common tasks such as saving a file or closing tabs are all there.
For those used to working in the terminal, you’ll find Nitrous easy to adapt to. In fact, you’ll really need to be comfortable with it to make full use of the service. Installing and starting packages like MongoDB or Memcached is done via the Nitrous package manager called Parts which, you guessed it, is command-line based. For example, installing MongoDB would go like this:
parts install mongodb
If you’re used to apt-get on Linux or brew install on OS X, this syntax should be very familiar.
The main thing to remember is that the editor is only one part of the equation. You’re basically running a complete machine here within a web browser so being comfortable in a *nix environment will definitely give you a leg up.
Even deploying your site will require you to use the command-line. There’s no “just push a button” option here. Nitrous integrates easily with the following services:
That gives pretty good coverage to several large cloud-based services. I was curious about their deployment support for Amazon but couldn’t find a lot of information on that, at least not enough to be able to understand how to set it up.
With that said, their documentation is very well organized and will easily guide you through most of the tasks you need to get up and running with their service.
Both services seem to offer compelling features that could make it easy to move over to full-time cloud-based development. With so many low-cost devices coming out that are clearly targeted at consumers who just want to be connected all the time, it makes sense that these service start to evolve and perhaps gain traction.
It’s hard to imagine giving up my trusty laptop with its i7 processor and speedy SSD for an all-cloud dev environment but I can’t outright dismiss it either. Every major software company is touting cloud services and I’m sure every one of you reading this uses multiple cloud services daily. It seems like a logical step to begin considering coding in the cloud.
]]>|
|