What is Java? A Visual Definition

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

1. Java was designed to use small amounts of memory
2. Java has an automatic "garbage collection" process that releases memory when it is no longer needed.
3. Java is an object-oriented language
4. Java uses an intermediate language called bytecode to make it platform independent
   
5. 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.
   
6. There are various methods of executing Java
   
7. 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.
   
8. 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.

Rails Envy:

Rails Envy: "Why Ruby On Rails?" Video Presentation

Shared via AddThis

Making good software

10 commandments for creating good code

with 29 comments

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.

1. Your code will be easier to read.
2. Your code will be easier to reuse (short methods are likely to produce loose coupling).
3. 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.

1. Have lots of unit tests.
2. 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

Shrink That Link: Boosting Brevity With URL Shorteners

On the short-messaging service Twitter, space is at a premium: You've got 140 characters to make your point, and you probably don't want to waste half of it on a super-sized link to your latest YouTube obsession. There's an increasingly popular quick fix: a free URL shortener. On one of these Web sites, you can plug in a long Internet address, known as a "URL," and it will assign you a much shorter one.

Posted using ShareThis

Link of the Week - Data transfer at a snail's pace. Literally.


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!

How to Save Your Newspaper??

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."