Archive for December, 2009

Opera on Mac gets new makeup; From 9.6 to 10.5

Dec 30

Posted by Pacoup in Uncategorized | No Comments

I’m seriously happy about Opera right now. Not only have they succeeded at keeping up with the technical updates, their browser is now finally another proud owner of a native shell on Mac.

This whole native shell movement really makes my eyes happy. Afterall, we did go from 9.6 to 10.5:

From the left to the right, Opera 9.6, Opera 10.1, Opera 10.5 Pre-Alpha for Labs.

10.5 also has a nice addition, smoothly animated tabs à-la-Safari.  We might see additional changes by the time this hits release, but it really makes me want to use Opera more. (Note, Opera 10.5 has other interface change niceties not covered here, but you get the gist of it; more animation and coolness, including for the first time being able to tab through checkboxes on Mac)

A note on speed

Opera Software proved once again that sheer technical expertise can surpass open source communities, as well Google on that note. On my computer, I got 393.2 ms for Opera 10.5 and 428.4 ms for Chrome 4 in the SunSpider JavaScript Benchmark, and it’s apparently even faster on Windows but I didn’t test that yet. Amazing.

HTML and CSS Discrepancies
Working around the W3C Box Model

Dec 21

Posted by Pacoup in Uncategorized | No Comments

Many thanks to Parakey for their Firebug Firefox Extension and to Opera Software for their Opera Dragonfly without which this CSS study wouldn’t have been possible.

If you’re an experienced web interface coder like me, the kind of guy who spent several years doing more than just toying around with HTML and CSS, you know that mastering these is pretty close to arcane magic. When using standards-compliant browsers, the CSS box model might not look logical. A lot of times I have faced issues where I thought the specifications were simply screwed up, but they are not. The real issue lies within the default CSS values established as standard.

It’s the real part that’s screwed up, but fortunately it’s easy to fix it and make it work the way it apparently should. The trick is to overwrite the defaults with your CSS style sheet. One marvel of specifying a higher than average amount of CSS rules is that even browsers like Internet Explorer 7 will end up displaying your web site correctly because a major problem in web standards is the default rule set. Hence, we’re essentially going to overwrite these defaults here.

Let’s start by breaking down this sample code:

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>CSS Box Model Test</title>
    <style type="text/css">
      .div01
      {
        width:150px;
        height:150px;
        background-color:blue;
      }

      .div02
      {
        width:150px;
        height:150px;
        background-color:green;
      }
    </style>
  </head>
  <body>
    <div class="div01"></div>
    <div class="div02"></div>
  </body>
</html>

This perfectly valid HTML 5 code will produce a blue and a green square like this:

What’s important to notice here is how the defaults specify a margin of 8px all around the body element. These defaults are what make HTML easy and very much helped its success. It avoids us having to specify tons of display properties. However, simplicity is always at the cost of control. Hence, designing very complex CSS layouts might result in a few headaches linked to surprise default values that weren’t expected. Unlike what we tend to think, most padding and margin values actually don’t default to 0.

To show what I mean, change the div02 to this:

<div class="div02">
  <h1>H1</h1>
</div>

And you get:

Take note here that we did not provide any padding or margin information to any of the squares for them to move down like this. If you see this in one of your complex designs, you might end up searching a complete afternoon for some discrepancies in your div blocks. The margin is actually on neither squares, those default to the expected 0px margin; it’s on the h1.

The problem lies in common mistakes made with the W3C Box Model, which differs quite a lot from the traditional box model older web developers might be used to. Quirksmode.org explains it very well.

Firebug can also give us insight at how the margin affects the result:

This is where it gets tricky though. The width of any text element like our h1 is predefined to fill its parent container from left to right. Our h1’s width is thus 150px. The height of any text element is predefined based on the font. In this case, it’s 36 px. This is shown by the green highlight around the h1. Our h1 also has a predefined top and bottom margin so to make it stand from the rest of the text. This is natural and removing this margin makes your text look cramped, but this margin is exactly where all the problem is.

In the W3C Box Model, there exists three ays to define extra spacing between elements; padding, borders and margins. The padding comes first, and is then followed by any border, and lastly by the margin. All of these elements exist outside the element’s width and height, meaning a 20px padding and a 100px width will equal a total width of 120px.

The border is self-explanatory, but the difference between a padding and a margin is more subtle and difficult to grasp. Layed down on paper though, it’s actually quite simple.

The margin is transparent and lies outside the border of an element. Even if the element has a border of 0px, it is still outside the border. A margin does not acquire the background color of an element.

The padding on the other hand lies between the border and the box of an element, or inside the border if you want. Hence, a lot of people like to call the padding a margin but for the an element’s content instead of the box. A padding acquires the background color of an element because it is part of the content (what’s within the border).

If we base ourself on the previously explained box model, then logically the h1 should be entirely contained within our green box, but it is not so. Why? Because the standards people screwed up. Wait, wait, you’re thinking, is this guy serious? Well yes I am, and all the evidence is there to prove it. In fact, a lot of modifications we can do to the code clearly demonstrate how every single browser manufacturer, probably due to the people who made the ACID tests, communally screwed up on this and manufactured a giant bug.

To understand how this bug works, let’s first look at what the result should look like:

To obtain the following, I replaced the 21px margin with a 21px padding like so:

h1
{
  margin-top:0px;
  padding-top:21px;
}

Doing so does provide a quick fix, but not in the event you’d be using a background for your h1 element. While such an occurence is rare, major web sites like Engadget use this background technique to make their links’ roll-overs. Replacing the margin with a padding would completely screw up their design by incurring a huge extra highlight on the text like so:

The real way to circumvent the problem is to use the box model in a way that doesn’t include the bug. Weirdly enough, this is quite easy and proves that it really is a bug. Simply add any padding or border to the affected box and voila, problem solved:

.div02
{
  width:150px;
  height:150px;
  background-color:green;
  padding-top:1px;
}

But just for the sake of it, I’ve made another example that demonstrates how this can only be a bug.

<!DOCTYPE html>
<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
    <title>CSS Box Model Test</title>
    <style type="text/css">
      .div01
      {
        width:150px;
        height:150px;
        background-color:blue;
      }

      .div02
      {
        width:150px;
        height:150px;
        background-color:green;
        color:white;
      }

      .div03
      {
        width:150px;
        height:150px;
        background-color:red;
      }

      .div04
      {
        width:100px;
        height:100px;
        background-color:yellow;
      }

      .div05
      {
        width:150px;
        height:150px;
        background-color:black;
      }

      .div06
      {
        width:100px;
        height:100px;
        background-color:yellow;
        position:relative;
        top:16px;
      }

      .div07
      {
        width:150px;
        height:150px;
        background-color:blue;
      }

      .div08
      {
        width:150px;
        height:150px;
        background-color:green;
        color:white;
        margin-top:20px;
      }

      .div09
      {
        width:300px;
        height:400px;
        background-color:red;
      }

      .div10
      {
        width:200px;
        height:140px;
        background-color:yellow;
      }
    </style>
  </head>
  <body>
    <div></div>
    <div>
      <p>Paragraphs are also affected</p>
    </div>

    <div>
      <div><p>This…</p></div>
    </div>

    <div>
      <div><p style="margin-top:0px;">should technically do this.</p></div>
    </div>

    <div></div>
    <div>Any block following another block with a margin is affected. This text doesn't have any margin.<br>
    The box does.</div>

    <div>
      <div><p>The first block remains intact or influences the one on the previous level if it exists as it is in this scenario.</p></div>
      <div><p>The second block follows the bug partern.</p></div>
    </div>
  </body>
</html>

Since it is possible to reproduce this bug at all times under specific conditions, it is clear this is a manufactured bug that has been hidden away as standard. If someone believes this is not a bug and that there is a logical explanation to this behavior, please post a comment and explain! (One from Håkon Wium Lie would be appreciated)

A Google Phone doesn’t have to be the death of Android

Dec 17

Posted by Pacoup in Uncategorized | No Comments

Micheal Gartenberg has had a bit of fun saying the Google Phone could be the death of Android. The rumored Google Phone is a would-be carrier-free (unlocked) phone built by HTC and sold directly through Google.

As Micheal points out: “Until someone can give me a ten-word answer to how Mountain View can manage to build an ecosystem while trying to compete with it, I will remain skeptical that the Google Phone ever comes to market”, it’s going to be hard selling that phone on the market without killing the Android ecosystem.

But as much as I’d like to believe Micheal’s great insight, my own insight says something quite different.

First of all, what ecosystem? The Android platform is just hot on paper right now. Its market share pales in comparison to the iPhone and is playing catch-up with BlackBerry. Sure, it’s quite obvious Android will be rivaling the iPhone in two years, but in two years.

Secondly, why can’t Google sell its own device? “Apple’s tried this [...] with the Newton” and failed, says Micheal. But it’s as if he was ignoring the fact that Apple did try again with the iPhone and clearly didn’t fail. The premise on which Google would kill the Android for selling a better Android phone is just plain stupid. I don’t even have to explain why it would work. Google has always worked that way; if you can’t do it as we wish, we’ll do it for you and steal your market in the process.

I’m pretty sure Google doesn’t care about Motorola, and clearly this is going to benefit the like only other major Android phone maker, HTC, because hey, they do manufacture the phone in question! Think about it, that’s HTC selling its own device without having to provide any kind of software support whatsoever. That doesn’t sound like killing a partner in my opinion, but more like giving heaven to them.

Google has long shown that the Microsoft way of thinking “don’t compete with your own market” only impedes on innovation and eventually market success. Google constantly competes with itself, making the life of everyone easier at its own cost, a very good example being the ability to use Gmail as a Pop3 client. But they don’t care, because that does only one thing: bring more people into Google and eventually give Google more money because it builds into their ultimate advertising ecosystem.

In other words, I can’t see the Google Phone as anything else than a tremendous success. And besides, the Android platform will still remain open and liked of everyone. Whether Google conquests the smart-phone market with an array of half-working crap devices from every manufacturer in the world or its own very good phone doesn’t quite make the world different; in the end, Android is taking over, and open source technologies are too at the same time, making everyone happy, except Microsoft, Apple, RIM and Nokia.

Bing Maps Betas its Way to Silverlight

Dec 14

Posted by Pacoup in Uncategorized | No Comments

I’ve just stumbled on the Silverlight beta for Bing Maps this morning while making my daily new-feature check routine and let me tell you this makes you want to develop with Silverlight.

The experience is smooth like no other. Essentially, the Bing Maps beta replaces all the JavaScript graphics work by Silverlight. The result is an obviously tremendously faster and animated map experience. There’s even StreetView, eh, I mean SideView…

Nevertheless, the results on Bing Maps still aren’t on par with Google’s offering, and Google has a much bigger StreetView coverage. It’s nice, and I had to mention it, but I’ll keep using Google Maps as long as it’s the only Mapping Application capable of finding where I live by only typing the street name (and then again, you’d be surprised at how much it’s difficult to find a house in a major urban center with Bing Maps).

Learn Java the Awesome Free Way

Dec 11

Posted by Pacoup in Uncategorized | No Comments

In my new career as a Java developer, as I’m French, I’ve been using the siteduzero.com’s Java tutorial. Actually, that’s just when I didn’t want to get my big Deitel and Deitel book out, but seriously, forget about SiteDuZero’s crap. I’m really sorry for the author, but as a message to you: “Your code sucks”.

All that said, if you want a serious and reliable source to learn Java, just try Java Tutorials! It’s an official publication from Sun, it’s free, and it’s more than complete (check out that massive index). You can even buy it in book form.

The only hiccup with this is the coding style. While K&R might be Java conventions, it might not be your cup of tee. I know, I’m allergic to K&R too and I prefer Allman. If you really can’t look at Sun’s code, there’s always Deitel and Deitel’s Java books.

Note: This does not cover Java EE. For that go to the Java EE 5 Tutorials (lol, it’s amazing really, they have it for like everything).

Enable Explicit Error Reporting in IIS 7

Dec 8

Posted by Pacoup in Uncategorized | No Comments

Well, after trying to find out via Google, I gave up with the stupid answers from dumb ASP.net programmers such as “VBScript is not a server-side language” or “you can’t run .asp on IIS 7″.

Sure…

So for the curious, here it is:

  1. Start
  2. Search for Internet Information Services (IIS) Manager
  3. In Debugging Properties, set “Send Errors To Browser”  to true
  4. Don’t forget to click “Apply” under the Actions panel on the right

That’s it. IIS will now shoot the runtime errors directly into your browser window instead of saying something went wrong with the URL. I’m pretty sure this is on by default in previous IIS versions, hence the confusion.

You might also want to turn on “Enable Parent Paths” in the Behavior section, which will enable the ..\ relative path notation. Frankly I don’t know why this is turned off by default… but hey, we’re talking classic ASP here. It’s not like Microsoft really cares.

Google Chrome, Now in Mac and Linux Flavors

Dec 8

Posted by Pacoup in Uncategorized | No Comments

Google Chrome is out in beta for Mac and Linux. The real surprise is Linux; only heard rumors of the one for Mac.

I’ll post a review here later.

20 Years Early; Java Applets

Dec 4

Posted by Pacoup in Programming | 3 Comments

Flash Wasn’t

Sun’s Java Applet technology was 20 years early, but Flash wasn’t. Two years after the Java Applet technology first appeared, which enabled Java bytecode to run directly in the browser, Macromedia came in with Flash (technically one year before but they bought it and then re-released it as version 2 under the Flash name).

When Flash came out, unlike Java, it only featured very basic functionalities. It even took until 1998 before Flash could support any kind of scripts to customize interactivity. But that was all it took to fire it up for the web. It was small and quick, unlike Java which was quite the beast, and solved the purpose of achieving richer content on a web which at the time wasn’t even fast enough for streaming video.

Simply said, Java’s power wasn’t needed on the web. Even today, Java is still a bit too powerful for what people are looking for on the web, which is why applets are 20 years early, not 15 years early.

And so, Flash rose and was eventually bought by Adobe right along the introduction of video capabilities, which helped YouTube make streaming video on the web something everyone takes for granted just a few years later.

The Rise of the RIA Frameworks

In 2004, all the rave was about Web 2.0. YouTube was on the verge of being launched, Google Docs’ first iterations were right around the corner and the push for web standards was the brand new thing with Firefox. Thus, companies started to make bets on the technologies that would power Web 2.0. Adobe bought Flash and created Flex and Air, while the W3C thought about XHTML 2.0 to re-invent the web, and Google and company placed their bets on AJAX and HTML 5 to power their rich internet applications.

Make no mistake, HTML 5 is a much a contender in the RIA race than Flex is. Afterall, RIA means Rich Internet Application. This means rich media, like HD videos, and rich functionality, like editing documents in the browser. Both Flash and HTML 5 allow this as a platform.

Somewhat late to the game, Microsoft came in with Silverlight and Sun with JavaFX. Now, from the perspective of a web rich in web, Silverlight’s effort at making video and audio capabilities at the center of its aplication is intelligent, despite being late, but Sun’s JavaFX seems a bit incomprehensive and again, too much of a dog for the application its supposedely meant for.

RIA vs HTML 5

Unfortunately for Adobe, Microsoft and Sun, the web industry is moving away from plugins. Native is considered the new king and Google is leading the way with the fastest JavaScript interpreters ever seen and advanced HTML 5 features being used in Google Docs and even more so in Google Wave, making slow-to-adapt browsers like Internet Explorer irrelevant for the future.

The future of the web is as a platform, and a platform has to be capable to run applications on its own. With the release of the Google’s Go language and the impeding one of Chrome OS, the step towards pure cloud computing is even closer.

You can often hear a lot of people argumenting that Silverlight is incomplete because it does not offer a desktop alternative like Adobe does with Air. But Air is irrelevant; we live in a evermore cloud-based world and the future of desktop applications is bleak. This is something Microsoft might have surprisingly understood with Silverlight; that there is no point for Silverlight’s developement to enable it to go off the browser. It would be lost effort since the real future is in the cloud and on the browser as the new platform, not on the operating system. But because Microsoft makes Silverlight part of the whole .NET family, and WPF (Windows Presentation Foundation) largely serves as Silverlight for the desktop, but on Windows-only, obviously, you could suppose that Microsoft’s disregard of offline capability with Silverlight is but a coincidence along the way.

Wether there is a place for RIA frameworks based on plugins in the near future is to see, but a native approach, say the ability to run Google Go compiled apps directly in the Chrome browser, and Chrome OS as well, without a plugin, is very enticing, especially on the performance front.

The Need for Speed

JavaScript is already dead. It’s not fast enough, nor is it complex enough to handle complex applications with ease (see Object-Oriented Programming). Although Google seems not to think so, I’d rather think Google thinks exactly the same thing. The impending Google Chrome OS and their seemingly out of the blues move with the Go programming language is not a coincidence, it’s exactly what Lary Page and Sergey Brin are so obessed about: making the world more efficient.

Since the web, and more specifically Google, is moving towards open standards and ways to develop RIAs without plugins, nothing makes more sense for Google than to develop a compiled OOP alternative to JavaScript that would run natively in the browser.

But what’s more important is the emphasis on the need for speed. For today’s current web apps, JavaScript is plenty sufficient. More sophisitcated web apps like Aviary’s image editing suite don’t find enough there so they go to RIA frameworks like the Flash Platform. But then again, those platforms are too slow and too media oriented.

The need for speed might not be apparent today, but it will be in 2015, 5 years after the Chrome OS launches. 5 years is what it took for Firefox to completely change the landscape of web standards on the web. With technology evolving even faster than before, imagine what Chrome OS could bring as a change in the next 5 years.

Take Adobe Photoshop or Autodesk Maya or even games for example. Since all of these are high performance applications, it’s unimaginable to see them as real competitors in the form of web applications today. Software that applies to the professional creative market is still thought to be king on the desktop, but this is bound to change in the years to come as the need for cloud computing increases, and it makes the need for speed all the more present.

Adobe Flash and Microsoft Silveright might make very cool rich media apps, but their performance and capabilities, especially the sandbox restrictions, are not enough for the this future.

High Performance Applications are not gimmicks

For a lot of people, the lack of ease of GUI design in JavaFX makes it stucks a lot in comparison to Flash and Silverlight, which both comprehend complex and complete suites of design tools to aid in the process. But when it comes to high performance applications like Photoshop, nobody cares about GUI design tools or how well you can do stuff without having to code.

Actually, nobody wants it because it impedes on capabilities and performance capabilities. When it comes to developing software that requires amazing amounts of computing power, the last thing you want is for a framework of some sort to impede on your development. The GUI comes afterwards, and is an easy thing for experienced developers to integrate. These applications are not made on super quick schedules by three fresh out-of-college students with their small web site production start-up.

Hence, these applications are still developed with C++ as we speak. In fact, even applications that don’t require much of that performance, like Google Chrome, are even developed with some parts in Assembly code to make it really faster. We’re talking Native. The developers of these applications have no interest in faster development, they want their software to be faster and more capable, something achieved with more efforts, not smarter but lower-performing code.

Java is powerful but nobody knows

JavaFX and Java Applets are just about the same thing. They only differ in that JavaFX uses a new script that is a little bit less do-it-all than true Java and a bit more RIA-oriented, along the likes of ActionScript 3. But like Applets, it runs on Java.

When it comes to JavaFX though, I often hear, and I said so myself before, that it sucks because there’s not enough graphics tools. Not enough support for video and multimedia, etc. I often hear that it sucks because it takes too long to load, because it’s allows to much and can’t run without asking the user for permissions.

In other words, JavaFX, as well as Applets, can’t be logically used on a web site to power regular video streaming, interactive advertising banners or other similar small tidbits you might want to add in Flash or Silverlight on your site, like a really cool animated menu.

If you come to the conclusion that Java on the web is dead because of this, you’re far off what Java could potentially really power. Java is more powerful because for one, it is more performant. Java has access to tons of libraries, like OpenGL, which can allow sophisticated 3D games to run directly in the browser as well as all sorts of other high computing power software.

Take Photoshop for example. It’s not instantaneous piece of software to boot, and nobody expects it to be. When you open Photoshop, you’re usually going to use it for quite a bit of time. The time to boot the software then becomes irrelevant and you also need to install it first, which also requires you to accept that Photoshop might harm your computer by having more access to it for the sake of making the piece of software more useful.

You wouldn’t distribute news through PSDs (Photoshop’s file format), would you? Well saying you’re going to make a news site with Java Applets or JavaFX is pretty much the equivalent. You just don’t do that. And that’s where everybody gets JavaFX wrong.

Just look at the way JavaFX apps need your permission to run because they require more access to your computer. Sounds familiar? It should. That’s exactly what a desktop application does and that’s exactly what JavaFX is doing. It’s empowering you with all the power of Java inside a browser, under a new brand of Applets, to make high performance applications, or RIAs, possible on the web.

5 Years Early; JavaFX

Essentially, JavaFX is a move by Sun that recognizes Applets weren’t at their time. Whether JavaFX was really meant as a competitor to Flash-class applications is unknown to me, but I can assure you JavaFX and Java in general pose a real threat to any future competitor in the field of cloud-based high performance applications.

In fact, it doesn’t even pose a threat, because no one has yet to create an equivalent platform. Google might do it, but as far as it goes, it looks like Go will be remain on NaCl (Native Client), which is a plugin too, and has nowhere near the support and community of developers that Java does, not to mention libraries and stuff.

If Google is to make Go native on their browser, they still have ways to go to make developers accept it. Reactions to the Go language were largely negative on most parts, with most developers affirming that if Go was to be a compiled JavaScript, that it would need to be developed by the community and not as a Google product.

The game of developement platforms is played on two parts; developers and platform-makers. Developers are a very powerful croud. They can push web browsers to near ridicule around the globe and they can decide whether your platform succeeds since the platform utimlately relies on developers making software for it. On the other hand, market forces can trump a developer’s will. For example, the ability of Apple to sell the iPhone with key apps on its first iteration and rapidly gain market share made it a no-brainer for developers. If you want to rake in the cash on mobile apps, the iPhone is the way to go. The same applies to Windows with video games. You don’t see much video games being developed exclusively for Mac OS X or Linux.

Google is unfortunately not in a position where its new platform could grant it power. Even worse, the web industry is extremely fearful of the past and will run away from any solution that doesn’t promess to be cross-platform. For example, if Microsoft was to make C# apps native on Internet Explorer a-la-VBScript, people would start throwing rocks at them. If Google is to start a native non-plugin approach with Chrome and Go, it has a seriously hard challenge ahead and better make all the efforts possible to make this technology available plugin-less with the rest of the Linux community, which means Firefox and Safari, and somewhat Opera since it is a very standards-oriented browser well respected among web developers.

If it is to be a plugin, developers will also refuse it. Remember the movers of the web developement community are trying to push away from plugins and away from Flash. Silverlight might be used commercially, but it has largely been ignored by the rest of the world. Flash is already everywhere, why go all the trouble with Silverlight.

And that’s where Java comes in

Java is everywhere too. Java is even more everywhere than Flash as it is an open technology. Yes, contrary to both Flash and Silverlight, Java is open source, and it’s included on every Mac and Linux machine, which incidentally also means Chrome OS. Java is also easily downloable on Windows and most often pre-installed on OEM PCs and business PCs given to government and enterprise users.

In fact, a computer without Java is bound to ecounter some compatibility issues while surfing the web or installing applications. Much like Flash, Java is considered an essential peice of software to have on one’s computer.

When it comes to developing high performance web apps, remember the time to boot won’t matter much, so JavaFX or Java Applets are perfect for the performance benefits gained afterwards. The same goes for games.

Java is also an incredibly vast platform. It includes everything from server to desktop to the web browser plugin. One developer could learn Java and theoretically be able to program for all of these different platforms to make a wonderful all-in-one piece for a web app project. No need to learn the awkward marriage between Flash and PHP, which is by the way also pretty slow, and no need to learn a platform of which you don’t have access to the inner pinnings because it is proprietary like .NET and Silverlight.

Java can power your server-side and your client-side and talk to all of its pieces in wonderful harmony. But what’s especially important in Java, besides its librairies, is that once it’s bytecode, it does not matter where it came from. Program in Scala, Ruby, Python or anything you like; it does not matter. The JVM takes it all, client and server-side.

So while Java might not be the utlimate solution for small web page stuff, it’s quite the solution for future cloud-based professional applications. You might not see the future versions of Office in Java, but I can bet that if Google doesn’t trump it with Go, it will be a major platform for these types of software. And even if Google does trump it, it pays to start developing now because you’ll be first to market and you can be garanteed it will work on Chrome and Chrome OS. Java is a requirement for any computer, and I’m sure Chrome OS will not be of exception. It would be like Chrome OS without Flash if they were not to include it, so Java is far from dead.