Activate your free membership today | Log-in

Tuesday, July 15th, 2008

RJK - Seven Reasons Why the New iPhone Sucks

Category: iPhone

Look before you leap before buying the new iPhone. This is the iPhone that all of us have been waiting for. It promised to address the deficiencies of the first generation iPhone, but does it really?

Here are some reasons why not:

1. Too expensive to own.
Apple and AT&T may have shaved a couple of hundred dollars off the price but they will more than make up for it in monthly fees. If you take into account the regular monthly fee, the data fee, the text message fee, which used to be free, and the $99 annual mobileme fee you could end up spending over $1,000 a year to own an iPhone, that’s 200 gallons of $5 gas.

2. Can’t use the GPS like a GPS.
Forget about getting turn-by-turn voice directions in your car from the new iPhone 3G. The iPhone SDK makes it pretty clear it’s not allowed, “Applications may not be designed or marketed for real time guidance.” Yes it will superimpose your position on a Google map, or show you the closest pizzeria but what about getting real-time route guidance? If you read reviews for other GPS devices you never come across a GPS that doesn’t provide some form of guidance. There’s a rumor that TomTom may be developing a guidance application but you have to wonder how they’ll get it past the Apple police.

3. Can’t tether the iPhone to your laptop.
Want to save sixty dollars per month for a 3G card for your laptop and use the iPhone instead? Not going to happen—not allowed. Although there are plenty of phones, including AT&T’s Tilt, that will allow you to use your 3G phone as a high speed modem for your laptop, the iPhone won’t be one of them so you can add the cost of a 3G card for your laptop at $720 a year to your total cost of ownership.

4. Still no cut and paste.
Cut and paste has been around on Apple computers since the earliest Mac Plus computers. What’s the big problem with implementing it on iPhones? Why is cut and paste so important? Suppose you’re browsing a web site and want to capture some text or a URL, or someone sent you an email and you want to grab some text from it and send to someone else. Not possible on an iPhone. Speaking of email, where’s the spell checker? Predictive typing is fine but spell checkers are everywhere else but here.

5. Wimpy 2 MP camera.
In the world of 5 MP Smartphones and 10 MP point and shoot cameras that you can buy for under $200, why is the iPhone still stuck with a measly 2 MP? That’s so 2003. While we’re at it how come we can’t record video, afraid the non-existent SD card might fill up? The iPhone should be able to stream video by now just like many other cell phones can already do right now.

6. No stereo Bluetooth.
We thought the iPhone was supposed to be part iPod. At least they fixed the recessed headphone jack flaw (and called it a new feature) but the A2DP stereo Bluetooth standard has been around for a while and is missing from the iPhone.

7. The list goes on.
Still no Flash player for rich media content (what grudge does Steve Jobs hold against Adobe). Still can’t send pictures in MMS messages, still no native voice dialing, no mobile TV, no replaceable battery, no flash memory card, and on and on.

Okay, now that I got that off my chest, I feel better and what the heck, so it’s not perfect but it’s still the coolest smartphone out there (other smartphones) and I still want one. I look forward to seeing you on the line.

Posted by dkennedy at 3:24 pm
1 Comment

OOOOO
Rate the above post

RJK Frontpage Only- PowerBuilder making a comeback

A 4GL rapid application development tool

Accelerate development with PowerBuilder, the market’s favorite 4GL RAD tool.

PowerBuilder lets you stay ahead of the development curve and offers the flexibility to develop for your most productive platform. PowerBuilder 11.2 incorporates new and emerging technologies that let you to build traditional two-tier applications, distributed applications, Web applications and Smart Clients with speed and ease. And with this new release, you can easily deploy your existing PowerBuilder applications to .NET with the RAD power of AJAX. Get started with PowerBuilder 11.2 today, and see how quickly and easily you can build data-driven applications.

Posted by dkennedy at 3:14 pm
Comment here

OOOOO
Rate the above post

Friday, July 11th, 2008

Remember the Web Apps; Don’t forget the first iPhone baby today

Category: JavaScript, iPhone

We see the birth of the second baby when it comes to building and running apps on the iPhone. People have already spent almost $100k in the first few hours of the AppStore not being open, so tomorrow is likely to be a great day for Apple, and developers, as people run around clicking on buy without thinking of the price.

I spent some time running the applications, and thinking about how different they are to Web versions. For example, when I launch Twitterific vs. a web based Twitter it actually was faster for the Web page to load Safari up with everything. Twitterific also had a strange feature for loading images. As I moved up and down the list the images looked like they were being pushed out of cache which made for a weird experience.

What if the iPhone offered the ability to aggressively cache “applications”. When you open the application it opens its own instance of Safari instead of just linking over to Safari. What if it had access to local storage APIs in WebKit?

The native applications do have benefits. They have access to the camera, addressbook, … well wait, those could be JavaScript APIs too.

There is the tool chain. You can have fine grained performance knowledge of your application with the Objective-C tools, but with SquirrelFish Apple is getting better and better there too. Other nice tooling could work well when constraining the Web interfaces to the iPhone form factor.

What about games? You couldn’t do super monkey ball, or could you if you had a really solid Flash, or feature complete canvas.

The native apps are great, but I am still betting on the Web as a great platform for mobile applications too.

Posted by Dion Almaer at 10:01 am
1 Comment

+++--
3.5 rating from 4 votes

YPulse: Fades and Pulsations Library

Category: Component, JavaScript, Library, Yahoo!

Kent Johnson has released YPulse a simple open source wrapper for the YUI Animation library that makes creating highlight fades and pulsing button glows a bit easier.

You pulse away with something like:

JAVASCRIPT:
  1.  
  2. var pulser = new YAHOO.squarebits.YPulse(
  3.   ‘my-div’,
  4.   ‘backgroundColor’,
  5.   ‘#FFFFFF’, // starting
  6.   ‘#FFFF00′, // ending
  7.   0.75, // The number of seconds for the start-end transition
  8.   0.10, // The number of seconds to wait after completing the start-end transition
  9.   0.75, // The number of seconds for the end-start transition
  10.   0.75, // The number of seconds to wait after completing the end-start transition
  11.   YAHOO.util.Easing.easeBoth, // The YAHOO easing method to use for the start-end transition
  12.   YAHOO.util.Easing.easeBoth // The YAHOO easing method to use for the end-start transition
  13. );
  14.  

Posted by Dion Almaer at 8:42 am
Comment here

+----
1.5 rating from 13 votes

A safety fence for your property lookups

Category: JavaScript, Tip

Michal Till posted a little JavaScript tip that he uses to create a safety fence for accessing properties:

As we all know, null not only does not have any properties, but their existence also can not be tested. So null.property retuns error instead of undefined.

You can end up with something like this:

JAVASCRIPT:
  1.  
  2. if (
  3. (node) &&
  4. (node.nextSibling) &&
  5. (node.nextSibling.className == ...)
  6. ... ) {
  7.    ...
  8.  

There is a neat trick that can simplify the boolean expression. We might supply an empty object {} or zero (0) as an alternative:

JAVASCRIPT:
  1.  
  2. if ( next = (node || 0).nextSibling) ) {
  3.  

Posted by Dion Almaer at 6:39 am
2 Comments

++---
2.7 rating from 17 votes

Thursday, July 10th, 2008

Ojay 0.2: easy keyboarding, a validation DSL, and two new UI widgets

Category: JavaScript, Yahoo!

James Coglan has updated Ojay, the chaining wrapper for YUI that we posted on a few months back.

The new release features really simple keyboard and form scripting and couple of new UI widgets, a new event system and a stack of other improvements:

Ojay.Forms. By far the biggest new package, Ojay.Forms sorts out a real pain point for me in terms of app development. It does two things: it provides unobtrusive replacements for the YAHOO.widget.Button family of classes, and it provides a DSL for handling form validation and Ajax submission.

Ojay.Keyboard. The new keyboard package is an abstraction over YAHOO.util.KeyListener that lets you say what mean without worrying about character codes, for example:

Ojay.Keyboard.listen(document, 'ALT SHIFT S', function() {
    // handle key press
});

It lets you group sets of keyboard commands together so you can make context-sensitive keyboard controls, and gives you easy access to enable/disable key events and their default browser responses. Not much more to say except that you should check out the documentation.

We have two new UI packages, Ojay.Overlay and Ojay.Paginator. Overlay gives you a bunch of classes for positioning content on top of the document, producing lightbox effects and the like, and Paginator implements the content slider effect that’s got a lot of attention recently, including the ability to lazy-load pages of content via Ajax, and easy integration with Ojay.History. Both packages come with a collection of events to allow your code to react to changes to the components, just like you would for DOM elements.

Speaking of events, this release introduces Ojay.Observable, a JS.Class module that allows any class to support the on() method used for listening to events. This module underlies the custom events published by all the Ojay components. More information and examples are in the documentation.

Posted by Dion Almaer at 10:41 am
1 Comment

+++--
3.6 rating from 11 votes

Code specialization; Namespaces again; Parasitic inheritance

Category: JavaScript

Karl Krukow has a new blog that has some interesting Ajax content. Rather than pick at one, we have a synopsis of a few of his recent posts:

Manual code specialization

A technique is presented (in terms of examples) which can give performance boosts in certain situations. The technique relies on higher-order functions, and sharing variables in closures.

Namespacing again

Namespacing has been generally accepted (in one form or another) as a good thing. In this posting, a pair of functions: 'namespace' and 'using' are presented. The former ensures the existence of a namespace, similar to what is offered in common JavaScript libraries. However, it accepts more general forms of namespace declarations:

JAVASCRIPT:
  1.  
  2. namespace({
  3.  com: {
  4.    trifork: {
  5.     tribook: ['model','view','controller']
  6.     }}});
  7.  

The latter function 'using' complements the namespace function. It brings a namespace into scope.

JAVASCRIPT:
  1.  
  2. using(com.trifork.tribook.model).run(function(m) {
  3.  
  4.  m.Reservation = function(start,end){
  5.   //...
  6.  };
  7. });
  8.  

Parasitic inheritance & instanceof

The object function advocated by Crockford in his work on parasitic inheritance makes a new object which has the input object as it's prototype. However 'instanceof' doesn't work with this function. A technique for combining these two is presented.

Posted by Dion Almaer at 10:37 am
Comment here

+++--
3.8 rating from 12 votes

Reverse Autocomplete; The details matter

Category: LiveSearch

Reverse Autocomplete

Autocomplete was one of the first Ajax patterns to come about. We often talk about how it looks, but the how it works part is what really matters. How smart is the algorithm to work out what you are completing against? How long do you go before you kick in to see a result? Does it narrow enough?

László Kozma wrote up his thoughts on Reverse Autocomplete which talks about helping the user as they change their mind during autocomplete, and being away of what they are doing, instead of just using field.value as an absolute. He acknowledges that he isn't the first to think about this, but there are some good ideas.

First, he shares a couple of use cases of the problem, such as:

I enter "German football team" in Google Suggest, then I change my mind and go back to change the query to "Italian football team". Autocomplete doesn't help me with this. Even when I entered "Italia| football team", (the | sign shows the cursor location), autocomplete doesn't do anything, as it doesn't look to the right from the cursor. For the record, "Italian football team" is a frequent query, if I type it normally from the beginning, as soon as I get to "f", Google Suggest knows what I want. Google Suggest seems to look at the text as a whole, trying to autocomplete to the right, ignoring the cursor.

In the browser I typed "mail.yahoo.com". Then I want to go to "mail.google.com" next. Even though "mail.google.com" appears in the history, when I correct the middle part, such as to "mail.g|.com" or even "mail.googl|.com", the autocomplete is clueless. Again, the same behaviour as before.

I typed "jenny@fictivecompany.com" in the e-mail To: field. Now I go back to change it to "jennifer@fictivecompany.com". Even though this address is in the address book, "jen|@fictivecompany.com" does not activate the autocomplete. This problem is similar to the previous one, but in this case space and the comma can both be considered a separator, as the boundary for autocompletions.

And his solution:

The solution is to simply take whatever method there was to search for the text before the cursor, and use it to match the text after the cursor as well. If a prefix tree is used, it is convenient to store the text to the right in reversed form for easier search. Most of the time the text after the cursor will be empty, so there won't be much overhead. When the cursor moves back, simply match the text both before and after the cursor, and only do autocomplete if something matches with both sides.

This example implementation in javascript is based on AutoSuggest v1.0.
I modified the code to perform the reverse search as well. Both the original and the modified version are under LGPL. For the cursor location code I modified this script. As this is just a user interface proof-of-concept, I don't recommend using the javascript code as such, as it is not more than a quick hack.

Text left and right of the cursor is shown for more clarity. Note that I didn't use any of the complex data structures mentioned, all we have is a simple array, as can be seen from the source.

Posted by Dion Almaer at 10:23 am
3 Comments

++++-
4.2 rating from 15 votes

Power, Authority, and Blame

Category: Editorial, Standards

Alex Russell has another one of his insightful posts titled Power and Authority. He talks about the core tenets and then ties it to the W3C, and who we should be "blaming" for the slow upgrade of the Web, and it requires a look in the mirror:

As a case study in putting your faith in the wrong idols, you can’t do better than posts like this which “blame the W3C” (via Molly). Blaming the W3C for not pushing the web forward is both humorously off-target and distressingly common. I’ve written about this before, but fundamentally you can’t blame the W3C for failing to act because it’s not the W3C’s job to act. An MBA should be able to tease this out a bit more effectively – any decision only requires that you have answers for five questions: why? what? how? when? who?

Answering these for pushing the web forward is straightforward, even on a simplistic level:

  • Why?: it’s too hard to build reasonably sophisticated interactions with current web technology
  • What?: new tags, JS and DOM APIs, CSS syntax, and renderer support for all of the above. Eventually, a spec or five reflecting these new technologies.
  • How?: we could try asking the W3C to do it, but they don’t have any power. When they’ve been left to their own devices, the W3C has failed. Miserably. Over and over and over again. Instead, browser makers should introduce new stuff and then agree to agree on it (via the W3C or similar organizations).
  • When?: introducing new features in any given browser seems doable in short-order. In the case of Open Source browsers, the answer is “as soon as someone decides to invest in them”. Competition has even spurred Microsoft to some level of action. The likely time-scale for new features over all, though, appears to be on the order of 5+ years. That’s clearly not soon enough.
    TODO: investigate ways to speed this up.
  • Who?: browser makers and others in a position to affect the code that goes into the renderers we use.

Figuring out “how” leads you directly to “who” in this case. The action we all want is the sole purview and responsibility of the browser vendors and they alone have the power to push the web forward. The “web standards community” has made it clear that they’ll need the imprimatur of some authoritative body where agreement can be forced, but that hasn’t kept the browser vendors from taking the initiative there, either. The big, open questions then center around how the “web standards community” can make enough room for renderer vendors to try out new stuff, since that’s how we get new things. Demanding agreement on what to do before trying it out demonstrably doesn’t work, so it’s then imperative that there be a mechanism for the web to iterate prior to standardization. In fact, I’ll argue that this is now the biggest reason that Paul Ellis isn’t getting the improvements he wants out of the web: there’s no mechanism in place by which any browser vendor can take significant risks without incurring the wrath of a swarm of WaSPs, or worse. Attempts to even begin to lay the groundwork for such a mechanism have been shot down forcefully by may folks who, like Paul, view “fixing the web” as the W3C’s job.

Standards bodies are animated only by the needs of industry to reduce costs by forcing vendors to agree on things. Like Open Source, they can act as a back-stop to the monopoly-creating power of network effects by ensuring that the price of software commodities eventually does reach zero. In this context, then, the W3C’s only effective function is to drive consensus when visions for how to go forward diverge or lead down proprietary ratholes. Asking the W3C for more is the fast path to continued disappointment.

The W3C is just a sail and all sails need the wind to function. You can’t blame the sail for the wind not blowing.

Posted by Dion Almaer at 10:10 am
Comment here

++++-
4 rating from 12 votes

Wednesday, July 9th, 2008

Passpack releases Host-Proof Hosting Library

Category: Library, Security

passpack

Passpack notified me about their new library to support Host-Proof Hosting (HPH) development (touched on earlier). The library allows anyone to set up HPH on their own infrastructure. It's mostly a browser-side library powered by JQuery, focused on transferring encrypted data, and there's also some sample server-side PHP code.

I think the most important part of HPH is that it provides users with real-world data privacy, it's not just a theory, it works now. I'd love to see the pattern get some traction with SaaS providers, but it's not the most obvious system to implement. To this avail, we've just released an MIT/LGPL library for creating Host-Proof Hosting applications: http://code.google.com/p/passpack/

Host-Proof Hosting is the pattern whereby the server knows nothing about the user's data, because the browser ensures it's kept encrypted each time it goes over the wire. It's been practiced in the real world for a couple of years now, but has received some extra attention lately. Clipperz, a Passpack competitor, recently mentioned interest from Richard Stallman in its advocacy for "zero knowledge web applications".

In their response to Clipperz, Passpack expressed a more pragmatic view:

The Zero Knowledge Web Application as-is, is a theory. This is not to say that there couldn’t be a future where it might become a credible solution for privacy, but until that happens, it is inappropriate to ask people to trust a theory with just too many inconsistencies.

Updated after clarification from Passpack - the library is for any server infrastructure, not an API to communicate specifically with Passpack's servers. They say such an API is on the radar.

Posted by Michael Mahemoff at 1:45 pm
Comment here

++++-
4 rating from 15 votes

Extending Firebug Tutorials

Category: Debugging

Jan Odvarko, a member of the Firebug Working Group, has kicked out a set of tutorials on extending Firebug.

If you have some functionality that fits into the performance world, instead of creating a new plugin, you can embrace and extend Firebug as other great tools such as YSlow have done.

To learn more, read up on:

Posted by Dion Almaer at 8:43 am
Comment here

++++-
4.8 rating from 21 votes

Unobtrusive DOM 2 Event implementation for IE; Uniform Event Model revisited

Category: Browsers, IE

Tavs Dokkedahl sent in a great email about work that he and Allan Jacobs have done on bringing DOM event implementations to IE. Here it is in full:

About a year ago or so I put out the Uniform Event Model (UEM) script which
was an implementation of the W3C DOM 2 Event Interface for IE. As it turned
out that release was very premature - the script was simply incomplete and
definitely not ready for production use.

The design ideas however were good enough. Since then Allan Jacobs has
joined the JSLab team and together we have written a new version of UEM
which is much more stable and modular.

This first release includes support for:

  • DOM 2 Event Interface in IE
  • DOM 2 UIEvent Interface in IE
  • DOM 2 MouseEvent Interface in IE
  • DOM 2 Legacy keyboard handling in IE (fancy way of saying "handle it like
    Firefox")

The code is unobtrusive - no special syntax or semantics are needed. A lot
of documentation is available

There still exists issues with some types of events but at large the code is
stable and is performing well enough to be released to the public. Hopefully
we can get some feedback on how to improve it and catch some early errors.

The size of the script is about 32Kb (when minified) it its basic form but
additional modules are available for inclusion. The download page can be
found at http://www.jslab.dk/jdc.download.php

We are currently working on finishing the DOM 3 KeyboardEvent and DOM 3
textInput interfaces (for IE, Firefox, Opera and Safari) besides various DOM
corrections for other browsers than IE.

Posted by Dion Almaer at 7:32 am
17 Comments

++++-
4.8 rating from 13 votes

Webslug: The hot or not of website performance tools

Category: Performance

Kimble Young has created Webslug, the "hot or not of website performance."

It was inspired by webwait but lets you compare the load times of sites and records every performance test for later analysis like browser used, country of origin, top competitors etc.

For example, comparing reddit to Digg:

Webslug

It is useful to compare versions of your own site, too.

Posted by Dion Almaer at 7:26 am
7 Comments

+++--
3.5 rating from 11 votes

Tuesday, July 8th, 2008

Spacius - Nintendo meets JavaScript - again!

Category: Games

Fellow Yahoo Matt Hackett took a leaf out of Jacob Seidelin's book and started converting old school arcade games to JavaScript. Instead of using Canvas his only "non JavaScript" solution is playing the music with Scott Schiller's Sound Manager (which, as we know, uses Flash under the hood).

You can come down with 8 bit shoot-em-up fever by clicking the screenshot.

Spacius by Matt Hackett

Matt also shows you what the score is and give some more game info on his blog.

Posted by Chris Heilmann at 4:41 pm
10 Comments

+++--
3.6 rating from 23 votes

Offline Access to Dojo Resources

Category: Dojo

Ever had a situation where you've desperately needed to get API information for your favorite toolkit only to find that the site is offline for some reason? The Dojo Toolbox aims to tackle this through the use of Adobe's AIR runtime. Built using the Dojo framework, the Dojo Toolbox allows for offline viewing of Dojo's API making it easy to have immediate access to the information, internet connection or not.

From search to easy navigation and cross-referencing, the Dojo Toolkit source code documentation can now be viewed everywhere you go. When future versions of the Dojo Toolkit are released, you will have the power to view multiple versions of the API within the Dojo Toolbox. We're also working on allowing you to view documentation for your own source code in a future release!

In addition, the Dojo Toolbox allows you to do custom builds of the Dojo framework as well as get a comprehensive list of learning resources all within the same application. This is a "must-have" for Dojo developers.

Posted by Rey Bango at 8:44 am
3 Comments

++++-
4 rating from 36 votes

Ext GWT 1.0: GWT 1.5 support, new APIs, performance, and docs

Category: Ext, GWT

Darrell Meyer has announced Ext GWT 1.0. This is the first fully stable release of the product and it includes a lot of goodies including:

  • Documentation: new screencasts of the various steps
  • GWT 1.5 support: "Ext GWT is a 100% native GWT application written in Java. Ext GWT does not wrap any 3rd party JavaScript and does not use any external JavaScript files. Ext GWT fully leverages the GWT API including the widget lifecylce, events, listeners, messaging, and RPC."
  • "Performance was a high priority item for the Ext GWT 1.0 release. Many changes were made since the first beta releases. Initial rendering times are quicker and the new layout code reacts quicker to window resizing. Improvements can easily be seen in the Explorer demo."
  • Advanced Form Layouts
  • Improved Data Loading, Store, Binder, and Field API

Looks like a very solid release indeed. Congrats to the team.

Posted by Dion Almaer at 8:15 am
4 Comments

+++