#JavaScript: ISO 8601 formatted string to Date

ECMAScript 5 includes new support for ISO 8601 dates. This means you’ll be able to create a new Date object using an ISO 8601 formatted string. However, only a few browsers (Firefox 3.5 and WebKit-based browsers) currently support the new ISO 8601 formatting, so you’ll still need to provide the conversion functionality for IE  8.

If you attempt to create a JavaScript Date with an ISO 8601 formatted string, you’ll get an invalid date error in IE 8. d = new Date(‘2010-10-20T07:32:12Z’);

Fortunately we have Google Closure Library. The next 2 lines of code will solve the problem in IE 8:

goog.require(‘goog.date’);
d = goog.date.fromIsoString(‘2010-10-20T07:32:12Z’).date_;

#Selenium: UI-Element helps to insulate testcases from change in underlying application

With traditional Selenium IDE recorded tests, small modifications to the presentational layer of a web application can break the ability of the test to locate elements on a page. Tests should be more resilient to change, such that testcase breakage can be minimized with careful test construction, and can be fixed at a central point as opposed to in all affected testcases. This calls for some mechanism of abstracting the locator.

source: http://goo.gl/zJ8d

Selenium UI-Element Reference

Distributed Version Control vs. Centralized Version Control

The main difference between distributed and centralized version control systems is that when you commit, you are committing to your local copy of the repository—effectively, to your own branch. In order to share your changes with others, there is an additional set of steps you need to perform. To do this, DVCSs have two new operations: pulling changes from a remote repository and pushing changes to it.

Continuous Delivery: Reliable Software Releases through Build, Test, and Deployment Automation by Jez Humble; David Farley

For example, here is a typical workflow on Bazaar:

  1. bzr pull —Get the latest updates from the remote repository.
  2. Write some code.
  3. bzr commit —Save your changes to your local repository
  4. bzr pull —Get any new updates from the remote repository.
  5. bzr merge —This will update your local working copy with the results of the merge, but will not check in the merge.
  6. bzr commit —This checks in the merge to your local repository.
  7. bzr push —Push your updates to the remote repository.

When not to use progress bars

Even worse than making the user guess when an operation will complete is lying to them about it.

Progress bars should only be used when a reasonable level of accuracy is possible. It’s never a good idea to have a progress bar that reaches 10 percent and suddenly jumps to the end (leading users to believe that the operation may have aborted in midstream), or even worse, to be pegged at 100 percent long before the operation actually completes.

If you can’t determine an accurate completion percentage, a good alternative to a progress bar is just some indication that something might take a long time; perhaps a text display along the lines of “Please wait while your data is processed—this may take a few minutes …”, or perhaps an animation that gives the illusion of activity while the lengthy operation progresses.

For the latter, a handy website at http://www.ajaxload.info/ generates GIF animations that you can tailor to match your theme.

jQuery in Action by Bear Bibeault; Yehuda Katz

#PowerShell set-content cannot access the file

gc file.txt | % {$_ -replace ‘xxx’, ‘yyy’} | sc file.txt
(gc file.txt) | % {$_ -replace ‘xxx’, ‘yyy’} | sc file.txt

These two commands are completly different. The first one will not work with the error message “The process cannot access the file…” When you try to set the content of the file after processing the first line, we still have it open so that we can send you the second line. To tackle with this problem we need to load the entire content of the file into memory before making any changes. The second command does it.