BMW Vision EfficientDynamics | Fubiz™

via fubiz.net

Posted via web from Whatsoever

Standardizing Service Endpoints

via oracle.com

Posted via web from CodeBetter

Enterprise Abstraction: Service naming standards

I've been doing some hunting to follow up on my previous posting regarding web service naming conventions and standards.  The pickings are slim.  Thomas Erl, a Canadian SOA expert and author, mentions some SOA naming conventions in an article he wrote for Oracle entitled Standardizing Service Endpoints. 

He prescribes a practical approach, naming services based on the utility (verb), entity (noun) or task/function (verb-noun -- do something to something), dependant on the scope and context of the service.  He also warns about ensuring that operations within the service reflect appropriately the scope of the service, and to eliminate redundancy in operation names.

From the article:

• The utility-centric context is found in application services involving operations that encapsulate cross-cutting functions, such as event logging, exception handling, or notification. These reusable services need to be labeled according to a specific processing context, agnostic in terms of any particular solution environment. For example, a utility service might be named Notify.
• An entity-centric context is established in a business service that represents a specific business entity, such as an invoice or a purchase order. The labeling of entity-centric business services is often predetermined by the entity name. For example, a service may simply be named Invoice or Customer.
• Task-centric contexts are required for services modeled to encapsulate process logic. In this case, the thread that ties together the grouped operations is a specific activity being automated by the service logic. Therefore, the use of verbs in service names is common. For example, a task-centric service may be called GetProfile or ProfileRetrieval, if that accurately represents the task's scope.

As with service names, labeling individual service operations is also a process that should be subject to standards and guidelines and for which there are already several best practices.

For example, the naming of the service itself ought to influence how the individual operations are labeled. Because a good service name will already clearly establish a meaning and a context, operation names should be streamlined to avoid the use of redundant wording. Take an operation that retrieves invoice history data for a service named Invoice. This operation does not need to be labeled GetInvoiceHistory, because the invoice context is already established by the service name. GetHistory would be sufficient.

Thomas really helped us move forward with our SOA initiative at CISTI both with a workshop to bootstrap our process, and through his books. 

via ea.typepad.com

Posted via web from CodeBetter

Why it's better to be lazy

Musings on Language and Design
Why it's better to be lazy
by Jeremy Meyer
June 8, 2008

Summary
Our parents were wrong when they told us not to be lazy. Laziness is a vital characteristic for success, and something we should strive for.

Classifying People

I have had recent to remember those 4 great classifications of people. Intelligent, Stupid, Active and Lazy.

My father often used to tell me about these classifications which he attributed to the Duke of Wellington. I have since read articles which have attributed them originally to Buddha, or some Buddhist swami, but the most credible source seems to suggest that they are more likely to have come from Helmuth Karl Gernhard Graf von Moltke, a German Military leader and strategist. (see below).

Actually it doesn't matter where they come from, the important thing is that they are an excellent insight into how and why people do things. If you haven't come across them before, they are very simple.

Everyone can be loosely classified into 4 groups, which are permutations of either activeness or laziness and , intelligence or stupidity.

Intelligent Lazy people, as my father would explain, are everyone's favourite. They do things in a smart way in order to expend the least effort. They don't rush into things, taking that little bit of extra time to think and find the shortest, best path. They tend to make what they do repeatable so they don't have to go through it all again. These people usually make good leaders, and they are good to have on teams.

Intelligent Active people are useful, because they are smart, after all, but their intelligence can be slightly diluted or tempered by their activity. Where they don't have a perfect solution, they might act anyway, rather than sitting on their laurels, so useful people but not great leaders, and on a team, they can often put noses out of joint by acting too early and too fast.

Stupid Lazy people have their place too, they are easy to manage, they generally don't act on their own initiative too much and, given tasks that are not beyond them, they will perform in a predictable, consistent manner. Usually they won't cause any harm on teams. Wellington, liked these people as foot soldiers.

Stupid Active people are the dangerous ones. Their default behaviour is to act, and in the absence of skill or thought they can cause all types of trouble.

Anecdotal Evidence

Stupid Active people are definitely good for one thing, though, they make for great anecdotes! They are the exclusive recipients of the Darwin awards, after all. We all know one of two of these, I bet if you think about it right now, you can think of at least one person you work with who you could classify immediately as stupid and active.

My own most recent amusing experience happened whilst on the management team for a large migration project. The team's task was to migrate UML Modelling projects from one version of UML to another, using Borland's Eclipse modelling tool, Together. In SCRUM tradition we had a daily call with our offshore team who were working on a backlog of many hundreds of projects that needed to be migrated. The task was fairly simple. Run the automated import facility, sanity check the project, and make any additional necessary changes to the UML model by hand.

One of the team, let's call him "Fred", reported that his progress was blocked by strange behaviour in his migrated Eclipse project. Diagrams were disappearing and reappearing and something was wrong. I noticed from his screen capture that something was awry with his project icons. I asked him to show me the contents of his Eclipse .project file. It contained the line..

<nature>uml14.uml14_nature</nature>

This is the line in the project file that tells Eclipse what type of project it is, and it told me that his automated import had failed. Clearly it had aborted, unable to convert the project from one type to another, no doubt due to corrupted input. I asked him to clean up the original UML diagrams, and re-try the import.

The following day, Fred reported that his icons were correct, but the project behaviour was still wrong. When I quizzed him on his approach, he explained that he had in fact edited the .project file by hand and changed the line above to:

<nature>uml20.uml20_nature</nature>

He had done this, he explained, because he had understood from what I had said that that particular line in the .project file was the problem. After much suppressed mirth, I patiently and politely explained that when changing the meta-model of one project to that of another, there was a great deal of work to be done, which is why it was automated, and why there was an import menu option for it. Manually changing the value of the "nature" tag in the project file didn’t change the nature of the project any more than wearing a baseball cap makes you a baseball player. To my astonishment, Fred defended himself with great verve. He stressed that he had "used his skills" in the best way he knew, to try and solve the problem. He seemed quite put out that I hadn't applauded his initiative. Not only was he actively stupid in his attempt to solve a problem, he was actively stupid in his attempt to justify it! Since he was my responsibility, but not my hire, I couldn't take what would have been my preferred action, firing him on the spot.

Everybody can be Stupid

Before I go on, I should say that Fred might well have been pretty smart in many ways. It has been my experience that you can't apply these classifications to people in general. There must be a context. You might be smart and lazy in your work, but stupid and active in the kitchen. I would like to believe that I am a smart, lazy software developer, but I am a very stupid, active DIY'er. Ask any of my friends who have been party to my crazy projects. My pond building exercise (where I cast my own bricks with moulds I made myself). Or my spontaneous tandoori oven, built from roof tiles at a holiday house in France (we ate cold, semi-raw chicken at 11pm that night). I am sure people do tend towards certain behaviours in all of their undertakings, but I think it is dangerous to apply the classifications generally. It is also hard to work with people whom you honestly believe are stupid in all walks of life. I have faith that there is something, somewhere that Fred does well and with careful consideration, but it certainly doesn't involve working with software tools.

Safety Net for Lemmings

My experience with Fred got me to thinking that when we create frameworks and even languages, we always try to cater for people like him. Some language designers feel this is their responsibility. Sometimes this is kind of helpful, like private methods and properties in a language, for example. Sometimes, it can be overly paternalistic. The old checked exception / unchecked exception debate springs to mind. C++ doesn't enforce the catching of an exception, Java does (with recent compromised made by Runtime exceptions). The question is, can you really defend yourself against active stupidity? Should you really try to defend yourself against it? Isn't it orthogonal to the actual intention of the effort, and just a bit like building safety nets on cliffs in case lemmings want to throw themselves off? (This is a metaphor, for more about the lemming myth, see the links below.) I was reviewing some code that looked like this, the other day:

   public void doStuff (int value) {  try {  applyCalculation();  } catch (Exception e) {  }  }    

Ah, that old chestnut. A swallowed, unlogged, unreported exception. It was lucky that I picked it up in the code review. This is a fine example of active stupidity in programming. It is actually less work, (less typing, even), and smarter to write:

	public void doStuff (int value) throws Exception {  		applyCalculation();  	}  

.. clearly, having checked exceptions in your language is no defence against a developer who is this active.

Should we try and drop all of these types of controls in language and architectures? Of course not, it is just that there is unlikely to be a linguistic construct or design approach which can prevent active stupidity without being so infuriating as to be almost unusable by someone whose approach is more lazy and intelligent. The acknowledgement of that should lead to a happy medium between choking restrictions and complete lack of structure.

If you try to enforce exception handling, there will always be those who find a work-around for the construct. If you create a Singleton connection factory class to ensure a single point of connection there will always be someone who tries to hack their own independent connection to the server. If you try and enforce static type checking and make, say, a type-safe collection, there will always be someone who will explicitly typecast their Objects before they add them to make the code compile.. and so on.

It's People who Write Programs

Ultimately, until technology moves on significantly, it is people who are using programming languages and frameworks. The smart, lazy ones will be looking to reuse what they can and to find neat, idiomatic ways of achieving functionality. The active stupid people will be looking to "use their skills" like Fred did. And get stuff done.. Somehow.

Training, documentation, teamwork, and feedback all help to make people smarter (if not less active) and that is where a great deal of effort needs to be applied.

Too rigorous an amount of control in a language or framework doesn't do as much good as everyone thinks. It can often just create huge time overheads, as in the extra syntactic fluff needed to typecast because of Java's static type checking for example.

Affordance

An architecture or a syntax should provide a good context for creating idioms. It should make writing idiomatic code feel right without feeling that you have to jump through hoops. There should be an inherent affordance of the right thing to do.

This puts a lot of faith in the user of the language/ framework or whatever, but there are very successful examples of this. Languages like Ruby and Python (and of course SmallTalk) which allow parametric polymorphism tend to be scary to Java developers, it is, after all, a bit unbridled and wild being able to send messages to any type, but hey, smart lazy people never seem to get into trouble with it.

Perhaps a bit of judicious application of the 4 types would give us an idea who we should be looking out for in our designs and make us realise that some people don't need protection and others just can't be protected.

Next week, why it is better to be rich than ugly.

What do you think? Should we consider the importance of peoples' personalities when designing? What is your favourite anecdote of a stupid, active developer?

I hope you enjoy classifying your collegues!

Resources

Bruce Eckel on The Checked Exception Debate:
Checked Exception

..and The Static Typing Debate:
Static Typing

Helmuth Karl Bernhard Graf von Moltke
Creators of the German Empire

The Lemming Mass Suicide Myth
The Lemming Myth

Talk Back!

Have an opinion? Readers have already posted 16 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Jeremy Meyer adds a new entry to his weblog, subscribe to his RSS feed.

About the Blogger

Jeremy has been designing and developing software for nearly 20 years, as well as teaching its mastery. He is fascinated by all aspects of architecture, design and development, the philosophical, the psychological and the aesthetic. He is currently a principal consultant for Borland Software in their modelling and design space.

This weblog entry is Copyright © 2008 Jeremy Meyer. All rights reserved.

via artima.com

Posted via web from CodeBetter

Richard Dingwall » C# 3.0’s var keyword: Jeff Atwood gets it all wrong

One of the new features of C# 3.0 is the var keyword, which can be used to implicitly declare a variable’s type. For example, instead of declaring the type, you can just write var instead, and the compiler will figure out what type name should be from the value assigned to it:

1.// A variable explicitly declared as a certain type.

2.string name = "Richard";

3. 

4.// A variable implicitly declared as the type being assigned to it.

5.var name = "Richard";

Note that a var isn’t a variant, so it’s quite different from say, a var in javascript. C# vars are strongly typed, so you can’t re-assign them with values of different types:

1.var name = "Richard"

2.name = 62; // error, can't assign an int to a string

Vars were introduced to support the use of anonymous types, which don’t have type names. For example:

1.var me = { Name: "Richard", Age: 22 };

But there’s nothing to stop you from using vars with regular types. In a recent article on codinghorror.com, Jeff Atwood recommends using vars “whenever and wherever it makes [your] code more concise”. Guessing from his examples, this means everywhere you possibly can.

The logic behind this is that it improves your code by eliminating the redundancy of having to write type names twice — once for the variable declaration, and again for a constructor.

There’s always a tradeoff between verbosity and conciseness, but I have an awfully hard time defending the unnecessarily verbose way objects were typically declared in C# and Java.

1.BufferedReader br = new BufferedReader (new FileReader(name));

Who came up with this stuff?

Is there really any doubt what type of the variable br is? Does it help anyone, ever, to require another BufferedReader on the front of that line? This has bothered me for years, but it was an itch I just couldn’t scratch. Until now.

I don’t think he’s right on this one — my initial reaction is that using var everywhere demonstrates laziness by the programmer. And I don’t mean the good sort of laziness which works smarter, not harder, but the bad sort, which can’t be bothered writing proper variable declarations.

Jeff is right though – writing the type name twice does seem a little excessive. However, as Nicholas Paldino notes, the correct way to eliminate this redundancy would be to make the type name on the right hand-side optional, not the left:

While I agree with you that redundancy is not a good thing, the better way to solve this issue would have been to do something like the following:

1.MyObject m = new();

Or if you are passing parameters:

1.Person p = new("FirstName", "LastName");

Where in the creation of a new object, the compiler infers the type from the left-hand side, and not the right.

Microsoft’s C# language reference page for var also warns about the consequences of using var everywhere.

Overuse of var can make source code less readable for others. It is recommended to use var only when it is necessary, that is, when the variable will be used to store an anonymous type or a collection of anonymous types.

In the following example, the balance variable could now theoretically contain an Int32, Int64, Single (float), Double, Decimal, or even a ‘Balance’ object instance, depending on how the GetBalance() method works.

1.var balance = account.GetBalance();

This is rather confusing. Plus, unless you explicitly down cast, vars are always the concrete type being constructed. Let’s go back to Jeff’s BufferedReader example, of which he asks, “is there really any doubt what type of the variable br is?”

1.BufferedReader br = new BufferedReader (new FileReader(name));

Actually, yes there is, because polymorphism is used quite extensively in .NET’s IO libraries. The fact that br is being implemented with a BufferedReader is most likely irrelevant. All we need is something that satisfies a Reader base class contract. So br might actually look like this:

1.Reader br = new BufferedReader (new FileReader(name));

Just because a language allows you to do something, doesn’t mean it’s a good idea to do so. Sometimes new features adapt well to solving problems they weren’t designed for, but this is not one of those situations. Stick to using vars for what they were designed for!

June 21st, 2008 | 40 Comments

via richarddingwall.name

Posted via web from CodeBetter

Static Typing Where Possible, Dynamic Typing When Needed

via research.microsoft.com

Instead of hammering on the differences between
dynamically and statically typed languages, we should
instead strive for a peaceful integration of static and dynamic
aspect in the same language. Static typing where possible, dynamic
typing when needed!

Posted via web from CodeBetter

How to watch Hulu outside the USA

via thenextweb.com

Posted via web from Whatsoever

再见，谷歌_李开复_新浪博客

   再见，谷歌

   李开复 

   时光荏苒，时光匆匆走过了一个四年，回望过去四年我在谷歌的职业生涯，所有的快乐、成就以及曾经面对的困难与挫折，所有的这一切如同一部电影在我的脑海里不断地闪过。在这离别之际，我不禁百感交集。在这四年时光里，谷歌中国从一个很小的雏形一直慢慢发展壮大，一直到今天，它成为了一家平稳，成熟，走上轨道的公司。

   在整整四年的时光里，我努力地把Google“平等、创新、快乐、无畏”的精神带到中国。这个过程并非一帆风顺，但是我们坚持着自己的信念与价值观，保持着超强的耐心精耕细作。

   我们压抑着做更酷、更炫的产品的欲望，努力耕耘最佳中文搜索。今天，谷歌中国的搜索质量已堪称最精确、最完整、最即时。优化中文搜索后，我们又开启了数十个产品，让谷歌中国的版图渐渐清晰。其中谷歌地图、谷歌手机地图、谷歌手机搜索、谷歌翻译都已经达到中国第一。另外，音乐搜索的推出，可以让网民首次享受到正版免费的音乐，创立了全球音乐下载的崭新模式。

   特别令我难忘的是我们热爱中国的员工面临雪灾、地震、风灾做出的及时产品和贡献，证实了谷歌中国人爱谷歌也爱中国，证实了谷歌中国人既能创新又有爱心。

   当我随意走进咖啡馆，看到年轻人在用谷歌的整合搜索查询信息，用地图查看实时交通流量，在iGoogle上挑选自己喜欢的“皮肤”（计算机界面），或者在用谷歌音乐听正版歌曲时，我都会露出发自内心的微笑。

   谷歌是一个伟大又可爱的公司，我非常感谢有这么一个千载难逢的机会，来从无到有地打造谷歌中国。在谷歌，我学到太多太多，无论是互联网技术、创新模式、价值观。

   对于谷歌，我现在已经没有遗憾，但我的人生还有一个缺憾没有实现，我想去弥补它。在过去的20年，我有幸在乔布斯、盖茨、施密特等身边学习成长，我有幸在PC时代历经苹果微软，我有幸在互联网时代历经谷歌，我有幸看到三个世界一流的公司的成长成功，我有幸在美国硅谷和中国的中关村崛起时，在这两个地方做过最有创意的工作。我拥有更多的是在科技领域的知识，更了解是企业成功的秘笈。这些职业经验才是我最有价值的资产，我非常希望能够把这些资产传授给中国青年。

   我的下一步就是和中国青年人一起打造新奇的技术奇迹，我想用自己的主动性做一个掌控全局的工作。我已经到了这个人生阶段，再不去做，我真的很怕来不及了。

   所以，尽管加州的山景城再次向我伸出了橄榄枝，希望我再续约四年，但是我却在此刻做出了发自内心的选择，我希望帮助年轻人圆梦的同时也圆自己的创业梦想。

   这个周末，我终于能够从业务发展、战略策划、离职宣布、工作交接中松一口气。这个周末，我会把我的思路理顺。下周，我会和大家分享的我的“从心选择”计划。

   每当我想到我将迈出的一步，我就会想起苹果创始人乔布斯的名言：

   “最重要的，拥有跟随内心与直觉的勇气，你的内心与直觉多少已经知道你真正想要成为什么样的人。任何其它事物都是次要的。”

via blog.sina.com.cn

Posted via web from Does IT Matters?

Robbers empty Apple store in 31 seconds

via news.ninemsn.com.au

Posted via web from Whatsoever

Coding Horror: Get Your Database Under Version Control

via codinghorror.com

Posted via web from CodeBetter

Microsoft's grip on users is being lost in the 'clouds'

via latimes.com

Posted via web from Does IT Matters?

Key legal win for open source

via mis-asia.com

Posted via web from Does IT Matters?

Forrester report says enterprise mashups on the rise

via mis-asia.com

Posted via web from Does IT Matters?