AOSD – Finally Thoughts

Friday, March 6th, 2009

We started with Keynote by John A. Stankovic from Universtity of Virginia, it was really cool keynote. He talk about defense system  The dynamics aspects where use to implement mechanism “right defense at the right time”. He describe real life problems with messages encryption, power management and sensor localization. The localization problem comes from that GPS do works only on open space. Thanks to aspects they provide sensor communication protocol. Also power management was treated as crosscutting issue and John describe protocols they develop for this propose. The final John thought is : “Flexibility offered by Dynamic AOP has great potential”.
I went to demo sessions, there was two demos, the first one is out of my interests, the second was quite interesting and open my eyes. I thought that JDK classes and aspect are not woven because of security reasons (this is what AspectJ team claims). Now I know that this issue is due to bootstrap classloader. It makes impossible to wave aspect to for example String class. The demo was about the tool which can do it. There are tools for that purpose called MAJOR and CARAJillo, one limitation of this tools is that JVM classes can only be woven statically. Great stuff.

Industry Panel was about “Challenges and Roadmap for Using AOSD in Industry”. The panel was rather boring. It was very slow and some trash talking: “it not easy to adopt new things to industry”, “risk management”, “academic solution doesn’t scale”, “no trust for aspect”,  “company policies ” and so on. Finally one of the panelist said that “Why we should use aspects if OOP currently works well”.There was few examples of industry usage from Accenture and Siemens.

Another demo session, two quite nice demos. First Lavash quite interesting probably not so aspect oriented framework of tools to automatic requirements processing. The second is in early stage and was about suggestion pointcut modification as we write new code. This may be very interesting tool in the future to keep programmers from silly mistakes. I will keep eye on it.

Industry session was more likely as panel. One good tough was that academic researcher should provide tools to make aspects fully testable. There was another aspect language proposal called “e” which mainly differs from AspectJ that AspectJ is focus on classes and “e” language on units. The session was improved by Uwe Hohenstein from Siemes. Uwe shows real project usage of aspects. Despite obvious examples such as connection pool monitoring,  performance monitoring. Siemens use aspect to address challenges of integrating 3rd party software in a maintainable manner keeping 3rd party software untouched. Most of the examples comes from Siemens Soarian project.

The last day came so quickly. AOSD is high level rather academic conference, but we should learn from the best.

Tags:
Posted in java, methodology, technology | 1 Comment »

AOSD Conference Day

Thursday, March 5th, 2009

The conference was started by Keynote. Paul Daugherty from Accenture talk about cost, and how they try to reduce it. 91 from top 100 companies are Accenture’s clients. They have consultants on every place in The Earth. He told that about 60% of cost goes to maintenance and keep live system. The solution is to use many different techniques as SOA architecture and Aspect Oriented Programming. Quite interesting and based on real example speech.
Next three papers was presented: Dependent Advice, Generic and Reflective Debugging Architecture and Expressive Scoping of Distributed AOP.  From my point of view the best of them was Generic and Reflective Debugging Architecture. Wouter has showed us problems when we must debugging system with aspect and where is the gap between program model and JVM TI. They write common aspect abstraction and it nearly ready for use. Great job.

After Lunch I went to Demo sessions. First demo was quite interesting made by Siemens. Product Lines  – features as aspects was about deliver features as crosscutting concerns implemented as aspects. Often our product is deliver to different client, and must get special features. Implementing this features as aspects can help us to keep product dependencies low and to deliver high quality software.
Next demo “Building a next generation digital news publishing” shows how introducing aspect helps to refactor and simplify code base. The problem was that news are deliver to different consumers (RSS, WWW, subscribers etc.) By using aspect they keep one source of news and many different consumers.

After break I saw demo “Druid – unexpected interaction detection”, it mangos the problem when introducing aspects can break other module tests. They make topological sort of modules and than executing junit tests, checking if something break if so, they provide special metadata. This metadata build graph about dependencies and unexpected interaction.  It may be used also to detects if every feature in module has it’s own test. The work is workable plugin for eclipse. The better integration between TDD and AOP. I talk with Andre Restivo and if you want to provide version for NetBeans or InteliJ feel free to contact with Andre. There is some kind of console magic so the plugin actually work only on Linux but should be no problem to port for OSX. There are some problems but you can download and try it now. I think that I will try to write port for InteliJ.

Last demo was funny, we have Frontend team which claims that Frontend will rule the Earth. Demo was about “AOSJ – aspect oriented programming framework for JavaScript” very interesting idea :)

The next day begin. Stay tuned.

Posted in java, methodology, technology | No Comments »

AOSD – Part One

Wednesday, March 4th, 2009

This year I choose as my conference 8th International Conference on Aspect-Oriented Software Development it is rather no commercial conference, and now I know it’s for sure not commercial, probably I’m only one from industry, other fellows are from Universities and so on. It is amazing experience.

First the trip from New York to Charlottesville, was quite interesting, when I will be back home I will publish this trip. Then the first day, it was a lot of good talk, from time to time there was hard time (e.g. type systems), next we have discussion about Aspect Oriented adoption in industry. From this discussion I’ve got some great ideas to realize, we’ll see.

The first day I mainly participated in Foundations of Aspect-Oriented Languages workshop, probably the closest to my interests was Mohamed ElBendary from University of Wisconsin Milwaukee paper presentation.  The most impressive person from my point of view was Mehmet Akşit from University of Twente. It gives quite nice talk about history of programming, and he has so many papers that I will spend another year to try to read them all. We’ve finished with Open session leaded by Shmuel Katz from Technion–Israel Institute of Technology.

The second day I had hard choose between Workshop on Early Aspects and 4th Domain-Specific Aspect Languages Workshop and finally I choose Early Aspects because it was more difficult so another workshop I will have occasion to read by myself.  I was right, it was hard, probably due to fact that I rather far from modeling and aspect there is some kind of magic for me.

So BPM with Aspect, Dependencies Graph and so on was hard. On the rescue  Mehmet comes with real application example for the Netherlands government. It was about traffic system, and Mehmet tells about it in details. It was worth to here this talk as we can teach from that that we should find crosscutting concerns on early stages of software development process, otherwise we don’t use the power of aspects.
And finally my time comes, Birds of a Feather with JBoss AOP. It was very good speech made by Kabir Khan
and Flavia Rainone from JBoss. They talk about details of JBoss AOP, about new features, plans and problems with new Microkernel based on OSGi. Currently JBoss AOP is the most advanced AOP implementation for day to day use. So you find more on this blog about it soon.
The conference have just started, but the level is still high, many papers and smart people. It is good to be here.

Tags:
Posted in java, methodology, technology | No Comments »

Testing – do we have to?

Friday, May 2nd, 2008

Reliability is the core of good testing. As we know our systems are made from many objects/components. Our system is as reliable as components on which it is build. It obvious that when our components are n percent reliable and we have k components our system is (n/100)^k percent reliable. We can quickly realize that if we have components that are not one hundred percent reliable, our system goes to zero percent as the number of components grow. From the other point of view if all of our components are one hundred percent reliable and we introduce to our system one component which is 50% it makes that our system is now 50% reliable. Of course it is theoretical, in practice we should provide weights for our components, and the system is rather non linear.

Now we agreed that reliability is good thing, but to talk about it we should measure it in some way. Of course to measure our system we should measure our low level components. To do this we must ensure that low level objects are reliable through unit testing. We must run this tests as often as we can (probably every commit), so the most important is that this tests must execute quickly (probably 2-3 second is maximum). And for such task the automation is needed. The answer is continuous integration tools, such as ( Atlassian Bamboo, TeamCity, Hudson, CruiseControl, etc.. ..). If you heard this idiom for the first time, you should read Martin Flower article about Continuous Integration.  BTW if you heard but don’t read this article you should read it, anyway. Even maven site goal may help here. In my company we use Atlassian Bamboo and it’s great tool, Atlassian has great license politics so if your projects is open source you can count on your free bamboo license ;) . If your company didn’t has money to buy such software you should see Hudson.

Test Types :

Unit Tests – verify behavior of small elements (single class). Tests should be quick and run as often as we can. Every language has it’s own test libraries. Some of them : JUnit and TestNG (java), unittest (python), Test::Unit module (ruby).

Integration tests - verify behavior of portion of a system, or subsystem. Requires installed external dependencies such as databases, ldap, etc.. This test tests code via API which is rather not accessible to the clients, and this test are rather quickly to execute. There are also some tools which makes this testing simpler: DBUnit (java), fixtures (ruby), pdbseed (python).

System tests – verify behavior of complete system, so all the system part must be fully installed. This kind of test runs for the long period of time, so the good idea is schedule this tests for night activity. Some of frameworks allows to do this test easily some of them not. For example we use webwork, which action class has no dependency to HTTP objects, and we can easily can test action simulating user actions.

Functional tests – calls also as acceptance tests, provides testing from the viewpoint of client. The tools for helping us are rather language independent, they depends rather on technology which clients use, for example for web application Selenium which simulates browser behavior, but for fat client other tools are.

There are more types but they has different propose, maybe I write about it someday:

  • UI testing (GUI testing, Usability testing, Accessibility testing)
  • Speed testing (Performance testing, Load testing,   Scalability testing, Stress testing)
  • Security testing
  • Smoke testing
  • Regression testing

and many others which I can’t remember now.
Summarize

  • Categorize your tests, and run this test separately, do not trust yourself or other developer use for this task continuous integration tools or call it from cron or similar tool.
  • Remember the cycle commit-test-result must be as quick as possible, there is no benefit from result which will came after developer goes to another task.
  • Heavy tests run nightly and when developer come to work he had result from them. Remember to do this you must have this tests automated.
  • And one important thing, if you ever find a defect, write test for it. The worse thing we can met is that our defect come back, so write test for defect first than resolve the problem. One point to mention is to write this test in such way that any new behavior is also tested (for example returning null when no data found)

Question : How about your tests, the speed, the quality, the schedule ?

Pedro

Posted in methodology, technology | No Comments »

Estimation

Thursday, July 12th, 2007

Yep today I was thinking about estimations. What is an estimation, how we know that given estimation is ok, and of course how to estimate.

Estimation is in my opinion believing in something, so naturally it strongly depends on personal fillings, knowledge, and many others attributes. So why we estimate, the answer is “because we have to”. So estimation makes managers happy because they know something. We must somehow point a date in calendar. The questions are: When we finish, how much effort is required and total cost.

The easy part is total cost, it consist of hardware cost (such as computers, servers, power etc), training cost (trainings, travels, etc) and the hard part effort cost. The clue point is to estimate “effort”.

How can we do it? The first part to consider is productivity term. There are some people who do task in an hour, and the same task another man do in a day. Also the same man doing a task in an hour in one team does this task in two days in another team. Don’t focus on people, focus on teams, and measure productivity of your team not members. The simplest method is to count units of work and divide it by person-hours. However as always for any problem there are many different solutions, which have different attributes.

How big is the software I we just build? Answer:
1. Size: Count lines of code, kilobytes, etc
2. Function: number of functionality (function points, object points)

The first one has some drawbacks for example 5 lines in ruby language is much powerful as 5 lines in java language. In my opinion using function points is the best way to measure. Of course functions differ from each other, so we have to introduce some complexity weights (user interaction, external interfaces, input, output, entity use). One point to mansion here is that difficulty of functionality depends on developer skills (there is solution for this knows as miracle estimation).

And the last “object points” is somewhere between functions point and size counting. We can count some objects for example, user screens, user actions, database tables, reports count, and module count and so on. Every object has effort (user screens -> 2 man-days). Object points as I know are used by COCOMO II estimation model.

The advantage of object points over function points is that they are easier to estimate from a high-level software specification.

We’re close to know our productivity but there are many factors which changes productivity. Some of them:
• Project size : larger project need more communication, more people evolved
• Domain experience : people who write web applications won’t be so productive writing standalone application, people writing financial software will won’t be so productive writing medical software etc
• Environment : morale, quiet vs loud, private vs public area, etc

Ok we have productivity of our team. Now we must somehow estimate effort. There is no simple one way to estimate. Here some of them:
• Analogy – if we build something similar so we can assume that the cost is similar
• Algorithm – we have some algorithm (similar to measuring productivity)
• Expert judgment – my favorite, each expert estimates and after that is discussion panel about these estimates. Estimation process is iterate until experts agreed
• And the last one is “don’t estimate just say price”, it’s good when effort depends on client budget.

There are two approaches for this methodologies top-down and bottom-up. Top-down starts at system level, examining overall functions by contrast bottom-up starts at component level. The advantage of one method is disadvantage of the second and vice versa.

You should look at COCOMO model which is well documented, public domain.

So you estimate your effort, I show you picture

So you can be wrong in design phase by 800%, nice heh?

Now you sure that you estimate effort, haven’t you? No it’s not finished now you should consider some other things. Maybe you should lower your prices because of
• Market opportunity – learn new technology, code reuse in other project, marriage with client get future profits
• Position – financial difficulty (better gain contract), new to market (nobody want talk with you), Future reference (yep we write this software for Google Inc ;) )

Or maybe you should raise a price because of:
• Uncertainty – maybe estimation was too optimistic, requirements changes

Posted in methodology | No Comments »

« Older Entries

about me

My name is Sebastian Pietrowski. I've finished Warsaw University as Master degree. During my studies I started work for merlin.pl. The primary language I use is Java but I have also programmed in Python, Ruby and Scala. I worked as a technical solution architect at merlin.pl. infrastructure when we were moving from PL/SQL to J2EE. I engineering a great performance optimized solution that made the application 10 times faster than requirements and 85 times faster as original solution.

Currently, I am working as a Senior Expert at F.Hoffmann-La Roche to help define future roadmap in design and development of Enterprise software at Roche and Genentech and build adoption for new technologies. I'm continuously mentoring new developers, helping them understand how important test driven development is and empowering them to get better at their daily job. I'm involved in many activities which brings new technologies for better and faster development. You can find more details on my LinkedIn profile.

But don’t get me wrong, I am not your typical nerd. I'm a pleasant guy that you can drink a glass of wine with me and talk about a range of topics with. My leisure activities include playing basketball, soccer and listening to music. I try to be pragmatic while staying focused on application performance and tuning with success in my daily work.

My favorite quote from Yoda's and my life’s motto is: Do, or do not. There is no try.