Innovation

Recently...

I encounter the word "innovation" more and more often. Where does it comes from? Who propagates this term currently?

Please, bear in mind: Innovation is a necessity, no solution for problems!

Only introduce and define innovation in a healthy IT environment.

Refactoring, Redesign and Architectural Overwork.

Actually, software should always apply to business demands with local refactoring. Refactoring can be seen as daily work where requirements and demands will be directly implemented by realigning code. It´s the programmers handcraft. You won´t need anything else for a long life software.

• If you are in need in a major redesign then you actually fucked up! This must never happen, learn some refactoring!

• If you are in need of an architectural overwork then you have already lost! Why didn´t you learn refactoring?

Nice article what happens if you don´t comply: Link. See? That happens if you have to rely on redesigning "experts".

Why Maintenance Matters!

Most developers focus on the software creation process. Software lacks documentation, design, tools and measures for later introspection. This will be a pain in the ass for later maintenance.

Why does maintenance matter? Because it´s fucking expensive! It´s 80% of the overall costs.

Read this excerp from Clean Code: Link.

The F.I.R.S.T. Rule For Writing Tests

There are the F.I.R.S.T. rules for writing tests. Clean tests follow five other rules that form the above acronym:

• Fast: Tests should be fast.
• Independent: Tests should not depend on each other.
• Repeatable: Tests should be repeatable in any environment.
• Self-Validating: Tests should have a boolean output.
• Timely: Tests need to be written in a timely fashion.

Original text from Clean Code: Reference.

Tests vs. Source Code

Tests are crucial for development. In that most agree. Tests must be maintained. In that most agree.

Do you really know how crucial test maintenance is?

https://kindle.amazon.com/post/3M2WEWSIVX2VL

What happens when you ignore this?

https://kindle.amazon.com/post/18NLTC6OJZD8M

Feature Envy

Feature Envy creates hybrid objects which are in need of refactoring.

"Feature Envy occurs when a code fragment references another object more often than it references itself, or when several clients do the same series of manipulations on a particular type of object." - found here.

Originally from the book - Refactoring.

YAGNI - You Arent Gonna Need It

It is an Extreme Programming practice which states:

"Always implement things when you actually need them, never when you just foresee that you need them."

The whole article can be found here: YAGNI

Clean Code - LeBlank's Law

Do you fix issues in your source code? Do you review your own code? Are you your codes biggest critic?

Or do you find excuses to do it later?

LeBlank's Law in software engineering: Later equals never.

From the book - Clean Code.

A nice article about this issue: Why You Won't Fix It Later

Programming Principles

Important object-oriented programming principles. Understand, remember and use them.

• Liskov Substitution Principle - Wikipedia

Substitutability is a principle in object-oriented programming. It states that, in a computer program if S is a subtype of T, then objects of type T may be replaced with objects of type S (i.e., objects of type S may be substitutes for objects of type T), without altering any of the desirable properties of that program (correctness, task performed, etc.).

• Law of Demeter -Wikipedia

The Law of Demeter (LoD) or Principle of Least Knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling.

Clean Code Developer in Brownfield-Projekten | heise Developer

Clean Code Developer in Brownfield-Projekten | heise Developer:

German article on handling dirty code and envrionment. Reengineering, refactoring as well as organisational changes.

Google Apps Hassle

Google apps engine sometimes remind me of the Java 2 Micro Edition. Even if you implement it properly there are glitches which can make your day go worse. Running on your system and running on the real server are two different things.

Seems that I have solved my "mixed-up-session" problem at the cost of platform independence. Now, my service uses google memcache in order to store my session object manually. Afterwards, I synchronize my data inside the database. Cleanups and periodical tasks will be written using google task queues.

This is a critical limitation I did not anticipate. I thought the app will be able to run everywhere. It is a small program though and still fun using the apps engine. At least I can concentrate on functional implementation and have no hassle anymore with session management.

Google Apps Development

I have now invested some days implementing something for the apps engine. My goal is a JSON standalone-service for serving as a backend for a browser-based chat. Well, I am now at the point where I not only have success but also have some drawbacks:

• When polling the server every second and with three browsers then the server seems to start to mix up sessions. This only happens on the real server and not on the local testenvironment.
• It's hard to write tests, because the app engine not only supports JPA persistence but also JDO. The provided toolset for testcases implements JDO tests and my JPA tests do not run.
• I encountered further datastore exceptions when I try to invoke database cleanups with spring tasks.
• The provided CPU-time quota of 6.5 CPU-hours is too restricting. Each web request that is calculated with around 50 milliseconds is sometimes measured as cost of 150 CPU-milliseconds.

Google Apps provides all kinds of work arounds, e.g. task queues, mem-caches and other services. It is forseeable though that even with those services my service will never run cost efficiently. Also I am not interested in their services because I want my service to be platform independent.

All in all it is really nice to tweak and try out the google apps engine. In case of business applications your still cheaper renting your on server and manage it yourself.

Google Apps Engine

If you have ever been interested in service development. Now is the perfect time. Google Apps Engine is here. It is free! It gives you:

• 500MB storage
• 5 million page views a month
• Java 1.5 or 1.6 Sandbox
• Easy eclipse plugin integration

Start now, start here.

Web Service Challenge 2010 Success

The year 2011 is already here. I hope to be able to report more often. Currently, I would like to report the results of the WSC 2010. The finals presentation of my collegue Thomas can be found here:

WSC 2010 Results

WSC 2010

The Web Service Challenge 2010 is currently preparing its launch website. More details will follow this weekend.

WSC - 2010

I am sorry, I do not have any news regarding the Web Service Challenge. The WS-Challenge will be held in Shanghai this year. A homepage and infos are still missing. I would suggest that you expect a similar task this year. I would say the same, I do not have any time I could spare to implement new challenge software.

I have a new job and help a company to implement a new architecture. Web Service Composition is currently no topic or me.

Job Interview - How To

I think the following site is relevant for everybody. I personally recommend it. The page's title says it all...

How to Answer The 64 Toughest Interview Questions

Software Development WTFs

The following website, called "The Daily WTF", lists regularily the most curious perversions in information technology. Literally^^

http://thedailywtf.com/

Web Service Composition Benchmark

During the WS Challenge we had a discussion about Web Service Composition benchmarks. I think this is also result of a recently published journal article on WSBen. WSBen is a web service composition benchmark that had been developed as a general composition benchmark for the AI community. The history of WSBen goes back to a Web Service Challenge on the EEE/ICEBE conference in 2005. I don't know further details and how it is related to the current Web Services Challenge but it seems that at least one participant from the Penn state University is related to this project or persons of this project. The test sets of WSBen are related to simplified WSDL documents and only support syntactic service discovery. The focus of WSBen is applying a network model in order to generate clusters of Web Services and is also able to visualize it with a GUI. So much about WSBen.

Let me make this clear from the beginning: The current Web Services Challenge Software (Generator + Client + Checker) is a Semantic Web Service Composition Benchmark. If we also consider that the source code is available and that we apply modern design patterns to make it open and extensible then it can be also called a framework. It is as easy as that. The test sets are purely random generated without any structure. Their difficulty range from test sets which can be used for testing your system and up to a difficulty which cannot be solved in minutes or hours with even the winning system. The test sets do not have any structure, an algorithm suitable for a specific test set maybe inadequate for another algorithm. The difference between a specific benchmark and our toolset is that we have not yet published a set of test sets which can be used to evaluate your system. We have not done this so far because we did not see any use in that. Now, with several fast composition systems at hand and two years of experience with these tools we could develop such benchmark.

The Web Services Challenge has over 5 years experience in measuring the performance of composition systems. We provide tools, test sets, rules, performance results and now also compositions systems. I have about 70 generated test sets from the last challenge and we will upload them shortly. Anybody who is still interested in a composition benchmark should download these test sets and document their results: test system, initialization time, response time, the result file and checking file. The evaluation should be done on a more or less simple desktop computer. The results will be collected and used to generate new test sets. On the other hand if we find several test sets where the algorithms produce different results then we are able to analyze them. The resulting package of test sets, already collected results and measurements will be the best benchmark available. Benchmarking is not the definition of an individual but a community effort.

Web Services Challenge 2010

The Web Services Challenge 2010 is still in planning but I want to describe some innovations. The innovations of the Web Services Challenges are dependent on resources. This means persons and money. The financial support is yet to be confirmed and so I can only give a rough list of ideas and changes. The project itself and a timetable cannot be planned at the moment. Please bear in mind, any changes in the WS Challenge means a lot of work for us, sometimes I even think more for us than for the participants. Each change in the challenge means a new testset generator, document formats, documentation, client application and of course a solution checking software. In contrast to the participant's composition system we have to ensure 100% bug free software. Otherwise the whole WS Challenge pointless and its results would be worthless. I am glad to say that we have successfully organized and improved the WS Challenge so far and of course want to continue our good work.

The WS Challenge 2010 will introduce a dynamic environment where both services and their Quality of Service (QoS) change. The initial set of services that are provided for the initialization of the composition system will be updated frequently. Services will be added and removed from the initial set of services. Furthermore, the QoS parameters on response time and throughput will change. Service changes and QoS values will be updated through a client application and the composition system has to answer with updated compositions. We will evaluate the time the composition system needs to respond with updated compositions and also the QoS of the overall composition which is comparable to last year. The proceedings will be as follows:

1. Composition System Initialization with WSDL, WSLA and OWL.
2. Sending the WSDL Request.
3. The Composition System responds with a valid composition.
4. Sending a list of removed services.
   
5. Sending a list of new services.
6. Sending a list of updated QoS parameters.
7. The Composition System responds with a valid composition.
8. Steps 4 to 7 can be repeated several times.
   

This is just a sketch of what we want to achieve in 2010 and still unconfirmed. I am open for any suggestions and hope for a lively discussion.