News aggregator

Viktor Kojouharov was sick of constantly having html code snippets inside his perl code. He was seeing too many projects where the code was a messy mixture of perl, html, and in some places, javascript. Since he is familiar with the Gtk+ toolkit he decided to make something similar targeted for the Web.

He ended up with IWL which is, in Viktors words:

basically a graphical toolkit, or widget library, much like Gtk+ or the ETK library for enlightenment. The main goal of this library is to create a full blown RIA, without the need to write html in your code. When I started working on it roughly a year and a half ago, there was nothing similar existed for Perl. By using the library where I work, it has so far mostly achieved its main objective (and has also proven to be an excellent subject for my diploma thesis :))

If you are a Perl developer who prefers writing apps in a toolkit style like below, then IWL may be fore you:

PLAIN TEXT PERL:

1.  
2.     use IWL;
3.    
4.     # create the main container, and a few widgets
5.     my $page = IWL::Page->new;
6.     my $frame = IWL::Frame->new;
7.     my $iconbox = IWL::Iconbox->new
8.         (width => '800px', height => '600px');
9.     my $button = IWL::Button->newFromStock
10.         ('IWL_STOCK_CANCEL');
11.     my %some_icon_info = ("foo.jpg" => 'foo', "bar.png" => 'bar');
12.  
13.     # Setting up the icons and adding them to the iconbox
14.     foreach (keys %some_icon_info) {
15.         my $icon = IWL::Iconbox::Icon->new;
16.         $icon->setImage($_);
17.         $icon->setText($some_icon_info{$_});
18.         $icon->setDimensions('64px', '64px');
19.         $icon->setSelected(1) if $_ == 'something';
20.         $iconbox->appendIcon($icon);
21.     }
22.  
23.     $page->appendMetaEquiv("Cache-control" => "no-cache");
24.     $frame->setLabel("Frame label");
25.     # Adding the children to their parents
26.     $frame->appendChild($iconbox);
27.     $frame->appendChild($button);
28.     $page->appendChild($frame);
29.  
30.     # Finally printing the page
31.     $page->print;
32.  

Erin and I are in our hotel room in Midtown Manhattan.  We’ve only been in the city about 30 hours so far, but it’s been a fun trip.  More on that later…  Right now we’re having some challenges with the NYC meet-up we planned to do on Saturday, October 20.  For those who are interested [...]

(Source: xkcd.com)

Nhật Ký Vàng Anh (NKVA) đã chính thức kết thúc (xem chương trình chia tay - phần 1 & phần 2). Đó là kết cục tất yếu cho câu chuyện mấy hôm nay đang ầm ĩ trên mạng của cô bé nhân vật chính Vàng Anh - Thùy Linh. Cũng chỉ mới xem một vài [...]

This week's travels: Arlington (outside Washington, DC), Atlanta, Dallas, Austin, and Boulder (outside Denver).

You can still sign up. We've been doing a pretty good job of getting everyone in, so don't worry if you're waitlisted... we'll probably fit you in.

Thursday's Austin event will be available on the internet, somehow, thanks to NewTek who will be bringing a TriCaster... a backpack-sized broadcast studio. Details to be announced.

Coming in November: Dublin, London, Cambridge, Amsterdam, and Copenhagen. More details later this week.

Not loving your job? Visit the Joel on Software Job Board: Great software jobs, great people.

Thomas Fuchs announced a preview release of the Script.aculo.us effects library. Script.aculo.us v1.8 Preview includes:

• Prototype 1.6 (lastest trunk version)
• Complete rewrite of Ajax.InPlaceEditor and Ajax.InPlaceCollectionEditor
• Full CSS inheritance in Effect.Morph
• New core effect: Effect.Tween
• Sound: play mp3 files for sound effects; uses native playback on IE and available plugins whereever possible
• Performance improvements
• Tons of bugfixes

You can find the full CHANGELOG here.

Eric Meyer has been keeping a secret since 2005 about CSS Vertical Bar Graphs. Well, not really, but it is good that he has come out with a nifty demo on how you can make this:

PLAIN TEXT HTML:

1.  
2. <table id="q-graph">
3. <caption>Quarterly Results</caption>
4. <thead>
5. <tr>
6. <th></th>
7. <th class="sent">Invoiced</th>
8. <th class="paid">Collected</th>
9. </tr>
10. </thead>
11. <tbody>
12. <tr class="qtr" id="q1">
13. <th scope="row">Q1</th>
14.  
15. <td class="sent bar" style="height: 111px;"><p>$18,450.00</p></td>
16. <td class="paid bar" style="height: 99px;"><p>$16,500.00</p></td>
17. </tr>
18. <tr class="qtr" id="q2">
19. <th scope="row">Q2</th>
20. <td class="sent bar" style="height: 206px;"><p>$34,340.72</p></td>
21. <td class="paid bar" style="height: 194px;"><p>$32,340.72</p></td>
22. </tr>
23. <tr class="qtr" id="q3">
24. <th scope="row">Q3</th>
25. <td class="sent bar" style="height: 259px;"><p>$43,145.52</p></td>
26.  
27. <td class="paid bar" style="height: 193px;"><p>$32,225.52</p></td>
28. </tr>
29. <tr class="qtr" id="q4">
30. <th scope="row">Q4</th>
31. <td class="sent bar" style="height: 110px;"><p>$18,415.96</p></td>
32. <td class="paid bar" style="height: 195px;"><p>$32,425.00</p></td>
33. </tr>
34. </tbody>
35. </table>
36.  
37. <div id="ticks">
38. <div class="tick" style="height: 59px;"><p>$50,000</p></div>
39.  
40. <div class="tick" style="height: 59px;"><p>$40,000</p></div>
41. <div class="tick" style="height: 59px;"><p>$30,000</p></div>
42. <div class="tick" style="height: 59px;"><p>$20,000</p></div>
43. <div class="tick" style="height: 59px;"><p>$10,000</p></div>
44. </div>
45.  

i.e. a bog standard table with some divs, and make it look like this:

Over the weekend Shane O'Sullivan released version 1.0 of Dojo Image Widgets, a set of Dojo widgets that allows easy creation of image galleries from Flickr.

One of the coolest features of all of these widgets is that they all feed off image data provided by the dojo.data API. What this basically means is that each widget can display images from any source, with no modification whatsoever. You simply pass it a Dojo data store, and is shows the pictures. Some of the data stores currently in the Dojo toolkit include:

• dojo.data.ItemFileReadStore - pull in simple JSON data in an array. You could use this if you simply have a directory of images on your own web server you would like to display
• dojox.data.FlickrRestStore (demo) - query the Flickr photo sharing website for images. This is all done on the browser, with no need for any server-side redirects. This is another of my additions to the Dojo toolkit - I love Flickr, feel free to check out my photo stream here.
• dojox.data.PicasaStore (demo) - query Google’s Picasa image sharing website for images. As with the Flickr data store, this is done on the browser, with no need for server side support.

and many more….. You can also write your own data store if you so desire, but the ones included in the toolkit should cover almost everything you might need.

Some of the features included are:

• Pages of thumbnails.
• Intelligent pre-loading of images so the images you are looking at are loaded first.
• Fade effects for transitioning of images
• Populated using JSON data - any JSON data, not just Flickr.
• Flickr integration - remotely load your Flickr images.
• Paging through a Flickr collection.
• Slideshow

You can read the full release notes and see demos at Sean's site.

Ryan Dewsbury, creator of gpokr is no stranger to Ajaxian as we did a writeup about his Ajax poker app last year. Ryan has since released another Ajax-based game called Kdice. Kdice is an online strategy game built using the Google Web Toolkit.

The goal of the KDice is to win all territories. At the end of each turn the number of new dice randomly distributed is based on the largest number connected territories for that player.

I've never played Kdice but considering that there are over 30,000 registered players on the site, this game must be a blast!

Ben and I have been surprised at how the universe of Ajax continues to expand. This redshift which has taken it past the browser onto the phone, the Wii, and the server is amazing.

Another technology that has done a similar thing is OSGi in the Java space. It started as a component model for devices, but has since grown to the desktop with Eclipse, and now the server.

To ties these together, the Eclipse Foundation has announced Eclipse Rich Ajax Platform (RAP) 1.0:

RAP 1.0 is the first Ajax platform that allows developers to create Rich Internet Applications (RIA) using the Eclipse component model, based on the OSGi standard. OSGi is a service-oriented, component-based environment that promotes the interoperability of applications and services. Organizations using RAP are now able to create Ajax and RIA applications that are component-based and integrate into existing enterprise systems.

RAP 1.0 includes features well-suited for enterprises that are building a large number of new applications based on Ajax and RIA technologies. These features include:

• The ability to create and deploy RIA or RCP applications from the same Java code base, allowing organizations the flexibility to create browser-based RIA application or desktop-based rich client applications.
• Support for creating Ajax applications based on the OSGi component model.
• Java development tools that tightly integrate with the Eclipse platform and allow developers to quickly develop, test, debug and deploy RIA applications.
• A complete set of frameworks for creating Ajax applications that support scalable user interfaces, complex widgets, databinding and loose coupling for UI elements.

Jochen Krause sat down with me to chat a little about what RAP is about. He talked about how the target audience for RAP is Java developers in the enterprise setting. If you know RCP/SWT and you want to develop rich browser applications, you are set. Jochen says that his company has seen that they can share the same base of code (~80%) for products that deploy to the web and the desktop. You get the benefit of using the same workbench and extension points that you know and love from RCP.

RAP is very different to something like GWT. RAP runs the logic on the server, and emits JavaScript for the controls at runtime (as opposed to compile-time). An implementation of SWT runs on the server and people can extend your views and perspectives to add functionality.

Jochen also thought that JSF wasn't as well suited to Ajax development due to its history as a document-centric technology. Many in the community would disagree with that (just ask the Seam folk!).

When developing your RAP applications, forget about the web a little. You can't style things with CSS as their needs to be a stricter mapping between the Java and JavaScript components. They do have a properties system that is similar to CSS in some ways.

Tooling is a definite benefit. You get all of the Eclipse tooling joy, and there is future work being done by many companies such as NEC to give you a rich DB -> client UI experience. This isn't done just for RAP, but for Eclipse in general, and RAP gets to piggy back on the work.

All in all it is interesting to see what happens with the marriage of OSGi and Ajax!

I remember in college trying to call the catalog companies to get them to stop sending me mountains of paper catalogs. It was futile. Most of them had no way of doing that, and even if you got off the list, you'd always find your way back on again two months later.

Catalog Choice (it's a .org) contacts catalog merchants on your behalf and gets them to stop sending you catalogs. For free.

Great idea, excellent implementation (very nice Ajax UI and great graphic design), and I'll let you know if it helps.

 

Not loving your job? Visit the Joel on Software Job Board: Great software jobs, great people.

Last Friday, I was sitting at the San Diego airport, trying to figure out if my flight was going to be on time.

Of course, Continental thinks it will:

Being suspicious, I notice that there's no plane at the gate.

Where is it?

Aha, looks like we're waiting for flight 1726. Where's that? I'll check FlightAware:

Arriving 3:21. A bit later than the display at the gate is showing, and a total of 39 minutes late. And indeed, we took off almost exactly 39 minutes late.

Thanks to Joe Farrell for this idea.

Not loving your job? Visit the Joel on Software Job Board: Great software jobs, great people.

This is great …

http://video.google.com/videoplay?docid=5547481422995115331&q=Zeitgeist+the+Movie&total=365&start=0&num=10&so=0&type=search&plindex=0

Should be turned into a Holywood movie.

Our shared physical reality is the most common state of reality we experience, but it certainly isn’t the only one.  Our nighttime dreams are another state, as are astral experiences, near-death experiences, and out-of-body experiences. I regard these different levels of reality as being at different frequencies or energy levels.  It’s like tuning into different TV channels.  Physical reality [...]

Douglas Crockford continues to bang the drum for securing JavaScript in his latest post:

It is possible to make secure programming languages. Most language designers do not consider that possibility. JavaScript's biggest weakness is that it is not secure. That puts JavaScript in very good company, but it puts web developers in an untenable position because they cannot build secure applications in an insecure language. JavaScript is currently going through a redesign that is again failing to consider the security of the language. The new language will be bigger and more complex, which will make it even harder to reason about its security. I hope that that redesign will be abandoned.

A more fruitful approach is to remove insecurity from the language. JavaScript is most easily improved by removing defective features. I am aware of two approaches that allow us to build secure applications by subsetting the insecure language.

The first approach is to use a verifier. That is how ADsafe works. A verifier statically analyzes a program, and certifies that the program does not use any of the unsafe features of the language. This does not guarantee that the program is safe, but it makes it possible to make programs that are safe. Any program can compromise its own security. The improvement here is that a program's security is not compromised by the language it is written in.

The second approach is to use a transformer. A transformer verifies, but it also modifies the program, adding indirection and runtime checks. The advantage of transformers is that they allow the use of a larger subset of the language. For example, ADsafe does not allow the use of the this parameter. A transformer can allow this because it can inject code around it and its uses to ensure that it is never used unsafely. The benefit is that it is more likely that existing programs could run in a safe mode with little or no modification. I think that is a dubious benefit because programs that are not designed to be safe probably are not. The downside is that the final program will be bigger and slower, and debugging on the transformed program will be more difficult.

Both approaches work. But we still need to fix the browser.

A new project, Google Caja, is trying to do source-to-source translation to secure things:

Using Caja, web apps can safely allow scripts in third party content.

The computer industry has only one significant success enabling documents to carry active content safely: scripts in web pages. Normal users regularly browse untrusted sites with Javascript turned on. Modulo browser bugs and phishing, they mostly remain safe. But even though web apps build on this success, they fail to provide its power. Web apps generally remove scripts from third party content, reducing content to passive data. Examples include webmail, groups, blogs, chat, docs and spreadsheets, wikis, and more.

Were scripts in an object-capability language, web apps could provide active content safely, simply, and flexibly. Surprisingly, this is possible within existing web standards. Caja represents our discovery that a subset of Javascript is an object-capability language.

FBJS is also trying to do some of this too. Got some time on Friday to look around some code? Take a look at some Caja.

Yahoo! has got a parallel universe going on between the US and the UK.

Last week we interviewed Steve Souders, Chief Performance Yahoo!, on the update to YSlow. Steve has a book out called High Performance Web Sites.

Meanwhile, in the UK, Stuart Colville and Ed Eliot also of Yahoo! have a book in the works called High Performance Web Site Techniques.

Stuart and Ed recently released the CSS Sprite Generator tool, and we sat down to discuss it, and other performance related topics:

I can't wait to hear what Yahoo! Australia has to offer next!

Jason Harwig has written a quick tip on Testing JavaScript Objects with Function.prototype.call. The example that he uses is:

PLAIN TEXT JAVASCRIPT:

1.  
2. /**
3. * Call a function with the given execution context and parameters.
4. * @param <object> instance the object to use as the "this" inside the function
5. * @param <array of Objects> parameters the objects to pass to the function
6. */
7. Function.prototype.call(instance, parameters...);
8.  
9. var x = { message: 'Hello World' };
10. var hello_function = function(name) {
11.   alert(this.message + ", " + name);
12. }
13. hello_function.call(x, 'jason');
14.  

In the context of Crosscheck, the JavaScript unit testing framework, you would see this work via:

PLAIN TEXT JAVASCRIPT:

1.  
2. // function to test
3. String.prototype.trim = function() {
4.    return this.replace(/^\s+|\s+$/g,'');
5. }
6.  
7. // crosscheck test
8. assertTrim: function() {
9.    assertEquals('text', String.prototype.trim.call('  text');
10.    assertEquals('text', String.prototype.trim.call('  text  \n ');
11. }
12.  

What is Crosscheck?

Crosscheck is an open source testing framework for verifying your in-browser javascript. It helps you ensure that your code will run in many different browsers such as Internet Explorer and Firefox, but without needing installations of those browsers. The only thing you need is a Java Virtual Machine.

Thật là xứng đáng.

Bob Buffone (Nexaweb, XAP, and a lot more) has created an application to test JavaScript performance. You can run the app in various browsers to compare the results.

Bob has done that work for you though, and has documented his findings which has him concluding that the general ranking is Safari, Firefox, IE.

Back in July, we held our third annual Ajax Reader Survey. The results are in. Some interesting observations:

• Prototype and Scriptaculous still dominate the field with 68% and 59% of readers using them, respectively. jQuery has a respectable 48% share. Yahoo UI!, Dojo, and Ext JS round out the top six. Google Gears enjoys usage by 22% of survey participants--pretty amazing for its youth. Despite Java's popularity amongst our readers, DWR is only used by 13% of readers, which surprised us.
• A little over 50% of readers use PHP, and about 40% use Java. Only 20% of readers use .NET technologies.
• The biggest concern on your mind? Cross-browser rendering issues, with 60% of you listing it as your biggest concern.

What questions/frameworks did we leave out? What do you think of the results?

UPDATE: There were 826 total responses to the survey. (Sorry this was left out of the PDF.)

UPDATE 2: It turns out MooTools received a whopping 11.3% of "Other" write-ins for the Frameworks question. Who knows how high it would have ranked if there was a direct option for it. In any event, we apologize for neglecting to include it.