Right question in scala world

When I started some real small project using scala. I read some rows of data from database and as usual wanted to

save it in some list. So first question appears in my mind

How to add some element to list ?

def testPersons(): List[Person] = {

    val conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:orcl")

    var persons = new List[Person]()

    try {

     val statement = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY)

     val rs = statement.executeQuery("SELECT * FROM Person where user_name like '%test%'")

     while (rs.next) {

       personsBuf.add(new Person(rs.getString("user_name"), rs.getString("first_name"), rs.getString("last_name")))

     }

    } finally {

     conn.close

    }

    persons

 }

 but after some investigation I realized the question is completely wrong.

 Philosophy of scala differ from philosophy of java. and first of all you must think immutably.

 You create list in variety of ways

 val fruit = List("apples", "oranges", "pears")

val nums = List(1, 2, 3, 4)

val diag3 = List(List(1, 0, 0), List(0, 1, 0), List(0, 0, 1))

val empty = List()

val fruit = "apples" :: ("oranges" :: ("pears" :: Nil))

val nums = 1 :: (2 :: (3 :: (4 :: Nil)))

val diag3 = (1 :: (0 :: (0 :: Nil))) ::

(0 :: (1 :: (0 :: Nil))) ::

(0 :: (0 :: (1 :: Nil))) :: Nil

val empty = Nil

but you after creating you can not change it because it is immutable. You can only create new one. It is like string in java.

the right way of my function is :

def testPersons(): List[Person2] = {

    val conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:orcl")

    var personsBuf = new scala.collection.mutable.ListBuffer[Person2]()

    try {

     val statement = conn.createStatement(ResultSet.TYPE_FORWARD_ONLY, ResultSet.CONCUR_READ_ONLY)

     val rs = statement.executeQuery("SELECT * FROM Person where user_name like '%test%'")

     while (rs.next) {

       personsBuf += new Person2(rs.getString("user_name"), rs.getString("first_name"), rs.getString("last_name"))

     }

    } finally {

     conn.close

    }

    personsBuf.toList

 }

I really need to use ListBuffer like mutable list inside function and than return immutable list to outside world.

And you can relay to this list on any place of you program, no one can change it or corrupt it. It is immutable.

It is scala world.  

There are things
I have done
There's a place
I have gone
There's a beast
And I let it run
Now it's running . . .
My way

There are things
I regret
To can't forgive
You can't forget
There's a gift
That you sent
You sent it . . .
My way

(Chorus)
So take this night
Wrap it around me like a sheet
I know I'm not forgiven
But I need a place to sleep
So take this night
And lay me down on the street
I know I'm not forgiven
But I hope that I'll be given . . .
Some peace

There's a game
That I play
There are rules
I had to break
There's mistakes
That I made
But I made them . . .
My way

(chorus)
So take this night
Wrap it around me like a sheet
I know I'm not forgiven
But I need a place to sleep
So take this night
And lay me down on the street
I know I'm not forgiven
But I hope that I'll be given . . .
Some peace . . .
Some peace . . .
Some peace

http://www.youtube.com/watch?v=8cucFfpsqf8

The Tao Te Ching (2)

When people see some things as beautiful,
other things become ugly.
When people see some things as good,
other things become bad.

Being and non-being create each other.
Difficult and easy support each other.
Long and short define each other.
High and low depend on each other.
Before and after follow each other.

Therefore the Master
acts without doing anything
and teaches without saying anything.
Things arise and she lets them come;
things disappear and she lets them go.
She has but doesn't possess,
acts but doesn't expect.
When her work is done, she forgets it.
That is why it lasts forever.

The longer I live, the more I realize the impact of attitude on life.

Attitude, to me, is more important than facts. It is more important than the past, than education, than money, than circumstances, than failures, than successes, than what other people think or say or do. It is more important than appearance, giftedness or skill. It will make or break a company... a church... a home.

The remarkable thing is we have a choice every day regarding the attitude we will embrace for that day. We cannot change our past... we cannot change the fact that people will act in a certain way. We cannot change the inevitable. The only thing we can do is play on the one string we have, and that is our attitude... I am convinced that life is 10% what happens to me and 90% how I react to it.

And so it is with you... we are in charge of our attitudes.

by: Charles Swindoll

The ability to prediction

Lets talk about ability to predict some situation. In my opinion it is very impotent feature of experienced programmer. I want to describe real world episode from my life.

I got the task to implement the monitoring system. This system must to monitor some resources like database tables, web services, web pages and etc. But I got task only for database tables and it was impossible to predict future resources. But from my experience I got feeling that it will be some growing. And despite of pressure from my manager I was implementing system taking in mind future growing of requirements and therefore system. So I implement system using principle “Program from Interface”. And afterword It helped us to reduce amount of code and therefore time for implementation. So following three subsystems like web services, web pages and flash I implemented using Interfaces from first system.

Summarize.
Try to predict future growing of system. Program from interface not from implementation.

Wild Cards and Generics in Java. Collections vs Arrays.

Once my coworker just asked me what for generics and wild cards in java. And I didn’t answer at once. And I need to investigate and find simple way to explain what for wild cards in java.
Collections are very useful instrument for store and work with data. In previous versions of java collections can replace arrays only partly. But started from version java 5 we can completely replace arrays. Because we can use autoboxing, so it does not matters you put primitives or objects in collections. But we still have some restriction, for example when you declare method for some collections

use(List < Item >)

but you want and can and must use this method not only for List < Item > but also collections with children of Item. Signatures for methods should be as general as possible to maximize utility. If one can replace a type parameter by a wildcard then one should do so.

So you can do it with wild cards.

use(List < ? extend Item >)

For example ItemA extends Item
so we can call method use(List < ItemA >)but we still have some restriction even here. We can only use collection but we can’t change it.
If you want to change collection you need to use another wild card

use(List < ? super Item >)

You may find it helpful to think of ? extends T as containing every type in interval bounded by null
below and T above (where null is a subtype of every reference type). Similarly, you may think of
? super T as a containing every type in an interval bounded by T below and Object above.

Another one topic is arrays. Arrays are covariant, meaning that type S[] is considered to be a subtype of T[] whenever S is a subtype of T.

Integer[] ints = new Integer[] {1,2,3};
Number[] nums = ints;
nums[2] = 3.14; // array store exception
assert Arrays.toString(ints).equals("[1, 2, 3.14]"); // uh oh!

In this fragment we got runtime exception.
but if we will use wild cards

List < Integer > ints = Arrays.asList(1,2,3);
List < ? extends Number > nums = ints;
nums.put(2, 3.14); // compile-time error
assert ints.toString().equals("[1, 2, 3.14]"); // uh oh!

We got compile time error, and it is more better because we will get to know about error earlier and errors is detected by the compiler.

Apart from the fact that errors are caught earlier, there are many reasons to use collections instead of arrays. Collections are far more flexible than arrays.

I can suggest only one case when array can be more efficient then collection. Arrays of primitives when you avoid boxing can be more efficient but only because compiler. I believe future compilers may optimize collection classes specially.

To summarize, I suggest to use collections rather then arrays expect case of backward compatibility. I believe covariant arrays are an artifact of the lack of generics in earlier versions of Java.

Боязнь потерять тёплое место
Сытую жизнь, перспективную работу
Молиться Богу и просить богатства
Всё это вызывает только рвоту

Тот, у кого есть мозги и руки
Никогда не пропадёт от голода и скуки
Никогда не станет рабом чужой воли
Ведь это страшнее голода и боли
Он не станет рабом судьбы
Вещей, системы — ничего не надо…

(с) Lumen — «Далеко»