Monthly Archives: July 2008

Our new LSIS Release is out!

I am glad to announce: Our new release of LSIS – The Life Science Search Engine is online.

Check it out:

  • Frontend: Flex
  • We eliminated the boolean AND for the user utilizing term-boosing, result-scoring depending on search terms and intelligent sorting instead.
  • No paging through results, just scrolling

Feedback very welcome!

Define an Array as Parameter in WSDL

I had the case to build a WebService which had to be called transporting an array with some user data. This was the first time I was using an array as parameter in a SOAP-Service. Here are some examples that show what I figured out about how to setup the WSDL:

Notice the complexType ArrayOfString at the top in the types-element, which did the trick.

By the way: I could not get my favorite tool SOAPUI to build the appropriate SOAP-request for me in order to test my webservice. ZendStudio did not generate working WSDL in this case.

Google Shell

For those who like working on the terminal, this wrapper for Google-Search is a must: http://goosh.org

Help of Goosh

It emulates a shell-like interface in your browser.

Short intro:

  • ‘s webdev-notepad’ – performs a search
  • ‘m’ – shows more results after you searched for something
  • ‘video pigor’ – searches for videos of pigor
  • ‘gmail’ – lets you log into GMail
  • it even saves a history of your commands

Play with it!

Stages of Innovation

The five stages of innovation:

1. People deny that the innovation is required.
2. People deny that the innovation is effective.
3. People deny that the innovation is important.
4. People deny that the innovation will justify the effort required to adopt it.
5. People accept and adopt the innovation, enjoy its benefits, attribute it to people other than the innovator, and deny the existence of stages 1 to 4.

Taken from http://sydfish.wordpress.com/2008/03/17/the-five-stages-of-innovation/

Developer Mantras

A nice list of developer mantras:

http://www.pragprog.com/the-pragmatic-programmer/extracts/tips

Excerpt:

  • Don’t Repeat Yourself
  • Eliminate Effects Between Unrelated Things
  • Don’t Assume It – Prove It
  • Design with Contracts
  • Finish What You Start
  • Refactor Early, Refactor Often
  • Test Your Software, or Your Users Will
  • Don’t Think Outside the Box – Find the Box
  • Coding Ain’t Done ‘Til All the Tests Run
  • There Are No Final Decisions
  • Fix the Problem, Not the Blame
  • Crash Early
  • Minimize Coupling Between Modules
  • Don’t Program by Coincidence
  • Start When You’re Ready
  • Find Bugs Once
  • and many more …

If you want to find out more, check out the books at the bottom of the mentioned URL.

Apply, Inspect and Adapt

Inspired by a talk of Joseph Pelrine

http://www.infoq.com/presentations/Agile-Adoption-Joseph-Pelrine

about why agile methods sometimes fail in organizations, I became aware of the following point:

The cycle to successful progress in agile teams is NOT Inspect > Adapt but rather Apply > Inspect > Apadpt.

Agile teams operate in complex environments (systems). Often there are no direct connections between causes and effects observable about things that are going on during project sprints. The only chance is to address issues in retrospect with a bit more distance and the picture how things evolved in the underlying system. You can not do a useful insprection and then do adaptions without really having tried (=applied) things out in your system’s environment.

Some other points from Joseph Pelrine’s session on why agile sometimes fails:

  • Not understanding the Apply > Inspect > Adapt cycle.
  • If you are doing agile by the book (only Inspect > Adapt), you are not doing agile.
  • Agile techniques are scary to many people. They can not deal with what comes up and tend to get crushed.
  • People not willing or able to step outside of their comfort-zones.
  • Problems in communication and conflicts.
  • Use of the wrong tools in wrong places just for the sake of using them.