On the way to better software

Thank you. This worked perfectly, and enabling fs...

2011-08-27T18:34:55.280+02:00

Thank you. This worked perfectly, and enabling fsc really helped with the make time.

Yikes! If you want to use a set of indices rather...

2011-06-08T20:10:31.074+02:00

Yikes!

If you want to use a set of indices rather than Range(..), don't forget to use a toSeq before the map!

idxSet.toSeq.map(seq).sum

Regarding the IDEA options: As far as I can rememb...

2011-03-13T14:48:08.682+01:00

Regarding the IDEA options: As far as I can remember I was trying all possible combinations without success.

Regarding fsc port: When configured to use fsc, IDEA starts fsc client complier as separate java process and from my understanding the client is responsible for picking the right port by looking at "port" file in directory /tmp/scala-devel//scalac-compile-server-port/

I hope that helps you.

Do you do anything with idea options like: - rese...

2011-03-13T12:30:08.858+01:00

Do you do anything with idea options like:
- reset fsc server
- shutdown fsc server
?
How IDEA knows to which port to connect?

Thanks

Peter, you're totally right. Non-indexed lists...

2011-02-27T16:00:03.979+01:00

Peter, you're totally right. Non-indexed lists are wrong choice for random access reads. I've tested Range-Map implementation once again with conversion in.toSeq replaced by in.toIndexedSeq. This time preformance is very good again also for non-indexed lists.

The result of the benchmarks depend on the type of...

2011-02-26T15:31:06.504+01:00

The result of the benchmarks depend on the type of the collection you are filtering. On Arrays, filterUsingMap is fast, however on Lists its behaviour is terrible.

This is because you use O(N) many indexed accesses, each of which is O(1) for arrays and O(N) for Lists. Thus filterUsingMap is O(N) for arrays, but O(N*N) for lists.

Good idea, I like it. Note that map(seq.apply(_))...

2011-02-23T00:58:38.901+01:00

Good idea, I like it.

Note that map(seq.apply(_)) can be shortened to just map(seq).

Thanks for pointing this out. Using +: gives bette...

2011-02-22T23:44:40.520+01:00

Thanks for pointing this out. Using +: gives better results. I've also tried with :: and it's even faster.
Btw, I figured out one more implementation which is very promising although it requires the collection to be a Seq: Range(offset, seq.size, step).map(seq.apply(_))
Benchmarks will be published soon.

#4 is O(n^2) overall because :+ is O(n) on List. +...

2011-02-22T03:34:21.415+01:00

#4 is O(n^2) overall because :+ is O(n) on List. +: is O(1) though, so you could build up the list in reverse order and then reverse it at the end of the loop, reducing the overall runtime to O(n).

Thanks, Krysztof

2011-01-30T08:16:29.303+01:00

Thanks, Krysztof

Thank You, Krzysztof! Your recipe does really help...

2011-01-05T23:48:10.622+01:00

Thank You, Krzysztof!
Your recipe does really help.

I've added "fsc -shutdown" at the beginning of the bash script, too.

Best regards,
Eugen Labun

I didn't know Qi4j before. After reading your ...

2009-09-08T23:35:27.831+02:00

I didn't know Qi4j before. After reading your comment I know I need to have a closer look on it.
And what are the werewolfs? There are several like wrong application architecture, ugly design, misuse of the tools.

"If all you have is an object, everything loo...

2009-09-02T06:05:55.547+02:00

"If all you have is an object, everything looks like a dependency."

-- Niclas Hedhman, 2004

You are right that DI is not a golden hammer, silver bullet (who/what is the werewolf?) or a magic trick to get your code in order. Quite contrary as you point out. Overuse, without scope and context management is a recipe for the very popular Bowl/Ball of Mud.

Now, Rickard Oberg and I have long been struggling with architectural questions around good Java applications, he coming from the EJB failure and I from the Apache Avalon failure. Our combined effort of "assume everything is wrong" and "challenge everything" has (IMVHO) produced a lot of "forgotten" insights into Java development.

The result is seen in Qi4j and what we call Composite Oriented Programming.

In respect to this article, Dependency Injection is central, BUT it is scoped and limited. Scope means "from where can this come from" and with limited we mean "not anything can be injected".

@Service BankTeller teller;

That is injection of a BankTeller service. Clear, concise, and since we make the declaration in code, we don't need to juggle with the XML.

JSR-330 also embraces the scope concept, but insist on doing so at the declaration and not at the injection;

@Inject BankTeller teller;

Is it a service, an entity or a plain value?? You must go to the declaration of BankTeller to find out. We think that simplifies writing, but makes reading much harder, and reading code is what needs to be simpler, not writing it.

Another mechanism that we are using heavily in Qi4j, that isn't thought of as Dependency Injection is the "Builder Pattern".
In Qi4j, you simply do;

UnitOfWork uow = factory.currentUnitOfWork();

EntityBuilder<User> builder = uow.newEntityBuilder( User.class );

User proto = builder.instance();
proto.name().set( "Niclas Hedhman" );
:
:
User user = builder.newInstance();

where,

public interface User
{
Property<String> name();
}

Now, since User is a interface it can not be instantiated. But, we provide a way to make declarations of visibility and mapping between a domain interface and a Composite (kind-of object),

public interface UserEntity extends User, EntityComposite
{}

and

public void assemble( ModuleAssembly module )
{
module.addEntities( UserEntity.class );
}

This gives us really simple mechanisms for 'injection' of what type is going to be used, for instance for TDD, but could be a 'sandboxed' environment, 'staging', 'secured' and so forth.

Builder patterns can easily be deployed for many of the Dependency Injection tasks without framework support or even if Spring Framework is the 'base architecture' (shrug) to minimize the amount of XML that needs to be juggled.

Spring has a large set of problems as a DI framework, from the idiotic idea that the presence of getAbc()/setAbc() makes Abc a property, to that everything should be injected, therefor institutionalizing the idea that object creation is best left to clients (*shrug*).