Move to create less clumsy robots

The race to create more human-like robots stepped up a gear this week as scientists in Spain set about building an artificial cerebellum.

The end-game of the two-year project is to implant the man-made cerebellum in a robot to make movements and interaction with humans more natural.
The cerebellum is the part of the brain that controls motor functions.
Researchers hope that the work might also yield clues to treat cognitive diseases such as Parkinson’s.
The research, being undertaken at the Department of Architecture and Computing Technology at the University of Granada, is part of a wider European project dubbed Sensopac.

Greater subtlety
Sensopac brings together electronic engineers, physicists and neuroscientists from a range of universities including Edinburgh, Israel and Paris with groups such as the German Aerospace Centre. It has 6.5m euros of funding from the European Commission.
Its target is to incorporate the cerebellum into a robot designed by the German Aerospace Centre in two years’ time.
The work at the University of Granada is concentrating on the design of microchips that incorporate a full neuronal system, emulating the way the cerebellum interacts with the human nervous system.
Implanting the man-made cerebellum in a robot would allow it to manipulate and interact with other objects with far greater subtlety than industrial robots can currently manage, said researcher Professor Eduardo Ros Vidal, who is co-ordinating work at the University of Granada.
“Although robots are increasingly more important to our society and have more advanced technology, they cannot yet do certain tasks like those carried out by mammals,” he said.
“We have been talking about humanoids for years but we do not yet see them on the street or use the unlimited possibilities they offer us,” he added.
One use of such robots would be as home-helps for disabled people.
Interacting robots

The next stage of the Sensopac project is to develop an artificial skin for robots, making them look more human-like as well as being information-sensitive in the same way as human skin is.
This system is being developed by the German Aerospace Centre in collaboration with other research groups. The ambitious project is just one of many attempts to create more human-like robots. Another European research project - dubbed Feelix Growing - has been given 2.3m euros to develop robots that can learn from humans and respond socially and emotionally.
The medical community is making huge strides in the use of man-made parts for failures in the human brain. Last year US scientists implanted a sensor in a paralysed man’s brain that has enabled him to control objects by using his thoughts alone. The fast pace of current robotics research has prompted deeper questions about how androids would be integrated into human society. Some have called for a code of ethics for robots while others question how humans will cope in the face of machine intelligence.

Gadgets 'threaten energy savings'

The growing popularity of hi-tech devices, such as flat-screen TVs and digital radios, threaten to undermine efforts to save energy, a report says.UK consumers spend £12bn a year on electronics, much of which is less efficient than older technology, a study by the Energy Saving Trust found.

By 2020, the gadgets will account for about 45% of electricity used in UK households, the organisation projected.It said flat-screen TVs and digital radios were among the worst offenders.

See how the energy costs of different TV types compare
Paula Owen, author of the report called The Ampere Strikes Back, said household appliances currently consumed about a third of an average home's electricity.But she warned this was likely to increase as a result of people buying more energy-intensive devices.

"Your old-fashioned, bulky cathode ray tube TV on average consumed about 100 watts of electricity when it was switched on," Dr Owen explained."What we are seeing now is a trend for much bigger flat-screened TVs. On average, we are seeing a three-fold increase in the energy needed to power these TVs.

"Pretty much in every other sector [such as fridges and washing machines], we find that as the technology moves on, the products get more and more efficient."Consumer electronics does not work like that."

'Radio ga-ga'
The equivalent of 14 power stations will be needed just to power consumer electronic devices by 2020, the report warned.By that time televisions on standby will consume 1.4% of all domestic electricity, it predicted.

Digital radios were also singled out by the report as being energy intensive."Traditional analogue radios consume about two watts when they are switched on," Dr Owen said.

"We've looked at digital radios and the average consumption of these is eight watts."

She added that listening to the radio via digital TVs or set-top boxes had an average consumption of more than 100 watts.Recent research by the communications watchdog Ofcom said that more than 80% of UK homes now had digital TV.

More people are buying digital TVs or set-top boxes because by the end of 2012 the analogue TV signal will no longer be available in the UK.But not all new technology was criticised by the report.

"Mobile phones and their chargers are one area where we have seen an improvement," Dr Owen said.A few years ago, she said, the current being drawn by chargers that were plugged in but not actually attached to a phone was about three to five watts.

"We have done some testing on the newest mobile phones and chargers you can buy today and reassuringly we could see that 'no-load' consumption had fallen below one watt."

But she added that the sheer volume of mobiles being used, about 63 million in the UK, meant that a huge amount of energy was still being wasted if people were not unplugging their chargers when they were not being used.

The report called for governments, manufacturers and retailers to do more to promote energy efficient devices, but also said consumers had a role to play."The simple message to people is switch things off when you have finished using them," urged Dr Owen.

Spring on Code organization for large projects

Code organization for large projects.

I discovered this 88 minute presentation on dzone.com today. Not a lot of people have time the time to sit through a presentation this long, so I have decided to write about the presentation. The majority of my comments below are simply paraphrasing what the presenter says, and I take no credit for his thoughts or words. I simply found them to be enlightening and want to share them.

Before I start on the presentation, I want to go over some of the terms that are used, as they are the principals that are under discussion.

Cohesion: A measure of how well the lines of source code within a module work together to provide a specific piece of functionality. That is, how well a module of code focuses on one single task or function.

Low Coupling: Refers to a relationship in which one module interacts with another module through a stable interface and does not need to be concerned with the other module's internal implementation. The benefit of low coupling is that when a change in one module is required, it will not require a change in the implementation of another module.

Dependency: A state where one object uses a functionality of another object.
Java Package: A set of Java classes organized for convenience in the same directory.
Now then, the complete presentation includes video and a slide show and can be found at http://www.infoq.com/presentations/code-organization-large-projects.

Summary
Juergen Hoeller shares his experiences working on large projects (including his role as chief architect of the Spring Framework) to provide general guidelines on Packaging and package interdependencies, Layering and module decomposition, Evolving a large code base. Juergen will also discuss how tools can play a role in enforcing architectural soundness.

Bio
Juergen Hoeller has been the most active Spring developer since the open source project began from Rod's Interface21 framework back in February 2003. Juergen and Rod together continue to provide the direction for Spring.

About the conference
The Spring Experience conference is hosted by Interface21 and NoFluffJustStuff Java Symposiums


Why worry about code organization?
Many organization and or programmers don't spend time thinking about code organization, it simply evolves without thought.

Personally, I usually come up with some sort of rough package structure before I start coding, but I don’t document it, and I don’t think about modules. My packages are usually based upon the layers of my multi-tiered design.

For example, my packages typically look like:

com.mycompany.myapp.dao
dao interfaces

com.mycompany.myapp.dao.hibernate
hibernate implementations of the dao interfaces

com.mycompany.myapp.services
service class interfaces and implementations

com.mycompany.myapp.web.springmvc
or com.mycompany.myapp.web.struts
for my web controllers

com.mycompany.myapp.model
for all my model classes

I share my package structure with you so that you can be reassured that others do it this way if this is how you structure your packages. If you don’t structure your packages this way, I am interested in how you do it and why.

There isn't a lot of literature on package dependency and interdependency best practices.

I have to agree with Juergen. Given all the books that I have read, the blogs that I subscribe to and the classes that I have taken, no one has ever spoken on best practices when it comes to package organization. I may have read about package interdependency without realizing what I was reading at the time.

Code needs to be logically organization. Code bases needs to be able to evolve based on its original structure and, even years later, based on completely new requirements.Refactoring and agile development are fine, but how do you preserve backwards compatibility once the code is released? What do you do if you already have people using your published code?

How should modules evolve? Separate modules might need to interact in a later revision, despite the original design not having intended it, thereby introducing new interdependencies at the module or package level.

How well does the code base allow for repackaging into more fine-grained modules if the need arises, while preserving the API?

I like that question. I think it’s fascinating how the Spring Framework can be divided up into a dozen packages or one single package, allowing the users to include only those packages that they need to use for their application. For example, you can use spring-full for the entire spring framework, or just spring-ldap, spring-aop, or spring-core, if you have more specific needs. That fact that the project can be divided into so many modules is a testament to the care and thought that they have put into their package design and code maintainability.

Package Interdependencies
Most public code bases are not good examples of good package design. For example the JDK libraries and many open source projects such as Hibernate. They contain bad practices such as cyclical package dependencies.

Later in the presentation, Juergen goes on to demonstrate how java.lang depends on java.util and how java.util depends on java.lang. For example the String class. He also shows that, on average, any given class in Hibernate depends on two-thirds of the entire Hibernate library.
As a counter example, Juergen states that “Spring does not contain any package circles.”

Typical scenario: Package B depends on package A according to the initial architectural design. New code in package A could use some code in Package B. Since you don't want to duplicate code, you call the code from package A to package B. Now you have package B using package A using package B.
Read as “Now you have package B dependent on Package A dependent on Package B”

Central rule: Packages should have one way dependencies between each other - at most. That is B can call A, but A should not call B.

Why are one-way dependencies between packages so important? Why are circles so undesirable?

Typically, circles are not deliberate, they usually sneek in. Over time, as more programmers touch the code, the original intent or design of the code is lost. Circles can be an indication of code deterioration and indicate to the state or maintenance of the code base.Consequences of cyclical dependencies include limited reuse of packages.

Cyclical dependencies create dependencies so that you can not extract that package for use with another project or some other code base. The packages becomes inseparable. Neither package can be compiled without the other package. So that in the event that you needed to extract some code for another project, you would also need to bring along some other package that has nothing to do with the new code base.

Avoid circular dependencies between packages. This is easier said than done, and many times you don't even realize that you have done it. To remove these circular dependencies, creative refactoring is usually required, which creates backwards compatibility challenges. Regardless, always avoid code duplication.

How do you avoid circular dependencies while at the same time avoid code duplication? Usually this means taking the time to analyze your package architecture to determine the best place for this new code. For example, at first thought you might want to put the code in some deeper package, but after some careful consideration, you determine that the code really needs to be placed in a shallower package.

Module Decomposition and Layering
Modules are conceptual in java. They are conceptual boundaries within your code base. Generally modules are a collection of specific packages that collaborate and/or are conceptually related. They might live in separate source directories but do not have to. Some modules might consist of a single package only, while others may consist of many packages. Identifying modules can be challenging.

Typically, modules are driven by deployment needs as much as conceptual boundaries. For example part of the code might be used by one application deployed on one server, while another part of the code might be used be a second application. Others created modules based on multi-tier separation. However, this is unnatural since it does not match conceptual boundaries.

So, the package structure that I use, which I described above would be considered a package structure based on multi-tier separation which Juergen states is “unnatural.” Sometimes modules are isolated by specific dependencies, such as JDK 1.5 or Hibernate. However, this is not a conceptual boundary, so it is a rather incorrect use of module separation. Sometimes modules are created to keep jar file size down. Again, this is an incorrect usage.

Desirable characteristics of modules include low coupling to other modules, and high cohesion within the module.

Modules are conceptual units as much as a source management and deployment unit. Modules should allow for individual usage or a distinct role within a larger system. For example, a new developer on the team, or a new user of your code should be able to review a module and understand the reasoning or the usage of that module - thus it is a complete, implemented concept with clear boundaries.

This sounds ideal. I know it would be great if when I was assigned to a new project I could pull it down and see distinct modules, and know what each of their responsibilities were, and knew that they did not overlap.

Modules should not have circular dependencies. Therefore module 1 -> module 2 -> module 1 is an undesirable situation.

Layering is essentially a logical view on the package structure. Higher layers build on lower layers. That is, higher level packages depend on lower level packages, not the other way around.

I seem to follow this rule of thumb with my DAO packages, being com.mycompany.myapp.dao and com.mycompany.myapp.dao.hibernate.

The module structure might have a straightforward mapping into layers. However this is not strictly necessary since modules might be a vertical slice. Modules are often driven by deployment considerations more than layering. That is, modules are usually vertical while layers are usually horizontal.

Establish natural conceptual boundaries in your code base. It does not mater where your code resides. It could be a single shared source root, or one source root per module. It does help if the source code structure mirrors the conceptual structure. This creates a natural package naming system and makes navigation easier.

Evolving a Large Code Base
The hardest challenge is evolving the code as well as the architecture over time without letting the code deteriorate and without compromising on architectural quality. This becomes exponentially harder with growing size of the overall code base. Consider the situation where you have many developers involved and no single point of architectural management or enforcement at the fine-grained artifact or module level.

You are going to see inconsistencies across the code, duplicated code, inconsistent naming, and most likely a decrease in loose coupling and high cohesion.

What is the trade-off between backwards compatibility and architectural quality? Strict 100% backwards compatibility might not allow for sustaining the architectural quality level. Nevertheless, there is always a better solution than compromising on architectural quality. For example a creative internal refactoring that allows to preserve compatibility as well as well-defined package dependencies.

Certain packages, for example the public API or core packages, can almost never be changed. The code base must revolve around these packages. One solution, if you must change the public API or core, is deprecation but even this is sometimes not possible. Some changes can only be done by breaking backwards compatibility. What do you do in that case? Break backwards compatibility or reduce the integrity of the architecture? The Spring development team is willing to accept a small breakage of backwards compatibility as long as the end result is a strong architecture.

Case Study: the Evolution of Spring

Background of Spring core:

Origins back to early 2001.
First public release was in 2002
First public source release was mid 2003
1.0 release in 2004
2.0 release in 2006, largely compatible with 1.2.

The spring project has faced many code evolution challenges including a broad public API used by applications; sophisticated SPI used by advanced applications as well as sister products and third-party frameworks; and new requirements addressed in every release, often implying some refactoring.

A tough situation that would not have been possible if not for their straightforward architecture and their strict adherence to the rules: accept small breakages of backwards compatibility as long as the end result is a strong architecture, and right from the start, no circles allowed at package level, not even as a temporary measure.

How has the Spring code base survived in its original shape for 3.5 years?

Strict architecture management and loosely coupled packages with well-defined interdependencies.Right from the start, no circles allowed at package level, not even as a temporary measure.

When introducing new code or functionality, great care is given in determining where the new code will go.

Challenges
Ever changing third party libraries.
Hibernate 2.1 -> 3.0 -> 3.1 -> 3.2
Resulted in the creation of the package hibernate3
Quartz 1.3 -> 1.4 -> 1.5 -> 1.6
What do you do in case of incompatible API changes in such libraries? The goal is always to try to maintain backwards compatibility, so in many cases, Spring developers were required to use runtime reflection to determine which library is in use and to maintain this compatibility. With reflection Spring can check to see if a certain method exists, and if it does, it is called, if it does not, it is skipped.

Tools for Architectural Analysis
How do we make sure that our architecture remains sound and avoids architectural violations? The best thing to do is to always keep these restrictions in mind, but even this can only get you so far.

Manual analysis only gets you so far, it is like manual testing vs. automated, repeatable testing. The only way to guarantee this is to use tools. Since 2003, Spring has been using JDepend before every public release. They have also recently introduced the SonarJ tool.

JDepend traverses Java class file directories and generates design quality metrics for each Java package. JDepend allows you to automatically measure the quality of a design in terms of its extensibility, reusability, and maintainability to manage package dependencies effectively.

JDepend is an open source tool that has been around since 2001. It is typically used as a command line tool. It can generate an analysis report which, among many other things, includes package dependency cycles.

SonarJ is an innovative solution that helps you to manage and monitor the logical architecture and the technical quality of your Java projects.

SonarJ is a commercial tool, is gui-driven, and is highly customizable. SonarJ also allows for on-the-fly analysis.

The presentation ends with a demonstration using SonarJ to analyze Spring.

I was about to go check out JDepend, when I realized that the IDE that I use, IntelliJ, contains cyclic dependency and backwards compatibility tests via the Analyze menu. Fellow IntelliJ users should see http://www.jetbrains.com/idea/features/code_analysis.html#Dependencies_Analysis and http://blogs.jetbrains.com/idea/2006/04/analyzing-code-dependencies-part-i/

50 Common Web Design Mistakes

This started out as a “Top Ten Newbie Web Mistakes” for my beginning web design students but it quickly became obvious that I couldn’t limit it to only ten. I was finally able to edit it down to 50. But I suspect, as soon as the comments start, it will begin growing again.

And, yes, I’ve made them all at one time or another.

Page Titles
1. Untitled documents: “Untitled Document” is the default title for pages created in Dreamweaver and other web design programs. Too many people forget to change it (see My Favorite Google Search).

2. Same title for all pages: The title is important. Help the world know which of your pages they want to see.

3. Non-descriptive titles: The page title is the headline for your link in search results (not to mention an important factor in determining those results). Instead of “Jim’s Page” try something like “Cartoons and Illustrations by Jim” or better yet “Political Cartoons.”

Meta Tags
4. Duplicate meta information on all pages: The keywords and description meta tags in the head of your page help search engines categorize your page. If you duplicate the tags across all pages of your site, they will look alike to searchers. Customize the keywords and descriptions for each page or don’t use them at all.

Site Structure
5. No index.html (or equivalent) in the root directory: By default the index.html (or an equivalent such as index.htm, index.php, default.htm, etc.) is displayed when you visit http://www.yourdomain.com. If you don’t include it, visitors will get an error message or be required to type out the full URI including the file name.

6. Disorganized file structure: How you organize your site files won’t affect what the site looks like but lack of organization can make your life hell down the road when you’re trying to update or redesign the site. Use directories (folders) to help organize your pages and images.

7. Uploading non-web files: Accidentally uploading a few native Photoshop files can eat up your disk space quickly (not to mention take forever). Store your resource files (Photoshop images, Word files, etc.) in a separate folder outside your local web folder.

Pages
8. “Under Construction” pages: If a page isn’t ready to post, don’t post it. If you can’t help yourself, remember “Under Construction” is supposed to be a temporary condition and, after a month or, so it starts to seem permanent.

9. Frames: There are good reasons why you might want to use frames but there are no good reasons to actually use them.

10. Horizontal scrolling: The least common denominator for monitor width is currently 800 pixels. You also need to leave space for scroll bars, page margins etc. so 760 pixels is a good standard width for your web pages. Wider may be acceptable depending upon your target audience but be careful!

11. Worthless content: If you don’t have anything to say, then don’t say it.

12. Out-of date content: If your content is no longer timely, delete it and, if you’re going to include a copyright notice, update it each January.

13. Overly long pages: Contrary to popular belief, there’s nothing wrong with long web pages (that’s what the scroll bar is for) if the content warrants it. But, if it can be done logically, it’s usually a good idea to have several shorter pages than one very long one. If you do have very long pages, provide additional navigation to make it easy for readers to move within or off the page (such as a simplified menu of text links at the bottom of the page).

14. Unnecessarily short pages: In an effort to make the content “fit” the design, designers often resort to a series of short pages when one long one would be more user-friendly.

15. “Orphan” pages: Pages you forget to provide links to don’t exist as far as the rest of the world is concerned.

16. “Alien” pages: Pages that completely ignore the look and feel of the rest of your website leave users feeling like they’ve been suddenly transported to a website far, far away.

Navigation, navigation, who’s got the navigation?
17. Pages without navigation: If you don’t offer them an option, visitors are more likely to close your page than to hit the browser’s “Back” button.

18. Broken links: ‘Nuff said!

19. “Hidden” links: Make links easily identifiable by using a contrasting color, underlining them, using “button” images or altering the rollover state.

20. “False” links: Underlined text and rollover images scream link. Use them cautiously.

21. Menus that move: Establish consistent “navigation zones” and stick with them.

22. Inconsistent navigation: Once the user learns how to use your site’s navigation, don’t change it on him.

Headlines
23. Restyling text instead of using heading tags: h1 is not the same as big paragraph text.

24. Using heading tags for design: Headings are structural elements and should be used to define the purpose of the text they enclose. Don’t use them just because you want big bold text.

Body Text
25. Using images for text: Text in images can’t be read by search engines or screen readers.

26. Justified type: It’s hard enough to make justified text look presentable on a static printed page. On a dynamic web page it’s nearly impossible.

27. Using br br instead of p: It will make formatting difficult.

28. Using br to control line breaks within paragraphs: Let the browser determine where your lines break within paragraphs. If you force the issue you may get strange results as not all browsers size type exactly the same.

29. Typos and grammatical errors: use your spell checker and check out 10 flagrant grammar mistakes that make you look stupid.

30. Type too small: Really, 9 point type on a printed page isn’t comfortable for most people. On screen it’s unreadable for anyone over 30. Except for the “small type” you’re trying to make unreadable 12 points (or even 14) should be your minimum.

31. Too little contrast between text and background: It’s really hard to read!

32. Using non-breaking spaces to align type: For tabular data use tables. To position type as a design element use CSS styles.

33. “Ransom” note styling: Using too many fonts, too many styles, too many weights, too many sizes and too many colors is simply too much.

Images
34. Images without the alt attribute: Search engines, screen readers, and that little text box that sometimes pops up when your mouse is over an image all use the alt attribute. You should too.

35. Jigsaw puzzle graphics: Don’t slice images more than necessary. Each slice requires an extra call to the server.

36. Resizing images in the browser: Size your images in your image editing program before placing them on your pages. Images that are blown up in the browser lose quality and images that are reduced in the browser increase the loading time of a page. For example, a 1 inch by 1 inch image loads 4 times quicker than a 2 inch by 2 inch image, even if they are displayed at the same size.

37. Improper image format: JPEGs are best for photos and continuous tone images. GIFs are best for images with large areas of flat color. Also, transparent GIFs are prone to “ghosting” if used incorrectly.

38. Use of transparent PNGs without Explorer fix: PNGs offer true transparency but it doesn’t work properly in Explorer 6 without a javascript fix.

Animations
39. Gratuitous Flash: No matter how fantastic your Flash splash page is, nobody really wants to watch it more than once. If you must “Flash” yourself, at least provide a “skip animation” link.

40. Non-stop animations: Let your animation cycle a few times and then stop it before it gets overly annoying. 41. Two many animations: More than one animation on a page is just annoying.

42. Use of the blink tag: Thankfully some browsers ignore it.

Philosophy
43 “Sheet of paper” pages: Your screen is not eight-and-a-half inches wide, things don’t necessarily stay where you put them and, when you get to the bottom, you can scroll. Take advantage of the design possibilities those attributes and others offer.

44 Confusing content and design: HTML tags (p, h1, h2, etc.) are structural elements and, by themselves, say nothing about how your page should look (see for example…). Organize your content using HTML and create the design of your pages with CSS (and maybe a table if absolutely necessary).

Miscellaneous
45. No contact information: The purpose of a website is communication. Right? Make sure people have a way to contact you if they’re interested in your work, product or service.

46. Reliance on email links: E-mail links only work if the user has an email program available and correctly configured. And they don’t work with G-mail and similar services. So people in libraries or school labs can’t use them. Most ISPs offer a form processing script that can convert the contents of a form to an email and send it to you. Use it.

47. Failure to respond to contacts: Sure you can ignore spam but, when a legitimate visitor takes the time to contact you, a prompt reply is just good manners.

48. Auto-play sounds: Unexpected sounds are annoying especially in an office or classroom.

49. Opening too many windows: Cluttering up someone’s screen with a new window every time they click on a link is just bad manners.

50. Failure to check for cross-browser inconsistencies: Your site should work on Macs and Windows, in Explorer, Firefox and Safari. If it doesn’t you’ll drive visitors away.