Because I'm very busy lately I'll keep it short. Having been annoyed by Hibernate, all the magic happening under the hood and rarely any information on what is really going on I decided to do a little research on hibernate lifecycle. I don't think any document of that sort exists on the web so I decided to share it with you. I tried my best to double check everything but I might have omitted something. If you spot an error - please let me know.
See Hibernate lifecycle document
This blog is no longer being maintained, please go to The missing link of Agile instead
Saturday, November 21, 2009
Wednesday, July 01, 2009
Design patterns in Scala: Adapter
One might think that when considering Adapter pattern the ol' good Java implementation is 'as good as it gets'. But as you're probably already guessing I believe it is not. Surprisingly (ye.. right) Scala shines also on this front.
Say the code we're dealing with is:
If you wanted to adapt 'Communism' to behave as 'Capitalism' (say we need it during visits of important foreign ministers ;)) in Java typically you'd do it like:
If you're in control of 'Capitalism' class it'd be even better to do 'Capitalism' a trait or create 'ICapitalism' trait which'd be implemented by 'Capitalism' class.
Anywho.. Let's do it Scala way.
That may seem like a one simple and insignificant improvement - but in fact it's pretty powerful stuff. After all an explicit conversion you did in Java is nothing but noise (by now you most probably noticed that Scala is the noise-annihilator).
Also it saves you from all that extra keystrokes and postpone RSI ;).
And with more difficulty it gets only better. Consider following problem:
For reasons unknown (Architectus Reloadus asked us to do so) we want to extend some lists in our system with a 'fancyMethod'. These conversion should apply only to the lists that contain elements able to be converted to a 'String'.
To do it in Scala you implement an implicit conversion of a 'listToStringList' and put a requirement on a user of providing an implicit conversion of each element to 'String'.
I won't provide the Java solution for this problem just because I care about my sinews..
An important thing to remember is that implicit conversions in Scala are not transitive. It is still possible to do such conversion (with calling any method explicitly) but it must be 'requested' with ':' operator.
Say the code we're dealing with is:
class Communism { def makePropaganda = ... }
class Capitalism { def usePublicRelations = ... }
If you wanted to adapt 'Communism' to behave as 'Capitalism' (say we need it during visits of important foreign ministers ;)) in Java typically you'd do it like:
class CapitalismAdapter(val communism : Communism) extends Capitalism {
def usePublicRelations = communism.makePropaganda();
}
// Usage:
new CapitalismAdapter(new Communism).usePublicRelations
If you're in control of 'Capitalism' class it'd be even better to do 'Capitalism' a trait or create 'ICapitalism' trait which'd be implemented by 'Capitalism' class.
Anywho.. Let's do it Scala way.
implicit def systemTransformation(communism : Communism) : Capitalism = new Capitalism {
def usePublicRelations = communism.makePropaganda();
}
// Usage:
new Communism.usePublicRelations
That may seem like a one simple and insignificant improvement - but in fact it's pretty powerful stuff. After all an explicit conversion you did in Java is nothing but noise (by now you most probably noticed that Scala is the noise-annihilator).
Also it saves you from all that extra keystrokes and postpone RSI ;).
And with more difficulty it gets only better. Consider following problem:
For reasons unknown (Architectus Reloadus asked us to do so) we want to extend some lists in our system with a 'fancyMethod'. These conversion should apply only to the lists that contain elements able to be converted to a 'String'.
To do it in Scala you implement an implicit conversion of a 'listToStringList' and put a requirement on a user of providing an implicit conversion of each element to 'String'.
trait StringList { val list : List[String]; def fancyMethod = () }
// implement implicit conversion of 'List[A]' to 'StringList'
implicit def listToStringList[A](aList : List[A])
// require to provide (another) implicit conversion method (A => String) in a scope of this conversion usage
(implicit aToString : A => String) = {
new StringList { val list = aList.map(aToString) }
}
// Usage:
def foo(s : StringList) = ()
// should cause error:
foo(List(1, 2, 3))
implicit def intToString(i : Int) = i.toString
// and now it works:
foo(List(1, 2, 3))
I won't provide the Java solution for this problem just because I care about my sinews..
An important thing to remember is that implicit conversions in Scala are not transitive. It is still possible to do such conversion (with calling any method explicitly) but it must be 'requested' with ':' operator.
class A; class B; class C; class D
implicit def aToB(a : A) = new B
implicit def bToC(b : B) = new C
implicit def cToD(c : C) = new D
// Usage:
val a = new A
println((a:B):C) // A => C
println(((a:B):C):D) // A => D
Monday, June 29, 2009
Design patterns in Scala: Command
Many people say that Command pattern in languages of functional paradigm is not really a pattern but actually an inherent feature of a language itself. I don't know about other languages but in Scala it is not entirely true. While it is rather quite easy to come up with Command pattern implementation - you write a closure and it's done ;) - but variety of possibilities that language gives you is pretty amazing.
Let's start from the very beginning.
I believe that the three following points represent the most important aspects to consider when choosing appropriate implementation of Command Pattern in Scala.
However concise and elegant it has important shortcomings. Firstly you get very wide and crude interface - (Int) => (Unit) means nothing after all. You won't communicate a lot of information with that and a user can pass any command to an "invoker" method (including ShutDownReactor procedure ;]). The second thing is a nasty wildcard you have to use when assigning an instance of a command to a variable. (which you may optionally use in 2. - and if you don't compiler will do it for you).
You can have a bit cleaner solution with following piece of code.
The method presented above is actually the partially applied function of a function from the previous example. You gain the advantage of not writing the '_' (placeholder) when assigning an instance to a variable - what IMHO both simplifies and makes it a little less magical :). And if you wonder what would happen if you've added it anyway, the answer is simple - you'd get a partially applied partially applied function ;P with following signature:
To solve the issue of wide interface you might use the more classical example of a Command pattern with a bit of functional language coolness on the top ;)
Pretty nice - it gives you very clean nice interface with possibility of extending it with whatever responsibility you like (what was obviously missing in first two examples). Nothing comes for free though - the ad hoc construction of a command class is more verbose than a simple command function.
If you're cra^M^M^Mbrave enough you might even try something like this:
And now the nice thing is that you may both use it as in 3. example and also pass it to a function defined in previous code snippets. Though I have no idea why anyone would like to do that ;)
While I'm at it I'd remind you about a cool Scala feature that let you extend class behaviour at instantiation and thus you can do the same with:
Fun Exercise! ;)
The implementation of a class that may be passed as a parameter to a 'coolFunction' is left to a reader and may be impossible :P
Let's start from the very beginning.
I believe that the three following points represent the most important aspects to consider when choosing appropriate implementation of Command Pattern in Scala.
- what the signature of "Command" used as a parameter looks like
- how do you construct a "Command" instance
- how do you assign a "Command" instance to a value
// Example 1
def command(i : Int) = println(i);
// Usage:
// 1
def invoker(cmd : Int => Unit) = cmd(1)
// 2
invoker(command _)
// or
invoker(command)
// 3
val savedCommand = command _
However concise and elegant it has important shortcomings. Firstly you get very wide and crude interface - (Int) => (Unit) means nothing after all. You won't communicate a lot of information with that and a user can pass any command to an "invoker" method (including ShutDownReactor procedure ;]). The second thing is a nasty wildcard you have to use when assigning an instance of a command to a variable. (which you may optionally use in 2. - and if you don't compiler will do it for you).
You can have a bit cleaner solution with following piece of code.
// Example 1
def command = (i : Int) => println(i);
// Usage:
// 1
def invoker(cmd : Int => Unit) = cmd(1)
// 2 a) prepared command
invoker(command)
// 2 b) ad hoc command
invoker((i : Int) => println(i))
// 3
val savedCommand = command
The method presented above is actually the partially applied function of a function from the previous example. You gain the advantage of not writing the '_' (placeholder) when assigning an instance to a variable - what IMHO both simplifies and makes it a little less magical :). And if you wonder what would happen if you've added it anyway, the answer is simple - you'd get a partially applied partially applied function ;P with following signature:
() => (Int) => Unit
To solve the issue of wide interface you might use the more classical example of a Command pattern with a bit of functional language coolness on the top ;)
// Example 3
trait Command { def apply(i : Int) }
object DefaultCommand extends Command { def apply(i : Int) = println(i) }
// Usage:
// 1
def invoker(cmd : Command) = cmd(1)
// 2
invoker(DefaultCommand)
// 2 b) ad hoc command construction
invoker(new Command { def apply(i : Int) = println(i) })
// 3
val savedCommand : Command = DefaultCommand
Pretty nice - it gives you very clean nice interface with possibility of extending it with whatever responsibility you like (what was obviously missing in first two examples). Nothing comes for free though - the ad hoc construction of a command class is more verbose than a simple command function.
If you're cra^M^M^Mbrave enough you might even try something like this:
class CrazyCommand extends (Int => Unit) { def apply(i : Int) = println(i) }
And now the nice thing is that you may both use it as in 3. example and also pass it to a function defined in previous code snippets. Though I have no idea why anyone would like to do that ;)
While I'm at it I'd remind you about a cool Scala feature that let you extend class behaviour at instantiation and thus you can do the same with:
new Command with (Int => Unit) { def apply(i: Int) = println(i) }
Fun Exercise! ;)
type CoolCommand = (Int => Unit) with (String => Unit)
def coolFunction(cmd : CoolCommand) { cmd(1); cmd("one") }
The implementation of a class that may be passed as a parameter to a 'coolFunction' is left to a reader and may be impossible :P
Thursday, June 18, 2009
Design patterns in Scala: Singleton
I am always keen on improving my knowledge of Scala. Second thing is that I really enjoy to share what I learned with everyone (I do really hope people eventually gain much more interest in Scala :D). That's why I decided to make series on .. GoF design patterns in Scala.
For starters I've chosen our old friend - Singleton. Let's go then!
Done! Thx for reading..
..just kidding, let's dig a little deeper into that.
You are probably curious about thread safety of this solution. The actual code generated in bytecode and decompiled with JAD looks like that:
There are 3 things to consider:
An important thing to notice is that Singleton is eagerly initialized so if you try:
The trick is to make default constructor private and have apply method of 'object' class type return the only instance of LazySingleton class.
Disadvantage of second implementation is a small but noticable difference in usage. First - requires '()' [apply[ operator to be used. Second - it returns different type of class depending on whether '()' is used (class LazySingleton) or not (object LazySingleton):
Modified 2009-06-23: Previous implemention of lazy singleton was incorrect and led to wrong conclusions.
For starters I've chosen our old friend - Singleton. Let's go then!
object Singleton
// Usage:
val singleton = Singleton
Done! Thx for reading..
..just kidding, let's dig a little deeper into that.
You are probably curious about thread safety of this solution. The actual code generated in bytecode and decompiled with JAD looks like that:
public final class Singleton$
implements ScalaObject
{
public Singleton$()
{
}
public int $tag()
throws RemoteException
{
return scala.ScalaObject.class.$tag(this);
}
public static final Singleton$ MODULE$ = this;
static
{
new Singleton$();
}
}
There are 3 things to consider:
- Singleton object is initialized in static block so thread safety is guaranteed by JVM
- Every time you reference Singleton object in your code, Scala compiler translates this call into 'Singleton$.MODULE$',
- This implemention has also quite cool semantics of access modifiers (which is a bit more advanced topic; search for 'companion module' to learn more).
An important thing to notice is that Singleton is eagerly initialized so if you try:
java.lang.Class.forName("Singleton$") it'll cause initialization to be performed. For now I have no idea how to force 'object' in Scala to be lazy initialized. The only solution I came up with would be:
// Incorrect (see the bottom of article)class LazySingleton private () {
def apply() = this
}
// Correct
class LazySingleton private () {
}
object LazySingleton {
lazy val INSTANCE = new LazySingleton();
def apply() = INSTANCE
}
// Usage:
val singleton = Singleton()
The trick is to make default constructor private and have apply method of 'object' class type return the only instance of LazySingleton class.
Disadvantage of second implementation is a small but noticable difference in usage. First - requires '()' [apply[ operator to be used. Second - it returns different type of class depending on whether '()' is used (class LazySingleton) or not (object LazySingleton):
scala> C()
res1: C = C@304648
scala> C
res2: C.type = C$@1b9e7fc
Modified 2009-06-23: Previous implemention of lazy singleton was incorrect and led to wrong conclusions.
Wroclaw Area Situated Scala Enthusiasts group established !!
I am happy to announce that Przemysław Pokrywka and Piotr Adamski established WrASSE (Wroclaw Area Situated Scala Enthusiasts) here in Wroclaw!! It's really amazing to meet people that care about Scala and hope for this great language to become the next Java :D
If you're curious how this image is connected to this post visit WrASSE discussion group
There are regular meetings planned in the (hopefully near) future, but a group is veeery young and all your great ideas for WraSSE are welcome!
If you are Scala fun (slash zealot .. whatever ;)) and do care about your professional future (which would be Scala mostly ;P) I encourage you to join this group and actively participate!
If you're curious how this image is connected to this post visit WrASSE discussion groupThere are regular meetings planned in the (hopefully near) future, but a group is veeery young and all your great ideas for WraSSE are welcome!
If you are Scala fun (slash zealot .. whatever ;)) and do care about your professional future (which would be Scala mostly ;P) I encourage you to join this group and actively participate!
Monday, June 15, 2009
My two cents on Agile adoption
Agile is like teenage sex, everybody is talking about it, most are not doing it and those that are doing it, are doing it wrong.So a guy - let's call him John - wants his company to be hip'n'cool and be Agile. He goes by the book, put some things into work and yeeeeaahh.. nooo.. - people scream, tools don't work, tests breaks, client's pissed.. He begins ranting on Agile being unable to deliver him its expected awesomeness.. trying harder and harder.. right until it breaks completely.paraphrase of James O. Coplien 1
Yeeah...
You know Albert Einstein was a pretty smarty guy? He actually said:
Insanity: doing the same thing over and over again and expecting different results.That is exaaactly what John is doing. I am honestly amazed how vast majority of people approach this problem. It may be characterized as: "Doesn't work? Let's ditch it". I mean.. WTF? Are they really that lazy to make any alterations? It's either that or they thought they'd be anointed by Holy Ghost with Agile skills.. I mean be reasonable you don't expect to become Software Architect one month after graduation...
However there's still a question to answer: "What might be a better solution than moving back to RUP" (which is bad and stinks and even IBM knows it :P).
You know how TDD cycle looks like don't you:
What if I've shown you something quite similar:
First - move slowly, take small steps. Otherwise you won't know what works and what doesn't, you will overwhelm your team2 with too much change and slow down development process down to nothing.
Second - use feedback! You're getting negative - may it be - in TDD red tests have the same value as green ones.
Third - don't expect to become Agile star overnight.
It requires time.
It requires effort.
It may deliver profits.
If you're not determined to take a risk don't put blame on a process. Just admit it.
1. From his superb presentation on DCI.
2. "Gently introduce change to a team. Don't expect things to suddenly change overnight." Ryan XXX [don't know last name]
Thursday, June 04, 2009
Been busy preparing presentation "Scala for practitioners"
Last month it was pretty silent on this blog and I got to say sorry for that. It was quite busy month for me and I couldn't even find the time to tweet not mentioning blogging. The most important thing that came out to live during this time was a presentation - on probably the best language in the world - titled: "Scala for practitioners". I gave it for the first time yesterday in Power Media S.A. (which is the company I'm currently cooperating with as a freelancer :)) and you can find the project I used during the presention here on github. The primary goal was to show Scala as language having real business value here and now, being really close to get significant impact in software projects. From all the feedback that I've gathered I guess I can safely state - it was a success! :D Next I'm planning on giving this presentation on Wroclaw JUG. It actually needs some minor corrections (what again will probably cause absence of new posts on this blog .. ;P) but I really hope it will trigger more enthusiasm for Scala in Java community. I'm also thinking on doing some screencasts on Scala but the exact idea is not fully matured yet, so all tips are welcome!
For all of you not to feel like you've lost another 2 minutes of your life reading this post:
Mindblowing example of how cool is regexp matching in Scala (if you think you've seen it try checking it out anyways - it's not the same old regexp matching example :P).
For all of you not to feel like you've lost another 2 minutes of your life reading this post:
Mindblowing example of how cool is regexp matching in Scala (if you think you've seen it try checking it out anyways - it's not the same old regexp matching example :P).
Sunday, May 03, 2009
Delivering the code is like doing the laundry
I hate doing the laundry.. it's definitely in the top 5 of housework activities I hate.. Recently I talked with my friend about - no, not about doing the laundry ;) but nonetheless the topic came around. He was actually amazed how might I not like this particular activity - 'cause in his eyes it was nothing more than putting your dirty stuff to the washing machine, switching it on and doing nothing for an hour or so. I couldn't answer right away so I decided to focus next time I'm doing the laundry on what exactly I don't like about it. Identifying the precise reason behind reluctance to a certain thing or activity is after all the first step to overcome it ;)). Then the day came - stuff started to pour out of the clothes basket (as usual) and I was forced to clean this mess up.. To spare you the details, the list of activities being part of doing the laundry is:
So this basic task is as a matter of fact damn strategic operation ;] And that's the precise reason why I hate doing the laundry :) (And will probably continue to not like it :]) At this point you must already be wondering "what the hell is this guy prattling about?" Let's begin a second story then! ;)
Recently I had a small discussion with my colleague about the (un) importance of testing. He defended the concept of testing being time-consuming and thus not acceptable in software business. He represented the old school of "yes I know it's important but we don't have time for this stuff we need to get the implementation fast". What drew my attention was the last part of this sentence "we need to get the implementation fast". As if in the software business we were responsible to push the code out of the door and not give a damn where/when/what it'll be used (for). This is not the first time I hear this opinion - software developers too often forget that the code is not what we produce (yes, I know it's easy to see it this way). Our job is however do deliver functionality to the client and not the crappy, low-quality kind of functionality which she/he never wanted. The high-quality and precise reflection of her/his requirements (which she/he might have not even been aware of.. that's the hard part).
When unit testing is not the elementary part of software development the whole activity of delivering a single requirement consists of:
Finally what's the resemblance between doing the laundry and delivering the code, you ask. There is a clear tendency for both to be interpreted too narrow! :)
Just like doing the laundry is more than putting clothes to the washing machine,
delivering the code is more than coding the implementation.
- sorting the laundry
- stuffing it to the washing machine
- going to the market because you forgot you were low on the @#$#@ washing powder
- taking the laundry out and hanging it on a dryer
- collecting the laundry after it dries
- ironing (personally at this point I'm too pissed about the whole activity and skip this point)
- folding clothes and putting them to the drawers, wardrobe or wherever they should be stuffed..
So this basic task is as a matter of fact damn strategic operation ;] And that's the precise reason why I hate doing the laundry :) (And will probably continue to not like it :]) At this point you must already be wondering "what the hell is this guy prattling about?" Let's begin a second story then! ;)
Recently I had a small discussion with my colleague about the (un) importance of testing. He defended the concept of testing being time-consuming and thus not acceptable in software business. He represented the old school of "yes I know it's important but we don't have time for this stuff we need to get the implementation fast". What drew my attention was the last part of this sentence "we need to get the implementation fast". As if in the software business we were responsible to push the code out of the door and not give a damn where/when/what it'll be used (for). This is not the first time I hear this opinion - software developers too often forget that the code is not what we produce (yes, I know it's easy to see it this way). Our job is however do deliver functionality to the client and not the crappy, low-quality kind of functionality which she/he never wanted. The high-quality and precise reflection of her/his requirements (which she/he might have not even been aware of.. that's the hard part).
When unit testing is not the elementary part of software development the whole activity of delivering a single requirement consists of:
- requirements elicitation
- coding
- QA testing
- fixing the code
- QA testing
- deployment
- client finding bugs (this is the optimistic version where the software actually reflects her/his requirements)
- fixing the code
- deployment
Finally what's the resemblance between doing the laundry and delivering the code, you ask. There is a clear tendency for both to be interpreted too narrow! :)
Just like doing the laundry is more than putting clothes to the washing machine,
delivering the code is more than coding the implementation.
Wednesday, April 29, 2009
It's not about how fast you code the requirements but how soon you get them right
The actual software is just a byproduct of the process of building an understanding of a given domain.
Jonas Bandi
The misconception behind the RAD tools comes from the desire to implement the software (ie. do the coding) as quickly as possible. People believe that producing software is hard - and they're correct, it really is! The problem is that it is not the implementation that is tough. Meeting blurry, vague wishes of your client - sometimes erroneously called requirements - is the hardest part in software development. And unless you work on really dumb system for feeding the data using few hundreds of forms (which most probably means you do software for govmt) you really need to get the domain right.
On all projects with non-trivial business domain you spend most of the time analyzing clients requirements, evolving (expanding and refactoring) the domain model to meet your clients demands. You spend hours in front of the whiteboard with the marker in your hand talking about the domain. You do Proof-of-Concept, you revert, do it again, revert.. And then if you're totally, 100% sure what's really going on in this damn business domain (and BTW most probably you're still wrong about it ;)) you go to do some front-end, mailing, logging and all that supportive stuff.
In my first job I had a teammate who was a decent programmer but he shone big time. I spent a gigantic amount of time on learning every detail in technology we used and I knew the class model very good. He knew just enough about it but still when it came to talking about the project he always knew better. The thing was it that he focused on and understanding specifics of business domain what almost always gave him massive advantage.
Most of the time you do the knowledge crunching.
Tuesday, April 28, 2009
OO design, reuse and serendipity
Steve Vinoski said pretty wise stuff about reusability of REST-based systems. He said that powerful stuff as Unix small languages was probably incidental just because the design (unix pipe) was based on modularity and simplicity.
It is entirely the same for Object Oriented design. Keep your interfaces simple (ie. make them have clear boundaries [PDF warning!]) and your abstractions simple (ie. having clear and sharp definitions [PDF warning!]* - and modularity comes for free. Simplicity enables modularity!
The important part is that, what is easily forgotten, reuse is not only about using parts of the code on different projects - this should actually be quite rare - I mean most of the time you use external frameworks to do generic stuff.. don't you?. But you should constantly reuse domain classes by using them second, third and nth time in different contexts. And by different contexts I mean implementation of the most exotic requirements of your clients. It's definitely not a good sign if you catch yourself saying "naahh.. we can't use that method for the new requirement, 'cause it's doing this thing and the other thing to do that stuff here.. here.. and over theeeere.. we gotta write a new one".
What you might rather try is:
- refactor (decouple),
- test,
- reuse.
Do it KISS, don't strive for too much generality, but do it right! After the umpteen requirement (and refactoring) you'll be amazed that you have evolved a very sharp abstraction with clear boundaries. Moreover you gained a fair amount of domain knowledge because you kept on building larger coherent structure and not only solving single problems. Always remember about GPS** (Gain Perspective Stupid).
"Serendipitous reuse" is definitely a good sign and if you do OO right it'll come for free.
* The rule of a thumb is that if you have to use two metaphors (or more, sic!) to explain a role of an abstraction to the person from outside the project it means that your domain model stinks in that particular area.
** Coined by my good colleague and great software developer Piotr Wójcicki.
It is entirely the same for Object Oriented design. Keep your interfaces simple (ie. make them have clear boundaries [PDF warning!]) and your abstractions simple (ie. having clear and sharp definitions [PDF warning!]* - and modularity comes for free. Simplicity enables modularity!
The important part is that, what is easily forgotten, reuse is not only about using parts of the code on different projects - this should actually be quite rare - I mean most of the time you use external frameworks to do generic stuff.. don't you?. But you should constantly reuse domain classes by using them second, third and nth time in different contexts. And by different contexts I mean implementation of the most exotic requirements of your clients. It's definitely not a good sign if you catch yourself saying "naahh.. we can't use that method for the new requirement, 'cause it's doing this thing and the other thing to do that stuff here.. here.. and over theeeere.. we gotta write a new one".
What you might rather try is:
- refactor (decouple),
- test,
- reuse.
Do it KISS, don't strive for too much generality, but do it right! After the umpteen requirement (and refactoring) you'll be amazed that you have evolved a very sharp abstraction with clear boundaries. Moreover you gained a fair amount of domain knowledge because you kept on building larger coherent structure and not only solving single problems. Always remember about GPS** (Gain Perspective Stupid).
"Serendipitous reuse" is definitely a good sign and if you do OO right it'll come for free.
* The rule of a thumb is that if you have to use two metaphors (or more, sic!) to explain a role of an abstraction to the person from outside the project it means that your domain model stinks in that particular area.
** Coined by my good colleague and great software developer Piotr Wójcicki.
Wednesday, April 22, 2009
My view on different level of abstractions in OO
Lately I've been trying to invent my very own classification of classes of abstractions you come across when creating object-oriented software. As every more-or-less formal classification it should give me (at least that's what I hope for) a possibility to infer various qualities and evaluate use-cases for each of the class of abstraction. It also gives you quite a nice foundation to introduce heuristics and conception of refactorings from/to certain class of abstraction.
I've come up with the idea of 3 categories which I call "nth class citizens":
- 1st class citizens - (abstract) domain classes,
- 2nd class citizens - (abstract) classes included in general purpose libraries - various data structures (eg. Collection, Set, Date, etc.),
- 3rd class citizens - primitive types and classes (eg. int, Long, BigDecimal).
In case of 1st class citizens the main problem is the metaphor. Every abstraction is described by either an abstract or real entity constituting its role. It is not always possible to model a goal and responsiblities of an entity in a programming language of your choice. It may happen that an object lose some meaning or demonstrates additional features. The first issue is easy to resolve as it requires us only to judge whether the lost qualities were necessary to fully express the intent of object existence. As for the latter:
- demonstrated features (qualities) may be the actual functions of the modeled abstraction - in this case by incident we get the useful extra "feedback of the metaphor",
- the new features have nothing in common with the modeled abstraction - the domain model is contaminated with false information. These features cause unnecessary confusion and draw away the attention of developers from the actual intent of choosing certain abstraction.
2nd class citizens use a general interface to communicate (this interface have a precise definition in the domain of computer science). Incidentally it matches the one of a modeled business domain. In most of cases (as in 80/20 rule) there is no need to hide the information they share with the external world - you should just use the standard "wide" general purpose interface. There is however a danger that:
- there are in fact 1st class citizens in disguise (eg. Set<Map<Account, Order>>),
- they either share too much information or their messages are too generic and hard too understand by their collaborators. In both situations they should be rather represented by 1st class citizens (implemented with encapsulation).
3rd class citizens, well... they just exist :). In most cases you just push them around - and in 99,999% of situations you should not use them to perform any business operation (eg. DON'T DO chargeClient(BigDecimal price)). They should always be "represented" by 1st class citizens (encapsulation).
This article is one of the first drafts and I hope I'll come back to this topic. There is never enough of polishing object oriented modelling, design and implementation skills! :)
I've come up with the idea of 3 categories which I call "nth class citizens":
- 1st class citizens - (abstract) domain classes,
- 2nd class citizens - (abstract) classes included in general purpose libraries - various data structures (eg. Collection, Set, Date, etc.),
- 3rd class citizens - primitive types and classes (eg. int, Long, BigDecimal).
In case of 1st class citizens the main problem is the metaphor. Every abstraction is described by either an abstract or real entity constituting its role. It is not always possible to model a goal and responsiblities of an entity in a programming language of your choice. It may happen that an object lose some meaning or demonstrates additional features. The first issue is easy to resolve as it requires us only to judge whether the lost qualities were necessary to fully express the intent of object existence. As for the latter:
- demonstrated features (qualities) may be the actual functions of the modeled abstraction - in this case by incident we get the useful extra "feedback of the metaphor",
- the new features have nothing in common with the modeled abstraction - the domain model is contaminated with false information. These features cause unnecessary confusion and draw away the attention of developers from the actual intent of choosing certain abstraction.
2nd class citizens use a general interface to communicate (this interface have a precise definition in the domain of computer science). Incidentally it matches the one of a modeled business domain. In most of cases (as in 80/20 rule) there is no need to hide the information they share with the external world - you should just use the standard "wide" general purpose interface. There is however a danger that:
- there are in fact 1st class citizens in disguise (eg. Set<Map<Account, Order>>),
- they either share too much information or their messages are too generic and hard too understand by their collaborators. In both situations they should be rather represented by 1st class citizens (implemented with encapsulation).
3rd class citizens, well... they just exist :). In most cases you just push them around - and in 99,999% of situations you should not use them to perform any business operation (eg. DON'T DO chargeClient(BigDecimal price)). They should always be "represented" by 1st class citizens (encapsulation).
This article is one of the first drafts and I hope I'll come back to this topic. There is never enough of polishing object oriented modelling, design and implementation skills! :)
Tuesday, March 31, 2009
the beauty of scala traits and self types
So I'm working on a small throw-away project to check out the Scala+Jersey+XStream stack and I've come across a nice implementation pattern (more precisely I found a way to use one I've heard of previously in the slight different context, see James Coplien presentation on DCI and the article on the subject).
I hold a reference to an instance of XStream class somewhere in my app. It is responsible for marshalling objects and it looks like this (examples are shortened for clarity):
That looks nice - the initialisation block gives the instantiation of XStream object nice DSLish look of a spec. But when I decided to use both XML and JSON and following chunk of code appeared on the screen.
Ok.. duplication strikes you right away. So how do you fight that monster? There are actually a few options to choose from:
Ok as for the first one - inheritance sux.. I mean really.. inheritance is for most of the time the last resort and you know it.
Second and the third one are ok.. I mean most of the time I'd say ok to this solution and implement something like this in Java.
Fourth one.. imho this is a hack and clear abuse of implicit conversion in Scala. Personally I believe that the use of implicit conversion can be justified when trying to bend the existing API for your purposes (ie. trying to seamlessly extend non-functional Java classes to full-blown Scala versions).
So what is the best solution I've found?
A powerful (and strikingly easy after you see it for the first time and get the 'aha moment') mechanism for introducing behavior into existing classes. It gives you a perfect decoupling and let you introduce an explicit abstraction for the extension ('configuration' in this case). And now I can do:
Which basically means: "give me an xstream instance.. but the configured one if you may!"
I am not sure I have fully explained the reason why I like the last one the most.. I got the gut-feeling this is the right path to go. Reusable, expressive, explicit.
I hold a reference to an instance of XStream class somewhere in my app. It is responsible for marshalling objects and it looks like this (examples are shortened for clarity):
val XML = new XStream(new xml.JDomDriver()) {{
setMode(XStream.NO_REFERENCES);
alias("courses", ScalaCollectionClasses.ListBuffer)
alias("course", classOf[resources.Course])
}}
That looks nice - the initialisation block gives the instantiation of XStream object nice DSLish look of a spec. But when I decided to use both XML and JSON and following chunk of code appeared on the screen.
val XML = new XStream(new xml.JDomDriver()) {{
setMode(XStream.NO_REFERENCES);
alias("courses", ScalaCollectionClasses.ListBuffer)
alias("course", classOf[resources.Course])
}}
val JSON = new XStream(new json.JsonHierarchicalStreamDriver()) {{
setMode(XStream.NO_REFERENCES);
alias("courses", ScalaCollectionClasses.ListBuffer)
alias("course", classOf[resources.Course])
}}
Ok.. duplication strikes you right away. So how do you fight that monster? There are actually a few options to choose from:
- inheritance
class MyXStream extends XStream {
setMode(XStream.NO_REFERENCES);
alias("courses", ScalaCollectionClasses.ListBuffer)
alias("course", classOf[resources.Course])
}
val XML = new MyXStream(new xml.JDomDriver())
val JSON = new MyXStream(new json.JsonHierarchicalStreamDriver()) - delegation
val XML = new XStream(new xml.JDomDriver()) {{ configure(this) }}
val JSON = new XStream(new json.JsonHierarchicalStreamDriver()) {{ configure(this) }}
def configure(xstream : XStream) = {
setMode(XStream.NO_REFERENCES);
alias("courses", ScalaCollectionClasses.ListBuffer)
alias("course", classOf[resources.Course])
}
or
val XML = configure(new XStream(new xml.JDomDriver()))
val JSON = configure(new XStream(new json.JsonHierarchicalStreamDriver()))
def configure(xstream : XStream) = {
xstream.setMode(XStream.NO_REFERENCES);
xstream.alias("courses", ScalaCollectionClasses.ListBuffer)
xstream.alias("course", classOf[resources.Course])
xstream
} - implicit conversion
val XML = new XStream(new xml.JDomDriver()).configure()
val JSON = new XStream(new json.JsonHierarchicalStreamDriver()).configure()
def xstreamToConfigurableXStream(xstream : XStream) = new {
def configure() = {
setMode(XStream.NO_REFERENCES);
alias("courses", ScalaCollectionClasses.ListBuffer)
alias("course", classOf[resources.Course])
}
}
Ok as for the first one - inheritance sux.. I mean really.. inheritance is for most of the time the last resort and you know it.
Second and the third one are ok.. I mean most of the time I'd say ok to this solution and implement something like this in Java.
Fourth one.. imho this is a hack and clear abuse of implicit conversion in Scala. Personally I believe that the use of implicit conversion can be justified when trying to bend the existing API for your purposes (ie. trying to seamlessly extend non-functional Java classes to full-blown Scala versions).
So what is the best solution I've found?
trait Configuration
/* 1. */ trait DefaultConfiguration extends Configuration { /* 3. */ this: XStream =>
/* 4. begin */
setMode(XStream.NO_REFERENCES);
alias("courses", ScalaCollectionClasses.ListBuffer)
alias("course", classOf[resources.Course])
/* 4. end */
}
/* 2. */val XML = new XStream(new xml.JDomDriver()) with DefaultConfiguration;
val JSON = new XStream(new json.JsonHierarchicalStreamDriver()) with DefaultConfiguration;
- Create a trait that will bind the reference to an instance of a class it extends to "this"
- Create an instance XStream for XML marshalling and extend with 'DefaultConfiguration' trait which..
- in fact will bind the instance of XStream to 'this' and..
- perform an initialisation of a bound object
A powerful (and strikingly easy after you see it for the first time and get the 'aha moment') mechanism for introducing behavior into existing classes. It gives you a perfect decoupling and let you introduce an explicit abstraction for the extension ('configuration' in this case). And now I can do:
def foo(xstream : XStream with Configuration) = "thanks for configured xstream instance bro"
Which basically means: "give me an xstream instance.. but the configured one if you may!"
I am not sure I have fully explained the reason why I like the last one the most.. I got the gut-feeling this is the right path to go. Reusable, expressive, explicit.
Keywords vs API, continued
Przekonany postem Jeffa Atwooda (którego mimo wszystko jeszcze czytam :P) postanowiłem, że decyzją pragmatyczną będzie zmiana języka bloga na 'informatyczne esperanto' czyli angielski. Z dniem dzisiejszym wszystkie posty będą ukazywały się w tymże języku.
-- Translation --
Jeff Atwood (whose blog I continued to read in spite of everything :P) convinced me in his latest post that it'd be a pragmatic decision to switch the langugage of posts to 'Esperanto of software world', ie. English. Therefore starting today all posts are written in English.
Here we go then!
In one of the older posts I mentioned that it may be quite a problem to migrate from Scala to Java world. The keywords chosen for Scala might have been used already for name of the methods or classes in existing Java APIs (e.g. 'match' or 'yield') thus preventing us from using them in our code. BTW the well known example of such a case is Java evolution itself (1.4 -> 1.5 and the appearance of 'enum' keyword')
It appears that in Scala nothing is impossible! Well it is not feasible to define/use functions as presented below:
Yet nothing prevents us from doing it this way:
It is incredibly useful not only for Scala adoption among Java developers but also quite helpful during the development of 'Scala greenfield projects'. While in Java it is not that big issue (due to relatively small number of keywords) in Scala it'd have probably started being a bit of pain in the ass (with keywords like 'val' or 'match').
The conclusion? Scala rox! :D
-- Translation --
Jeff Atwood (whose blog I continued to read in spite of everything :P) convinced me in his latest post that it'd be a pragmatic decision to switch the langugage of posts to 'Esperanto of software world', ie. English. Therefore starting today all posts are written in English.
Here we go then!
In one of the older posts I mentioned that it may be quite a problem to migrate from Scala to Java world. The keywords chosen for Scala might have been used already for name of the methods or classes in existing Java APIs (e.g. 'match' or 'yield') thus preventing us from using them in our code. BTW the well known example of such a case is Java evolution itself (1.4 -> 1.5 and the appearance of 'enum' keyword')
It appears that in Scala nothing is impossible! Well it is not feasible to define/use functions as presented below:
def match() = "Hello world! I am a 'match'!"
def yield() = "Hello world! I am a 'yield'!"
match()
yield()
Yet nothing prevents us from doing it this way:
def `match`() = "Hello world! I am a 'match'!"
def `yield`() = "Hello world! I am a 'yield'!"
`match`()
`yield`()
It is incredibly useful not only for Scala adoption among Java developers but also quite helpful during the development of 'Scala greenfield projects'. While in Java it is not that big issue (due to relatively small number of keywords) in Scala it'd have probably started being a bit of pain in the ass (with keywords like 'val' or 'match').
The conclusion? Scala rox! :D
Sunday, March 15, 2009
404 done the right way
Ponieważ po raz kolejny napotykam się na beznadziejny komunikat 404 .. postanowiłem poprawić jeden z nich. Na poprawce spędziłem +/- 30 sekund i przepraszam za ewentualne błędy.
Przed Pawłem:
Po Pawle:
Po Pawle wersja minimalistyczna:
Dlaczego uważam, że moje wersje są lepsze? Pozwolę sobie skomentować niektóre fragmenty komunikatu:
1) "Welcome to 404 error page"
Przeciętnego użytkownika Internetu doprawdy niewiele obchodzi czy kod błędu w protokole HTTP to 404, Alfa8 czy Dupa16.. Chciałbym, żeby programiści wreszcie zaczęli sobie z tego zdawać sprawę. Z drugiej strony świadomy użytkownik internetu zdaje sobię sprawę że nie istniejąca strona to kod 404 - więc po co mu o tym przypominać?! Kolejna rzecz, że obsługa błędów powinna być transparentna dla użytkownika i wtedy nie będzie musiał się uczyć różnicy między 404 a dajmy na to 410. Informacje czytelne dla komputerów zostawmy komputerom.
2) "Welcome to this customized error page. You've reached this page because you've clicked on a link that does not exist."
Ok.. odniosłem wrażenie jakbym celowo otworzył tę stronę i to co czytam było początkiem artykułu o kodzie błędu 404. Naprawdę nie wystarczyło krótkie i treściwe "Page does not exist" ?
3) "This is probably our fault..."
Nie miejsce i czas na unoszenie się honorem. Stare porzekadło ludowe mówi: "Klient ma zawsze rację". Komunikat powinen brzmieć: "This is totally our fault! We beg for forgiveness!"
4) "but instead of showing you the basic '404 Error' page that is confusing and doesn't really explain anything, we've created this page to explain what went wrong."
I co? Mam być wdzięczny, że straciłem 10 cennych sekund mojego życia czytając komunikat błędu ?!?!
5) "You can either (a) click on the 'back' button in your browser and try to navigate through our site in a different direction, or (b) click on the following link to go to homepage."
Chociaż mogli a i b pogrubić bo zajęło mi z dobre kilka sekund (a to dużo; odsyłam do badań z usability) żeby się dowiedzieć co mogę zrobić.
Reasumując:
Tworząc komunikaty z błędami kierujmy się zasadą KISS. Zaoszczędzimy użytkownikom dużo cennego czasu, który mogą spędzić, np. stymulując polski rynek browarniczny ;)
Przed Pawłem:
Po Pawle:
Po Pawle wersja minimalistyczna:
Dlaczego uważam, że moje wersje są lepsze? Pozwolę sobie skomentować niektóre fragmenty komunikatu:
1) "Welcome to 404 error page"
Przeciętnego użytkownika Internetu doprawdy niewiele obchodzi czy kod błędu w protokole HTTP to 404, Alfa8 czy Dupa16.. Chciałbym, żeby programiści wreszcie zaczęli sobie z tego zdawać sprawę. Z drugiej strony świadomy użytkownik internetu zdaje sobię sprawę że nie istniejąca strona to kod 404 - więc po co mu o tym przypominać?! Kolejna rzecz, że obsługa błędów powinna być transparentna dla użytkownika i wtedy nie będzie musiał się uczyć różnicy między 404 a dajmy na to 410. Informacje czytelne dla komputerów zostawmy komputerom.
2) "Welcome to this customized error page. You've reached this page because you've clicked on a link that does not exist."
Ok.. odniosłem wrażenie jakbym celowo otworzył tę stronę i to co czytam było początkiem artykułu o kodzie błędu 404. Naprawdę nie wystarczyło krótkie i treściwe "Page does not exist" ?
3) "This is probably our fault..."
Nie miejsce i czas na unoszenie się honorem. Stare porzekadło ludowe mówi: "Klient ma zawsze rację". Komunikat powinen brzmieć: "This is totally our fault! We beg for forgiveness!"
4) "but instead of showing you the basic '404 Error' page that is confusing and doesn't really explain anything, we've created this page to explain what went wrong."
I co? Mam być wdzięczny, że straciłem 10 cennych sekund mojego życia czytając komunikat błędu ?!?!
5) "You can either (a) click on the 'back' button in your browser and try to navigate through our site in a different direction, or (b) click on the following link to go to homepage."
Chociaż mogli a i b pogrubić bo zajęło mi z dobre kilka sekund (a to dużo; odsyłam do badań z usability) żeby się dowiedzieć co mogę zrobić.
Reasumując:
Tworząc komunikaty z błędami kierujmy się zasadą KISS. Zaoszczędzimy użytkownikom dużo cennego czasu, który mogą spędzić, np. stymulując polski rynek browarniczny ;)
Tuesday, March 03, 2009
Scala nabiera prędkości
Widać, że zainteresowanie Scalą rośnie (Hura!). Chyba czas najwyższy poważnie zacząć w nią inwestować (np. ruszyć Dage'a :P).
Książki o Scali które są - lub w najbliższej przyszłości będą - wydane.
Ponieważ już wiele osób mnie pytało jak zacząć przygodę ze Scalą, poniżej zamieszczam kilka przydatnych linków:
Prezentacja o Scali - Konkretna, pragmatyczna, krótka (108 slajdów :P).
Tutorial - szybkie wyprowadzenie do języka. (15 stron)
Przegląd możliwości języka - naprawdę "mind-blowing". Polecam!! (kiedyś 55 stron w PDF - teraz dostępne na stronie)
Scala poprzez przykłady - wprowadzenie do języka. (145 stron)
Specyfikacja języka - tylko jeśli wybrałeś czerwoną pigułkę ;) (180 stron)
Książki o Scali które są - lub w najbliższej przyszłości będą - wydane.
Ponieważ już wiele osób mnie pytało jak zacząć przygodę ze Scalą, poniżej zamieszczam kilka przydatnych linków:
Prezentacja o Scali - Konkretna, pragmatyczna, krótka (108 slajdów :P).
Tutorial - szybkie wyprowadzenie do języka. (15 stron)
Przegląd możliwości języka - naprawdę "mind-blowing". Polecam!! (kiedyś 55 stron w PDF - teraz dostępne na stronie)
Scala poprzez przykłady - wprowadzenie do języka. (145 stron)
Specyfikacja języka - tylko jeśli wybrałeś czerwoną pigułkę ;) (180 stron)
Monday, March 02, 2009
Streszczenie: Investigating architecture and design
Jedną z rad w przeczytanej ostatnio przeze mnie książce "Pragmatic Thinking & Learning: Refactor your wetware" autorstwa Andy'ego Hunta jest prowadzenie wiki. W takiej wiki może znaleźć się wszystko od ciekawych cytatów, poprzez przemyślenia aż do streszczeń książek oraz artykułów (itd. itp.). Streszczanie książek/artykułów, podkreślanie ważnych fragmentów, dopisywanie komentarzy etc. samo w sobie jest polecane przez Hunta jako świetny sposób na lepsze przyswojenie tematu... Nie będę jednak przepisywał porad z książki Andy'ego bo nie o tym miało być :) (choć gorąco zachęcam do jej przeczytania!).
Zamiast tego zamieszczam streszczenie artykułu Neal'a Forda "Investigating architecture and design" przeplatane moimi przemyśleniami.
Notatka powstała przy użyciu pluginu do VIM'a - viki oraz konwertera deplate (dla zainteresowanych wystarczy: sudo gem install deplate).
Źródło:
Evolutionary architecture and emergent design: Investigating architecture and design[1]
1 Introduction
==============
Architecture is being separated into two categories:
* application architecture - coarse-grained pieces that compose an
application - which is further dived into:
+ framework-level architecture - the combination of frameworks,
+ application architecture - logical separation of concerns.
* enterprise architecture - how enterprise as a whole consumes
application.
+++ Metaphor for software architectures
Enterprise architecture => city planning
Application architecture => building architecture
2 Definitions of architecture
=============================
"In most successful software projects, the expert developers working on
that project have a shared understanding of the design system design.
This shared understanding is called 'architecture'. This understanding
includes how the system is divided into components and how the
components interact through interfaces." Ralph Johnson
"Architecture is about the important stuff. Whatever it is." Martin
Fowler
"Stuff that's hard to change later." Neal Ford
3 Important note
================
!!! Architecture -> Evolves !!!
Because it consists of elements that must exist before you start
building an application.
!!! Design -> Emerge !!!
Because it is grown over time.
4 Useful equations
==================
"Flexible architecture" + "Reversible decisions" = "Evolving
architecture"
"Just-in-time dirty hacks" = "Technical debt" = "Rising entropy"
5 Complexity
============
* essential,
!!! Watch out for essential complexity! It might be possible to
!!! lower it by asking customer to consider her/his choices more
!!! carefully. Money argument is the ultimate way of doing that.
* accidental.
Accidential complexity:
1. Just-in-time hacks.
2. Duplication.
3. Irreversibility.
+++ Because genericness adds entropy, you damage your ability to evolve
the design in interesting ways early in the projects.
[1] http://www.ibm.com/developerworks/java/library/j-eaed1/index.html
Zamiast tego zamieszczam streszczenie artykułu Neal'a Forda "Investigating architecture and design" przeplatane moimi przemyśleniami.
Jeśli komuś spośród garstki osób, które odwiedza mojego bloga ;) podoba się pomysł takiego właśnie dzielenia się wiedzą będę od czasu do czasu publikował notki tego typu. W przeciwnym razie, żeby się nie pozbawiać i tak nielicznego grona czytelników :P odpuszczę sobie.
Czekam na feedback!
Notatka powstała przy użyciu pluginu do VIM'a - viki oraz konwertera deplate (dla zainteresowanych wystarczy: sudo gem install deplate).
Źródło:
Evolutionary architecture and emergent design: Investigating architecture and design[1]
1 Introduction
==============
Architecture is being separated into two categories:
* application architecture - coarse-grained pieces that compose an
application - which is further dived into:
+ framework-level architecture - the combination of frameworks,
+ application architecture - logical separation of concerns.
* enterprise architecture - how enterprise as a whole consumes
application.
+++ Metaphor for software architectures
Enterprise architecture => city planning
Application architecture => building architecture
2 Definitions of architecture
=============================
"In most successful software projects, the expert developers working on
that project have a shared understanding of the design system design.
This shared understanding is called 'architecture'. This understanding
includes how the system is divided into components and how the
components interact through interfaces." Ralph Johnson
"Architecture is about the important stuff. Whatever it is." Martin
Fowler
"Stuff that's hard to change later." Neal Ford
3 Important note
================
!!! Architecture -> Evolves !!!
Because it consists of elements that must exist before you start
building an application.
!!! Design -> Emerge !!!
Because it is grown over time.
4 Useful equations
==================
"Flexible architecture" + "Reversible decisions" = "Evolving
architecture"
"Just-in-time dirty hacks" = "Technical debt" = "Rising entropy"
5 Complexity
============
* essential,
!!! Watch out for essential complexity! It might be possible to
!!! lower it by asking customer to consider her/his choices more
!!! carefully. Money argument is the ultimate way of doing that.
* accidental.
Accidential complexity:
1. Just-in-time hacks.
2. Duplication.
3. Irreversibility.
+++ Because genericness adds entropy, you damage your ability to evolve
the design in interesting ways early in the projects.
[1] http://www.ibm.com/developerworks/java/library/j-eaed1/index.html
Tuesday, February 24, 2009
moje książki (for share)
Ponieważ kupowanie książek na Amazon w ostatnim czasie stało się wyjątkowo drogie (albo raczej realistycznie mówiąc ceny powróciły do dawnych standardów) postanowiłem, że być może lepiej zorganizować coś swoim w środowisku. I tak doszedłem do wniosku, że najłatwiej będzie się po prostu powymieniać :D Posiadane przeze mnie książki znaleźć można tutaj.
Monday, February 16, 2009
Java jakiej nie znacie
Dzisiejszy post dedykuję wszystkim, którzy podobnie jak ja myśleli, że choć arkana ClassLoader'a są im obce, znajomośc refleksji jeszcze nie ta i garbage collector wciąż zaskakuje to składnie języka znają od podszewki.
Dalszą część pozostawiam bez komentarza :)
Amazing ain't it ?
Dalszą część pozostawiam bez komentarza :)
interface Quacks {
void quack();
}
interface Walks {
void walk();
}
class Duck implements Quacks, Walks {
public void quack() {
System.out.println("Quack!");
}
public void walk() {
System.out.println("[a sound of a duck walking :P]");
}
}
public class Hunter {
<T extends Quacks & Walks> void shoot(T animal) {
animal.walk();
System.out.println("[a sound of a gunshot]");
animal.quack();
System.out.println("[a sound of a quacking, walking animal dying]");
}
public static void main(String[] args) {
new Hunter().shoot(new Duck());
}
}
Amazing ain't it ?
Thursday, February 05, 2009
Odpowiedź wujka Boba na podcast takich dwóch..
Zachęcam do przeczytania odpowiedzi Roberta C. Martina aka Uncle Boba na podcast Jeffa i Joela o którym pisałem kilka dni temu.
Dla zachęty pozwolę sobie zacytować jeden z komentarzy Pana Eduardo Scoz'y (Scoza?):
Być może ma rację. Może zamiast się denerwować należało tę dyskusję wyśmiać ? :P
Dla zachęty pozwolę sobie zacytować jeden z komentarzy Pana Eduardo Scoz'y (Scoza?):
I was listening to the podcast during my way to work when they started talking about TDD and quality, and I the same WTF?? feeling. Honestly, I started laughing in the bus..
Być może ma rację. Może zamiast się denerwować należało tę dyskusję wyśmiać ? :P
Wednesday, February 04, 2009
jak bezwzględnie wykorzystać i porzucić RFC 2616
RFC 2616 to oczywiście nasze ulubione HTTP/1.1 :)
Siedzę tak sobie w domu i się nudzę (głównie gdyż ponieważ na czwartek przygotować mam wstęp teoretyczny do pracy dyplomowej ;P). I tak z braku zajęć przerabiam skrypt powiadamiający mnie o ogłoszeniu wyników z egzaminu... a że jakiś czas temu zakończyłem czytanie w/w specyfikacji doszło do mnie, że w sumie warto wreszcie chociaż w minimalnym stopniu spróbować tę wiedzę wykorzystać!
Tak powstał poniższy skrypcik:
Enjoy ! :)
P.S. Skrypt zadziałał - AK2 zaliczone na 4.0 :)
Siedzę tak sobie w domu i się nudzę (głównie gdyż ponieważ na czwartek przygotować mam wstęp teoretyczny do pracy dyplomowej ;P). I tak z braku zajęć przerabiam skrypt powiadamiający mnie o ogłoszeniu wyników z egzaminu... a że jakiś czas temu zakończyłem czytanie w/w specyfikacji doszło do mnie, że w sumie warto wreszcie chociaż w minimalnym stopniu spróbować tę wiedzę wykorzystać!
Tak powstał poniższy skrypcik:
#!/bin/zsh
function get {
curl -Iis -H"If-None-Match: `cat $ETAG_FILE`" \
http://sun10.ci.pwr.wroc.pl/~kwiatkow/archdwa/mat_archdwa.html
};
function put_etag {
echo "$RESPONSE" | grep ETag | cut -f2 -d' ' > /var/tmp/exam1-ak2.etag
}
ETAG_FILE=/var/tmp/exam1-ak2.etag
RESPONSE=`get`
if [ ! -e $ETAG_FILE ]; then
`put_etag`
exit
fi
if [ `echo "$RESPONSE" | head -n1 | cut -f2 -d' '` != "304" ]; then
`put_etag`
sms -g plus -n XXXYYYZZZ -m "Zmiana na stronie dr Kwiatkowskiego ! \
Czyzby wyniki z egzaminu ?"
fi
Enjoy ! :)
P.S. Skrypt zadziałał - AK2 zaliczone na 4.0 :)
Sunday, February 01, 2009
Joel i Jeff - czyli o dwóch takich co gadają niemądrze..
Dzisiaj nadziałem się (a przynajmniej uczucie po przeczytaniu było takie jakbym się nadział) na zapis z podcastu rozmowy Joela Spolsky'ego i Jeffa Atwooda. Ponieważ przedstawione opinie mocno mi napsuły krwi prezentuje je poniżej, coby się trochę wyzewnętrznić :].
Ok.. Zgadzam się z powyższym - ale jeśli ktoś ma choć trochę oleju w głowie, zawsze - ale to zawsze - zgodzi się z jakąkolwiek krytyką skrajności. Skrajność jest zła !! ZŁAAAA! "Being extreme is evil and wrong. EOF" - to idealna odpowiedź, dyskusja z głupotą ją nobilituje..
Ok.. to ma sens.. zdarzają się zmiany które puszczą z dymem 10% testów jednostkowych. Pomijając fakt, że przy poprawnie napisanych unit testach najpewniej będzie to zmiana archiektury, istotnej dla projektu technologii albo jakaś hiper-istotna zmiana biznesowa - zdarza się.
MENU !?! ok.. wtf ? jakie menu ?! testy jednostkowe i menu ? .. no sorry, ale po gościu który jest autorytetem w IT spodziewam się conajmniej zrozumienia róznicy między testami jednostkowymi, a innymi - te też mylę nigdy nie wiem czy testy UI to integracyjne, akceptacyjne czy jakie tam, ale _na pewno_ nie jednostkowe!
Zgadzam się.
Ok.. gdyby te testy tam były "in the first place" to byśmy mogli zmienić i mieli spokój. Co więcej napisanie testów do istniejącego kodu - którego nie znasz - jest na moje oko przynajmniej rząd trudniejsze. Oczywiście po raz kolejny ważny jest zdrowy rozsądek, bo trzeba mieć wyczucie kiedy testy pisać bardziej, ile tych testów, umieć wyczuć kiedy implementacja się stabilizuje itp., itd. miałem nie pisać o rzeczach oczywistych - ale jak widać Jeff Atwood albo sobie żartuje albo ich nie rozumie.
Ok. To idealnie pokazuje ile wspólnego ma Joel z oprogramowaniem biznesowym :P Kompilator ..
W językach obiektowych mamy metody i to je testujemy. Dla mnie to niesamowicie duża różnica konceptualna bo metody służą do komunikacji między obiektami podczas gdy funkcje obliczają wynik.
Dla mnie osobiście to podejście Uncle Bob'a brzmi akurat niesamowicie rozsądnie ...
Pozwolę sobie skontrować słowami znanego autorytetu w dziedzinie IT: "People that say things like this have just never written a heck of a lot of code. ".
Ok.. tu zaczynają mnie ponosić emocje i chciałoby się podsumować "Blablablabla". Powiem jedno.. jeśli Joel nie rozumie projektowanie zorientowanego obiektowo to ja straciłem nadzieję w ludzi - albo po prostu on jest dobrze ukrywającym się w przebraniu programisty bardzo dobrym biznesmenem. A już byłem pełen optymizmu gdy na ostatniej konferencji JAOO usłyszałem słowa: "Ludzie [programiści, projektanci, architekci, etc.] zaczynają wreszcie po 30 latach rozumieć o co chodzi w programowaniu obiektowym".
M$ SUUUX !!! :P Przepraszam za brak profesjonalizmu ;) Nie mogłem sobie darować :D
W przypadku oprogramowania biznesowego: "Your code's going to be SEEN millions and millions of times."
Amm .. ok.. dobra bo nie kumam - co jest dziwnego w osobnym trzymaniu Employee i Salary.. czyli mam naćpać wszystkie algorytmy obliczania ZUS'ów, progów podatkowych, urlopów do klasy Employee ? Zresztą, w każdym sensownym systemie kadrowym byłoby jak najbardziej wskazane te dwie klasy wyróżnić. No chyba że to portal WEB 2.0 w którym zarobki to zwykły prymitywny float... ale to skrajny przykład (patrz wyżej na temat skrajności).
Nie wspomnę już o tym, że Joel (albo ja) absolutnie nie zrozumiał na czym polega Single Responsibility Principle. Podczas gdy on mówi o zmianie stanu obiektu Uncle Bob wyraźnie pisze o zmianie klasy !! Obiekt a klasa .. no proszę, mnie na 2 roku uczyli je rozróżniać.
Racja, ah Ci głupi zwolennicy OO. Assembler ROX !
.. jak problem roku 2000.
.. really do make people rich. (vide programiści systemów bankowych w roku 1999 :P).
.. jak problem roku 2000. khy khy
A w restauracji Twoim jedynym obowiązkiem jest obsługiwać klientów. Naczynia się posprzątają same.
Kwestia balansu oczywiście... ale do tego trzeba hmmm.. myśleć ?
.. and saying - vide ta dyskusja Joela z Jeffem.
Reszta rozmowy dostępna jest na blogu Joela bo ja naprawdę nie mam siły... Przyznaję, że kilka razy zastosowałem trochę nieczyste chwyty (np. z przykładem problemu roku 2000), ale ogólnie opinie Joela i Jeffa mocno mnie zdenerwowały. Nie spodziewałem się że inteligentni i świadomi (jak sądziłem) programiści będą pier.. wygadywać takie głup.. niemądre rzeczy.
Pozostawiam tę ichnią rozmowę do Waszej rozwagi.
P.S. Jeśli Joel z Jeffem po prostu "robili sobie jaja" (co jest bardzo prawdopodobne) proszę mnie powiadomić abym mógł zdjąć tego posta lub odpowiednio go zkorygować. :P
Joel: But, I feel like if a team really did have 100% code coverage of their unit tests, there'd be a couple of problems. One, they would have spent an awful lot of time writing unit tests, and they wouldn't necessarily be able to pay for that time in improved quality. I mean, they'd have some improved quality, and they'd have the ability to change things in their code with the confidence that they don't break anything, but that's it.
Ok.. Zgadzam się z powyższym - ale jeśli ktoś ma choć trochę oleju w głowie, zawsze - ale to zawsze - zgodzi się z jakąkolwiek krytyką skrajności. Skrajność jest zła !! ZŁAAAA! "Being extreme is evil and wrong. EOF" - to idealna odpowiedź, dyskusja z głupotą ją nobilituje..
But the real problem with unit tests as I've discovered is that the type of changes that you tend to make as code evolves tend to break a constant percentage of your unit tests. Sometimes you will make a change to your code that, somehow, breaks 10% of your unit tests. Intentionally. Because you've changed the design of something...
Ok.. to ma sens.. zdarzają się zmiany które puszczą z dymem 10% testów jednostkowych. Pomijając fakt, że przy poprawnie napisanych unit testach najpewniej będzie to zmiana archiektury, istotnej dla projektu technologii albo jakaś hiper-istotna zmiana biznesowa - zdarza się.
you've moved a menu, and now everything that relied on that menu being there... the menu is now elsewhere. And so all those tests now break. And you have to be able to go in and recreate those tests to reflect the new reality of the code.
MENU !?! ok.. wtf ? jakie menu ?! testy jednostkowe i menu ? .. no sorry, ale po gościu który jest autorytetem w IT spodziewam się conajmniej zrozumienia róznicy między testami jednostkowymi, a innymi - te też mylę nigdy nie wiem czy testy UI to integracyjne, akceptacyjne czy jakie tam, ale _na pewno_ nie jednostkowe!
So the end result is that, as your project gets bigger and bigger, if you really have a lot of unit tests, the amount of investment you'll have to make in maintaining those unit tests, keeping them up-to-date and keeping them passing, starts to become disproportional to the amount of benefit that you get out of them.
Zgadzam się.
Jeff:
I think that's a great point. Although, I do think if you're working on older code bases that don't have a lot of churn, ...
Joel:
Yeah.
Jeff:
To me it's about churn. If you're working on an old code base that isn't going to have that much churn, and you want to change it where you can't break anything, where if you break anything it's really really bad, then it's probably worth your time to go in and develop a bunch of unit tests. You're building scaffolding around this grand old building, this classic old building that's not going to change for another 200 years, so sure, build a bunch of scaffolding around the building.
Ok.. gdyby te testy tam były "in the first place" to byśmy mogli zmienić i mieli spokój. Co więcej napisanie testów do istniejącego kodu - którego nie znasz - jest na moje oko przynajmniej rząd trudniejsze. Oczywiście po raz kolejny ważny jest zdrowy rozsądek, bo trzeba mieć wyczucie kiedy testy pisać bardziej, ile tych testów, umieć wyczuć kiedy implementacja się stabilizuje itp., itd. miałem nie pisać o rzeczach oczywistych - ale jak widać Jeff Atwood albo sobie żartuje albo ich nie rozumie.
Joel:
Yeah. They work really for things like a compiler, where the design is not going to change because the language is fixed.
Ok. To idealnie pokazuje ile wspólnego ma Joel z oprogramowaniem biznesowym :P Kompilator ..
Jeff:
That's right.
Joel:
I might do more black-box tests, sort of like unit tests but more from the perspective of "does this compile all code correctly," with enormous numbers of tests, than just the internal, "does this particular function work in this particular way at all times."
W językach obiektowych mamy metody i to je testujemy. Dla mnie to niesamowicie duża różnica konceptualna bo metody służą do komunikacji między obiektami podczas gdy funkcje obliczają wynik.
Last week I was listening to a podcast on Hanselminutes, with Robert Martin talking about the SOLID principles. (That's a real easy-to-Google term!) It's object-oriented design, and they're calling it agile design, which it really, really isn't. It's principles for how to design your classes, and how they should work. And, when I was listening to them, they all sounded to me like extremely bureaucratic programming that came from the mind of somebody that has not written a lot of code, frankly.
And here I am ranting against somebody that doesn't have a chance to respond. But just to give you one example, a part of the SOLID principles was that if you write a class, that class has contracts with all the other classes that it interacts with, and those contracts should be expressed in interfaces [PDF]. So you shouldn't just interact with the class, because that class may change. If you have a particular class that you need to use, you should make a custom interface just for what you're going to use in that class. That interface, then, never has to change. And the interface is the only thing that you have to #include.
Does that make sense? So, you've got some class, with 40 different little methods on it, and I'm only going to use six of them, so I should make an interface with those six things that I can use, and the class will implement that interface, and that's my contract with the class, that those are the only six things I'm going to use.
Dla mnie osobiście to podejście Uncle Bob'a brzmi akurat niesamowicie rozsądnie ...
People that say things like this have just never written a heck of a lot of code.
Pozwolę sobie skontrować słowami znanego autorytetu w dziedzinie IT: "People that say things like this have just never written a heck of a lot of code. ".
Because what they're doing is spending an enormous amount of time writing a lot of extra code, a lot of verbiage, a lot of files, and a million little classes that don't do anything and thousands of little interface classes and a lot of robustness to make each of these classes individually armed to go out into the world alone and do things, and you're not going to need it. You're spending a lot of time in advance writing code that is just not going to be relevant, it's not going to be important. It could, theoretically, protect you against things, but, how about waiting until those things happen before you protect yourself against them?
This seems to be where a lot of the Object Oriented Design community went, and if anybody has any strong feelings about this, call in and tell me what you think--tell me if I'm totally off track here--but it seems to me like a lot of the Object Oriented Design principles you're hearing lately from people like Robert Martin and Kent Beck and so forth have gone off the deep end into architecture for architecture's sake. It doesn't seem like you could actually get any code written if you're spending all your time writing 8,000,000 unit tests, and every single dinky little class that you need to split a URL into four parts becomes an engineering project worthy of making a bridge, where you spend six months defining 1000 little interfaces. They've just gone off the deep end, and I don't think these people write very much code if they're coming up with these principles, to be honest, it doesn't even make sense.
Ok.. tu zaczynają mnie ponosić emocje i chciałoby się podsumować "Blablablabla". Powiem jedno.. jeśli Joel nie rozumie projektowanie zorientowanego obiektowo to ja straciłem nadzieję w ludzi - albo po prostu on jest dobrze ukrywającym się w przebraniu programisty bardzo dobrym biznesmenem. A już byłem pełen optymizmu gdy na ostatniej konferencji JAOO usłyszałem słowa: "Ludzie [programiści, projektanci, architekci, etc.] zaczynają wreszcie po 30 latach rozumieć o co chodzi w programowaniu obiektowym".
Jeff:
Well, there are places where that level of testing makes sense. If you're working at Microsoft and you're working on the .NET Framework...
M$ SUUUX !!! :P Przepraszam za brak profesjonalizmu ;) Nie mogłem sobie darować :D
Joel:
Yeah.
Jeff:
... you have a totally different set of obligations to your public ...
Joel:
Correct.
Jeff:
... Your code's going to be used millions and millions of times.
W przypadku oprogramowania biznesowego: "Your code's going to be SEEN millions and millions of times."
Joel:
Yeah. In fact, if you're making any kind of API, a plug in API, it is very important to separate things into interfaces and be very very contractual, and tightly engineered. Just like you want to put a lot of effort into your user interface, you also want to put a lot of effort into your API that people are calling... it's just an interface, and you want it to be good and solid and robust. And that's fine.
But this idea that every single class in your code, all these classes interacting with each other, should be so tightly defined ...
Listening to this interview on Hanselminutes, there seemed to be an intense obsession with creating lots and lots of little classes that all did one particular thing...
One of the SOLID principles, and I'm totally butchering this, but, one of the principles was that you shouldn't have two things in the same class that would be changed for a different reason [PDF]. Like, you don't want to have an Employee class, because it's got his name which might get changed if he gets married, and it has his salary, which might get changed if he gets a raise. Those have to be two separate classes, because they get changed under different circumstances.
Amm .. ok.. dobra bo nie kumam - co jest dziwnego w osobnym trzymaniu Employee i Salary.. czyli mam naćpać wszystkie algorytmy obliczania ZUS'ów, progów podatkowych, urlopów do klasy Employee ? Zresztą, w każdym sensownym systemie kadrowym byłoby jak najbardziej wskazane te dwie klasy wyróżnić. No chyba że to portal WEB 2.0 w którym zarobki to zwykły prymitywny float... ale to skrajny przykład (patrz wyżej na temat skrajności).
Nie wspomnę już o tym, że Joel (albo ja) absolutnie nie zrozumiał na czym polega Single Responsibility Principle. Podczas gdy on mówi o zmianie stanu obiektu Uncle Bob wyraźnie pisze o zmianie klasy !! Obiekt a klasa .. no proszę, mnie na 2 roku uczyli je rozróżniać.
And you wind up with millions of tiny little classes, like the EmployeeSalary class, and it's just... (laughs) idiotic! You can't build software that way!
Racja, ah Ci głupi zwolennicy OO. Assembler ROX !
The way real software works is that you create these very imperfect things, and they work great.
.. jak problem roku 2000.
They really do.
.. really do make people rich. (vide programiści systemów bankowych w roku 1999 :P).
And then you have a little problem, and you go and you fix the little problem, because it's code, and you have an editor, and you edit it.
.. jak problem roku 2000. khy khy
These classes are not going to go wander off flying in the universe all by themselves and need to work perfectly and unchanged until the end of time.
Jeff:
Right. The longer I think about this, the less I care about code hygiene issues (laughs). Because the unit of measure that really matters to me is, how quickly you can respond to real business needs with your code. And by that I mean, how well are you serving the people that are using your code.
A w restauracji Twoim jedynym obowiązkiem jest obsługiwać klientów. Naczynia się posprzątają same.
To me that's what it's all about. Anything that gets in the way of you fixing your code or improving your code in a way that your customers can appreciate, is a negative. If that means using Ruby, or having lots of unit tests: whatever's working for you: do that. But if it's getting in the way, if it becomes friction, like, "I'd love to have this great new feature but I'd have to have 1000 unit tests," that's a negative.
Kwestia balansu oczywiście... ale do tego trzeba hmmm.. myśleć ?
Joel:
Yeah. And the worst thing that happens is that you get people that just stop thinking about what they're doing.
.. and saying - vide ta dyskusja Joela z Jeffem.
Reszta rozmowy dostępna jest na blogu Joela bo ja naprawdę nie mam siły... Przyznaję, że kilka razy zastosowałem trochę nieczyste chwyty (np. z przykładem problemu roku 2000), ale ogólnie opinie Joela i Jeffa mocno mnie zdenerwowały. Nie spodziewałem się że inteligentni i świadomi (jak sądziłem) programiści będą pier.. wygadywać takie głup.. niemądre rzeczy.
Pozostawiam tę ichnią rozmowę do Waszej rozwagi.
P.S. Jeśli Joel z Jeffem po prostu "robili sobie jaja" (co jest bardzo prawdopodobne) proszę mnie powiadomić abym mógł zdjąć tego posta lub odpowiednio go zkorygować. :P
Co z tą Javą
Od pewnego czasu popularne stały się posty w których autorzy próbują spekulować na temat: "Czy język XXX zastąpi Javę?". Oczywiście założeniem implicite jest, że Java potrzebuje i będzie przez coś zastąpiona. Osobiście jestem zwolennikiem teorii, iż Java powinna się powoli kończyć. Nie wiem czy i kiedy się to stanie. Mimo że my - programiści, jesteśmy w pewnym stopniu odpowiedzialni za tę decyzję należy ona w dużej mierze do naszych szefów ;).
Biorąc pod uwagę fakt, że ogólnie jestem zwolennikiem koncepcji polyglot programming - wierzę, że językiem przyszłości dla JVM w warstwie "stabilnej" jest Scala. Ponieważ jednak wciąż przoduje wiara w teorię "jeden jęzka do wszystkich zastosowań" coraz częsciej zdarza mi się czytać posty porównujące Scalę z Ruby. Według mnie świadczy to bardzo dobrze o samej Scali i tym bardziej przekonuje mnie, żę powinna ona zastąpić Javę. Sądzę, że takie porównanie wynika z niesamowitej elastyczności i ekspresywności języka - mimo tego, że Scala jest typowana statycznie (burzy mit, że "static typing" == Java). Pozwala to na rozmycie się argumentów w odwiecznym sporze zwolennków języków statycznych i dynamicznych. Java w tym świetle jest językiem "zeszłego Millenium" - do bólu imperatywnym, nadmiarowym (verbose) i ordynarnym (crude) - i nic nie zapowiada że się to szybko zmieni.
Ostatnio odbyłem krótka dyskusję ze znajomym właśnie na temat "Co dalej?", w której staraliśmy się rozstrzygnąć czy należy zainwestować w Scalę, Ruby'ego (i Railsy) czy też pozostać przy Javie. Na dziś dzień moja decyzja to polyglot programming w oparciu o:
- Scala (warstwa "stabilna"),
- Grails (Groovy) albo Lift (Scala) albo Rails (Ruby) (warstwa "dynamiczna" - prezentacji),
- JVM (istniejące technologie i frameworki).
W oparciu o powyższe: TAK - dla Scali, NIE - dla Javy, MOŻE - dla reszty.
Biorąc pod uwagę fakt, że ogólnie jestem zwolennikiem koncepcji polyglot programming - wierzę, że językiem przyszłości dla JVM w warstwie "stabilnej" jest Scala. Ponieważ jednak wciąż przoduje wiara w teorię "jeden jęzka do wszystkich zastosowań" coraz częsciej zdarza mi się czytać posty porównujące Scalę z Ruby. Według mnie świadczy to bardzo dobrze o samej Scali i tym bardziej przekonuje mnie, żę powinna ona zastąpić Javę. Sądzę, że takie porównanie wynika z niesamowitej elastyczności i ekspresywności języka - mimo tego, że Scala jest typowana statycznie (burzy mit, że "static typing" == Java). Pozwala to na rozmycie się argumentów w odwiecznym sporze zwolennków języków statycznych i dynamicznych. Java w tym świetle jest językiem "zeszłego Millenium" - do bólu imperatywnym, nadmiarowym (verbose) i ordynarnym (crude) - i nic nie zapowiada że się to szybko zmieni.
Ostatnio odbyłem krótka dyskusję ze znajomym właśnie na temat "Co dalej?", w której staraliśmy się rozstrzygnąć czy należy zainwestować w Scalę, Ruby'ego (i Railsy) czy też pozostać przy Javie. Na dziś dzień moja decyzja to polyglot programming w oparciu o:
- Scala (warstwa "stabilna"),
- Grails (Groovy) albo Lift (Scala) albo Rails (Ruby) (warstwa "dynamiczna" - prezentacji),
- JVM (istniejące technologie i frameworki).
W oparciu o powyższe: TAK - dla Scali, NIE - dla Javy, MOŻE - dla reszty.
Wednesday, January 21, 2009
blogowania ciąg dalszy - hibernate tips&tricks
Od daaaawna nie było żadnego posta (od lipca zeszłego roku ;]). Nie będę się na ten temat zbytnio rozpisywał bo tematem bloga w końcu nie jest "Dlaczego regularnie zarzucam blogowanie?", a przyczyna jest prozaiczna - brak czasu. Ponieważ jednak różne przemyślenia w głowie już mi się kotłują, a ciekawych linków na sieci coraz więcej postanowiłem, że od dziś będę starał się wrzucać posty regularniejsze a krótsze (dosłownie 2 zdania jeśli nie będę miał czasu na więcej). Ponieważ szcerze mowiąc sciągnąłem ten pomysł z bloga Stefana Tilkova nie mam zamiaru się go wstydzić :)
Do rzeczy - czyli Hibernate tips and tricks:
1) Strategie nazewnictwa "bytów" w bazie danych
Jeśli w projekcie każde pole (tudzież setter) opakowane jest kupą adnotacji z tym jak nazywać poszczególne elementy w bazie danych (skądinąd przygotowane takiego standardu w zakresie projektu to bardzo dobry pomysł) być może przyszedł czas zcentraliować te informację. Hibernate przychodzi nam z pomocą i dostarcza możliwość określenia strategii jak poszczególne elementy po-naszemu nazywać :)
Tip: Warto dodać strategię nie tylko do aplikacji ale (i to zwłaszcza) do ant'owego taska generującego schemat :)
2) Filtrowanie kolekcji po stronie bazy danych
Nie raz zdarzyło mi się znaleźć kawałki kodu przepuszczające kolekcje przez jakąś logikę (mniej lub bardziej biznesową) które albo:
- zamiast wykorzystać istniejącą asocjację kolekcji po prostu zbierały te informację z bazy danych, dodając do zapytania warunek 'WHERE'.
albo
- zbierały z bazy całą kolekcję (na ogół przez lazy fetch, czyli po prostu wywołanie gettera) po czym sobie po niej radośnie iterowały szukając odpowiednich danych.
Tymczasem Hibernate pozwala na przefiltrowanie kolekcji (oraz tablic) do których dostęp mamy po stronie Javy za pomocą mechanizmu filtrów. Już nie musimy wybierać między szybkością (HQL i baza danych) oraz czytelnością (zrobić to po stronie Javy).
3) Nazywanie kolumny a nazwy zabronione
Jeśli tylko korzystasz z PostgreSQL pewno nie raz już ucieszył Cię error "wszystko wybucha wywołaj getNextException() żeby odkryć gdzie" (skądinąd takie połykanie Exceptionów przyprawia mnie o lekki ból głowy) tylko po to by dowiedzieć się że Twoja klasa User (chyba User.. o ile pamiętam że właśnie ten wybuch zaliczyłem na PostgreSQL :]) niestety tak się nazywać nie może :) Jeśli nie chcesz użyć nazw typu: Ape, Non_Geek dla swoich klientów polecam zapoznanie się z lekturą.
Do rzeczy - czyli Hibernate tips and tricks:
1) Strategie nazewnictwa "bytów" w bazie danych
Jeśli w projekcie każde pole (tudzież setter) opakowane jest kupą adnotacji z tym jak nazywać poszczególne elementy w bazie danych (skądinąd przygotowane takiego standardu w zakresie projektu to bardzo dobry pomysł) być może przyszedł czas zcentraliować te informację. Hibernate przychodzi nam z pomocą i dostarcza możliwość określenia strategii jak poszczególne elementy po-naszemu nazywać :)
Tip: Warto dodać strategię nie tylko do aplikacji ale (i to zwłaszcza) do ant'owego taska generującego schemat :)
2) Filtrowanie kolekcji po stronie bazy danych
Nie raz zdarzyło mi się znaleźć kawałki kodu przepuszczające kolekcje przez jakąś logikę (mniej lub bardziej biznesową) które albo:
- zamiast wykorzystać istniejącą asocjację kolekcji po prostu zbierały te informację z bazy danych, dodając do zapytania warunek 'WHERE'.
albo
- zbierały z bazy całą kolekcję (na ogół przez lazy fetch, czyli po prostu wywołanie gettera) po czym sobie po niej radośnie iterowały szukając odpowiednich danych.
Tymczasem Hibernate pozwala na przefiltrowanie kolekcji (oraz tablic) do których dostęp mamy po stronie Javy za pomocą mechanizmu filtrów. Już nie musimy wybierać między szybkością (HQL i baza danych) oraz czytelnością (zrobić to po stronie Javy).
3) Nazywanie kolumny a nazwy zabronione
Jeśli tylko korzystasz z PostgreSQL pewno nie raz już ucieszył Cię error "wszystko wybucha wywołaj getNextException() żeby odkryć gdzie" (skądinąd takie połykanie Exceptionów przyprawia mnie o lekki ból głowy) tylko po to by dowiedzieć się że Twoja klasa User (chyba User.. o ile pamiętam że właśnie ten wybuch zaliczyłem na PostgreSQL :]) niestety tak się nazywać nie może :) Jeśli nie chcesz użyć nazw typu: Ape, Non_Geek dla swoich klientów polecam zapoznanie się z lekturą.
Subscribe to:
Posts (Atom)