Thursday, September 11, 2008

IE Background Image Problem

Imagine that, you have a blog and you are designing a new rating system, where you will use the golden stars to rate your entries, then you made an HTML prototype to create the layout of your new rating system, and here is the code you have written:

  1 <html> 
  2     <body> 
  3         <h1> 
  4             <div id="stars"> 
  5             </div> 
  6             How is the BG IMG fixed in IE 
  7         </h1> 
  8     </body> 
  9     <style> 
 10       #stars{ 
 11         height: 20px; 
 12         width: 100px; 
 13         float: right; 
 14         background: url("star_on.png") repeat; 
 15       } 
 16     </style> 
 17 </html>

The "star_on" image you are using is 20 x 20 px, the hieght of the stars DIV is 20px to fit with the image, the image is set to repeat and the width is set to 100px so that you will see 5 stars.

So far we have done coding, the next step is to test this on the browsers to be supported, in different browsers it is working well ( tested on safari, opera, FF and chrome ) and here is how it is displayed:

Good Rating

When it was the turn for the lovely IE and its unique rendering engine, it decided to render the markup as seen below:

Bad Rating

Note that the problem is that the image is repeated vertically and go beyond the 20px high DIV it should display within...

Lets start with the fix and then see why IE decided to extend the image,

The Fix is to adjust the font-size property for the rating DIV :

  1 #stars{ 
  2   height: 20px; 
  3   width: 100px; 
  4   float: right; 
  5   background: url("star_on.png") repeat; 
  6   font-size: 1pt; 
  7 }

But why on earth the font-size is related to the BG image ?!

In fact, the problem is when IE pass by an empty DIV in the markup it assume anon-breaking-space inside the DIV, then accordingly it applies to it the nearest inherited font-size, in our case the H1 font-size; which is larger than the 20px hieght so the BG image found some more space to sneak into.

So to solve this you had to override this font-size and adjust it to have your backgroung image displayed correctly!

Friday, August 15, 2008

Worlds First Photo

1pic Worlds First Photo

The worlds first photo was taken by Joseph Niepce in France in 1826. It took an exposure time of 8 hours and is on an 8″x 6.5″ pewter plate. The photo has been on display at the University of Texas since 1964.

firstcolorphoto Worlds First Photo

The above photo taken by Louis Ducos du Hauron in 1872 is said to be the worlds first color photograph. The photo is of a view of Angouleme in Southern France.

Find more here : http://www.hrc.utexas.edu/exhibitions/permanent/wfp/
And here : You think your camera is too slow?

Saturday, July 26, 2008

Which programming language I am?


You are Prolog. You enjoy looking for different ways to solve a problem.  You take longer to solve them, but usually come up with more than one solution.
Which Programming Language are You?

Thursday, February 28, 2008

JavaScript Interfaces and Duck Typing

A C++ virtual class or a Java interface provides a mechanism to define a contract concept in code. We always speak of the interface as a contract between different components of software; this can provide good separation of concerns. JavaScript has no formal concept of an interface, so how can we do it?

The simplest approach is to define the contract informally and simply rely on the developers at each side of the interface to know what they are doing. Dave Thomas has given this approach the name of "duck typing" —if it walks like a duck and it quacks like a duck, then it is a duck. Similarly with our Shape interface, if it can compute an area and a perimeter, then it is a Shape.

Let's suppose we need to add areas of two shapes, in Java this could be look like:

public double addAreas(Shape s1, Shape s2){
return s1.getArea() + s2.getArea();
}

Java is type strict so the method signature will forbid passing any other objects rather than a Shape, but in JavaScript there is no guarantee :

function addAreas(s1,s2){
return s1.getArea() + s2.getArea();
}

Another way of thinking: JavaScript is highly customizable so lets plugin our interface mechanism in the Object prototype:

Object.prototype.implements=function(funcName){
return this && this[funcName] && this[funcName] instanceof Function;
}

Here we have three check points:
1. there is an Object
2. that has the specified Name ( each JS object is considered as an associative array )
3. and at last it is a function

This allows us to have our interface definition:

function isShape(obj){
return obj.implements("getArea") && bj.implements("getPerimeter");
}

If you notice the java method above there is a single check missing to complete our interface : the return value. With the current interface you can not guarantee that these two methods are returning doubles or double string representations, we can never know this in JS until we invoke the functions.

So we need another check point for the type:

function isNum(arg){
return parseFloat(arg)!=NaN;
}

At this point we have completed our Shape interface, we can rewrite our addAreas() function like this :

function addAreas(s1,s2){
var total=null;
if (isShape(s1) && isShape(s2)){
var a1=s1.getArea();
var a2=s2.getArea();
if (isNum(a1) && isNum(a2)){
total=parseFloat(a1)+parseFloat(a2);
}
}
return total;
}

we have used parseFloat here, so if a1="12" and a2="34" we don't get "1234"

In summary, duck typing keeps things simple but requires you to trust your development team to keep track of all the details. Duck typing is popular among the Ruby community. As one moves from a small team to larger projects involving separate subgroups, you can not rely on this trust, and you may want to add a few checks and balances to your code on top of duck typing.

Thursday, February 14, 2008

Compile and run Java code in a Java program

With the new Compiler API introduced in the JDK SE 6 it is possbile to compile Java code in a Java program.

Start by making an instances of Java Compiler and Java File Manager.

JavaCompiler jc = ToolProvider.getSystemJavaCompiler();
DiagnosticCollector dl = new DiagnosticCollector();
StandardJavaFileManager sjfm =
jc.getStandardFileManager(dl, null, null);


After that you make a compilation task for the Java compiler, it is possible to add more then one task to the Java Compiler. The getJavaFileObjects method accepts a variabel amount of parameters, this way you can pass more then one file. Don’t forget to close the Java File Manager when you no longer need it.

File javaCode = new File("c:/java/CompilerTest.java");
Iterable codeObject = sjfm.getJavaFileObjects(javaCode);
jc.getTask(null, sjfm, null, null, null, codeObject).call();
sjfm.close();

When there are no errors in the CompilerTest.java you should have a compiled version generated beside your java file. When you need to have the class file generated some other place you’ll have to add some options to the compilation task.

String[] options = new String[]{"-d", "c:/java/classes"};
jc.getTask(null, sjfm, null, Arrays.asList(options), null, codeObject).call();

After compiling the Java code you can load the class into a running program.

File classesMap = new File("c:/java/classes");

URL[] urls = new URL[]{classesMap.toURL()};
URLClassLoader ucl = new URLClassLoader(urls);
Class clazz = ucl.loadClass("the.package.of.the.class.CompilerTest");


Note: you need JDK 6.0 jars to run the code

Saturday, January 19, 2008

Top 10 Javascripts for Image Manipulation

Reflex
Reflex.js

This javascript enables you to add a cover flow effect to any image on your web page. You can add reflection, tilt angles and also borders to your images. The results look like this:-

Reflex Image

Curl
Curl.js

This is an unobtrusive javascript to add page curl effect to your images and works on all the major web browsers. It can also produce the curl on mouseover where it animates the effect. Here is what it can accomplish:-

Curl Image

Edge

Edge.js

This javascript can help you in adding nifty edges to your images. You can even mask a second transparent image to generate some nice looking eye candy. I was able to make the script do this:-

Edge Image

Corner
Corner.js

This javascript lets you add effects to your image corners like rounded corners, shadow (both inner and outer), shading etc. This is what can be done using this javascript :-

Corner Image

Slided
Slided.js

You can add slide frames to your images by using this javascript in your web pages. I am sure it can be useful to some people. This is what I came up with:-

Slided Image

Glossy
Glossy.js

Add a glossy effect to your images to make them stand out. This javascript also allows to add corners, shading and shadow. Here is my result:-

Glossy Image

Filmed
Filmed.js

This javascript allows you to add film strips around your images. You can also add shadow and shine to your film strip edges. This is what it looks like:-

Filmed Image

Loupe
Loupe.js

Did you ever want to add a lens to your page which will let you zoom into the images. This script will let you do that and much more using two versions of your image. Here is a preview:-

Loupe Image

Instant
Instant.js

This javascript lets you add an instant picture effect to your images. You can add border, tilt and shadow to give your images that photo effect which you always wanted. Here is a sample:-

Instant Image

Bevel
Bevel.js

This javascript simulates a whole bunch of effects! It allows you to add bevels with glow, shading and shine to your images. Here is the javascript in action:-

Bevel Image

Thursday, January 17, 2008

10 Reasons Why the Command Line is More User-Friendly than the Desktop

I aim all of these not just at Linux, BSD, and Unix-alikes, but at every computer system ever. Nor do I say all of this as a power-using geek, but to apply it to every computer user everywhere.

1. Keying is faster than mousing.
You might argue this point, and if you do, I'd just point out "Why are there keyboard shortcuts on most menu entries in a GUI?" And why are they called "shortcuts"? Because using a mouse to do something is the long way to do it, each and every time.

2. It's easier to both give and get help.
Nearly every Debian system has synaptic, and I'll bet most people use it. Yet even amongst synaptic users, they'll still answer questions with an "apt-get" statement. It doesn't matter if you use apt-get or synaptic; it's still more efficient to use the command expression behind the GUI action to answer questions online. You can interpret the answer into the GUI tool of your choice.
Ever seen somebody answer a question that has no command-line answer? "Go here, double-click that, click this pull-down, click the arrow, click 'yes', click 'edit', double-click this, that, highlight this..." And this applies on Windows as well; even there it's easier to define an action in DOS commands than it is to describe mouse actions.

This is why our mail is addressed to our house, instead of having instructions to the postman: "Go down main street, turn left, go to spruce street, turn right, go to the eighth building on the right, go up the stairs...".

3. Repetitive stress injury comes from the mouse, not the keyboard.
Do something that uses the keyboard for awhile, then do something that uses the mouse for awhile. How do your hands feel? I especially notice that when I play a game like Diablo or Starcraft, my right hand is cramping terribly after a few hours. But I can play Nethack all day and not feel any pain at all. It stands to reason that if you filter the work of both hands and ten fingers through one wrist and three fingers, you'll have more repetitive motion stress.

4. Commands are standard where GUIs are not.
How do I find a word in a document using a GUI? Do I click "edit - find and replace"? Do I click "view - find"? Do I click "find - search page"? Does the dialog pop up, or does it pop in from the side, or does it show up in a bar at the bottom? Do I have to click close afterwards, or will it close itself? Is the 'find' dialog separate from the 'replace' dialog, or are they combined? Does the dialog on the program understand a regular expression? It all depends on which program you're using - and often which version. And - again, no matter what platform - there's a dozen possible GUI tools to do the same thing with complete feature overlap. Which one do you have available?

How do I find a word in a document using a command line? Grep! I learned grep once in 1998 and haven't had to open the man page since. I'll still be able to use grep 20 years from now. Every Unix-based system has it, even Macs and Windows has it available, and it's always the same from platform to platform.

5. Commands are more powerful.
I don't care how well-designed the GUI is, there's always something you need to do that they forgot to put in a menu item for. But commands can be adapted to many purposes. Especially when you have to do the same action many times. Go ahead, resize a bunch of images to thumbnails in your GUI tool; you'll be working all day while I can type out an Image Magick incantation in one minute and go take a nap while it does it all automatically.

How about editing a document where you need to change all instances of something, except where a special case is true? Unzip a stack of downloaded files, rename them all to a specific scheme, and move them all to different directories? The GUI is good only for limited-use cases and specific actions, but it only takes you that far.

6. You can automate commands.
Really, you only have to learn each command once. Then, no matter how complex, you can save it in a shell script, run it from a menu item, execute it from one key-press, or even give it to cron to perform automatically. There is no computing job on Heaven or Earth that cannot be reduced to a single motion, given a proper scripting environment.

7. Commands are easier to remember than clicks.
Face it, our brains handle words better than they handle spacial sequences of motions. How many times have you tried to show somebody else how to perform a mouse task, only to realize that without sitting in front of the machine doing it yourself, you can't remember how it goes? Learn a command and it's yours for life.

8. GUIs are always changing.
Everybody wants to re-invent the widget set, patent the scroll wheel, re-think the dialog, put their own stamp on the GUI environment. Bring up GUI design, and there's a flame war all over the place about simple things like where a menu should go and whether to use a spin-box or a combo-box. Commands have been performed the same way since the keyboard was invented, end of story.

9. Commands are more error-safe.
All I ever hear is how you can accidentally type "rm -rf ./*" or "del *.*" in the wrong place and wipe out your file system, but look at practical experience. How many times have any of us actually done that? Now, how many times have you clicked 'yes' or 'allow' to the wrong dialog, clicked the wrong button and closed a window when you meant to minimize it, opened the wrong file in a dialog, selected the wrong action in a menu, had to make three tries to drag a selection box around a group of files, dragged and dropped a folder to the wrong place... the list goes on and on. Mousing takes intense co-ordination and concentration to hit a target a few pixels wide, and in the event of a mistake the wrong action is always performed instantly.

A command line does not fire off until you hit enter. So you can read it after you've typed it to be sure it's what you want to do. You can edit it before you execute it. And your brain is actually engaged in the task, instead of focusing on performing millimeter-precise actions with a few muscles in one hand.

10. You have to type to use a computer anyway.
You can get quite far on a computer without a mouse, as long as the programs are set up to accept keystroke commands. But try this: unplug the keyboard and hide it. Now, how far did you get using the computer? How can you IM, email, edit, comment, name files? No matter how much you love your GUI interface, you still spend the bulk of your time using a keyboard.

Friday, September 14, 2007

Who To Block, Internet Explorer or Firefox?

A short time ago I came across a website, while using the Firefox extension StumbleUpon, which advocated blocking Internet Explorer users from your website. And then, ironically enough, I recently came across another website, also while using StumbleUpon, that advocated blocking Firefox users from your website.

While at first glance, this seemed to be a simple “whose is bigger” kind of fight, I soon came to realize it ran much deeper. Both groups have some valid concerns, and both groups seem to believe in their cause wholly. But why would anyone want to effectively block a large portion of their potential customers and readers?

Advocates of blocking Internet Explorer claim it’s because of the inferior code rendering engine employed by Internet Explorer. And I, as a web developer, can definitely understand that. IE has a great deal of bugs when rendering code; a lot of commands that work in every other browser will not work in IE.

For example, take the following code:


<html>
<head>
<style>
#centercontent{
width:600;
Margin:auto;
}
</style>
</head>
<body>
<div id=”centercontent”>
Lorem ipsum yada yada yada
</div>
</body>
</html>


In any browser except Internet Explorer that would display a 600x600 pixel square content box in the center of the screen, with the words “Lorem ipsum yada yada yada” written inside. But, in IE, it would display the same box on the left side of the screen. This is because it doesn’t properly render the box using the “margin” property.

In order to get the exact same box in IE, you’d have to use this code:


<html>
<head>
<style>
#iecenter{text-align:center;
}
#centercontent{width:600;
Height:600
Text-align:left;
Margin:auto;
}
</style>
</head>
<body>
<div id=”iecenter”>
<div id=”centercontent”>
Lorem ipsum yada yada yada
</div>
</div>
</body>

</html>



That may not seem like that big of a deal, and it’s not, most developers do it without thinking now. But, that is just one example. There are many other instances like that in which IE requires a lot of extra code, just to display the exact same thing that would work in any other browser.



But, according to the opposing group, Firefox is not without its faults. The problem with Firefox stems from the use of the Adblock extension. Basically, the Adblock extension removes all ads from a website. For the obvious reasons this hurts the revenue of website owners. The only way to block Adblock users is to block Firefox completely.

So who do you block? I say neither.

Although I dislike having to write the extra code required to make my websites display properly in Internet Explorer, I don’t feel as if I have to place to say who can and can’t visit them. If web developers don’t feel like they should have to write extra code, then they shouldn’t. They should simply leave the code how it is, and let IE users deal with a page that does not display properly.

I will not block Firefox users because they make up such a large majority of my traffic. The StumbleUpon extension is my number 1 traffic source, and its users make up about 80% of my traffic. In total, Firefox users are about 90% of my readers. Blocking all of them, just because of the small portion who use Adblock, would hurt my revenue much more than it would help.

In addition, I again do not feel like I have the right to block users, simply because they choose not to view the ads on my website. The internet is all about free information, and I’m willing to give up a portion of my profits to uphold that.