Yes, Fix Their Computer… With a rubber duck.

There is a popular saying in IT, “No, I will not fix your computer”. There are mugs, t-shirts and stickers of it.

   

I usually agree with this, since every time you help someone with their computer, you instantly become their computer guy, which is not good for your sanity.

Then two days ago, my engine stopped while I’m driving.

Any sufficiently advanced technology is indistinguishable from magic. — Arthur C. Clarke

I pulled over, opened up the hood. Just stared at it for a minute, looking for a restart switch, went back inside and tried to start the engine. It started, with a frustrating vibration and almost no response to the gas pedal. I went back, looking under the hood and it hit me: This is how people feel when their computers are broken. Helpless, not knowing what was going on underneath, not even having a clue of how to fix it or what actually was causing the error. I had to call a friend of mine who is good with cars, and yes, he did fix my car.

From now on, I’ll at least try to fix people’s computers.

Thinking from the developers point of view, developers are not that helpless. They usually have the skills to figure out what’s going on when they face a challenge. But when it comes to undocumented software, like some application built in-house or even tool that can’t easily be googled, the urge to ask for someone’s help emerges. Asking for help is not a big deal, but what about providing it? Do we keep relying on “No, I will not fix your computer”? I don’t. I use a rubber duck instead.

And you can use the rubber duck for your own purposes too.

In a pinch a coworker might be able to substitute for the duck, however, it is often prefered to confide mistakes to the duck instead of your coworker.

I have a friend at work, he is my rubber duck. Every time I face a problem, I go to him and explain what the problem is. He sits there with his arms crossed and listens. At some point in conversation, I usually figure out what’s the issue. Vice versa, when someone asks for my help, before giving any ideas about the solution, I let them do the talking. I’m even thinking of placing an actual rubber duck on my desk.

And yes, I definetly am learning about engines so I won’t be helpless next time. Same thing goes with coding, too.

The 501 Developer Manifesto

I’ve been thinking and reading about The 501 Developer Manifesto lately. There are quite different opinions about it; I think the discussion gets stuck at the point when defining what a hobby, or free time is for each individual.

I agree with the fact that companies never should force employees to work a minute more than they are required to. But as software developers, most of us enjoy to study or research about the work we do, and do not consider it a free-time killer. I personally am preparing this post in a sunny Sunday, but as long as I enjoy it, it becomes a hobby of mine, not a free-time killer.

The Manifesto is so strict in terms that if you agree with it and count yourself as a 501 Developer, you might as well be a robot working in an assembly line. I chose to be a developer, because I love it. And I find myself to be a lucky man, considering the fact that I don’t actually have to work hard for a lifetime, because I usually enjoy what I do in company time. This is not dictated to me, this is not what my company requires me to do. What I do in my spare time is truly irrelevant, yet that seems to be the strong argument of the manifesto.

The Manifesto states:

To us it is just a job, but we still do it well.

In order to do this job well, you need to sharpen yourself. If your job does not require you to learn, research and master your skills, then you really are working in an assembly line. And if you’re OK with working in an assembly line… I respect you for it. There’s probably some pity in there too, but honestly, it’s mostly respect.

Final words for all, even though I don’t agree with most of it, this manifesto is a good step towards a better working environment. Its aim should actually be the managers and people that lead software development teams, not software developers themselves.

Turkcell PAF Takımı

Turkcell PAF Takımı programı ile Turkcell’de staj olanağı için başvurular başladı.

Başvurular 27 Nisan 2012 tarihine kadar açık olacak. 2010 yılında bu program kapsamında Turkcell Teknoloji’de staj yapmış birisi olarak daha önce izlenimlerimi yazmıştım.

Turkcell’de staja kabul edildikten sonra beklentilerim o kadar yüksek değildi, sonuçta benimle birlikte 30′a yakın stajyer vardı ve hepimizle ilgilenemeyeceklerini, zaten oldukça büyük bir yer olduğu için bilgisayarlarımızın başında kendi kendimizi eğitmeye çalışarak zaman geçireceğimizi düşünüyordum. Ama staja ilk başladığım günden itibaren bunun tamamen yanlış bir düşünce olduğunu anladım. Staj süresince bizler için ciddi eğitimler planlandı, oryantasyon sürecini rahat atlatabilmemiz için etkinlikler düzenlendi. Yöneticilerimiz teknik ve şirket kültürü anlamında fayda sağlayabilecek her toplantıya bizim de katılmamızı sağladı, standart eğitimlerin dışında kendi insiyatifleri ile eğitimler planladılar. Blog’da bu eğitimlerden çok ufak bir kısmını paylaşabildim sadece.

Şunu da eklemek isterim, bu bir reklam değildir :)

Subclipse behind a proxy

Having plenty of experience with coding homeworks and projects for a long time now, me and my project partner Emrah decided to use an online source control system for our Senior Project at YTU and the first annoying problem appeared. After seeing that my friend Cem encountered the same problem today, I wanted to say a few words about it.

I’ve successfully installed Subclipse plugin for Eclipse. With a free account from XP-Dev I’ve set my SVN Repository up and checked out the root project using Subclipse to test the SVN server. Everything went as smooth as possible.

The next day, I wanted to use the Eclipse instance at work to check out the project. What a surprise, it failed with the following message..

RA layer request failed

After some digging, I’ve found Mark’s Post about this very issue. It turns out that Subclipse does not use the proxy settings defined in Eclipse Preferences. In a few words, here is the solution:

  1. For Windows, open file %APPDATA%\Subversion\servers.
  2. Find the section [global] at the bottom of the file and edit the related entries. Remember to uncomment them, and do not leave any spaces at the beginning of the line.

Eğitim Notları – 5

Yine biraz geç de olsa, Transactions konusundaki notlarım aşağıdaki gibidir. Kitapta bayağı ilerledik aslında, diğer notlarımı da en yakın zamanda eklemeye çalışacağım.

  • Transaction kavramı, bir veritabanını File System’den ayıran en önemli özelliklerdendir. Transaction’lar, veritabanını bir durumdan başka bir duruma geçirirler ve bunu atomik olarak yaparlar.
  • Bir veritabanı sistemindeki Transaction’lar ACID özelliklerini sağlamalıdır.
    • Atomicity : Ya hep ya hiç. Bir Transaction ya tamamlanır, ya da hiç çalışmamış gibi davranılır.
    • Consistency : Bir transaction veritabanını bir durumdan diğerine geçirir. Eksik veri ile bırakmaz.
    • Isolation :  Transaction COMMIT edilene kadar, o transaction’un değişiklikleri diğer Transaction’lara gözükmeyebilir.
    • Durability :  Transaction tamamlandığında, veri sağlama alınmış demektir.
  • Oracle’da bir Transaction, veriyi değiştiren yani ilk TX kilidini alan statement tarafından başlatılır, elle başlatılmaz. Bu noktadan sonra ya COMMIT ya da ROLLBACK ile Transaction sonlandırılır.
    • COMMIT : Değişiklikleri kalıcı hale getirir.
    • ROLLBACK : Değişiklikleri geri alır, Transaction çalışmamış gibi davranılır.
    • SAVEPOINT : Transaction içinde belli noktalara geri dönüş sağlayabilmek için kullanılır.
  • Tekrar söylemek lazım, DDL her zaman COMMIT edilir. DDL hata verse dahi o Transaction COMMIT edilir.
  • COMMIT ve ROLLBACK, o Transaction’ın elindeki kilitlerin hepsini kaldırır.
  • Eğer çalıştırılan statement bir trigger’ı tetikliyorsa ve bu trigger çalıştıktan sonra hata alınıyorsa, bu noktada yapılan ROLLBACK işlemi trigger’ın yaptığı değişiklikleri de geri alır.
  • PL/SQL bloklarında çalışan prosedürler de statement olarak kabul edilir ve atomiktir.

Son iki madde ile ilgili olarak aşağıdaki örnekleri inceleyelim ve örnekler için Thomas Kyte’a teşekkür edelim. Örnekte, T2 tablosu bir trigger yardımıyla T tablosundaki satırların sayısını tutmakla görevli. T tablosuna ise bir contraint sayesinde sadece sıfırdan büyük değerler girilebiliyor:

CREATE TABLE T ( x int check( x>0 ) );
CREATE TABLE T2( cnt int );
INSERT INTO T2 VALUES( 0 );
CREATE TRIGGER t_trigger BEFORE INSERT OR DELETE
    ON T FOR EACH ROW
BEGIN
    if (inserting) then
        UPDATE T2 set cnt = cnt + 1;
    Else
        UPDATE T2 set cnt = cnt - 1;
    end if;
    dbms_output.put_line( ‘I fired and updated ’ || sql%rowcount || ‘  rows.’ );
END;

Şimdi tabloya satır eklemeye çalışalım.

INSERT INTO T VALUES ( 1 );
I fired and updated 1 rows
1 row created.
INSERT INTO T VALUES ( -1 );
INSERT INTO T VALUES (-1 )
*
ERROR at line 1:
ORA-02290: check constraint (TKYTE.SYS_C001570) violated
I fired and updated 1 rows

Görüldüğü gibi, ilk satırı hata almadan ekleyebildik ve çıkış olarak ekrana trigger içerisinden “I fired and updated 1 rows” yazıldı. İkinci denememizde ise doğal olarak hata aldık, ancak aynı mesajı ekranda yine gördük. Yani trigger çalıştı, ve T2’deki satırı güncelledi. Bu noktada T2 tablosunda ‘2’ değerini görmeyi bekleriz. Ancak T2 tablosunda ‘1’ değeri bulunmaktadır. Yani Oracle, trigger içerisinde çalışan kodu da transaction’ın bir parçası olarak görür ve hata durumunda onu da geri alır. Diğer veritabanlarında tam tersi geçerlidir, trigger’lar kendilerinden sorumludur. Diğer sistemlerde çağırılan statement bir hata alırsa, trigger’lar kendi rollback işlemlerini yapmalıdırlar. Oracle’da statement’lar çağırılırken, aslında aşağıdaki gibi sarmalanır:

Savepoint statement1;
  Insert into t values ( 1 );
If error then rollback to statement1;
Savepoint statement2;
  Insert into t values ( -1 );
If error then rollback to statement2;

Eğer t_trigger’da içerisinde gerçekleştirdiği işlemler sonucunda başka bir trigger’ı tetikleseydi, hatta o da başka bir trigger’ı tetikleseydi bile, ilk ifadeye yapılan ROLLBACK sonucunda bütün trigger’ların gerçekleştirdiği işlemler geri alınacaktı.

  • PL/SQL blokları da statement level atomicity özelliklerini kullanırlar. Aşağıdaki prosedürü ele alalım:
CREATE OR REPLACE PROCEDURE p
AS
BEGIN
    INSERT INTO T VALUES ( 1 );
    INSERT INTO T VALUES (-1 );
END;

Bu prosedürün hata alacağını zaten biliyoruz. Burada soru şu; prosedür çağırıldıktan ve hata aldıktan sonra, T ve T1 tablolarının son durumu nasıl olacak? Burada p prosedürü bir statement olarak ele alınıyor ve ya hep ya hiç mantığı ile, ikinci INSERT hata aldığında bütün prosedür geri sarılıyor. İlginç noktalardan bir diğeri, eğer prosedürü aşağıdaki gibi çağırırsak:

BEGIN
    P;
EXCEPTION
    WHEN OTHERS THEN NULL;
END;

İkinci satır hata almasına rağmen, T tablosuna birinci satırın INSERT edildiğini görürüz. Bunun nedeni, yukarıda belirtilen sarmalama kodunda saklıdır. İkinci statement hata aldığında, “If Error then rollback” çalışamadan Exception yakalanır, ve böylece ROLLBACK yapılmamış olur. Buradan alınması gereken ders şudur, bir Exception bloğu transaction’un davranışını önemli ölçüde değiştirebilir.

  • Tablolar üzerindeki Integrity Constraint’ler varsayılan olarak SQL çalıştırıldıktan sonra kontrol edilir. Arka arkaya çalışan SQL’lerde de her SQL ifadesinden sonra kontrol yapılır. Bu işlemin sonra yapılmasının sebebi çok basittir, aşağıdaki örneği inceleyelim:
CREATE TABLE T (x int unique);
INSERT INTO T VALUES (1);
INSERT INTO T VALUES (2);
UPDATE T set x = x + 1;

Eğer her satır UPDATE edildikten sonra kontrol edilseydi, Unique Constraint ihlali yapılmış olurdu.

  • Integrity Constraint Check işlemini istersek erteleyebiliriz, ancak bu erteleme en fazla bir sonraki COMMIT’e kadar olabilir. Yani COMMIT, mutlaka yapılmamış Constraint Check’i yapar. Constraint Check işlemi her constraint için aşağıdaki şekilde ertelenebilir ve açılabilir:
SET CONSTRAINT <constraint_name> deferred;
SET CONSTRAINT <constraint_name> immediate;
  • Geliştirme yaparken, sadece COMMIT edilmesi gerektiğinde COMMIT etmeliyiz. Oracle’da transaction’lar için açılan kilitler pahalı değildir. Veri bütünlüğünden ödün vererek kilitleri kullanmamaya çalışmak saçma olur, çünkü kilitlerin Oracle’da maliyeti yoktur. Okuyucular yazıcıları, yazıcılar da okuyucuları beklemez. Transaction’lar veri bütünlüğünü korumak için vardır, hız kazandırmak için değil.
  • JDBC API kullanırken AUTOCOMMIT meselesine dikkat etmek gerekir. AUTOCOMMIT, her SQL ifadesinden sonra bir COMMIT çalıştırır, ve malum COMMIT çalıştırıldıktan sonra o veri geri sarılamaz.