Cheap corel draw x5 , cheap corel draw software

Over on the Mootools forum digitarald (a contributor to Mootools) has posted date.js, a date parsing script that converts just about any date a user could imagine entering into a field into an actual date. I’m probably going to add this to our /mootools.extensions/Native folder and integrate it in with our own date.picker.js.

var date1 = date2 = new Date() = "Fri Jun 08 2007 14:42:57 GMT+0200"
date1.increment('day', 2) = " Sun Jun 10 2007 14:42:57 GMT+0200 "
date2.decrement('hour', 12) = " Fri Jun 08 2007 02:42:57 GMT+0200 "
date1.diff(date2, 'hour') = " 60 "
date1.getOrdinal() = " st "
date1.getDayOfYear() = " 161 "
date1.lastDayofMonth() = " 30 "
date1.getWeek() = " 24 "
date1.getTimezone() = " GMT "
date1.getGMTOffset() = " +0200 "
date1.format('db') = " 2007-06-10 14:42:57 "
date1.format('iso8601') = " 2007-06-10T14:42:57+0200 "
date1.format('rfc822') = " Sun, 10 Jun 2007 14:42:57 GMT "
date1.format('short') = " 10 Jun 14:42 "
date1.format('long') = " June 10, 2007 14:42 "
date1.format various strftime = " a = Sun ; A = Sunday ; b = Jun ; B = June ; c = Sun Jun 10 2007 14:42:57 GMT+0200 ; d = 10 ; H = 14 ; I = 02 ; j = 161 ; m = 06 ; M = 42 ; p = PM ; S = 57 ; U = 24 ; w = 0 ; x = 06/10/2007 ; X = 02:42PM ; y = 07 ; Y = 2007 ; T = +0200 ; Z = GMT "
Date.daysInMonth(2, 2006) = " 31 "
Date.isLeapYear(2006) = " false "
Date.parse('10/12/1982') = " Tue Oct 12 1982 14:42:57 GMT+0200 "
Date.parse('2007-06-08 16:34:52') = " Fri Jun 08 2007 18:34:52 GMT+0200 "
Date.parse('2007-06-08T16:34:52+0200') = " Fri Jun 08 2007 16:34:52 GMT+0200 "
Date.parse('today') = " Fri Jun 08 2007 14:42:57 GMT+0200 "
Date.parse('tomorrow') = " Sat Jun 09 2007 14:42:57 GMT+0200 "
Date.parse('yesterday') = " Thu Jun 07 2007 14:42:57 GMT+0200 "
Date.parse('next monday') = " Mon Jun 11 2007 14:42:57 GMT+0200 "
Date.parse('1st') = " Fri Jun 01 2007 14:42:57 GMT+0200 "
Date.parse('14th October') = " Sun Oct 14 2007 14:42:57 GMT+0200 "
Date.parse('24th May, 2007') = " Thu May 24 2007 14:42:57 GMT+0200 "
Date.parse('May 3rd 2006') = " Wed May 03 2006 14:42:57 GMT+0200 "

History Manager

Here’s another digitarald script that I’m eyeing with a bit of interest, a state manager for ajax environments. From his site:

“Ajax History”, “Back-Button”, “Ajax Bookmarks”, call it however you like. This is an unobtrusive MooTools plugin to allow history handling for multiple modules, try it out. It can handle back/forward history actions and bookmarks with the location hash.

Features

• Allow users to bookmark your ajaxified application in the current state
• Forward/Backward history browsing for your Accordion and every other
• Save states of One-Page-Applications over sessions
• Change easily default options and customize the behaviour with Events

New Mootools Blog

The Mootools site now has a nifty blog and it’s got some great stuff on it already. First up is a quick set of reference links to everything you need to learn javascript. Many of these things are stuff I’ve linked to in my side-bar or in various posts, but it’s a nice collection for sure.

SlickSpeed

You might have seen this show up on Ajaxian, but the Mootools gang released Slickspeed, a set of browser tests for dom selector comparisons for various browsers:

IE Debugger: My DebugBar

Here’s a new debugger for IE that looks promising. I haven’t fooled around with it yet but if anyone has or does, post a comment with your thoughts!

Google Gears

If you’ve followed ajaxian in the last two weeks no doubt you’ve seen this already, but Google launched Google Gears a week or two ago. In their words:

Google Gears (BETA) is an open source browser extension that enables web applications to provide offline functionality using the following JavaScript APIs:

• Store and serve application resources locally
• Store data locally in a fully-searchable relational database
• Run asynchronous Javascript to improve application responsiveness

Sounds promising. Here’s a nice little write up from Uriel Katz.

Fx.Morph

Was glancing through the demos at http://demos.mootools.net and stumbled on to Fx.Morph, a short little Fx class that transitions an element’s properties from one css class to another. I wrote something like this a few months ago but ultimately decided I didn’t really need it but now I’m giving it a second thought.

So over at Ajaxian today they have a post on Dean Edward’s latest update for his excellent packer javascript compression tool:

Dean Edwards has released Packer v3.0, one of the top utilities to squeeze your JavaScript like a lemon.

• respects Microsoft conditional comments
• new option to shrink variable and argument identifiers
• removed the special chars feature
  
  (except the ;;; feature which people seem to like)
• some bug fixes:
  • packer no longer closes spaces between the +/- operators so code like this is safe: c = a++ +b;
  • the throw”error”} bug that affected Safari (this is a Safari bug really but packer gets around it)
  • the __proto__ bug for Mozilla browsers (this only affected the online version of packer)
  • a minor parsing bug affecting the detection of regular expressions
• simplified the user interface

Update:

The problems I outline below are fixed. Thanks Dean!

Unfortunately, I ran one of our libraries through it and found two issues that we’ll need to address before we can use it (luckly, I have a local copy of the previous version of the Packer…):

• ‘http://…’ breaks. Your packer wants this to be double quotes (“http://…”).
• /*comment*//*followed by another comment*/ breaks. This happens in our code because we concatenate several files together and each file starts with comments and ends with comments.

I emailed Dean. Maybe he’ll have a fix. If not, we’ll have to figure something out or use the old one.

Just today I was asked over in the Mootools forums why we don’t create a dependency map like the one in Mootools. My answer there was, basically, that the common code we publish here on clientside is but a small portion of our library. Our javascript spans numerous teams, sites, and applications, and keeping a map like this by hand is probably not practical.

Then today on Ajaxian there’s this post about T.J. VanSlyke’s alterations to Dean Edward’s Base.js to allow him to generate a dependency map of all the classes he writes. This isn’t quite the same as mapping out file-by-file dependencies, but it’s a start. Considering that Mootools is largely based on Base.js, this shouldn’t be too hard to incorporate over there. Read the rest of this entry »

via Ajaxian and pertinent to some of our security efforts:

Shreeraj Shah has published a paper on Crawling Ajax-driven Web 2.0 Applications.

Crawling web applications is one of the key phases of automated web application scanning. The objective of crawling is to collect all possible resources from the server in order to automate vulnerability detection on each of these resources. A resource that is overlooked during this discovery phase can mean a failure to detect some vulnerabilities.

The introduction of Ajax throws up new challenges for the crawling engine. New ways of handling the crawling process are required as a result of these challenges. The objective of this paper is to use a practical approach to address this issue using rbNarcissus, Watir and Ruby .

It really shows how powerful tools like Watir are.

What are you waiting for? Get Firebug now.

One year and twelve days later I am happy to announce that the leopard’s growl has been quieted to a purr, clearing the path for the final Firebug 1.0 to make its way in the world.

If you read this blog, that won’t mean much to you personally since you’re probably already using 1.0 beta. However, there are still tens, maybe even hundreds of thousands of people who are still using 0.4.1 and are going to get a very nice present the next time they restart Firefox.

Thanks to all the people who have supported Firebug during its infancy, especially those who have contributed new ideas and donations to the project. We’re just getting started here! If nothing else, I hope Firebug inspires the makers of other browsers to invest more time in development tools. The web development paradigm wants to evolve, but we can’t build the future with yesterday’s hammer.