Traffic in Moscow

September 27th, 2006

Here is the map of the one of the Moscow’s streets with the directions on how to get from one street to another.

razvyazka.jpg

They should have put the roundabout there…


Axis 1.x or Axis2?

September 26th, 2006

This blog post answers the questions about which version of Axis framework developers should use and also gives a short story about Axis development history. Short and must read.


Testing Windows Live Writer

August 14th, 2006

So far so good. It works.

But what about pictures?


Websphere security: five tips for first time WAS hardeners

July 27th, 2006

Spent some time trying to enable Websphere security on my machine. Here are some tips:

  1. Before trying to secure your WAS create the additional profile and use it to train yourself. Creation of the profile takes five minutes and you could delete it after you finished.

    Use %was_install_dir%/bin/ProfileCreator/pctWindows.exe or use command line tool from %was_install_dir%/profiles/default/bin/wasprofile.bat

  2. Before you going to mess up this profile, make a copy %profile_dir%/config/cells/%cell_name%/security.xml
    If you mess up the security and server won’t start at all - just replace security.xml with saved copy. Chances are that server will start after that and you don’t have to re-create profile.

  3. If you made some mistake and profile won’t start anymore - just delete profile using wasprofile -delete -profileName %your_profile_name%
    Sometimes this command won’t remove the profile. In this case go to %was_install_dir%/properties and remove line with your profile from profileRegistry.xml. Then you can just simply delete the profile folder.

  4. After you enabled security you may see the exceptions in the SystemOut.log: (SECJ0305I, ADMN0007I) saying something about UNAUTHORIZED user can not be authorized. To resolve this simply add group, named EVERYONE to the Monitor role
    Admin Console - System Administration - Console settings - Console Groups - Add - Select from special subject

  5. If you securing Websphere, supplied with Rational Software Development Platform, you will have problems starting server and/or deploying applications to it. Editing of the server profile will not always help. The best way is to create the Server project in J2EE perspective and then create the server in that project.
    Don’t forget to use Security options in the server profile and use SOAP for server communications as RMI not always work.


Sequence Diagram Guidelines revisited

July 26th, 2006
  • Strive for left-to-right ordering of messages.

    And if you need to put right-to-left non-return message - consider using another instance of the swimline

  • Layer classifiers

    Huh?

  • Give an actor the same name as a class, if necessary.
    We are not dealing with classes in sequence diagrams, so give name to the instance of the actor’s class.

  • Include a prose description of the logic.
    Not always needed, but helps in complicated places.

  • Place proactive system actors on the left-most side of your diagram.
    Actors are always start interactions. This is whe they called actors - they act.

  • Place reactive system actors on the right-most side of your diagram.
    No actors in the right side of the diagram at all. This is the rule!

  • Avoid modeling object destruction.
    Model object destruction freely if it whats you modeling.

  • Don’t sweat activation boxes.
    Again - if it is required you have to model it. Don’t leave it for developer to decide.

  • Name objects when you reference them in messages.
    Don’t do it. It will add much more complexity to the message signatures with no added value.

  • Name objects when several of the same type exist.
    Name all objects. This is what developer will do anyway.

  • Apply textual stereotypes to classifiers consistently.
  • Apply visual stereotypes sparingly.
  • Focus on critical interactions.
  • Justify message names beside the arrowhead.
    Don’t waste your time. This will not be appreciated.

  • Create objects directly.
    Is there another way? I think not.

  • Apply operation signatures for software messages.
  • Apply prose for messages involving human and organization actors.
  • Prefer names over types for parameters.
    This is true, but you should also set the types for all parameters too.

  • Indicate types as parameter placeholders.
  • Apply the > stereotype for use case invocations.
    No use case invocations in sequence diagrams! It is possible, but will not help developer. Remember: sequence diagram is for developers.

  • Do not model obvious return values.
    Model them! Let developer know that return value is expected.

  • Model a return value only when you need to refer to it elsewhere on a diagram.
    Model it everywhere.

  • Justify return values beside the arrowhead.
    Waste of time!

  • Model return values as part of a method invocation.
    Before it was said that we don’t have to model return values and not we need to model them? As I said - model return values all time.

  • Indicate types as return-value placeholders.
    Model them in the method signature.

  • Indicate the actual value for simple return values.
    Indicate the type of the return value. Anything else goes into comments.


Activity Diagrams Guidelines revisited

July 26th, 2006

Last year, after reading a book about UML, I wrote a set of posts with distilled UML guidelines. Now it is the time to look at them again and put some comments on usage.

  • Place the start point in the top-left corner.

    I tend to create vertical activity diagrams, so I usually place the start on top and in center. This way looks more visual.

  • Include an ending point.

    What? No ending point? So activity never ends? I always have at least one ending point

  • Simplify operations requiring flow charts.

    The whole goal of activity diagrams is to visualize and, if possibly, simplify the process.

  • Question “black-hole” activities. Question “miracle” activities.

    I would question any activities. It is very usual to have some unneccesary work only because analyst and/or client do not fully understand what is needed and what is achievable

  • Reflect the previous activity by using decision points.
  • Avoid superfluous decision points.
  • Ensure that each transition leaving a decision point has a guard.

    If there is no guard then what this flow is trying to decide?

  • Do not overlap guards.

    Huh?

  • Ensure that guards on decision points form a complete set.
    And if they not - why do you have decision point, by the way?

  • Ensure that exit transition guards and activity invariants form a complete set.
  • Apply an [otherwise] guard for “fall-through” logic.

    This one support the thesis about having the complete set of the guards next to each decision point.

  • Model guards only if they add value.

    If you don’t have real guards - you should not have the decision point in this place

  • Ensure that forks have corresponding joins.

    Not always true - some of the forked processes may be terminated before they go to the join. Messaging is a good example.

  • Ensure that a fork has only one entry transition.
  • Ensure that a join has only one exit transition.
  • Avoid superfluous forks.
  • Order swimlanes in a logical manner.

    It is all about logic, why say more?

  • Apply swimlanes to linear processes.
  • Have less than five swimlanes.
    I would say that is you trying to add fourth swimlane, you are already creating something bigger, than anybody in your team can comprehend without asking you more questions. It is time to simplify the activity.

  • Consider swimareas for complex diagrams.
    Consider to use UML2 and include sub-activities in this activity

  • Reorganize into smaller activity diagrams when swimareas include several activities.
    Yes, very good point.

  • Consider horizontal swimlanes for business processes.
    Well, it depends on business process and your preference.

  • Model the key activities in the primary swimlane.
    Good point. If you don’t have key activities in the primary swimlane chances are that you modeling incorrect activity.

  • Place shared action objects on swimlane separators.
  • Apply state names when an object appears several times.
  • Reflect the life-cycle stage of an action object in its state name.
    And use color, if your modelling program allows it.

  • Show only critical inputs and outputs.
  • Depict action objects as smaller than activities.

Security in JSF apps

July 26th, 2006

Java Developer’s Journal published a very good article on security issues in JSF applications. The article consists of three pages. Two first pages provide the neccessary background information with the possible solution. The third page looks like the editors decided not to publish more details and just finish that article as fast as possible. And source code attachment does not work either.

Another link to check is JSF security project on Sourceforge


CoComment finally become useful

July 25th, 2006

The CoComment service, which was debuted this year, has some updates, which make this service actually useful. Before those updates there was no way to check for and be notified about comments posted to somebody’s post. Now it is possible!

For example: you noticed some interesting post, but don’t want to participate in the comments. But you still want to look at other people’s thoughts. The only option would be to bookmark the post and come back later. In many cases you will just forget about returning back and the discussions will be gone.

Now you just instruct CoComment’s crawler to report any comments and it, if you have any luck, will.


The essence of London

May 6th, 2006



The essence of London, originally uploaded by CTPEKO3A.

This is my best photo so far. It has been seen 350 times as of 7th of May, 2006.


Filenet does XSLT

April 12th, 2006

When some developer sees the XSLT first time she tries to use it the “normal” way - she builds procedural code. Resulting XSLT template will have horrendous memory footprint and will performs really slow. This is exactly what happens with Filenet Workplace.

If you have been on Filenet Fundamentals or Filenet Web Framework course, you have heard that Workplace starts so slow because “the JSPs are being compiled”. This is, of course, not true because Filenet Web Framework’s JSPs are really small ones. Real reason lies in XSLT transformation. It uses procedural XSLT and most of the time just wastes CPU time and server memory.

Of course nobody bothers to cache the results of the transformations, so the same pieces of content are compiled and transformed by XSLT processor again and and again.


Bad Behavior has blocked 45 access attempts in the last 7 days.