Sun in Red

One week after the approval from EU commission ...

Java is colored in Red ... The Oracle Red!

And it came as a great surprise to me today...

And you can see Oracle everywhere...

And I believe that Java would be more successful with Oracle...

My best wishes for Oracle...

چرا من دیگر از اپل خرید نخواهم کرد

پس از یک انتظار طولانی، سرانجام کمپانی اپل وسیله قابل حمل جدید خود به نام آیپد را معرفی کرد و بیش از پیش من را ناامید ساخت.

آخرین وسیله اپل من یک iPod Touch بود و کاملا از آن راضی بودم و حس می کردم هر چیزی که اپل تولید کند بهترین است. اما ماجرای زیر نظر مرا نسبت به اپل عوض کرد. نزدیک سه ماه است که در خانه دیگر از لینوکس استفاده نمی کنم. در شرکت نیز قصد دارم اوبونتو را پاک کنم و ویندوز 7 یا OpenSuse را به عنوان سیستم عامل محیط کار امتحان کنم. با اینکه هیچ گاه کاربر اپل در دسکتاپ نبوده ام اما همیشه این حس را داشتم که OS X سیستم عامل برتر است تا اینکه تصمیم گرفتم یک MacBook Pro بخرم!

پس از جستجو دریافتم که مدل های جدید اپل همگی با مانیتورهای براق (glossy) عرضه می شوند! و خوب من فکر می کنم مدل های براق به هیچ وجه برای کار حرفه ای مناسب نیستند. کار کردن با این مانیتورها در یک محیط پر نور بسیار سخت است و برتری این مانیتورها در فراهم کردن رنگ های زنده تر، برای من که اکثرا مشغول کار با متن هستم بی فایده است.

پس از آن با توجه به اینکه مدتی خواستار خرید یک صفحه نمایش بزرگ بودم، تصمیم گرفتم که یک مانیتور 23 اینچ سامسونگ و یک دستگاه مک مینی بخرم! قیمت این دستگاه حدود 900 هزار تومان است که با توجه به قابلیت های آن اصلا نمی ارزد. پس از مدتی پرس و جو به این نتیجه رسیدم که خوب بهتر است که یک iMac بخرم ولی باز متوجه شدم که iMac ها نیز فقط با مانیتورهای براق عرضه می شوند! در همین روز ها بود که Tablet جدید اپل عرضه شد و اپل کلکسیون محصولات خود که با ذایقه من سازگار نیستند را کامل کرد.

با اطمینان می توانم بگویم که تنها کار خوبی که این وسیله می تواند انجام دهد خواندن صفحات وب و کتاب های دیجیتال است. ویژگی های صوتی و تصویری آن نیز باید فوق العاده باشد. با وجود این همه سر و صدا این وسیله هیچ چیزی جز یک iPhone با صفحه بزرگتر نیست و من ترجیح می دهم پول خرید آن را نگه دارم تا سال آینده یک لپتاپ سریع تر و سبکتر بگیرم. حتی iPad امکان Multitasking هم ندارد.

چون یک Ebook Reader سونی دارم (بدترین خرید عمرم) حس می کنم اپل با عرضه iPad مسیر درستی را در زمینه کتاب خوانهای دیجیتال طی می کند. تکنولوژی E-Ink به کار رفته در ebook reader ها سرعت refresh بسیار پایینی دارد و به راحتی کاربر را آزار می دهد. اما فکر می کنم که هنوز خواندن کتاب به صورت کاغدی از همه این تکنولوژی های بهتر است. مسلما آیپد برای بسیاری از کاربرانی که قصد خرید یک ebook reader را دارند گزینه مناسبی است.

سیاست های اپل نشان می دهد که هیچ گونه احترامی برای نظر کاربران حرفه ای قایل نیست و فقط به دنبال تست کردن ایده های جدید خود است. هرچند اپل در بسیاری از زمینه ها خالق نوآوردی بوده و خواهد بود، ولی رفتارهای انحصار طلبانه و دیکتاتوری آن مثل AppStore، رمزگذاری دیتا بیس iPod به نحوی که تنها با iTunes بتوان روی آن موزیک ریخت، عدم پشتیبانی از Flash، قفل iPhone و دردسر Jailbreak و عرضه سیستم عامل با سخت افزار خود (لپ تاپ های با مانیتور براق) از جمله دلایلی هستند که من دیگر از اپل خرید نخواهم کرد.

بجای iMac یک IdeaCentre لنوو می خرم. بجای iPhone یک Nexus One گوگل و سال آینده یکی از لپتاپ های پرقدرت و سریع لنوو مثل T400s. با توجه به پایداری و سبک بودن ویندوز 7، دیگر نیازی به OS X هم ندارم!

I love Muse

The only album worth listening to in 2009 was The Resistance from my favorite band Muse.

Three music videos from The Resistance:

The r.a.Pe of JSF - Part V : The Transient Method

Amongst all the past and future posts in this series, this is definitely my favorite. This is ignorance at its limits. I really mean it. For those of you who are unfamiliar with the Transient annotation in Java Persistence API let me quote from the official Java document: "This annotation specifies that the property or field is not persistent. It is used to annotate a property or field of an entity class, mapped superclass, or embeddable class."

What does it mean? When you annotate a class with the @Entity annotation, by convention the properties get mapped to a column with the same name as property's name. In some cases entities have some properties which are for runtime use only and should not be persisted. For example a boolean property holding the selected status of the object in UI tables. To exclude these properties from being persisted, you must annotate them with @Transient. You have two options: annotating fields or getters. I personally prefer field annotations, because it makes my code more readable.

Let's see what our friend has done here:

This helper method belongs to a controller. Annotating a helper static method on a controller with @Transient is something I have never seen before!

The r.a.Pe of JSF - Part IV: Naming Conventions

If you have ever tried to write an enterprise application in Iran, you definitely have felt what I call it the naming crisis. The business domain names in Persian are strange. Most of them are taken from Arabic that I don't even understand their meaning in Persian. For example when I hear the word "اموال غیر منقول" or "وثایق" I have only a vague idea of its meaning.

Since you can not name your Java class in Persian and even if you could it would be a mess (English and Persian in a file), there are currently two common methods for naming domain entities. The first one and in my opinion better one is to Use Finglish, and the second one, for some assholes tending to be very English and original, the translation in English.

There are two major problems in translating domain names in English. First usually you don't know the exact translation! And you end up with some shit. For example in this project they used "Immovable Properties" for "اموال غیر منقول". It is really funny. When I hear the word immovable, I think of something like a chair that is tied to the ground and you can not move it!

The second problem is that Software Systems are by nature not fixed. They evolve and change. And usually another team will work on it in the future. They usually won't get your translations if you don't provide an extensive glossary explaining your reasons for names and after three generations of developers the code becomes a zoo.

But there is third approach! Again from our asshole programmer. Obviously he was very interested in English names with some "تخمی" selection and translation. In the middle of this ruin I find an spectacular example of naming:

Come on! Gardesh Deposit Last Six Month! :)))))) He used Finglish, whenever he did not the translation.

Use Finglish for your domain object names! You may seem to be illiterate in English but you would free the next generation of developers from a great deal of pain!

The r.a.Pe of JSF - Part III : The fear of SQL Injection

This is the third post of this series discussing one more interesting pattern in the mentioned project. If you are interested to find out how you should not write your program, read Part I and II either.

According to Wikipedia, "SQL injection is a code injection technique that exploits a security vulnerability occurring in the database layer of an application. The vulnerability is present when user input is either incorrectly filtered for string literalescape characters embedded in SQL statements or user input is not strongly typed and thereby unexpectedly executed".

If you are unfamiliar with this type of attack, read the whole article. It has clear examples of different types of SQL injection. The SQL injection is all about the user input! You can not attack yourself inside your code. Most libraries like JDBC or JPQL provide a mechanism for escaping user input.

For example in JPQL (or equivalently HQL) you must not insert user arguments directly inside the query. For example consider the following example which search students by name:

public Student searchStudent(String name) {
// Allows SQL injection attacks:
Query q = em.createQuery("from Student where name = '" + name + "'" );

// How to prevent injection
Query q = em.createQuery("from Student where name = :name" );
q.setParameter("name", name);

//The rest of code
...
}

The string after : in the query will be considered as an input parameter and you must provide its value after constructing the query using setParameter(name, value) method.

Now see what our asshole programmer friend has done here:

The loan request statuses are internal pieces of this application. When User opts for seeing all loan requests which are submitted to information office, this method get called. No way he can inject statuses inside the query.

IMO there are two reasons why he has wrote this method this way. First maybe he didn't know anything about SQL injection and just copy/pasted it from another method, where the use of parameters where correct. The second reason is that he knew about SQL injection and was very afraid of his code injecting malicious statements to his query! :D

Try to keep your code clean and readable. You can not attack your queries inside your program.

R.I.P

From James Gosling's blog (The father of Java language)

The r.a.Pe of JSF - Part II: Learn how to program

If you have not read the first part of this series yet, look here.

One of the basic moral principles of Software Development is that if you don't know how to program (and by how to program I mean loops, data types and methods ... ) find another job. At least this way you would make life much easier for the next generation of developers!

There are even some assholes who don't know the basics of programming, but use some advanced frameworks like Seam. The code they produce has always hidden bugs that would not manifest themselves until deadline or demo day! (Moments of truth in our profession)

For example look at this code snippet taken from the mentioned project:

I've got a NullPointerException when the application executed this section. The reason is apparent. The checking for null reference is after calling getType() method! I speculate that the report object is not null most of the time, so the code could be executed without any problem. But I never could understand why he has put the initialization check after that!

For God's sake don't write code like this!

The r.a.Pe of JSF - Part I

This is the first post of the new year. I was busy writing SOP and other applying's bullshit and could not update Wickoo. Most likely I would be busy during next month either. As I told you in one of my last posts, I'm working on a very bad-written (if you ever could use the verb write) code base. My aim is to change the data access layer from Oracle to DB2. DB2 instance is a legacy database and it forced me to change some data model and structure of code. I wish I didn't do that! As I'm going deeper into the code, I find amazing stuff. Although rewriting the 80% of this project was a pain in ass, I have learned a lot. It was also a real geeky fun. In a series of posts I wanna share some screenshots from the code with you. They are really good stuff! ;)

1) How to initialize a backing bean:

Suppose you want to initialize a property by calling a method on corresponding backing bean before rendering the page. What would you do? The answer is not obvious in JSF, especially if the request is not a post-back. With Seam you can set the method to be executed in pages.xml file. See how they solved this problem. This project is in fact a Seam/JSF project:

Binding an OutputText to a method???? The name of the method is interesting too. It depicts that they knew themselves that it was a dummy way for initialization. It is worth to note that you can not use method expressions in JSF standard for values of the components. This initialization technique was possible only through Seam and JBoss EL and they actually abused both Seam and JSF!

2) Layering in Java application

Since I entered the Enterprise programming field, layering was the heart of our architecture. Usually there were a DAO layer that hid the JPA or Hibernate Session from above layers. Look at this two code snippets that are taken from a controller:

Yes, they are from a single controller. DAO instance is also injected into this controller. The first one shows apparently the interest of the programmer in Criteria API, so he exposed Session to use it! The second case is really amazing. The programmer wanted to presumably cancel an edit operation. because the entities were managed, they've got changed and this changes were visible to the user. (Although they were not actually persisted)

See what he has done! Totally stupid: Clearing the entity manager and also flushing it. The answer in this case is to simply use refresh method on entity manager to clear changes made to the managed entity. Clearing the persistent context causes all entities become unmanaged and you must merge them again before any operation. One of the goals of Seam and Conversational scopes is to avoid merging and LazyInitializationException! and even if you want to clear it, why flushing it back to the database!

There is even something more interesting. It seems that the cancel method did not work properly for the developer, so he injected an entity manager right before the method and used a combination of its methods to solve the problem. For God's sake, learn the concept of technologies that you use!

If you have any other ideas, or maybe think you've understood the intent of the programmer better, please leave a comment.

Next time with two other examples of how you should not write your JSF code! After these series, I wanna start Java EE 6 tutorial here.