Sunday, November 15, 2009
Saturday, November 14, 2009
Not my work... got from net.
How great minds work (:o)
They were playing a game called 'Asteroids' in a mainframe (a computer used by many people simultaneously), and because of the congestion, the game was slow and they couldn't control their spaceship and got hit by asteroids too frequently. Their friends started making fun of them and though it was not their mistake they took it personally and decided to show them their real talent in the game.
For this they needed a better computer, and since they were working at AT & T labs they had plenty of them to choose from (I am talking about an incident taking place around 1970 here... this is before the time of the PC). They got hold of an unused one but unfortunately that computer did not have an OS! So our frieds Brian and Dennis decided to write an OS for it (man... what sort of gaming freaks!!! writing an OS to play a game).
So they sat and wrote an Os in assembly language on some other computer (lets call it the 'testing' computer to prevent confusions later on) to test it and got it ready. But now to install the OS in there gaming computer they need to translate the program to its assembly language. So they decided that instead of unnecessarily reinventing the wheel, if they use a high level language to write their OS, all they would have to do is install the compiler of the language in the computers that they wish to install the OS. So they sat about designing a new language, and for it a new compiler. Then they installed the compiler in the gaming machine as well as the testing machine, tested their new OS in the testing machine and installed it in the gaming machine, played 'asteroids' and lived happily ever after.
Their language was called C which is now used to write the code for games because of the high processing speed (This leads to a rather perplexing question... what came first? computer games or C... thats an example of an obscure joke :)... read through the post 'what orkut meant' for more details).
Almost all the inventions in history took place as a result of a chain of necessities starting from a very simple need or as a search for a very trivial problems in life. We all are waiting for a big opportunity to do something great, but are ignorant of the small ones that that cross our path everyday
My all time fav piece ....
Friday, July 10, 2009
Sunday, June 28, 2009
Historical Origins
In 1991, Sun Microsystems created a research project that was code named Green. The project's purpose was to
create a language that could run intelligent consumer electronic devices (set top boxes). The project resulted in an object-oriented (C- and C++ based) language that it's creator, James Gosling, called Oak. He called it Oak after an oak tree outside his office window. It turned out that there was already another computer language named Oak. As a result, the new name of Java arose when a group of Sun employees went to a local coffee shop.
The marketplace for intelligent consumer devices was not going well at the time, and the Green project was almost cancelled. Fortunately, the world wide web exploded in popularity in 1993, and the advantages of using Java as a web programming language became apparent.
The first public release of Java was Java 1.0 in 1995. Java 2.0 was released in 1998, and there were different editions for different platforms. JSEE was the enterprise edition, JSSE was the standard edition, and JSME was for mobile applications.
In May 2007, Sun made all of Java's core code free/open source, except for a small portion, which they did not rights to.
Key Features
- Java was designed to use small amounts of memory
- Java has an automatic "garbage collection" process that releases memory when it is no longer needed.
- Java is an object-oriented language
- Java uses an intermediate language called bytecode to make it platform independent

- A Java Virtual Machine (JVM) has been designed for most operating systems. The Java Virtual Machine translates the intermediate bytecode to the native machine language for that operating system.

- There are various methods of executing Java

- The same Java code can run on a stand-alone computer, a browser client, or a web server. Java code is called an "application" when it runs on a stand alone computer. It is called an "applet" when it runs in a client's browser, and it is called a "servlet" when it runs on the server. Java Server Pages (JSP) are like Active Server Pages. They carry out commands to process data and build web pages on the fly.

- Java is different from JavaScript. JavaScript is a just scripting language - it is not a full-blown language like Java. Java is compiled into bytecode, but JavaScript is not. JavaScript is embedded into static HTML pages to make them appear more dynamic. For example, JavaScript might be used to create a pull-down menu or a pop-up screen.
Although Java applications and applets have experienced some success, Java's real strength lies on the server side. Java is the most popular language for communicating across the network, and Sun's J2EE enterprise model has become the application server standard.
Saturday, June 27, 2009
Monday, June 15, 2009
Making good software
10 commandments for creating good code

1.- DRY: Don’t repeat yourself.
DRY is usually the easiest principle to understand, but it is quite harder to apply. It means that when finding similar code in two or more places, we should abstract them into a new method and change the previous code fragments so they will now call the new method with the appropriate parameters.
DRY is maybe the most universal coding principle, I have never found a developer who would argue that repeating code is good, but, I have found developers that forget about this principle when coding unit tests, as an example: imagine that you have changed the interface of a class which had lots of unit tests, if you haven’t used DRY, you will have to manually change the call to this class interface to match the new signatures to each test case.
2.- Write short methods.
There are three very good reasons for writing short methods.
- Your code will be easier to read.
- Your code will be easier to reuse (short methods are likely to produce loose coupling).
- Your code will be easier to test.
3.- Use good names for your classes, methods and variables.
There is nothing nicer than using some other developer code and not having to read its documentation because the names of the classes and the methods are telling us everything, so, make everyone’s life easier and take this approach, expend always a few seconds before naming any element in your code.
4.- Assign the right responsibility to each class.
One class, one responsibility, that will sound familiar to those who know about the SOLID principles, but not any responsibility, the right responsibility, so if we have the class Customer, we won’t assign to it the responsibility to create a new sales action, we will just assign it the responsibility to handle all the data related with a customer.
5.- Keep your code organized.
This organization is at two levels.
- Physical organization: Whatever the structure you are using, packages, namespaces, folders… Organize your classes in such a way that is easy and intuitive to find where the code is stored.
- Logical organization: Whatever belongs logically together should have access to each other members, but what belongs to a different logic structure has to access them by an interface. These logic groups are commonly implemented as layers, services…
6.- Create lots of unit tests.
The most tests you have, the better, they are our safety net for all the changes we will have to perform in the code in the future.
7.- Refactor often and sooner.
Software development is a continuous discovery process, in order to keep up to date with good code that matches the new/changing requirements is essential to refactor the code as we go. As this is a risky task there are 2 main preconditions to avoid entering new bugs into the system.
- Have lots of unit tests.
- Do small refactor steps at a time. In software development there are very few things more annoying than start refactoring 2000 lines of code to after 3 hours of work realize that is necessary to roll back to the original version because now nothing works and the track of which change is causing the problem is lost.
8.- Comments are evil.
This particular one is a bit controversial, most of us were taught that comments are good, and actually it’s better to have a comment in an obscure piece of code than just having the code by itself, what this point means is that: even better than having a comment for an obscure piece of code is to not to have that code at all, just refactor it until is a nice and readable piece of code. [EDIT] Please read this other post for a better explanation of what “comments are evil” means.
9.- Code to an interface, not to an implementation.
This is a classic one, coding to an interface will free us from the implementation details, we just define a contract and rely on calling the defined operations on the contract, expecting that the actual implementation will be passed to our code or decided at runtime.
10.- Have code reviews.
We all make mistakes, and there’s nothing better than asking some other person to have a quick and informal review in our code to find them, in order to make the reviews, it’s better not to wait until the code is completed, it’s better to ask for reviews whenever some important part of the code has been completed or when a few days have passed from the previous review.
Written by Alberto G
June 4th, 2009 at 11:29 pm
Posted in Software Development Theory
Sunday, June 7, 2009
Shrink That Link: Boosting Brevity With URL Shorteners
Posted using ShareThis
Friday, June 5, 2009
The snail-based system in feed-forward action. Image courtesy Herbert Bishko. Photo on front page courtesy Lysanne Ooteman, stock.exchng
If you think you have problems with the sometimes slow pace at which information travels from one computer to another, then consider the solution offered by this scientific paper: “Snail-based Data Transfer Protocol.”
It describes an experiment in data transfer using real, genuine, live snails, along with a “lettuce-based guidance system.”
No lie.
There’s even a picture (see right).
The papers’ authors, Shimon Schocken, dean of Efi Arazi School of Computer Science Herzliya, and Revital Ben-David-Zaslow of the Department of Zoology at Tel Aviv University, Israel, reported that their experiment delivered a 37 million bits-per-second data transfer rate — faster than ADSL.
Their paper earned the distinction of being named a “Classic” by the Annals of Improbable Research, the same organization that awards the yearly Ig Nobel Prizes for research that “makes people laugh and then think.” (Or, as some wags put it, for “research which can not — and should not — be reproduced.”)
The paper does admit to a drawback: “In some regions, most notably France, culinary habits may pose a denial-of-service (DOS) problem.”
PS: We found escargot to be rather nice — especially after drinking plenty of wine first!
Thursday, June 4, 2009
How to Save Your Newspaper??
How to Save Your Newspaper??
Time magazine's cover story by Walter Isaacson --with its proposal for saving newspapers from a crisis of "meltdown proportions"--has bloggers buzzing. No more free content, the writer suggests (and, uh, you can view a version of the article for free at Time's own website and even more ironically, reposted for free under Isaacson's pictureatHuffington Post.) Isaacson, a veteran print editor and now CEO of the Aspen Institute, says forsaking newsstand sales and subscriptions for an all-ad-supported model online was a terrible play for papers, admitting even he doesn't pay to read the New York Times anymore. "I still buy the paper. Thanks, Walter, for making me feel like a chump!" says Scott Rosenberg's WordYard. Isaacson proposes protecting content and charging online readers small fees. He has some useful ideas, but let the mocking begin! "Laughable," saysTechdirt. "If most newspapers switch to micropayments,someone ...will create a new news site that doesn't charge."
Many have considered micropayments a dead issue since Clay Shirky's seminal trashing of the concept. If newspapers all simultaneously institute fees, it might belegally prohibited as a form of price fixing, suggestsScreenwerk. Nerd Acumen doesn't even think the idea is possible: "While I don't condone piracy or copytheft of any kind, I do have two words for Mr. Isaacson: COPY, PASTE." Isaacson was on The Daily Show Monday night, where Jon Stewart wondered how you can get people to pay for somthing they've been getting free, says Daily Cartoonist (which takes the opportunity to embed prehistoric video of a 1981 newscast about people reading the San Francisco newspapers on their home computers.) Sadly, blogs Mathew Ingram at Nieman Lab, the idea that people will suddenly volunteer to pay the full freight for all of the great journalism that newspapers dois just wishful thinking. Rex Blog is just offended, as a loyal reader of free online content: "They're suggesting that my free-loading is why their product is failing." No Silence Here says free news won't go away: "I predict that journalists who lose their newspaper jobs are likely to continue practicing journalism to the extent their personal finances allow. People go into journalism because they want their voices heard. Being paid to have their voices heard was just a bonus." There are no easy answers in sight. Newspaper have dropped the ball on content, not charging for content, suggestsHitsville: "The truth was, [in the past] it didn't matter what they published. People just subscribed...For the ads, because they always had, some even for the news.Online, you have to publish stuff people want to read...That's the transition that's killing newspapers; it's something most reporters, editors and publishers never had to do."
Monday, March 30, 2009
Why can't we divide by zero?

Understanding Mathematics by Peter Alfeld, Department of Mathematics, University of Utah
Why can't we divide by zero?
The reason that the result of a division by zero is undefined is the fact that any attempt at a definition leads to a contradiction.
To begin with, how do we define division? The ratio r of two numbers a and b:
is that number r that satisfies
Well, if b=0, i.e., we are trying to divide by zero, we have to find a number r such that
for all numbers r, and so unless a=0 there is no solution of equation (1).
Now you could say that r=infinity satisfies (1). That's a common way of putting things, but what's infinity? It is not a number! Why not? Because if we treated it like a number we'd run into contradictions. Ask for example what we obtain when adding a number to infinity. The common perception is that infinity plus any number is still infinity. If that's so, then
which would imply that 1 equals 2 if infinity was a number. That in turn would imply that all integers are equal, for example, and our whole number system would collapse.
What about 0/0?
I said above that we can't solve the equation (1) unless a=0. So, in that case, what does it mean to divide by zero?
Again, we run into contradictions if we attempt to assign any number to 0/0.
Let's call the result of 0/0, z, if it made sense. z would have to satisfy
That's OK as far as it goes, any number z satisfies that equation. But it means that the result of 0/0 could be anything. We could argue that it's 1, or 2, and again we have a contradiction since 1 does not equal2.
But perhaps there is a number z satisfying (2) that's somehow special and we just have not identified it? So here is a slightly more subtle approach. Division is a continuous process. Suppose b and c are both non-zero. Then, in a sense that can be made precise. the ratios a/b and a/c will be close if b and c are close. A similar statement applies to the numerator of a ratio (except that it may be zero.)
So now assume that 0/0 has some meaningful numerical value (whatever it may be - we don't know yet), and consider a situation where both a and b in the ratio a/b become smaller and smaller. As they do the ratio should become closer and closer to the unknown value of 0/0.
There are many ways in which we can choose a and b and let them become smaller. For example, suppose that a=b throughout the process. For example, we might pick
Since
for all choices of a we get the ratio 1 every time! This suggests that 0/0 should equal 1. But we could just as well pick
and let a be twice as large as b. Then the ratio is always 2! So 0/0 should equal 2. But we just said it should equal 1! In fact, by letting a be r times as large as b we could get any ratio r we please!
So again we run into contradictions, and therefore we are compelled to
let 0/0 be undefined.
It's a common strategy in teaching to simplify concepts when they are first encountered. In other words, it's common for your teacher to lie to you. I just did! Actually, there is a way to make sense of the expression 0/0. The basic idea is to let both the numerator and the denominator become smaller and smaller, and to make the value of 0/0 dependent upon the way in which numerator and denominator approach 0. This is explained more thoroughly here.
Fine print, your comments, more links, Peter Alfeld, PA1UM
[17-Feb-1997]


