Kurumsal Java Yazılımı
Pratik Programcı Yayınları
Kurumsal Java Yazılımı |
|
- Yazılımda ve Yazılımcıda Çok Boyutluluk
- JVM Nasıl Çalışır Yazı Serisi – Java Just In Time Compiler (JIT) Nasıl Çalışır?
- JVM Nasıl Çalışır Yazı Serisi – Java Nesne Düzeni (Java Object Layout)
- Blog Yazılarım Ekitabı Yeni Sürümü
- Yazılımda Şemsiye Modeli
- Kıymeti Bilinmeyen Eskimiş Bilginin Kıymeti
- Daha İyi Bir Programcı Olmak İçin Sınırlar Nasıl Zorlanmalı?
- Karadelikler, Soyutluk ve Yazılım
- Gitolite İle Git Depo Erişimi
- Paralel Evrenlerin Programcıları
|
Yazılımda ve Yazılımcıda Çok Boyutluluk Posted: 08 Sep 2016 04:23 AM PDT Matematiksel anlamda boyut belli bir yönde ölçülmüş bir büyüklüğü ifade etmek için kullanılan geometrik bir terimdir. Günlük kullanılan dilde boyut kelimesi bakış açısı, vizyon, perspektif, farkındalık gibi kelimelerle eş anlamlıdır. Ben de boyut kelimesini bu doğrultuda kullanarak, çok boyutluluğun yazılım ve yazılımcı için ne anlama geldiğini bu yazımda aktarmak istiyorum. İzin verirseniz boyutun ve çok boyutluluğun geometrik anlamda ne olduğunu inceleyerek başlayalım. Matematikte bir nokta tek boyutlu bir nesne olarak kabul edilir. Bu noktayı bir kalemin ucu ile bir kagıt üzerine çizilmiş bir nokta olarak düşünmeyin, çünkü mikroskop altında bakıldığında kalemin oluşturduğu noktanın da genişlige, yüksekliğe ve bir ene sahip olduğu görülecektir. Şimdi kendinizi bir boyutlu bir varlık olarak hayal edin. Bir kutunun içindesiniz ve bu kutunun satıhlarından birisinde bulunuyorsunuz. Bir kutunun içinde olduğunuzu bilebilir misiniz? Kutunun kendisi üç boyutlu bir nesne. Kutuyu oluşturan altı satıh iki boyutlu nesnelerden oluşmakta. Bu durumda sizin görebileceğiniz alan neyi kapsamaktadır? Hiçbir şeyi! Ne kutunun içinde ne de satıhlardan birisinde olduğunuzu bilebilirsiniz. Kısaca üç boyutlu bir sahada tek boyutlu bir varlık olarak hem körsünüz hem de olan bitenden bihabersiniz. Şimdi size ikinci bir boyut verelim ve iki boyutlu bir varlık olun, yani eniniz ve genişliğiniz olsun. Bu durumda kutunun neresinde olduğunuzu bilebilir misiniz? Bilemezsiniz, çünkü üçüncü boyutta olup bitenlerden bihabersiniz. Siz sadece iki boyutlu olan satıh üzerinde olup bitenleri kavrayabilecek boyut kapasitesine sahipsiniz. Kutu içinde olup bitenleri anlamanız imkansız. Bunun için yükselmeniz, yani üç boyutlu bir varlık haline gelmeniz gerekiyor. İki boyutlu canlı olarak kutunun üzerinde bulunduğunuz satıhta diğer iki boyutlu canlılarla beraber yaşamınızı sürdürüyorsunuz. Kutu içinde olup bitenler yani üç boyutlu canlıların yaşantıları ve yaptıkları size nasıl yansırdı? Bunu anlayabilmek için şöyle bir deney yapalım. Siz iki boyutlu satıh üzerindesiniz. Bu satıhı bir kağıt parçası olarak düşünelim. Şimdi ben bu kağıdın yüzeyinden kalemin ucuyla bir delik açarak, kalemi yukarıdan aşağıya doğru geçiriyorum. Siz üç boyutlu olan kalemi nasıl görürdünüz? İki boyutlu bir canlı olduğunuz için üç boyutlu kalemi görmeniz ve kalem olduğunu anlamanız mümkün değil. Ama bir şeyler göreceksiniz. Bu gördükleriniz, kalem sizin boyutunuzdan geçerken kalemin bulunduğunuz satıh ile kesiştiği iki boyutlu kesitleri olacaktır. Yani siz kalemin iki boyutlu parçalarını göreceksiniz ve sizin dünyanızdan geçen şeyin bir kalem olduğunu anlamanız mümkün olmayacak. Şimdi bu deneyin tam tersiniz yapalım. Kutunun içinde yaşayan üç boyutlu varlıklar satıh yüzeylerinde yaşayan iki boyutlu canlılar hakkında neler bilebilirler? Yine bir deney yapalım. Siz iki boyutlu bir varlık olarak bulunduğunuz satıhta iki boyutlu bir kasa sahibi olun. Bu kasa içinde yer alan nesneleri iki boyutlu canlıların görmesi mümkün degildir. Peki bu durum üç boyutlu varlıklar için de geçerli mi? Hayır, çünkü onlar doğrudan iki boyutlu bir kasanın içinde olanları görebilirler. İki boyutlu bir kasa üç boyutlu bir varlık için sadece bir dikdörtgen ya da karedir. Siz iki boyutlu bir canlı olarak üç boyutlu varlıklardan hiçbir seyi saklayamaz ya da gizleyemezsiniz. Onlar her şeyi apaçık görürler. Bu boyut deneylerini dördüncü boyuta bu şekilde taşımak mümkün mü bilmiyorum, lakin benim aklıma takılan soru şu: Biz üç boyutlu varlıklar olarak dört boyutlu bir varlığı nasıl algılardık? Bizim gördüklerimiz de sadece dördüncü boyutun üç boyutlu parçaları mı olurdu? Aklıma daha ilginç bir soru geliyor: Onlar bizim kasalarımız içindeki her şeyi görebiliyorlar mı? Şimdi bu yazdıklarımın yazılım ile ne ilgisi olduğu konusuna gelmek istiyorum. Yazılım dünyasını bir kutu olarak düşünelim. Yaptığımız deneylerden yola çıkacak olursak, kutu içinde olup bitenleri kavrayabilmek için en az üç boyutlu yazılımcı olmak gerekiyor. Bu kutu dışına taşacak şekilde çok boyutlu yazılımcı olmak da mümkün. Bunu tercih etmeyip, bir ve iki boyutlu yazılımcı olarak kalmayı tercih eden yazılımcılara da rastlamak mümkün. Bunun ana sebebi, yazılımın sadece kod yazmak olarak algılanmasıdır. Kod yazabilmek yazılımcıya sadece tek bir boyut kazandırır. Kod yazabilen bir yazılımcıyı kutu içindeki tek boyutlu bir varlık ile kıyasladığımızda, yazılımda boyutsuzluğun beraberinde getirdiği dejavantajlar net olarak görülebilmektedir. Yazılımcıda yeterli sayıda boyut mevcut değilse, kendisinin yazılımın (kutunun) neresinde olduğunu kavraması zorlaşır. Boyut kutu içinde olup bitenleri kavramak ve farkındalık için çok önemlidir. Bu yüzden ana amac boyut kazanmak olmalıdır. Ne yazık ki yazılım kutusu sadece üç boyutlu statik bir yapı değil. Yazılımı ilginç kılan tarafı da zaten bu. Bu yapı sürekli boyut kazanıyor. Üç boyutlu bir yazılımcı üç boyutlu bir kutu içinde olup bitenleri zorlanmadan takip edebilirken, kutunun dört boyutlu bir yapı haline dönüşmesi, yazılımcının yine bir boyut geride kalmasına sebep olduğundan dolayı gidişatı zorlaştırmaktadır. Yazılımcı yeni bir boyut kazanarak, bu açığı telafi edebilir. Örneğin yapılandırma (build), sürümleme (release), versiyon yönetimi (version control), yeniden yapılandırma (refactoring) gibi konularda ihtisas, yazılımcıya yeni boyutlar, perspektifler ve bakış açıları kazandıracaktır. Yazılım aslında devamlı süregelen bir boyut yarışıdır. Yazılım bir üst boyuta geçer, yazılımcı bunu açığı kapatmaya çalışır. Bazıları bu açığı kapatır, bazıları kapatamaz. Farkında bile olunmayan bir eksiklik nasıl telafi edilebilsin ki. Boyut == Farkındalık.
|
|
JVM Nasıl Çalışır Yazı Serisi – Java Just In Time Compiler (JIT) Nasıl Çalışır? Posted: 14 May 2016 08:41 AM PDT Java’yı çoğu programcı yorumlanan (interpreted) dil olarak bilir. Java’nın yavaş olduğu efsanesi de başlangıcını da burada bulur. Bytekod olarak derlenen Java sınıfları Java sanal makinesi (Java Virtual Machine – JVM) bünyesinde yorumlanır. Tek derleme işlemi Java sınıflarının bytekoda dönüştürülmesi esnasında yapılmaz. JVM bünyesinde de bytekodun makine koduna dönüştürüldüğü bir derleme gerçekleştirilir. Bu işleme Just in time (JIT) compilation ismi verilmektedir. Bu yazımda JVM bünyesinde kodun nasıl derlendiğini örnekler üzerinden aktarmak istiyorum. Derleme (compilation) sürecini yüksek dillerde yazılan program kodlarının işlemcinin (CPU) anladığı makine koduna dönüştürüldüğü ve bu şekilde CPU üzerinde koşturulabilir hale getirildiği işlem olarak tanımlayabiliriz. Derleme işlemini gerçekleştiren programları yani derleyicileri kabaca iki guruba ayırmak mümkün. Bunlar:
C/C++ gibi diller AOT tarzı derleciyiler kullanırlar. AOT derleyicileri program kodunu programın koşturulmasından önce kullanılan donanımın anladığı makine koduna dönüştürürler. JIT ise Java gibi dillerde uygulamanın çalışması esnasında (runtime) kazanılan performans verileri doğrultusunda uygulanan derleme tekniğidir. JIT devreye girmeden önce kod bytekod olarak yorumlanır. AOT ile derlenen uygulamalar JIT ile derlenen uygulamalara kıyasla daha hızlı çalışırlar, çünkü kod tamamıyla işlemcinin anladığı şekilde derlenmiştır ve yorumlanmadan doğrudan işlemci bünyesinde koşturulur. Buna karşın AOT ile derlenen uygulamalar derlendikleri platformlara bağımlıdırlar ve başka donanım türlerinde koşturulamazlar. Bunun için yeniden derleme işleminin gerçekleştirilmesi gerekmektedir. JIT derleyicileri platformdan bağımsız çalışırlar. Java kodları javac ile derlenir. Bu derleme işlemi sonucunda bytekod oluşur. Aşağıdaki örnekte HelloWorld sınıfının nasıl derlendiğini ve derlenen sınıfın hangi bytekodu ihtiva ettiğini görmekteyiz.
C:\>java HelloWorld
public class HelloWorld {
public static void main(String[] args){
System.out.println("Merhaba Dünya!");
}
}
C:\>javap -c HelloWorld.class
Compiled from "HelloWorld.java"
public class HelloWorld {
public HelloWorld();
Code:
0: aload_0
1: invokespecial #1 // Method java/lang/Object."<init>":()V
4: retur
public static void main(java.lang.String[]);
Code:
0: getstatic #2 // Field java/lang/System.out:Ljava/io/PrintStream;
3: ldc #3 // String Merhaba D?nya!
5: invokevirtual #4 // Method java/io/PrintStream.println:(Ljava/lang/String;)V
8: return
}
Bir Java uygulaması JVM bünyesinde çalışır hale getirildiğinde, yukarıda yer alan bytekod JVM tarafından yorumlanmaya başlar. JVM bu durumda “interpreted” modundadır ve bytekodunu satır, satır yorumlar. Bu haliyle JVM bir durum makinesidir (state machine). JVM bytekodu yorumlarken kodun sık kullanılan alanları hakkında istatistiki bilgiler toplar. Bu şekilde örneğin hangi metodun hangi sıklıkla koşturulduğunu ölçmek mümkündür. JVM parametreleri aracılığı ile JIT in derleme işlemine geçtiği barajlar tanımlanabilir. Örneğin bir metot on bin kez koşturulduktan sonra, bu metodun JIT tarafından derlenmesi ve bytekoddan makine koduna dönüştürülmesi sağlanabilir. Bu değeri örneğin bin olarak değiştirmek de mümkündür. JIT ile derleme işlemi gerçekleştikten sonra JVM “compiled” moduna geçer. Bu modda JVM işlemciye (CPU) has işlemleri (native direct operations) gerçekleştirir. Kod artık yorumlanmadığı için daha hızlı çalışmaktadır. JVM bir state machine olmaktan çıkmış ve artık doğrudan işlemci üzerinde işlem yaptığından bir native register machine haline gelmiştir. JVM in yorumlama, derleme ve uygulamayı koşturma esnasında içinde bulunduğu durumları aşağıdaki diyagramda görmekteyiz.
(1) Interpreted --> (2)Profiline
^ |
| |
| v
(4) Deoptimize <-- (3)JIT Compiled
JVM başlangıçta interpreted (1) yani bytekodu yorumlayıcı durumundadır. Kod yorumlanırken JVM tarafından profiling (2) tekniği ile ölçümler gerçekleştirlir. Bu veriler baz alınarak kodun hangi bölümlerinin JIT ile derleneceği kararı alınır ve kod derlenir. JIT derleme (3) işlemi esnasında tüm bilgilere sahip olamayacağından bazı varsayımlarda bulunur ve spekülasyona dayalı kararlar neticesinde derleme işlemini gerçekleştirir. Bazı şartlar altından bu varsayımlar geçerliliklerini kaybettiklerinden, derlenen kod işe yaramaz hale gelir ve bir kenara bırakılarak (4), yeniden yorumlama (1) moduna geçilir. Bu döngü uygulamanın hayatı boyunca devam eder. Belli bir kullanım süresinden sonra kod hakkında toplanan bilgiler yeterli olduğundan, kodun çok kullanılan alanları derlenmiş olur ve bu da Java uygulamalarını C/C++ uygulamaları gibi hızlı kılar. JIT derleyicisi bir AOT derleyicisine nazaran daha fazla runtime istatistik bilgisine sahip olduğundan, kodun işlemci için optimize edilme işlemi daha verimli sonuçlar verir. Bu yüzden Java uygulamalarının C/C++ uygulamalarına nazaran yer yer daha hızlı çalıştığı söylenebilir. Diğer bir yazımda JIT tarafından uygulanan kod optimizasyon tekniklerine değineceğim. Aşağıda yer alan Calculator sınıfı aracılığı ile JIT tarafından derleme işleminin nasıl yapıldığını inceleyebiliriz.
package com.kurumsaljava.jvm.jit;
public class Calculator {
public static void main(String[] args) {
int max = Integer.parseInt(args[0]);
System.out.println(addAll(max));
}
private static int addAll(int max) {
int result = 0;
for (int i = 0; i < max; i++) {
result = add(result, i);
}
return result;
}
private static int add(int result, int i) {
return result + i;
}
}
JIT tarafından yapılan derleme işlemini takip edebilmek için -XX:+PrintCompilation parametresini aşağıdaki şekilde kullanmamız gerekiyor. Bunun yanı sıra -server parametresinin kullanılması, JIT derleyicisinin daha agresif bir şekilde derleme işlemine girişmesini mümkün kılacaktır.
c:\>java -server -XX:+PrintCompilation com.kurumsaljava.
jvm.jit.Calculator 100000
Calculator sınıfı 1 – 100000 arasındaki rakamları toplamakta ve neticeyi ekranda görüntülemektedir. Ekran çıktısı şu şekilde olacaktır: 1 80 1 3 java.lang.Object::<init> (1 bytes) 2 82 2 3 java.lang.String::hashCode (55 bytes) 3 83 3 3 java.lang.String::charAt (29 bytes) 4 86 4 3 java.lang.Character::toLowerCase (9 bytes) 5 86 5 3 java.lang.CharacterData::of (120 bytes) 6 86 6 3 java.lang.CharacterDataLatin1::toLowerCase (39 bytes) 7 86 7 3 java.lang.CharacterDataLatin1::getProperties (11 bytes) 8 86 8 3 java.lang.String::indexOf (70 bytes) 9 87 9 3 java.util.Arrays::copyOfRange (63 bytes) 10 87 10 3 java.lang.AbstractStringBuilder::ensureCapacityInternal (16 bytes) 11 88 11 n 0 java.lang.System::arraycopy (native) (static) 12 88 12 3 java.lang.AbstractStringBuilder::append (29 bytes) 13 88 13 3 java.io.WinNTFileSystem::isSlash (18 bytes) 14 88 14 s 3 java.lang.StringBuffer::append (13 bytes) 15 89 15 3 java.lang.String::length (6 bytes) 16 89 16 1 java.lang.Object::<init> (1 bytes) 17 89 1 3 java.lang.Object::<init> (1 bytes) made not entrant 18 89 17 3 java.lang.String::getChars (62 bytes) 19 91 18 3 java.lang.Math::min (11 bytes) 20 97 19 3 sun.misc.FDBigInteger::mult (64 bytes) 21 97 20 3 sun.misc.FDBigInteger::<init> (30 bytes) 22 98 21 3 sun.misc.FDBigInteger::trimLeadingZeros (57 bytes) 23 98 22 3 sun.misc.FDBigInteger::mult (44 bytes) 24 100 23 n 0 java.lang.System::nanoTime (native) (static) 25 100 24 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) 26 100 25 1 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) 27 100 24 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) made not entrant 28 105 26 3 java.lang.AbstractStringBuilder::append (50 bytes) 29 110 27 % 3 com.kurumsaljava.jvm.jol.Calculator::addAll @ 7 (75 bytes) 30 111 28 3 com.kurumsaljava.jvm.jol.Calculator::addAll (75 bytes) 31 113 29 3 sun.nio.cs.SingleByte$Encoder::encode (32 bytes) 704982704 Birinci kolonda satır numaralarını, ikinci kolonda JVM in işlem için kullandığı zamanı (millisecond), üçüncü kolonda derleme sırasını, dördüncü kolonda derleyici seviyesini, beşinci kolonda derlenen metodu görmekteyiz. Bizim için ilginç olan derleme işlemleri aşağıda yer almaktadır: 25 100 24 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) 26 100 25 1 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) 27 100 24 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) made not entrant 29 110 27 % 3 com.kurumsaljava.jvm.jol.Calculator::addAll @ 7 (75 bytes) 30 111 28 3 com.kurumsaljava.jvm.jol.Calculator::addAll (75 bytes) 25. ve 27. satırlarda add() metodunun derlendiğini ve derleme neticesinin 4 byte büyüklükte olduğunu görmekteyiz. 27. satırda “made not entrant” ibaresi yer almakta. Bu JIT in kullandığı varsayımların geçerliliğini yitirdiği ve derlenen kodun devre dışı kaldığı anlamına gelmektedir. 27. satırda JVM deoptimizasyon moduna geçerek, metodun yeni bilgiler doğrultusunda yeniden derlenmesinin önünü açmaktadır. Derleme sırasının düzenli olmadığını görmekteyiz. Bu JIT derleyicisinin arka planda thread bazlı çalıştığının göstergesidir. 26. satırda add() metodu tekrar derlenmekte ve işlemci üzerinde makine kodu olarak koşturulabilir hale getirilmektedir. Ayrıca 29. ve 30. satırlarda addAll() metodunun da derlendiğini görmekteyiz. 29. satırda yer alan % isaretinin ne anlama geldiğine birazdan değineceğim. Daha önce de bahsettiğim gibi JIT derleme işlemi esnasında kodu mümkün mertebe daha hızlı çalışabilsin diye optimize etme gayretindedir. Derleyiciler tarafından yapılan bu optimizasyonların başında method inlining gelir. Bu derleme esnasında bir metot gövdesinin kullanıldığı metota kod olarak eklenmesi anlamına gelmektedir. Örneğin aşağıda yer alan addAll() ve add() metotları JIT tarafından şu şekilde optimize edeilecektir:
private static int addAll(int max) {
int result = 0;
for (int i = 0; i < max; i++) {
result = add(result, i);
}
return result;
}
private static int add(int result, int i) {
return result + i;
}
JIT tarafından optimize edilen kod şu yapıpdadır:
private static int addAll(int max) {
int result = 0;
for (int i = 0; i < max; i++) {
result += i;
}
return result;
}
Görüldügü gibi JIT add() bünyesindeki kodu birebir addAll() metoduna taşıdı. Bu şekilde add() metoduna geçmek için gerekli frame (bknz. JVM Stack Nedir ve Nasıl Çalışır? başlıklı yazım) oluşturma işlemi gereksiz hale geldiğinden, JVM kodu daha hızlı koşturulabilmektedir. Method inlining işleminin gerçekleştiğini ispatlamak amacıyla Calculator sınıfını aşağidaki şekilde değiştirerek, tekrar koşturuyorum:
public class Calculator {
public static void main(String[] args) {
int max = Integer.parseInt(args[0]);
System.out.println(addAll(max));
}
private static int addAll(int max) {
int result = 0;
for (int i = 0; i < max; i++) {
long start = System.nanoTime();
result = add(result, i);
long duration = System.nanoTime() - start;
if (i % 10000 == 0)
System.out.println("add execution took " +
((duration) / 1000.0d) + " µs");
}
return result;
}
private static int add(int result, int i) {
return result + i;
}
}
Ekran çıktısı şu şekilde olacaktır:
80 1 3 java.lang.Object::<init> (1 bytes)
82 2 3 java.lang.String::hashCode (55 bytes)
83 3 3 java.lang.String::charAt (29 bytes)
86 4 3 java.lang.Character::toLowerCase (9 bytes)
86 5 3 java.lang.CharacterData::of (120 bytes)
86 6 3 java.lang.CharacterDataLatin1::toLowerCase (39 bytes)
86 7 3 java.lang.CharacterDataLatin1::getProperties (11 bytes)
86 8 3 java.lang.String::indexOf (70 bytes)
87 9 3 java.util.Arrays::copyOfRange (63 bytes)
87 10 3 java.lang.AbstractStringBuilder::ensureCapacityInternal (16 bytes)
88 11 n 0 java.lang.System::arraycopy (native) (static)
88 12 3 java.lang.AbstractStringBuilder::append (29 bytes)
88 13 3 java.io.WinNTFileSystem::isSlash (18 bytes)
88 14 s 3 java.lang.StringBuffer::append (13 bytes)
89 15 3 java.lang.String::length (6 bytes)
89 16 1 java.lang.Object::<init> (1 bytes)
89 1 3 java.lang.Object::<init> (1 bytes) made not entrant
89 17 3 java.lang.String::getChars (62 bytes)
91 18 3 java.lang.Math::min (11 bytes)
97 19 3 sun.misc.FDBigInteger::mult (64 bytes)
97 20 3 sun.misc.FDBigInteger::<init> (30 bytes)
98 21 3 sun.misc.FDBigInteger::trimLeadingZeros (57 bytes)
98 22 3 sun.misc.FDBigInteger::mult (44 bytes)
add execution took 1.579 µs
100 23 n 0 java.lang.System::nanoTime (native) (static)
100 24 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
100 25 1 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
100 24 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) made not entrant
add execution took 0.0 µs
add execution took 0.395 µs
105 26 3 java.lang.AbstractStringBuilder::append (50 bytes)
add execution took 0.0 µs
add execution took 0.0 µs
add execution took 0.0 µs
add execution took 0.0 µs
110 27 % 3 com.kurumsaljava.jvm.jol.Calculator::addAll @ 7 (75 bytes)
111 28 3 com.kurumsaljava.jvm.jol.Calculator::addAll (75 bytes)
add execution took 0.0 µs
add execution took 0.0 µs
113 29 3 sun.nio.cs.SingleByte$Encoder::encode (32 bytes)
add execution took 0.0 µs
704982704
İlk on bin adet add() koşturulması neticesinde toplam koşturma süresi 1.579 µs dır. Akabinde kodun iki sefer derlendiğini ve koşma süresinin 0.0 µs şeklinde değiştiğini görmekteyiz. Bu değer add() metodu inline edildiği zaman oluşabilecek bir değerdir. Add() metodu JIT tarafından “made not entrant” yapıldıktan yani derlenen kod çöpe atıldıktan sonra bir sonraki on bin adet koşturulması 0.395 µs süresinde gerçekleşmektedir. Bu add() metodunun deoptimizasyon sonucunda tekrar yorumlanmaya başlandığının ispatıdır. Add() daha sonra tekrar derlenerek, koşturma zamanı sıfıra düşmektedir, çünkü JIT tarafından tekrar addAll() bünyesinde inline edilmiştir. Bu arada addAll() metodunun ilk derlendiği yerde % işareti görmekteyiz. Bu JIT in derleme işlemini “On stack replacement” modunda yaptığı anlamına gelmektedir. On stack replacement ne anlama gelmektedir? JIT genelde çok kullanılan metotları birebir derleme eğilimindedir. Derleme işleminden sonra derlenen metodu kullanan diğer metotlar yeni makine koduna işaret edecek şekilde yeniden yapılandırılır. Bunu bir hashtable bünyesinde yapılan bir eşleme olarak düşünebiliriz. Tüm kullanıcı metotlar derlenen metoda işaret ederler. JIT in metodu derleyebilmesi için metodun stack frame ini açmamış yani koşuyor durumda olmaması gerekmektedir. Bu add() metodu bünyesinde mevcut olan bir durumdur. Bu metot yüz bin kez koşturulmaktadır ve JIT bu metodu derlemek için gerekli fırsatları değerlendirmektedir. Lakin addAll() metoduna baktığımızda, bu metodun sadece bir kez koşturulduğunu görmekteyiz. Buna rağmen addAll() metodu JIT için bir sicak alandır (hotspot) ve derlenmelidir, çünkü uygulama için gerekli zamanın çok büyük bir kısmı bu metot bünyesinde geçmektedir. JIT sadece bir kez koşturulan ama derlenmeyi hak eden metotları on stack replacemant yöntemi ile derlemektedir. Bu yöntemde tüm metot derlenmemektedir. JIT sadece for döngüsünün başlangıcından, sonuna kadar olan bölümü derler ve for döngüsünü koşturan yorumlayıcının (interpreter) sahip olduğu stack frame i derlenen koda giriş noktası olarak kullanır. Bu şekilde uzun döngülerin de derlenmesi mümkün hale gelmektedir. JIT tarafından yapılan method inlining işlemini -XX:+PrintInlining parametresi ile takip etmek mümkündür. Şimdi uygulamayı bu yeni parametre ile çalıştırarak, hangi metotların inlining yöntemi ile yok edildiğini inceleylim. Bu parametreyi kullanabilmek için -XX:+UnlockDiagnosticVMOptions parametresi ile gerekli JVM kanallarının açılması gerekmektedir. Bu sebeple Calculator sınıfını aşağıdaki şekilde koşturmamız gerekmektedir:
c:\>java -server -XX:+PrintCompilation -XX:+UnlockDiagnosticVMOptions
-XX:+PrintInlining com.kurumsaljava.jvm.jit.Calculator 100000
Ekran çıktısı şu şekilde olacaktır:
65 1 3 java.lang.Object::<init> (1 bytes)
68 2 3 java.lang.String::hashCode (55 bytes)
68 3 3 java.lang.String::charAt (29 bytes)
@ 18 java/lang/StringIndexOutOfBoundsException::<init> (not loaded) not inlineable
71 4 3 java.lang.Character::toLowerCase (9 bytes)
@ 1 java.lang.CharacterData::of (120 bytes) callee is too large
@ 5 java.lang.CharacterData::toLowerCase (0 bytes) no static binding
71 5 3 java.lang.CharacterData::of (120 bytes)
71 6 3 java.lang.CharacterDataLatin1::toLowerCase (39 bytes)
@ 4 java.lang.CharacterDataLatin1::getProperties (11 bytes)
71 7 3 java.lang.CharacterDataLatin1::getProperties (11 bytes)
72 9 3 java.lang.AbstractStringBuilder::ensureCapacityInternal (16 bytes)
@ 12 java.lang.AbstractStringBuilder::expandCapacity (50 bytes) callee is too large
72 8 3 java.util.Arrays::copyOfRange (63 bytes)
@ 16 java.lang.StringBuilder::<init> (7 bytes)
@ 3 java.lang.AbstractStringBuilder::<init> (12 bytes)
@ 1 java.lang.Object::<init> (1 bytes)
@ 20 java.lang.StringBuilder::append (8 bytes)
@ 2 java.lang.AbstractStringBuilder::append (62 bytes) callee is too large
@ 25 java.lang.StringBuilder::append (8 bytes)
@ 2 java.lang.AbstractStringBuilder::append (50 bytes) callee is too large
@ 29 java.lang.StringBuilder::append (8 bytes)
@ 2 java.lang.AbstractStringBuilder::append (62 bytes) callee is too large
@ 32 java.lang.StringBuilder::toString (17 bytes)
@ 13 java.lang.String::<init> (62 bytes) callee is too large
@ 35 java.lang.IllegalArgumentException::<init> (6 bytes) don't inline Throwable constructors
@ 54 java.lang.Math::min (11 bytes)
@ 57 java.lang.System::arraycopy (0 bytes) intrinsic
73 11 n 0 java.lang.System::arraycopy (native) (static)
73 10 3 java.lang.String::indexOf (70 bytes)
@ 66 java.lang.String::indexOfSupplementary (71 bytes) callee is too large
73 12 3 java.lang.AbstractStringBuilder::append (29 bytes)
@ 7 java.lang.AbstractStringBuilder::ensureCapacityInternal (16 bytes)
@ 12 java.lang.AbstractStringBuilder::expandCapacity (50 bytes) callee is too large
73 16 1 java.lang.Object::<init> (1 bytes)
73 1 3 java.lang.Object::<init> (1 bytes) made not entrant
73 13 3 java.io.WinNTFileSystem::isSlash (18 bytes)
73 14 s 3 java.lang.StringBuffer::append (13 bytes)
@ 7 java.lang.AbstractStringBuilder::append (29 bytes)
@ 7 java.lang.AbstractStringBuilder::ensureCapacityInternal (16 bytes)
@ 12 java.lang.AbstractStringBuilder::expandCapacity (50 bytes) callee is too large
74 15 3 java.lang.String::length (6 bytes)
74 17 3 java.lang.String::getChars (62 bytes)
@ 9 java/lang/StringIndexOutOfBoundsException::<init> (not loaded) not inlineable
@ 27 java/lang/StringIndexOutOfBoundsException::<init> (not loaded) not inlineable
@ 43 java/lang/StringIndexOutOfBoundsException::<init> (not loaded) not inlineable
@ 58 java.lang.System::arraycopy (0 bytes) intrinsic
76 18 3 java.lang.Math::min (11 bytes)
78 19 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
79 20 1 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
79 19 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) made not entrant
80 21 % 3 com.kurumsaljava.jvm.jol.Calculator::addAll @ 7 (23 bytes)
@ 9 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
81 22 3 com.kurumsaljava.jvm.jol.Calculator::addAll (23 bytes)
@ 9 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
704982704
Bizim için ilginç olan bölümleri şu şekilde özetleyebiliriz:
1) 78 19 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
2) 79 20 1 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
3) 79 19 3 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes) made not entrant
4) 80 21 % 3 com.kurumsaljava.jvm.jol.Calculator::addAll @ 7 (23 bytes)
5) @ 9 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
6) 81 22 3 com.kurumsaljava.jvm.jol.Calculator::addAll (23 bytes)
@ 9 com.kurumsaljava.jvm.jol.Calculator::add (4 bytes)
5. satırda add() metodunun addAdll() metoduna taşındığını görmekteyiz. 3. satırda add() metodu depotimizasyon sonucu devre dışı kaldığından, 6. satırda add() metodu tekrar derlendikten sonra addAll() metoduna inline edilmektedir. JIT tarafından yapılan işlemlerin XML olarak bir dosyaya eklenmesini istiyorsak, JVM i aşağıdaki şekilde çalıştırabiliriz:
c:\>java -server -XX:+UnlockDiagnosticVMOptions -XX:+LogCompilation
com.kurumsaljava.jvm.jit.Calculator 100000
Oluşan log dosyasını JitWatch uygulaması ile analiz etmek mümkün. JVM nasıl çalışır yazı serisinin bir sonraki yazısında buluşmak üzere. |
|
JVM Nasıl Çalışır Yazı Serisi – Java Nesne Düzeni (Java Object Layout) Posted: 03 May 2016 10:57 AM PDT Bu yazımda bir Java nesnesinin hafıza alanında (heap) nasıl yer aldığını yanı sahip olduğu hafiza düzenini (object layout) aktarmak istiyorum. Bu amaçla aşağıda yer alan sınıfı kullanacağım.
public class BirSinif {
boolean b;
char c;
int i;
float f;
double d;
String s;
byte bb;
}
Java nesnelerinin hafıza düzenini elde etmek için JOL isimli aracı kullandım. Burada JOL kullanım örneklerini bulabilirsiniz. Yukarıda yer alan BirSinif isimli sınıfın hafıza düzenini JOL aracılığı ile şu şekilde edinebiliriz:
public static void main(String[] args) throws Exception {
System.out.println(ClassLayout.parseClass(BirSinif.class).toPrintable());
}
Ekran çıktısı şu şekilde olacaktır:
com.kurumsaljava.jvm.jol.JOLSample1$BirSinif object internals:
OFFSET SIZE TYPE DESCRIPTION VALUE
0 12 (object header) N/A
12 4 int BirSinif.i N/A
16 8 double BirSinif.d N/A
24 4 float BirSinif.f N/A
28 2 char BirSinif.c N/A
30 1 boolean BirSinif.b N/A
31 1 byte BirSinif.bb N/A
32 4 String BirSinif.s N/A
36 4 JOLSample1 BirSinif.this$0 N/A
Instance size: 40 bytes
Space losses: 0 bytes internal + 0 bytes external = 0 bytes total
BirSinif sınıfından bir nesne oluşturulduktan ve hafızada konuşlandırıldıktan sonra bu nesne arka arkaya dizilmiş byte elementlerinden oluşan bir düzene sahip olacaktır. Bir Java nesnesinin hafızada kapladığı alan hep sekizin katlarıdır. Nesnenin kapladığı hafıza alanının ilk 12 byte elementi nesne başlığını (header) teşkil etmektedir. Başlık bünyesinde mark word ve klass pointer ismini taşıyan yapılar yer almaktadır. Klass pointer 32 bitlik sistemlerde 4 byte uzunluğundadır ve nesnenin heap hafıza alan adresini ihtiva etmektedir. 64 bitlik sistemlerde bu alan 8 byte uzunluktadır. 64 bitlik sistemlerde nesne hafıza alanı adreslerinin 4 byte artış göstermesi CPU belleklerinde (cache) daha az sayıda nesne referansi tutulabilmesine sebebiyet vermiştir. Bu aynı anda daha az sayıda nesne üzerinde işlem yapıldığı anlamına gelmektedir. Bu sorunu gidermek için compressed oops (ordinary object pointers) mekanizması kullanılmaktadır. 64 bitlik bir sistemde tüm hafıza alanı 2^64 genişliğindedir. Bu genişlikteki alanı sadece 64 bit ile adreslemek mümkündür. Bu yüzden klass pointer 8 byte uzunlulğunda olmak zorundadır. 64 bitlik sistemlerde compressed oops mekanizması kullanıldığında, klass pointer 4 byte uzunluğu ile yetinmekte ve bu değer adres offset değeri olarak kullanılarak, yine teoride 64 bitlik adres alanını adreslemek için kullanılabilmektedir. -XX:+UseCompressedOops JVM parametresi ile compressed oops mekanizması yönetilebilmektedir. Nesne başlığının diğer parçası olan mark word 32 bit sistemlerde 4, 64 bit sistemlerde 8 byte uzunluğundadır ve nesne lock, nesnenin yaşı, hash değeri, hangi thread tarafından bloke edildiği ve garbage collection işlemleri için kullanılmaktadır. Markoop.hpp dosyasında bu yapının tanımlaması yer almaktadır. Aşağıdaki alıntıda 32 bit ve 64 bit sistemlerde mark word yapısının nasıl şekillendirildiği yer almaktadır. // 32 bits: // -------- // hash:25 ------------>| age:4 biased_lock:1 lock:2 (normal object) // JavaThread*:23 epoch:2 age:4 biased_lock:1 lock:2 (biased object) // size:32 ------------------------------------------>| (CMS free block) // PromotedObject*:29 ---------->| promo_bits:3 ----->| (CMS promoted object) // // 64 bits: // -------- // unused:25 hash:31 -->| unused:1 age:4 biased_lock:1 lock:2 (normal object) // JavaThread*:54 epoch:2 unused:1 age:4 biased_lock:1 lock:2 (biased object) // PromotedObject*:61 --------------------->| promo_bits:3 ----->| (CMS promoted object) // size:64 ----------------------------------------------------->| (CMS free block) // // unused:25 hash:31 -->| cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && normal object) // JavaThread*:54 epoch:2 cms_free:1 age:4 biased_lock:1 lock:2 (COOPs && biased object) // narrowOop:32 unused:24 cms_free:1 unused:4 promo_bits:3 ----->| (COOPs && CMS promoted object) // unused:21 size:35 -->| cms_free:1 unused:7 ------------------>| (COOPs && CMS free block) Nesne başlığının ardından sınıf bünyesinde kullanılan sınıf değişkenleri için rezerve edilen byte elementleri gelmektedir. BirSinif bünyesinde birçok veri tipine sahip değişkenler yer almaktadır. Bu değişkenlerin kapladıkları hafıza alanlarını aşağıda görmekteyiz. 12 4 int BirSinif.i N/A 16 8 double BirSinif.d N/A 24 4 float BirSinif.f N/A 28 2 char BirSinif.c N/A 30 1 boolean BirSinif.b N/A 31 1 byte BirSinif.bb N/A 32 4 String BirSinif.s N/A 36 4 JOLSample1 BirSinif.this$0 N/A Int görüldüğü gibi 4 byte genişliktedir ve 32 bit değerleri ihtiva edebilmektedir. Buna karşın double 8, float 4, char 2, boolean 1, byte 1 ve String 4 byte genişliktedir. Hepsini topladığımızda BirSinif sınıfından olan bir nesnenin hafızada kapladığı alan 40 byte büyüklüktedir. Bu yazımda Java nesnelerinin hafızadaki düzenlerine değindim. “JVM Nasıl Çalışır” başlıklı yeni yazı serisine JVM bünyesinde olup, bitenlere ışık tutmak için yeni blog yazılarımı yakında sizlerle paylaşacağım.
|
|
Blog Yazılarım Ekitabı Yeni Sürümü Posted: 04 Mar 2016 02:03 PM PST Blog Yazılarım isimli ekitabımın 4. sürümünü hazırladım. Bu link üzerinden ücretsiz edinebilirsiniz.
|
|
Posted: 26 Feb 2016 01:41 PM PST Yazılımda testlerin gerekliliğini ve hangi testlerin ne zaman uygulandığını açıklamak amacıyla şemsiye modeli ismini verdiğim bir model oluşturdum. Bu yazımda sizlerle bu modeli ve işlevini paylaşmak istiyorum. Şemsiyeler gerçek hayatta yağmurdan ve yer yer güneşten korunmak için kullanılır. Yazılım süreçleri için oluşturduğum şemsiye modelinde yazılım testleri uygulamayı korumak için açılan şemsiyeleri temsil etmektedir. Şemsiyenin büyüklüğüne ve işlevine göre uygulamayı hatalara karşı korumak ve sağlıklı bir şekilde gelişmesini sağlamak mümkündür. Şemsiye modelinde değişik büyüklükte şemsiyeler yer almaktadır. Açılan bir şemsiyenin kapsadığı bir alan mevcuttur. Bu alan şemsiyenin koruyabildiği alandır. Değişik test türleri değişik büyüklükte alanları koruyabilirler. Testleri olmayan bir uygulamayı şemsiye modeli ayazda ve yağmurda kalmış olarak tanımlar. Böyle bir uygulamanın akıbeti bellidir. Ayazda kalmış bir uygulamaya göz atarak başlayalım. Resim 1 de böyle bir uygulama görülmekte.
 Resim 1 Resim 1 de yer alan uygulamanın yağmurdan korunması yani hatasız olması ve kalabilmesi için hiçbir şemsiye açılmamış yani test oluşturulmamıştır. Böyle bir uygulamanın geliştirilmesi tamamen rus ruleti benzeri bir girişimdir. Testler olmadığı sürece yani bir veya daha fazla koruyucu şemsiye açılmadığı sürece bu uygulama su altında kalmak zorundadır. Projenin belli bir aşamasından sonra ekibin tek işi, su dolan teknenin batmasını engellemeye çalışmak olacaktır. Teknenin su dolmasını engelleyici bir mekanızma olmadığından, su tahliyesi bir şey ifade etmemektedir. Tekne er ya da geç batacaktır. Şimdi her türlü hava koşulunda uygulamayı istenilen hedefe taşımak için atılması gereken adımlardan bahsetmek istiyorum. Şemsiye modelinde değişik büyüklüklerde, uygulamanın belli bir kısmını ya da tümünü yağmurdan koruyacak türde şemsiyeler yani test türleri yer alıyor. Küçük şemsiyelerin kullanımı ve taşınmaları yani test türü olarak oluşturulmaları ve koşturulmaları kolay. Bu tür testler için gerekli yatırım düşük. Buna karşın kapsama alanları kısıtlı yani küçük şemsiyelerle uygulamanın tümümü korumak mümkün değil. Bu küçük şemsiyeleri bir araya getirip, uygulamanın her tarafını koruma altına almak da mümmkün değil, çünkü yapıları itibari ile bir araya getirilip, daha büyük bir şemsiye oluşturma kabiliyetine sahip değiller. Buna karşın şemsiye modelinde tüm uygulamayı ya da büyük bölümlerini koruma altına alabilecek daha büyük şemsiyeler de bulunmakta. Bu tür şemsiyeler çok büyük bir alanı koruyabiliyorlar. Lakin oluşturulmaları ve koşturulmaları zaman alıcı. Bu yüzden maliyetleri yüksek. Şemsiye modeli ile değişik büyüklükte şemsiyeler kombine edilerek, uygulanın tümünü koruma altına almak mümkün. Şimdi bu şemsiyeleri, nasıl kullanıldıklarını, oluşturulma maliyetlerini ve uygulamayı nasıl koruklarını yakından inceleyelim. Şemsiye modelindeki en küçük şemsiyeler birim testleridir. Birim testleri sadece bir kod birimi, bu bir metot, sınıf ya da modül olabilir, test etmek için kullanılırlar. Kod birimlerinin dışa bağımlılıkları mevcut olabilir. Birim testlerinde bu bağımlılıklar yok sayılır ve mock olarak isimlendirilen ve bağımlılıkları simüle eden kod birimleri ile yer değiştirilmeleri sağlanır. Bu şekilde sadece test edilen kod birimi bünyesinde olup, bitenleri test etmek mümkündür. Nihayi amaç kod biriminin bağımlılıkları olmadan nasıl davranış gösterdiğinin test edebilmesidir. Eğer teste test edilen kod biriminin bağımlılıkları da dahil olursa, test birim testi olmaktan çıkar ve bir entegrasyon testine dönüşür. Bu tür testlerin kullanımı da şemsiye modelinde yer almaktadır. Lakin birim testleri ile sadece işletme mantığı barındıran kod birimlerine konsantre olunur ve birim şemsiyesi açılarak belli bir kod birimi koruma altına alınır ve bağımlılıkları göz ardı edilir. Bu bağımlılıkların dolaylı olarak test edilmediği anlamına gelmektedir.  Resim 2 Resim 2 de birim şemsiyesinin işlevi görülmektedir. Bu örnekte D ismini taşıyan modül birim testleri ile koruma altına alınmıştır ve yağmur görmesi engellenmektedir. D ve diğer modüller arasında interaksiyon olduğunu düşünecek olursak, birim testleri ile bu interaksiyonu test etmediğimiz için D için açmış olduğumuz şemsiye sadece D bünyesindeki işleteme mantığını korur türdendir. Eğer interaksiyon içindeki modülleri tamamen koruma altına alacak büyüklükte bir şemsiyemiz yani testimiz yoksa, bu durumda uygulama entegrasyonun gerçekleştiği noktalarda yine yağmura mağruz kalacaktır, çünkü bu alanlar birim testleri ile test edilemez. Böyle bir şemsiyeyi bir entegrasyon testi yazarak, oluşturabiliriz. Resim 3 de bu yapıyı görmekteyiz.  Resim 3 Entegrasyon testlerinde birbirlerine bağımlı olan modüllerin davranışları test edilir. Örneğin müşteri bilgilerini edinmek için kullanılan CustomerDao ismindeki bir sınıfı test etmek için veri tabanına ihtiyaç duyulmaktadır. Birim testinde veri tabanı erişimi mock olarak implemente edilirken, entegrasyon testinde CustomerDao sınıfının erişebileceği bir veri tabanı oluşturulur ve bu iki modülün entegrasyonu test edilir. Birim testleri ile CustomerDao sınıfının entegre edilmiş bir sistemindeki işlevini test etmek mümkün değildir. Bu belirsizlik şemsiyenin büyüklüğünü ve kapsama alanını tayin etmektedir. Bu sebepten dolayı birim testleri ile tüm uygulamayı koruma altına almak mümkün değildir, çünkü birim testleri “gerçek olmayan bir ortamda” kabiliyetleri çerçevesinde izole edilmiş kod birimleriyle ilgilidirler. Gerçek bir ortamda bir veya daha fazla modülün birlikteliğini test etmek için entegrasyon testlerine ihtiyaç duyulmaktadır. Entegrasyon testleri gerçeğe yakın bir ortam oluşturubildiklerinden, kapsama alanları daha geniştir ve böylece uygulamanın daha geniş alanlarına hitap edebilirler. Resim 3 de entegrasyon şemsiyelerinin birim şemsiyelerine nazaran daha büyük ve ağır oldukları görülmektedir. Bu sebepten dolayı taşınmaları daha zordur. Bu entegrasyon testlerinin birim testlerine nazaran daha maliyetli oldukları ve koşturulmalarının daha zaman alıcı olduğu anlamına gelmektedir. Birim testlerinde de olduğu gibi sadece entegrasyon testleri ile tüm uygulamayı koruma altına almak mümkün değildir, çünkü entegrasyon testleri tüm sistem entegrasyonu yerine bazı modüllerin entegrasyonuna ağırlık vermektedirler. Tüm sistem entegre edilip, test edilmediği sürece, açılan şemsiyelerin altında yer alamayan kod birimleri mutlaka olacaktır ve daha büyük şemsiyeler açılmadığı sürece, bu kod birimleri ayazda kalacaktır. Bu sistem hatalarının var olacakları anlamına gelmektedir. Tüm uygulamayı kapsama alanına alabilecek kabiliyete sahip testler onay/kabul testleridir. Resim 4 de onay/kabul şemsiyesinin işlevi görülmektedir.  Resim 4 Onay/kabul testleri uygulamayı bir kara kutu olarak görürler ve onun kullanıcı perspektifinden test edilmesini mümkün kılarlar. Onay/kabul testleri kullanıcı ya da müşteri tarafından tanımlanan onay/kabul kriterlerini (acceptance criteria) baz alırlar ve programcılar tarafından implemente edilirler. Onay/kabul testleri ile bir uygulayı gerçek koşullarda en tepesinden en alt katmanına kadar entegre test etmek mümkündür. Topdown olarak isimlendirilen bu yaklaşım uygulamada kullanıcıların ihtiyaç duyduğu tüm uygulama davranışlarının test edilmesini mümkün kılmaktadır. Çalışır durumda olan onay/kabul testleri uygulamanın beklenen davranışı sergilediğinin kanıtıdır ve bu sebepten dolayı müşteri ya da kullanıcı tarafından uygulamanın onaylanmasını / kabul görmesini beraberinde getirir. Bir uygulamanın çalışır durumda olduğunun en iyi ispatı onay/kabul testlerinin varlığı ve çalışır durumda olmalarıdır. Onay/kabul testleri ile uygulamanın sahip olması gereken tüm davranış biçimleri test edilebilir. Lakin resim 4 de de görüldüğü gibi onay/kabul şemsiyenin büyüklüğü maliyetine işaret etmektedir. Bu tür testlerin implementasyonları karmaşık yapılarından dolayı zaman alıcı olabilir. Bu proje maliyetini artırıcı bir durumdur. Bunun yanı sıra onay/kabul testleri tüm sistem entegrasyonunu hedef aldıklarından, koşturulma zamanları buna orantılı olarak uzundur. Sadece onay/kabul testlerinin uygulanması bize tüm uygulamayı kapsayacak bir koruyucu şemsiyenin açılabileceği izlenimini vermekle birlikte, şemsiyenin büyüklüğünden doğan hantallık, projenin çevikliğini aksatacaktır. Buradaki yazımda da değindiğim gibi çeviklik yazılım testleri ile bir uygulamanın istenilen şekilde yoğrulması için gerekli ortamın oluşturulmasıdır. Uygulamayı yeni müşteri gereksinimleri doğrultusunda yeniden yapılandırabilmek için yapılan değişikliklerin sebep olduğu yan etkilerin lokalizasyonu için geribildirime ihtiyaç duyulmaktadır. Bu geribildirim ne kadar hızlı alınırsa, yeniden yapılandırma o oranda ivme kazanacaktır. Onay/kabul testleri bu tür geribildirim sağlama yetisine sahiplerken, koşturulma zamanları uzun olduğundan dolayı, hızlı bir şekilde geribildirim alıp, gerekli yeniden yapılandırma işlenimi seri halde gerçekleştirmek mümkün değildir. Bunun için daha hızlı geribildirim sağlayan bir mekanizmaya ihtiyac duyulmaktadır. Bu mekanizmanın ismi birim testleridir. Görüldüğü gibi tüm sistemi koruma altına almak ve bunun yanı sıra çeviklikten ödün vermemek için değişik türdeki testlerin kombine edilmesi gerekmektedir. Bir sonraki yazımda şemsiye modelinin nasıl implemente edilebileceğini bir örnek üzerinde sizlerle paylaşacağım. |
|
Kıymeti Bilinmeyen Eskimiş Bilginin Kıymeti Posted: 22 Jan 2016 10:18 AM PST Bilginin yarı ömrünün aylar seviyesinde ölçüldüğü bir çağdayız. Her şeyi çok hızlı tüketiyoruz. Bu bilgi için de istisnasız geçerli. Bu durumun en büyük mağdurlarından birisi yazılımcılar. Sürekli yeni bir şeyler öğrenmek zorundalar. Onlarca çatıya (framework) ve onların neredeyse her ay çıkan yeni sürümlerine hükmetmek hangi yazılımcıyı zorlamıyor ki. Zaman zaman bu konuda ipin ucunu kaçırmışlık hissinin oluşması da cabası, öyle değil mi? Yazılımda aslında bilgi bahsettiğim şekilde eskimiyor. Bu sadece subjektif bir algı. Bu yazımda bahsettiğim gibi değişen ya da gelişen sadece soyutluk seviyesi. Yaptığımız işin birkaç temel prensibi mevcut. Bugün yazılımda geldiğimiz soyutluk seviyesi bu birkaç temel prensibin üzerine inşa edilmiş durumda. Yeni çatıları ve onların sürümlerini kanser hücreleri gibi çoğaltan yazılımcının soyutlama ihtiyacı. Yazılımcılar herhangi yeni bir çatıyı öğreneceklerse, edindikleri kaynakların mevzubahis çatının en son sürümüne vakfedilmiş olmasına dikkat ederler. Eski sürümlerle ilgili kaynaklara itibar etmez, onları eskimiş olarak sınıflandırırlar. Ama burada ne yazık ki gözden kaçan bir nokta bulunmakta. Bu yazımda bu noktaya değinmek istiyorum. Eskimiş olarak tabir edilen bilginin içinde çok büyük hazineler yatıyor olabilir. Söz konusu yazılım ise, eskimiş bilgi yazılımın temellerini açıklayıcı türden olabilir. Ne demek istediğimi açıklamak için elektronikten bir örnek vermek istiyorum. Bugünkü modern mikro işlemcilerin temelinde dijital elektronik yatıyor. Dijital elektronik denince benim aklıma gelen TTL (transistor to transistor logic) bazlı AND ve NOR gibi mantık kapıları (gatter). Bu yazımda TTL bazlı mantık kapılarından yaptığım sayaç yer alıyor. Bu tür entegre devreler bundan elli, altmış sene önce yapılmış ve günümüzdeki modern mikro işlemcilerin temelini oluşturuyorlar. Bu mantık kapıları ile deneyler yapmış bir yazılımcıya bir programlama dilindeki &, |, &&, ||, ^ gibi operatörleri anlatmanıza gerek yok. Ne işe yaradıklarını ve nasıl kullanıldıklarını içgüsel olarak bilir, çünkü onları daha önce entegre devre olarak elinde tutmuştur. Bunun nasıl bir devlet olduğunu eline donanıma ait hiçbir parça almadan yazılımcı olma yolunda ilerleyen müstakbel programcılara baktığımızda anlayabiliyoruz. Bahsetmiş olduğum entegre devrelerle 8, 16 ya da 32 bitlik bir mikro işlemciyi kendiniz oluşturabilirsiniz. Buna ne gerek var diyebilirsiniz. Dijital elektronik ve mikro işlemcilerin temel çalışma prensiplerini kavramak için bunun yapılması şart. Aksi taktirde bu yazımda belirttiğim gibi mikro işlemcilerden bihaberlik söz konusu olucaktır. Mikro işlemcileri ve çalışma prensiplerini tanımayan bir yazılımcının ne kadar iyi kod yazdığı tartışılır. Günümüzdeki modern yazılımın ve donanımın temelini oluşturan ve transistör bazlı bu entegre devreleri anlatan güncel bir tane kitap bile bulamazsınız. Bu konularda muhtemelen en son kitaplar yetmişlerin sonunda yazıldı. Bu konuda ihtisas yapma istegim benden daha yaşlı kitapları edinmeme sebep oldu. Bugün hangi yazılımcının eline 1974 de yayımlanmış TTL cookbook kitabını verseniz, “bu ne, bunun 2016 sürümü yok mu” diye size soracaktır. İronik ama ne yazık ki gerçek: yazılımcı her daim bilginin en son sürümünü tüketme eğilimi gösteriyor. Bunun ne kadar fatal error olduğunu bu yazımda aktarmaya çalışacağım. Bu yazıyı kaleme alma fikri node.js öğrenmek için aldığım bir kitabı okurken oluştu. Kitap 2012 yılında yayımlanmış ve node.js in 0.8 sürümünü baz alıyor. Kitaptaki örnekleri uygulayabilmek için node.js sayfasına giderek, oradaki en güncel sürümü edinmem gerekti. Bir de ne göreyim, en güncel sürüm 5.5 versiyon numarasına sahip. Aradaki farka bakar mısınız! Yerimde kim olsa hemen o kitabı çöpe atıp, node.js 5 sürümünü inceleyen bir kitap alırdı, hatta hatta o kitabı almazdı. Bir ara kendimi güncel node.js kitaplarını araştırırken bulmadım değil. Bunun başlıca sebebi, en yeninin en iyi olduğunu düşünmemiz. Lakin ben node.js öğrenmeye bu kitapla devam ediyorum. Neden mi? Her çatının temelinde yatan bazı prensipler vardır. Bu Spring çatısında örneğin bağımlılıkların enjekte edilmesi ve bağımlılıklerın tersine çevrilmesi (DIP – Dependency Injection Principle) prensibidir. Bugün güncel bir Spring kitabı alın, bahsettiğim bu iki konunun derinlemesine incelenmediğini ya da bir, iki sayfada geçiştirildiğini göreceksiniz. Bunun yerine artık onlarca modülden oluşan bir Spring çatısının yüzlece sayfada ve onlarca örnekte nasıl konfigüre edildiğini okursunuz. Bu büyük bir buzdağının su üstünde kalmış küçücük bir kütlesi ile ilgilenmek ve derinde olup, bitenlerden bihaber olmaktan başka bir şey değildir. Günümüzüm bilimum bilişim kitapları bu buzdağının görünür kısmını incelerler, çünkü soyutlama dediğimiz şey o buz dağının en tepesine çıkma eğiliminden başka bir şey değildir. Oradan suyun altında olup, bitenler hakkında fikir yürütmek imkansızdır. Buzdağının nereye gideceğini tayin eden suyun altındaki kütlesidir, suyun üstünde kalmış şapkası değil. Şimdi node.js örneğine geri dönmek istiyorum. Node.js günümüzün en popüler çatılarından birisi. Kısa zamanda 5.5 sürümüne gelmiş olması bunun en güzel ispatı. Bugün node.js in 5.5 sürümünü anlatan bir kitap ile node.js öğrenmeye başlayan birisi, node.js in var olma nedeni olan temel prensipleri anlayamadan, node.js in ve ihtiva ettiği modüller içinde kaybolup, gidecektir. Sürüm versiyon numarası çatının hacmine işaret etmektedir. Hacim ne kadar büyükse, yazılımcının onun altında kalma ve ezime teklikesi o kadar büyüktür. Yazılımcı bu kütle altında kalmamak için ondan uzak durur. Sadece onu yüzeysel olarak anlar ve kullanır yani buz dağının tepesinden ona hükmetmeye çalışır. Buna karşın çatının ilk sürümlerini inceleyen bir kitap kendini olmayan bu hacme değil, çatının temelinde yatan ana prensiplere adayacaktır, çünkü işin başlangıcından temel prensiplerden başka anlatılabilecek bir mevzu yoktur. Bu şekilde çatının temelinde yatan temel prensipleri kavramak ve doğru yerde kullanmak mümkün olacaktır. Bu radikal bir fikir gibi görünüyor olabilir. Lakin soyutluk denen canavardan kurtulmak ve motor kapağı altında olup, bitenleri kavramak, daha iyi bir yazılımcı olabilmek için günümüz koşullarında artık zaruri hale geldi. Biraz daha geriden sarmak ve eski sürümlerden öğrenmeye başlamak zaman alıcı bir uğraş gibi görünebilir. Lakin bu yatırımın size yol ve su olarak geri döneceğinden emin olabilirsiniz “Neden Spring, JPA ve Diğer Çatılar ÖğrenilmeMEli” başlıklı bir yazım olmuştu. O yazımda da belirttiğim gibi “Teknolojiler gelip, geçicidir, felsefeler ise her zaman daim”.
|
|
Daha İyi Bir Programcı Olmak İçin Sınırlar Nasıl Zorlanmalı? Posted: 01 Jan 2016 06:14 AM PST Herhangi bir konuda daha iyi olabilmenin yolu, mevcut sınırları ve bariyerleri daha öteye taşımaktan geçer. Bu sınırlar fiziksel ya da manevi türde olabilir. Fiziksel sınırları ileriye taşımanın nasıl bir şey olduğunu ilk pist deneyimimde tekrar tecrübe etme fırsatım oldu. İlk piste çıkışımda, pisti dönme sürem 2 dakika 47 saniye ile benim için büyük bir şok oldu. Dördüncü günün son ayağında bu süreyi 2 dakika 0 saniyeye indirebildim. Dönme sürelerinin iyileşmesiyle birlikte motora ve piste olan hakimiyetimin de arttığını gözlemledim. Sürekli sınırları zorlamak hem acı verici hem de daha iyi olabilmek için verilen savaşın kazanılmasından dolayı zevkliydi. Fiziksel sınırlarımı bu denli zorlamış olmak ve kendi çapımda bu konuda başarılı olduğumu görmek, aklıma elde ettiğim tecrübe ve bilgileri diğer ilgi alanlarıma nasıl aktarabilirim sorunu getirdi. Bu yüzden bu blog yazısını yazıyorum. En büyük ilgi alanım programcılık. Peki programcılıkta sınırlarımı nasıl zorluyorum ya da zorlamalıyım? Aynı ekip içinde kısa bir zaman sonra herkesin kod yazma tarzı üç aşağı, beş yukarı aynı seviyeye gelir. Her yiğidin yoğurt yeme tarzı farklılık göstermekle birlikte, programcılar başkalarının kod yazma tarzlarını kopyalayarak, yaptıklarında onlara benzemeye başlarlar. Sonuç itibari ile kullanılan programlama dili programcının program yazarken kendisini ifade etme tarzını büyük oranda belirlediğinden dolayı, aynı ekip içinde yazılan kodlar birbirine benzemeye başlar. Bu şu anlama geliyor: “İstediğim kadar uğraşayım, programcı olarak bir zaman sonra motosiklet örnegindeki 2 dakika 0 saniyelik bariyerin altına inmem mümkün değil, yani programcı yetilerimi geliştiremiyorum, aynı seviyede kalıyorum.” Bunun başlıca nedeni, kullanılan programlama dilinin programcının düşünüş ve kendini ifade etme tarzını tayin etme gücüne sahip olmasında yatmaktadır. Bir programlama dilinin kod yazmak için sunduğu yapılar bellidir. Kod parçaları bu yapıların kombinasyonlarından oluşur. Durum böyle iken bu sınırlı sayıdaki kombinasyonlar en mükemmel hallerinde programcının er ya da geç en sade çözüme erişmesini, ama daha iyi bir kombinasyon mümkün olmadığından orada takılıp kalmasına sebebiyet verirler. Programcı kullandığı dilin sınırlarına dayanmıştır, daha iyisini yapması mümkün değildir. Bu aynı zamanda onun daha iyi bir programcı olabilmesi için önündeki en büyük engeli teşkil etmektedir. İki dakikada zor bela dönmeyi başardığım pisti, 1 dakika 36 saniyede dönen pilotlar var. Günlerce kendi dönüş zamanımı düzeltme çabası içindeyken, 1:36 lik bir zamanın nasıl mümkün olabildiği sorusunu sordum kendime. Son pist gününde 2:03 olan en iyi zamanımı 2:00 düşürmek için harcadığım eforu mantıklı bir şekilde açıklamam mümkün değil. Bu perspektiften bakıldığında 1:36 lık bir zaman erişilmez gibi görünüyor. Peki 1:36 lık bir zaman nasıl mümkündü? Kimine göre o pilotlar slick olarak isimlendirilen mucizevi tekerlere sahiptiler. Başkalarına göre kullandıkları motorlar çok hafifdi. Elli gram tasarruf yapabilmek için motorsikletlerin akülerini bile değiştirmişlerdi. Kullandıkları grenajlar karbondu. Bunun gibi birçok efsane dinledim. Bu spora yeni başlayan birisi olarak bana her türlü hikayeyi satabilirsiniz. Ama bildiğim bir şey var. Eğer teknik olarak 1:36 mümkün ise, oraya varmanın en az bir yolu mevcut. Oraya varmak için motorun üzerine binip, konvansiyonel yöntemlerle tur atmak hiçbir zaman yeterli olmayacak. Sürekli yeni şeylerin denenmesi, sürüş tarzının adapte edilmesi, bilen birilerine sorulması, yeniliklere açık olunması ve biraz da cesur olunması gerekecek. Bu yolda birçok şeyin harmanlanması 1:36 ya giden yolun inşası için zaruri. 1:36 lık zamana erişebilmek için motor sürmenin çok değişik boyutlarına inmek gerekiyor. Bunun programlamada karşılığı birden fazla programlama diline hakimiyet. Hani usta programcılar hep “yeni programlama dilleri öğrenin” tavsiyesini verirler ya… İşte bu öyle laf olsun diye verilmiş bir tavsiye degildir. Bir programcıya verilebilecek en iyi tavsiyedir o. İnsanların konuştukları diller ve programcıların kullandıkları programlama dilleri ortak bir özelliğe sahipler. Kullanılan dil kullanıcısının düşünüş ve kendisini ifade etme tarzını şekillendiriyor ya da sınırlıyor. George Orwell’in 1984 isimli romanında yöneticiler suni bir dilin kullanılmasını zorunlu kılıyorlar. “Yeni dil” ismini taşıyan bu dil kısıtlı bir kelime hazinesine sahip. Bu suni dilin ana amacı halkın kapsamlı ve sorgulayıcı düşünmesini engellemek. Halk örneğin baskıcı rejime karşı ayaklanamıyor, çünkü kullanılan dilin kelime hazinesinde böyle bir kelime yok. Her dilin dünyaya bakış açısı, edebiyata yatkınlığı, yeni kelimeler türetebilme kabiliyeti ve fonetiği değişik. Dil onu oluşturan insanların dünyayı nasıl algıladıklarının bir aynası. Birden fazla dil bilen insanların da dünyaya bakış açıları ve kendilerini ifade etme ve düşünme tarzları değişiklik gösterebilmekte. Aynı şey programlama dilleri için de geçerli. Tek bir programlama diline hakim olan bir programcının o dilde kendisini ifade etme şekli sınırlıdır. Bu sınırı ona kullandığı dil koymaktadır. Programcının kendisine programlama dili tarafından vurulan bu zinciri kırabilmesi için kelime hazinesini genişletmesi yani başka programlama dilleri ve konseptleri tanıması gerekmektedir. Sadece bu şekilde programcı problem çözerken dayandığı manevi sınırları aşabilir. Birçok programlama diline hakim programcılar geniş bir kelime hazinesine sahiptirler. Kullandıkları dilin sunduğu imkanlar yetmediginde, başka programlama dillerinden tanıdıkları konseptleri uygularlar. Bu onların hem daha iyi kod yazmalarını hem de sürekli kendilerini programcı olarak geliştirmelerini mümkün kılmaktadır. İki dil, iki insan sözü, iki programlama dili, iki programcı olarak da anlamını korumakta. Tek bir programlama dilinde iyi bir programci olmak mümkün. Lakin daha ilerisi için birden fazla programlama diline hakimiyet şart.
|
|
Karadelikler, Soyutluk ve Yazılım Posted: 04 Dec 2015 07:09 AM PST Günümüzde yazılım elli sene öncesi gibi if/else/while ile yapılsa da, en büyük farklılığı gelinen soyutluk seviyesi teşkil ediyor. Elli sene önceki gibi yazılımcılar artık mikro işlemcinin üzerinde işlem yapmıyorlar. Artık yazdıkları program parçaları mikro işlemcilerin anlayacağı dilden bile değiller. Bazı programcılar sadece sanal makinelar için (virtual machine) program yazar oldular. Yazılan kod mikro işlemcinin registerlerine düşene kadar beş, altı katmandan geçiyor. Bu yazılımda süre gelen soyutlamanın bir neticesi. Yazılımcılar soyutlayıp, bir üst katmana çıkarak, gidişatı daha kavranabilir ve yönetilebilir hale getirmeye çalışıyorlar. Bu bir nevi evrim. Yazılımda ilerleme sadece bu şekilde mümkün. Soyutlama yetisinin yazılımdaki yeri şüphesiz çok önemli. Bu olmadan günümüzün karmaşık uygulamalarını makina kodunda yazmamız mümkün olmazdı. Bu bir gereklilik. Lakin bu gerekliliğin karanlık bir tarafı da yok değil. Evrende hiçbir şeyi bedelini ödemeden, sürekli kendi çıkarınıza hizmet edecek şekilde kullanamassınız. Kazancın olduğu yerde, kayıpta olmak zorunda. Bu soyutlama mekanizmaları için de geçerli. Siz soyutladıkça işiniz kolaylaşır, lakin bunun bedeli olarak neyin nasıl çalıştığını, hangi temel prensiplere dayandığını bir zaman sonra kavramanız zorlaşır. Soyutlama işlemi bir nevi bilginin ziplenmesidir. Mevcut bilgi alınır, üzerine bir kulp takılır, bir başka kulp daha takılır, daha sonra bir kutuya konur, o kutu da başka bir kutuya konur, paketlenir, paketlenir ve daha büyük bir paketin yanına konur, bu paketlerden kocaman bir dağ oluşur. Birisi gelir ve bu dağı zipler, o kadar bilgiyi avuç içine sığacak bir paket içine sıkıştırır. Başka birisi gelerek, bu ziplenmiş pakete yeni bir kulp takar ve soyutlama döngüsü böyle devam eder gider. Bir karadelik düşünün. Bu karadeliğin bir iğne başı büyüklüğündeki bir parçası güneş sistemimizdeki tüm gezegenlerin kütlesine eşit ağırlıkta olabilir. Karadelik soyutlama işleminin karanlık tarafını gösteren güzel bir metafor. Soyutlama süreci yazılımda sürekli karadelikler doğurur, bilginin anlaşılamayacak şekilde sıkıştırılıp, yeni bilgiye dönüştürüldüğü karadelikler. İşte günümüzde yazılımcılar bu karadeliklerle savaş halindeler. Her yeni jenerasyon ile karadeliklerin kütleleri artıyor, çünkü soyutlama süreçleri onları devamlı besliyorlar. Bugün bu karadeliklerin iğne ucu kadar parçaları birkaç gezegen kütlesine eşitken, önümüzdeki on yıllarda bu iğne uçları galaksilerin kütlelerine eşit olacaklar. Bilgi arttıkça, soyutlama süreçleri bu bilgileri sıkıştırıp, yoğunlaştıracaklar. Hem bilgi artacak hem yazılımcının hayatındaki karadelikler hem de yazılımcının bilgisizliği. Artan bilgiyi verimli kullanmanın tek yolu soyutlamadan geçiyor. Bunun bedeli yazılımcı olarak nasıl çalıştıklarını tam olarak anlamadığımız araç, çatı ya da metotları kullanma zorunluluğu. Bu detay bilgi eksikliği oluşan sorunları daha kısa bir zamanda çözmemizin önündeki en büyük engel. Hem soyutlamayı çalışma verimimizi artırmak için işimize geldigi gibi kullanma isteğine sahip olmak hem de alt tarafta olup bitenleri kavrama sorumluluğunu reddetmek, birbiriyle uyuşmuyor. Kendi içimizde çelişkiye düşmemek adına bu ikisini bağdaştırmamız gerekiyor. Bunu nasıl yapabiliriz? Gerçek şu ki bilgi sürekli artacak. Bu sebepten dolayı mantıklı bir çerçevede kullanılabilmesi için soyutlanması gerekiyor. Soyutlama süreçlerinin sonucu her zaman yoğunlaştırılmış bilgidir. Bu yoğunluk bir karadeliğin ufacık bir parçasına galaksi boyu yıldız ve gezegenlerin sığması seviyesinde olabilir. Bu yoğunluktaki bir bilgiyi kullanarak, istediğimiz bir neticeyi elde edebiliriz, ama ne olduğunu anlamayabiliriz. Ne olduğunu anlamak için bilginin içine değil, temeline göz atmamız gerekiyor. Bilginin içine girdiğimiz zaman detaylar içinde kaybolabiliriz. Temelini incelediğimiz zaman, onu kavramamız daha kolaylaşacaktır. Soyutlamanın yan etkilerinden korunmanın, yoğunlaştırılmış bilginin temelinde yatan prensipleri anlamakla mümkün olduğunu düşünüyorum. Temelde yatan prensipleri anladığımız taktirde, bilginin nasıl kullanıldığını değil, aynı zamanda neden kullanıldığını da anlayabiliriz. Neden sorusuna cevap verebildiğimiz taktirde, bilginin doğru yerde ve doğru şekilde kullanılması mümkün hale gelmektedir. Bu yazım yazılımda temel prensipleri anlatmaya çalışacak bir yazı serisinin başlangıcını teşkil ediyor. Bu yazı serisi “Temelinde Yatan Prensipler” başlığı altında değişik konulara ışık tutmaya çalışacak. Bu serinin ilk yazısı “Mikroservis Mimarilerinin Temelinde Yatan Prensipler” başlığını taşıyor. Bu yazıyı yakında beğeninize sunacağım.
|
|
Posted: 26 Nov 2015 07:07 AM PST Gitolite sunucu üzerinde bulunan Git depolarına (repository) erişimi kontrol etmek için kullanılan bir ara katman. Gitolite ile kullanıcılara SSH protokolü aracılığı ile depo bazında okuma ve yazma hakları tanımak mümkün. Bu yazımda Gitolite kurulumu ve depo erişim haklarının nasıl tanımlandığını örnekler üzerinde göstermek istiyorum. Geolite kurulumuna başlamadan önce Git sunucusu olacak bilgisayar üzerinde git isminde bir sistem kullanıcısı oluşturmamız gerekiyor. $ adduser -r git Root olarak login yaptığımız sunucuda git isimli kullanıcıyı oluşturduktan sonra, Gitolite kurulum işlemine başlayabiliriz. $ su - git $ mkdir -p ~/bin $ git clone git://github.com/sitaramc/gitolite $ gitolite/install -ln ~/bin $ gitolite setup -pk gitadmin.pub Gitolite kurulumunu yapabilmek için gitadmin.pub isminde bir public anahtara ihtiyacımız var. Bu anahtarı şu şekilde oluşturabiliriz (Bu işlemi Git sunucusu üzerinde ya da başka başka bir bilgisayarda yapabilirsiniz. Git Bash bünyesinde de ssh-keygen komutu mevcut, yani Windows altında bile bu anahtar çiftini oluşturabilirsiniz): $ ssh-keygen -t rsa -f gitadmin Bu işlemin ardından aşağıdaki anahtar çifti oluşmuş olur: $ ls -l total 5 -rw-r--r-- 1 oezcanac Administ 1679 Nov 26 12:03 gitadmin -rw-r--r-- 1 oezcanac Administ 402 Nov 26 12:03 gitadmin.pub gitadmin private yani gizli ve kullanıcıda kalması gereken, gitadmin.pub public yani herkesin görebileceği açık anahtar parçasıdır. Gitolite kurulumunu public anahtar ile yapmamız gerekiyor. Gitolite kurulumunu gerçekleştirdikten sonra, dizin yapısı aşağidaki şekilde olacaktır: $ ls -l drwxrwxr-x. 2 git git 4096 Nov 26 11:13 bin -rw-r--r--. 1 git git 402 Nov 26 11:09 gitadmin.pub drwxrwxr-x. 6 git git 4096 Nov 26 11:12 gitolite -rw-------. 1 git git 0 Nov 26 13:09 projects.list drwx------. 5 git git 4096 Nov 26 12:07 repositories repositories dizininde git depoları bulunmaktadır. Başlangıçta Gitolite aşağıdaki depoları oluşturur: ls -l total 12 drwx------. 8 git git 4096 Nov 26 13:09 gitolite-admin.git drwx------. 7 git git 4096 Nov 26 12:13 testing.git Gitolite kullanıcı erişim haklarını gitolite-admin.git ismini taşıyan Git deposu üzerinden yönetmektedir. Git depolarına erişim hakkı tanımak istediğimiz kullanıcıların public anahtarlarını bu depoya eklememiz gerekiyor. Bu amaçla önce bu depoyu klonlamamız gerekiyor. Şu şekilde yapıyoruz: git clone git@gitsunucusu:gitolite-admin Bu şekilde gitolite-admin deposunu klonlamak istedigimde, git SSH protokolünü kullanmaktadır. Klonlama işlemini kendi desktop bilgisayarım üzerinde yapıyorum. Gitolite ve Git depolarının bulunduğu sunucu gitsunucusu ismine ve 192.168.1.10 ip adresine sahip. Kendi bilgisayarımdan Git sunucusuna bağlanabilmem için Gitolite kurulumunu yaparken kullandığım anahtarın gizli olan private anahtar parçasını kullanmak gerekiyor. Sadece bu anahtar yardımıyla gitolite-admin deposunu klonlayabilirim, çünkü sadece bu anahtarın gitolite-admin deposuna erişim hakkı var. Şimdi oluşturduğum ve kullandığım anahtar çiftinin nasıl olduğunu tekrar hatırlayalım: $ ls -l total 5 -rw-r--r-- 1 oezcanac Administ 1679 Nov 26 12:03 gitadmin -rw-r--r-- 1 oezcanac Administ 402 Nov 26 12:03 gitadmin.pub Gizli olan gitadmin anahtarını OpenSSH formatına dönüştürmem gerekiyor. Bunu puttygen.exe ile yapabilirim:
Bu amaçla Load butonuna tıklayarak, gizli olan anahtar parçasını yüklüyorum. Akabinde Export OpenSSH key menüsüyle dönüşümü gerçekleştiriyorum.
Yeni anahtarın id_rsa ismi altında C:\Users\kullanici-ismi\.ssh dizinine yerleştirilmesi gerekiyor. Klonlama işleminde SSH protokolü ile sunucuya bağlanıldığında, ssh.exe bu dizinde olan id_rsa anahtarını kullanacaktır. Bir şeyi daha kontrol etmemiz gerekiyor. Klonlama işlemini gerçekleştirdiğimiz bilgisayar ile Gitolite sunucusunun aynı SSH implementasyonunu kullanmaları gerekiyor. Bu benim örneğimde OpenSSH. Yerel bilgisayarda hangi ssh implementasyonun kullanıldığını şu şekilde bulabiliriz. where ssh C:\ProgramFiles\Git\bin\ssh.exe Peki Git klonlama işleminde hangi SSH implementasyonunu kullanıyor? set GIT_SSH GIT_SSH=C:\Program Files\TortoiseSVN\bin\TortoisePlink.exe Git’in kullandığı SSH implementasyonunu tayin etmek için GIT_SSH isminde bir çevre değişkeninin tanımlanmış olması gerekiyor. Yukarıdaki örnekte Tortoise Git client ile gelen ssh implementasyonunu kullanmaktayım. Bu sunucu bağlantılarında sorun oluşturdu, çünkü kullanıcı ve sunucu SSH implementasyonları uyumlu değil. Bu yüzden GIT_SSH parametresinin içeriğini şu şekilde değiştirdim: set GIT_SSH=C:\ProgramFiles\Git\bin\ssh.exe Bunun ardından klonlama işlemini şu şekilde gerçekleştirebiliriz: git clone git@gitsunucusu:gitolite-admin Bu işlemin hangi safhalardan oluştuğunu tekrar özetleyelim:
Klonlama işlemi gerçekleştikten sonra yeni kullanıcı ve kullanıcı hakları tanımlayabiliriz. Bunun nasıl yapıldığını şimdi bir örnek üzerinde inceleyelim. Gitolite bünyesinde pratikprogramci.git isminde yeni bir depo oluşturmak istediğimizi düşünelim. Bu depo için user1 isimli kullanıcıya okuma ve yazma hakları tanıyacağız. Önce Gitolite sunucusunda yeni depoyu oluşturuyoruz: $ su -l git $ pwd $ /home/git $ cd repositories $ mkdir pratikprogramci.git $ cd pratikprogramc.git $ git init --bare En son komutu yalın (bare) bir Git deposu oluşturmak için kullandım. Sunucu üzerinde gerekli Git deposunu oluşturmus olduk. Şimdi user1 ismini taşıyan kullanıcı için gerekli anahtar çiftini oluşturalım: $ ssh-keygen -t rsa -f user1 ssh-keygen Git Bash ile kullanılabilecek olan bir komut. Ayrıca puttygen.exe ile bu anahtar çiftini oluşturmak mümkün. Oluşan anahtar çifti aşağıdaki şekilde: $ ls -l -rw-r--r--. 1 git git 402 Nov 26 11:09 user1 -rw-r--r--. 1 git git 402 Nov 26 11:09 user1.pub gitolite-admin deposunu daha önce klonlamıştık. user1.pub dosyasını bu depada yer alan keydir dizinine kopyalıyoruz. Ayrıca user1 isimli kullanıcının pratikprogramci.git dizine olan erişim haklarını gitolite-admin/conf/gitolite.conf dosyasında şu şekilde tanımlıyoruz:
repo gitolite-admin
RW+ = gitadmin
repo pratikprogramci
RW+ = user1
Şimdi yaptığımız değişiklieri commitleyerek, yeni kullanıcı için gerekli işlemleri tamamlayalım. $ git add --all $ git commit -m "user user1 added" $ git push Push işlemi esnasında Gitolite gitolite-admin/keydir/ dizine koyduğumuz user1.pub dosyasını alarak (Git bünyesinde bu bir hook ile yapılmaktadır), içeriğini /home/git/.ssh/authorized_keys dosyasına eklemektedir. Sadece bu durumda ssh ile sunucuya bağlanmak isteyen bir kullanıcının sunucuya erişebilmesi mümkündür. Kullanıcının gizli anahtarı ile şifrelenmiş olan bilgiler sunucu tarafından kullanıcının public anahtarı kullanılarak doğrulanmaktadır. Böylece user1 isimli kullanıcıyı pratikprogramci.git isimli depoyu klonlayabilir hale getirmiş olduk. Şimdi user1 bu depoyu şu şekilde klonlayabilir: git clone git@gitsunucusu:pratikprogramci Bu işlemin gerçekleşebilmesi için user1 isimli kullanıcının sahip olduğu id_rsa dosyasının .ssh dizinine kopyalanması gerekiyor. Bu dosyayı OpenSSH formatında puttygen.exe ve kullanıcının gizli anahtarı yardımıyla oluşturabiliriz. Eğer user1 aşağıdaki klonlama işlemini gerçekleştirseydi, hata alırdı, çünkü bu kullanıcının gitolite-admin isimli depoya erişim hakkı bulunmamaktadir git clone git@gitsunucusu:gitolite-admin Eğer Git kullanımı ilginizi çekiyorsa, Pratik Git isimli kitabıma bir göz atmanızı tavsiye edebilirim.
|
|
Paralel Evrenlerin Programcıları Posted: 20 Oct 2015 07:04 AM PDT Bir önceki yazımda frontend ve backend programcılığı arasındaki ayrımın kalkacağından bahsetmiştim. Kendi programcılık kariyerim için bu yazımı bir dönüm noktası olarak görüyorum. Yirmi birinci yüzyılın yazılımcılığında bir dönüm noktasına gelmiş bulunuyoruz. Bu yazımda bunun sebebi açıklamaya çalışağım. Java’nın ilk günlerinden beri programcı olarak bu dille ekmek paramı kazanıyorum. Son on beş yılda birçok Java çatısı (framework) ile çalıştım. Kendimi daha çok backend tarafında gören bir yazılımcıydım ta ki yukarıda linkini verdiğim yazıyı yazana kadar. Bir backend yazılımcısı değil, kendi programcı evreninde yaşayan bir programcıymışım ve paralel programcı evrenlerinin farkında bile değilmişim. Ne oldu da birden yazılımcı evreninin merkezinde olmadığımı, başka evrenlerinde var olduğunu keşfettim? Anlatmaya çalışayım. Ağaçlara bakmaktan ormanı göremez hale gelmişiz… Yıllardır o çatı senin, bu çatı benim diye yazılım yapıyoruz. Bugün bir kurumsal projeye göz atın, içinde en az on beş tane çatı bulabilirsiniz. Artık çatı olmadan yazılım yapılamıyor. Ne yazık ki geldiğimiz durum bu. Çatı yok, proje yok! Bundan daha vahim bir durum olabilir mi? Ne yedügü belirsiz bir ton kodu projene çekiyorsun ve onların üzerine birşeyler inşa etmeye çalışıyorsun. Hasbelkader çalışıyor! Çoğu zaman çalışmıyor, neden çalışmıyor diye kafandaki saçları yoluyorsun. Çatı kullanımı teknik borçlanma türevlerinden birisidir, er ya da geç tasarlanmadığı bir senaryo ile karşılaşıldığında, workaroundlar kaçınılmazdır. Her workaround bir teknik borçtur. Neyse, konumuzdan fazla sapmayalım… Ben çatılarla büyümüş bir yazılımcı jenerasyonuna dahilim. Kullandığım diller statik veri tipli ve derlenen diller. Kendimi en çok böyle dillerde güvende hissediyorum. Yazdığım kod bana daha bi deterministik geliyor. Neden derleyici varken bir değişkene doğru veri tipinde bir değer atadım mı diye kendim kontrol edeyim ki! Ne gerek var… Yazdığım kodun derlenmesi için belli bir zamana ihtiyacım var. Bunun üzerine çatıların çalışma şekilleri, konfigürasyonları ve kodumu test etmek için çalışır hale getirirken geçen zaman eklenince, en ufak bir değişikliğin bile derlenen dillerde ne kadar büyük zaman kaybına açabileceğini düşünebilirsiniz. İki binli yılların başında EJB (Enterprise Java Bean) uygulamalarını çalışır hale getirmek için onlarca dakika beklemek zorunda kaldığım günleri unutmadım. Bunları neden yazıyorum? Çalıştığımız projelerde artık sorgulamadan belli kalıpları takip eder olmuşuz. Yeni bir proje mi var, hemen Spring, Hibernate, o çatı, bu çatı… Bu kalıpların dışına çıkamıyoruz, hep aynı şekilde hareket ediyoruz, çünkü içinde bulunduğumuz evren bu araçlardan oluşuyor. Hep bunlarla çalışmışız, bir mazohist gibi acı çekmeye alışmışız, ama onlardan vazgeçmemiz söz konusu bile olamaz, öyle değil mi? Tipik bir Spring uygulamasını alın. Basit bir konfigürasyon yapacağım derseniz, elli dereden su getirmek gerekiyor. Peki Spring nasıl oluştu? Spring’in tek varoluş nedeni, Java EJB teknolojisinin çok hantal olmasıydı. Spring çatısını geliştirenler ortaya çıktılar ve “arkadaşlar bırakın şu saçma, sapan EJB, MJB leri, bizde uygulama sunucusu olmadan bile çalışabilen yeni bir çatı var, yazılım yapma hızınızı çok artıracak, bu çatıyı lütfen deneyin” dediler. Bizde sazan gibi atladık, çünkü başka bir alternatif yoktu. Daha hızlı yazılım yapma iddasi ile ortaya çıkmış olan bu çatıya şimdi bir bakın. Ne hallere gelmiş durumda! Grails bünyesindeki spring/resources.groovy içinde Spring Bean DSL bazlı bir cronjob tanımlaması ihtiyacı duyan bir task için bir saat konfigürasyonla ugraşmak zorunda kaldım. “Aga böyle olmadı” deyip, durdu Grails sunucusu. Kafayı sıyırtacak seviyeye getirdi kısacası. Şu içine düştüğümüz duruma bir bakın hele. Bize vaad edilen hızlı yazılım geliştirme araç, gereçleri idi. Bir çatının asıl vazifesi, programcısını angaryadan kurtarmaktır. Kullandığımız çatılar angaryadan kurtarmıyor değiller. Ama oradan kazandığımız zamanı uygulamaları çalışır hale getireceğiz, kodu derleyeceğiz, konfigüre edecegiz diye harcıyoruz. Hızlı yazılım geliştirmek için yanlış araçları kullanıyoruz. Bu cümbüşün içinde birileri gelip “AngularJS, NodeJS gibi teknolojileri denesenize abi, çok daha hızlı uygulama geliştirirsiniz” diyor. Bıyık altından pis, pis gülüyoruz. “O da neymiş yahuuu, biz burada çok ciddi enterprise, menterprise teknolojileri ile uygulama geliştiriyoruz” diyoruz. Yalan mı? Ama o da ne, paralel bir evren mi gelişiyor orada yoksa! Bak, bak hele… bize hiç haber etmemişler. NodeJS de neymiş ki? Adam bize neden haber etsin ki. Bir defa senin gibi teknoloji içine çakılıp, kalmamış. Tek derdi hızlı bir şekilde müşteri isteğini koda döküp, çalışır hale getirmek. Senin gibi teknoloji fanatiği değil. İki nokta arasındaki mesafenin bir çizgi olduğunu biliyor. Bizim gibi iki noktayı otuz beş köşe üzerinden birleştirmiyor. He mi gelip sana anlattığında, nazarı dikkate alacak mısın? Almayacağının en büyük nedenini söyleyeyim mi? Kullandığın araçlar ve teknolojilerin üstünlüğüne inanmışsın. Başkaları daha ileri teknolojiler oluşturuyor ya da kullanıyor olamaz! Burada sen diye hitap ettiğim kendi şahsımdır, üzerinize alınmayın. Bir tarafta köklü ve gelenekli proje geliştirme yöntem ve teknolojileri, diğer tarafta hızlı ürün geliştirmek için oluşmaya başlayan teknolojiler. Bir tarafta teknolojiden gözü körleşmiş yazılımcılar, diğer tarafta yazılımın daha kolay yapılabileceğine inanan ve ihtiyaç duydukları araçları oluşturan yazılımcılar. Bir tarafta backend, frontend ayrılmalı diyen yazılımcılar, diğer tarafta aynı teknoloji ile backend ide yazarım diyen pragmatik frontend yazılımcıları. İki ayrı evren… Ne vahim durumda olduğumuzu gösterir başka bir örnek vermek istiyorum. IBM mainframe üzerinde çalışan Cobol programcılarına neden kolay kolay nesneye yönelik programlama tekniklerinin öğretilemeyeceğine değinelim. Cobol dilinde funksiyonlar bile yok. Cobol programcısının network ya da desktop tecrübesi yoktur ya da çok azdır. Cobol programları structured programming teknikleri ile yazılır. Bir Cobol programcısı işletme mantığı dendiğinge gözünde birçok şeyi canlandırabilirken, kalıtım, o, bu demeye başlandığında, söylenenler bir kulagından girer, diğer kulağından çıkar, çünkü görüş alanında son otuz yıldır kullandığı teknikler, yöntemler ve teknolojiler vardır, OOP yoktur. Kurumsal projelerde çalışan biz yazılımcılar da aynı duruma düşmüş durumdayız. Birileri bize gelip, olup, bitenlerden bahsetmeye çalışıyor, lakin bunlar bir kulağımızda giriyor, diğer kulağımızdan çıkıyor, çünkü gidişatı kavrayamıyoruz, sadece kullandığımız çatılara odaklanmış durumdayız. Ağaçlara bakmaktan, ormanı göremiyoruz. Sadece bir evrenin olabileceğine inanıyoruz. Paralel evrenlerin farkında değiliz. Ama içinde yaşadığımız evren yok olma tehlikesi altında. Biz kendi evrenimizde frontend, backend programcılığının ayrımını tartışa duralım, fullstack developer bize çok radikal bir fikir gibi gelsin, her şeyi çatıların üzerine inşa etmeye devam edelim, oluşmakta olan paralel evrende adamlar hızlı yazılım geliştirme filozofisini frontend den alıp, backende taşımak üzereler. Bizim 5 günde yaptığımız işi 2 saat içinde yapacak seviyeye geldiklerinde, bizim evrendeki işsizlik oranı çok yükselecek gibi. Maksadım içinize korku salmak değildi. Sadece yorumlamaya çalışmaya çalıştığım gidişati sizlerle paylaşmaya çalışıyorum. Daha önce kendisine gönderilen iş ilanlarında Javascript ibaresini gördüğünde burun kıvıran bir yazılımcı olarak, kafamızı kaldırıp, etrafımızda olup, bitenleri takip etmemiz, onlara kulak vermemiz gerektiği düşüncesindeyim. NodeJS, AngularJS, BackboneJS ve ReactJS yolculuğun nereye gittiğine işaret ediyorlar. Daha şimdiden bizim bildiğimiz backend teknolojilerine gerek kalmadan Javascript ile katmanlı mimariler oluşturmak mümkün. Javascript artık öğrenilmesi mecburi bir dil haline geldi. Javascript oluşmakta olan paralel evrenlerin sadece bir tanesinde kullanılan bir dil. Daha böyle birçok paralel evren oluşmadığı ne malum.
|
| You are subscribed to email updates from Pratik Programcı Yayınları. To stop receiving these emails, you may unsubscribe now. |
Email delivery powered by Google |
| Google Inc., 1600 Amphitheatre Parkway, Mountain View, CA 94043, United States | |
KurumsalJava.com – Özcan Acar
- Neden Frontend ve Backend Programcısı Tarihe Karışıyor
- Bir Sonraki Pratik Programcı Yayınları Kitabı
- Yazılımcıların Performansı Nasıl Ölçülür?
- Nasıl Usta Programcı Olunurmuş
- Programcıların Besleyip, Büyüttükleri Canavar
- Yeni Çalışma Masam ve Kitaplığım
- Yazılımcı Olarak Daha İyi ve Usta Olmak Mecburiyetindesiniz
- Merkezi Versiyon Yönetim Sistemlerinde Sürüm Almak İçin İş Akışı Nasıl Şekillendirilir?
- Programcının Evrimi
- Kod Kalitesi Denince Akla Gelenler
- Public/Private Anahtar İkilisi İle Git Repository Erişimi
- 2015 Yılına Geldik, Hala Spring’le Birlikte İnterface sınıf mı Kullanmak Zorundayız?
- JavaOne 2015 İçin Sunum Önerim
- Eclipse Altında Birim ve Entegrasyon Testleri Nasıl Ayrı Koşturulur?
- Kod Redaktörlügü
- Yazılımda Otopilot
- 20 Yaş, 30 Yaş, 35 Yaş ve Bugünki Programcı Ben
- JVM Nasıl Çalışır Yazı Serisi – JVM Stack Nedir ve Nasıl Çalışır?
- JVM Nasıl Çalışır Yazı Serisi – Java Dilinde Neden Göstergeçler (Pointer) Yok?
- Neden Kafam Bu Kadar Rahat?
- Versiyon ve Sürüm Numaraları Nasıl Oluşturulur?
- Hangi Programlama Dilini Öğrenmeliyim?
- Java Şampiyonluğu Nedir ve Nasıl Olunur?
- Kokan Kod – 1. Bölüm
- JVM Nasıl Çalışır Yazı Serisi – Çalışan Bir Java Uygulamasında Bytekod Nasıl Değiştirilir?
- Bilişim Sohbetleri
- Teknik Borç Nedir ve Nasıl Ödenir?
- Başkalarının Kodu Okunarak Daha İyi Programcı Olunabilir mi?
- JVM Nasıl Çalışır Yazı Serisi – Java String Nesnelerinin Hafıza Kullanımı Nasıl Azaltılır?
- Çok Gezen mi Bilir, Çok Okuyan mı?
- Yazılımda Geviş Getirme Taktiği Nasıl Uygulanır?
- Yazılımcılığın Ne Olduğunu Anlamamış Bilgisayar Mühendisi
- Başlama ve Bitirme Kriterleri
- 5 Adımda Daha Kaliteli Yazılım Testleri
- Müşteri Gereksinimlerini Anladığımızdan Nasıl Emin Olabiliriz?
- Programcının Hayatını Kolaylaştıran 18 Alışkanlık
- Birim Testlerinde Beklentilerimi Daha Net Nasıl İfade Edebilirim?
- Sözde Lean!
- En Basit Çözümü Oluşturma Yetisi Nasıl Kazanılır?
- Yeni kitabım Pratik Agile
- Dağın Ayağına Gelmesini Bekleyen Birisi
- Standart Java API’ler Neden Tercih Edilmeli?
- Java’ya Nereden Başlamalıyım?
- Ne Zaman Test Güdümlü Yazılım Yapmalıyım?
- java.lang.IncompatibleClassChangeError: Implementing class Nedir ve Analizi Nasıl Yapılır?
- 500 Beygir Gücünün Hazin Sonu
- Ne Zaman Başımız Göğe Erer?
- Türkiye Yazılımcı Raporu 2013
- Spring 3.x İle Gelen Yenilikler
- Agile Türleri
- Spring’in Varoluş Nedeni
- Yazılımcının Verimliliğini Artıran Eclipse Ayarları
- Spring Çatısının Yazılım Geliştirme Filozofisi
- Yeni Kitabım Pratik Spring
- Kitap Okumanın Önemi
- Spring Core Sertifika Sınavı Ardından
- KurumsalJava.com Kitabı
- Yazılımcı Anketi 2013
- JVM Nasıl Çalışır Yazı Serisi – Java Hotspot, Assembly Kod, Hafıza Bariyerleri ve Volatile Analizi
- İlk DevelopersTube Söyleşisi
- Mikrodevre.com
- Koddan Korkan Programcı
- Alışkanlıkların Gücü
- Kim Senior Programcıdır?
- Açık Kaynağa Destek
- SpringSource Certified Integration Specialist Sertifikası
- TeletAPI’nin API’si
- Bir Java’cının Gözünden Ruby
- Alet İşler, El Övünür
- Cahilliğime Verin
- Açık Sözlü Programcı
- Java Generics Get ve Put Prensibi
- Programcılık Çıtası Yükseliyor
- Organizasyonel Değişim
- Türkiye Yazılımcı Raporu 2012
- Neden Fonksiyonel Programlamayı Öğrenmek Zorundayız
- Nasıl Arkadaş Kazanır ve Diğer İnsanları Etkilersiniz
- Ayakta Alkışlıyorum
- Kurumsal Java RSS Adresi
- Copy/Paste Programcı
- Test Edebilme Uğruna Her Şey Mübahtır!
- Deneme Yanılmanın Bedeli
- Uzaktan Eşli Programlama
- Veresiye Satan Yazılımcı
- Uzman ve Usta Yazılımcı Arasındaki Fark
- İzci kuralı
- Sorumluluk Sahibi Olmak
- Böyle Girişimcilik Olmaz!
- Göz Boyamaca
- Acı Çekmeden Üstad Olunmaz
- Detayları Görebilmek Ya Da Görememek
- Yazılımda Çeviklik İflas mı Etti?
- Gezen Defterin Hikayesini Biliyor musunuz?
- Kataların Eşli Programlanması
- Yazılımcı Anketi 2012
- Kişisel Gelişim
- Bilgisayar Mühendisi mi, Yazılım Mühendisi mi?
- Kod A.Ş. – Kod Anonim Şirketi
- KodKata.com
- Java’da Bilinmeyenler
- Bugün Neler Ögrendim?
- Kataların Anası
- Ultra Lüks
- Neden Her Programcının Bir Blog Sayfası Olmalı?
- Benlik Güden Programcılar
- Melek Programcılar ve Şeytan Yatırımcılar
- Neden Java Kullanıyorsunuz Sorusunu Sorulduğunda Hangi Cevabı Verirsiniz?
- JVM Nasıl Çalışır Yazı Serisi – Old Generation Parallel Garbage Collector Hatası
- Yeni Bir Programlama Dilini Öğrenmenin En Kolay Yolu
- JVM Nasıl Çalışır Yazı Serisi – Çöplerin Efendisi
- Mantığın Köleleri
- Java Heap Nedir?
- JVM (Java Virtual Machine) Nedir?
- Matrix’de Yaşayan Programcılar
- Meğer Neymişiz!
- Programcıyım, Yönetici Değil!
- Programcılık Sanat mı, Zanaat mı?
- Ekibin Dikkati ve Saygısı Nasıl Kazanılır?
- Eşli Programlama, Code Review, Code Retreat ve Adada Yaşayan Programcılar
- İnşaat ve Yazılım Mühendisleri Arasındaki Fark
- Battı Balık Yan Gider
- Kod Kata ve Pratik Yapmanın Önemi
- Çevikliğin Böylesi
- Programcılar yazar olsalardı keşke!
- SOLID
- Parametrik Konstruktör (Parameterize Constructor)
- Metot Düzenleme (Compose Method)
- Yeni Sınıf Oluşturma (Extract Class)
- Stable Abstractions Principle (SAP) – Stabil Soyutluk Prensibi
- Stable Dependencies Principle (SDP) – Stabil Bağımlılıklar Prensibi
- Acyclic Dependency Principle (ADP) – Çevrimsiz Bağımlılık Prensibi
- Common Closure Principle (CCP) – Ortak Kapama Prensibi
- Koşullu Mantığın Komut İle Değiştirilmesi (Replace Conditional Dispatcher With Command)
- Metodu Metot Nesnesine Dönüştürme (Replace Method with Method Object)
- Refactoring Oturumu (Video)
- Geçici Değişkenlerin Sorguya Dönüştürülmesi (Replace Temp with Query)
- Parametrele Değer Atamasının Kaldırılması (Remove Assignments to Parameters)
- Yeni Metot Oluşturma (Extract Method)
- Koşulları Parçalarına Ayırma (Reverse Conditional)
- IDL Compiler
- Tek Kelimeyle Harika!
- Subclipse Şifresi
- Yazılım Maketleri
- Credit Suisse – Zürich
- Corebanking Next Generation
- Maven2 ve OutOfMemory
- İlk Program Bug’ı
- Kim Daha İyi Programcı?
- Common Reuse Principle (CRP) – Ortak Yeniden Kullanım Prensibi
- Decorator Tasarım Şablonu
- K.Maraş Sütçü İmam Üni. – Bilge Programcı – Nasıl Uzman Yazılımcı Olunur ?
- Java Compiler Versiyonu
- Bilge Programcı – Nasıl Uzman Yazılımcı Olunur? Seminerinden İzlenimler
- Yeni KurumsalJava Seminerleri
- Java İle Yazılımı Kavramak
- Java JVM’i (Java Virtual Machine) Anlamak
- Java Dilini Kavramak
- Java’da Finalizer Metodu
- Java’da Final Anahtar Kelimesi
- Covariant Return Types
- Java Enum ile Singleton Tasarım Şablonu
- Oracle’ın Sun ve Java için stratejik planları hakkında ip uçları
- DBUnit JUnit Entegrasyonu
- HSQLDB ve JUnit Entegrasyonu
- SCEA 5 (Sun Certified Enterprise Architect) Kiti
- SCEA 5 (Sun Certified Enterprise Architect)
- Türkiye’den İlk Java Champion Özcan Acar
- Write Through Cache
- Kreditwerk Wohnrente Projesi
- Intercepting Filter Tasarım Şablonu
- Reuse-Release Equivalence Principle (REP) – Tekrar Kullanım ve Sürüm Eşitliği
- JPA Anotasyonları ve Dinamik Tablo İsmi
- Apache ile Tomcat Arasında Reverse Proxy Oluşturma
- Devoxx 2009 İzlenimleri
- YAGNI
- KISS – Keep It Stupid Simple
- DRY – Don’t Repeat Yourself
- UML’i Sevmeyenler İçin
- Interface Segregation Principle (ISP) – Arayüz Ayırma Prensibi
- Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri
- Builder Tasarım Şablonu
- Service Locator Tasarım Şablonu
- Business Delegate Tasarım Şablonu
- Dependency Inversion Principle (DIP) – Bağımlılıkların Tersine Çevrilmesi Prensibi
- Liskov Substitution Principle (LSP) – Liskov’un Yerine Geçme Prensibi
|
Neden Programcılık Harici İşlerle Uğraşmak Daha İyi Bir Programcı Olmayı Sağlar Posted: 04 Jun 2017 02:18 AM PDT Programcılığın çok büyük bir bölümünü basmakalıp işler oluşturur. Bu zamanla programcının belli kalıpların dışına çıkmasını zor hale getiren bir durumdur. Belli kalıplar çerçevesinde düşünmeye başlamak, yaratıcı ve çözüm üretici olmanın önündeki en büyük engeldir. Bu kalıpları yıkmanın ya da en azından onların görüşü engellemeyecek şekilde aşılabilmelerinin tek yolu programcılık harici iş ve projelere zaman ayırmaktan […]
|
|
Zaman Eksenindeki Teknolojik Fay Hatlarının Programcılar Üzerindeki Etkileri Posted: 17 Apr 2017 07:31 AM PDT Programcılık gibi bilgi güdümlü mesleklerin bir dejavantajı bulunmakta. Bu tür meslekler sadece bilgiyi taşıyanı yanlarında geleceğe taşırlar. Bilgi de öyle bir kitap karıştırma ile edinilecek bir şey değildir. Çoğu bilgi daha önce edinilmiş bilgiyi temel alır. Yani bilgilenme süreci yıllarca süren ve sağlam bilgisel temellere ihtiyaç duyan bir yapıdır. Bilginin değeri ona duyulan ihtiyaç ile […]
|
|
Posted: 23 Dec 2016 08:12 AM PST İkibinli yılların başlarında bir konferansda eski başbakanlarımızdan Tansu Çiller’e etrafındaki korumalarının ve çalışma arkadaşlarının sayın başbakanım diye hitap ettiklerine şahit olmuştum. Başbakanlık görevi on sene geride kalmış bir şahıs için neden başbakan ünvanı kullanılmaktaydı? Nedenini tam olarak hala bilmemekle birlikte, bunun nezaket kuralları çercevesinde, ünvan sahibi şahsı onure etmek ve onu eski ünvanı ile bir […]
|
Posted: 08 Sep 2016 05:09 AM PDT Yazılımda ve Yazılımcıda Çok Boyutluluk başlıklı yazım.
|
Posted: 14 May 2016 08:31 AM PDT Java’yı çoğu programcı yorumlanan (interpreted) dil olarak bilir. Java’nın yavaş olduğu efsanesi de başlangıcını da burada bulur. Bytekod olarak derlenen Java sınıfları Java sanal makinesi (Java Virtual Machine – JVM) bünyesinde yorumlanır. Tek derleme işlemi Java sınıflarının bytekoda dönüştürülmesi esnasında yapılmaz. JVM bünyesinde de bytekodun makine koduna dönüştürüldüğü bir derleme gerçekleştirilir. Bu işleme Just in […]
|
|
Yeni Kitaplarım Pratik Git Ve Design Patterns Yayımlandı Posted: 03 May 2016 11:37 AM PDT Yeni kitaplarım Pratik Git ve Design Patterns Pratik Programci Yayınları tarafından yayımlandı. Detaylar için lütfen resimlere tıklayınız.
|
Posted: 03 May 2016 11:17 AM PDT Bu yazımda bir Java nesnesinin hafıza alanında (heap) nasıl yer aldığını yanı sahip olduğu hafiza düzenini (object layout) aktarmak istiyorum. Bu amaçla aşağıda yer alan sınıfı kullanacağım. Java nesnelerinin hafıza düzenini elde etmek için JOL isimli aracı kullandım. Burada JOL kullanım örneklerini bulabilirsiniz. Yukarıda yer alan BirSinif isimli sınıfın hafıza düzenini JOL aracılığı ile şu […]
|
|
Blog Yazılarım Ekitabım 4. Sürüm Posted: 04 Mar 2016 02:23 PM PST |
|
Blog Yazılarım isimli ekitabımın 4. sürümünü hazırladım. Bu link üzerinden ücretsiz edinebilirsiniz.
|
|
Posted: 27 Feb 2016 12:34 AM PST Yazılımda Şemsiye Modeli başlıklı yazım.
|
Posted: 25 Jan 2016 03:10 PM PST Kıymeti Bilinmeyen Eskimiş Bilginin Kıymeti başlıklı yazım.
|
Posted: 01 Jan 2016 06:43 AM PST Daha İyi Bir Programcı Olmak İçin Sınırlar Nasıl Zorlanmalı? başlıklı yazım.
|
|
Karadelikler, Soyutluk ve Yazılım Posted: 06 Dec 2015 12:19 PM PST Karadelikler, Soyutluk ve Yazılım başlıklı yazım.
|
Posted: 04 Dec 2015 05:35 AM PST Gitolite İle Git Depo Erişimi başlıklı yazım.
|
|
Paralel Evrenlerin Programcıları Posted: 02 Nov 2015 06:58 AM PST Paralel Evrenlerin Programcıları başlıklı yazım.
|
|
Neden Frontend ve Backend Programcısı Tarihe Karışıyor Posted: 15 Oct 2015 03:01 AM PDT Neden Frontend ve Backend Programcısı Tarihe Karışıyor başlıklı yazım.
|
|
Bir Sonraki Pratik Programcı Yayınları Kitabı Posted: 08 Oct 2015 07:15 AM PDT Bir sonraki Pratik Programcı Yayınları kitabını belirlemek için sizi bu ankete katılmaya davet ediyorum. Uzmanlık alanıma girmesi durumunda bu seçim benim bir sonraki kaleme alacağım kitap olabilir. Bir Sonraki Pratik Programcı Yayınları Kitabı Anketi
|
|
Yazılımcıların Performansı Nasıl Ölçülür? Posted: 28 Sep 2015 08:44 AM PDT Yazılımcıların Performansı Nasıl Ölçülür? başlıklı yazım.
|
|
Nasıl Usta Programcı Olunurmuş Posted: 09 Sep 2015 07:17 AM PDT Nasıl Usta Programcı Olunurmuş başlıklı yazım.
|
|
Programcıların Besleyip, Büyüttükleri Canavar Posted: 09 Sep 2015 07:15 AM PDT Programcıların Besleyip, Büyüttükleri Canavar başlıklı yazım.
|
|
Yeni Çalışma Masam ve Kitaplığım Posted: 23 Aug 2015 02:45 PM PDT Burada yeni çalışma masamın oluşum safhalarını paylaştım. Aşagıdaki resimler de yeni kitaplıktan… EOF (End Of Fun) Özcan Acar
|
|
Yazılımcı Olarak Daha İyi ve Usta Olmak Mecburiyetindesiniz Posted: 11 Aug 2015 10:08 AM PDT Yazılımcı olarak daha iyi ve usta olmak mecburiyetindesiniz, çünkü İşini bilmeyen birçok yazılımcının geride bıraktığı kaousu siz toplamak zorunda kaldığınızda, işin içinden nasıl çıkacağınız hakkında fikir ve bilgi sahibi olabilmek için; Geride kaos bırakan bir önceki yazılımcı olarak anılmamak için; Kaliteli kod yazarak, işinize ne kadar hakim olduğunuzu göstermek için; Ekipteki genç yazılımcılara örnek olarak, […]
|
|
Merkezi Versiyon Yönetim Sistemlerinde Sürüm Almak İçin İş Akışı Nasıl Şekillendirilir? Posted: 11 Aug 2015 09:50 AM PDT Merkezi Versiyon Yönetim Sistemlerinde Sürüm Almak İçin İş Akışı Nasıl Şekillendirilir? başlıklı yazım.
|
|
Posted: 11 Aug 2015 09:46 AM PDT Programcının Evrimi başlıklı yazım.
|
|
Kod Kalitesi Denince Akla Gelenler Posted: 11 Aug 2015 09:44 AM PDT Kod Kalitesi Denince Akla Gelenler başlıklı yazım.
|
|
Public/Private Anahtar İkilisi İle Git Repository Erişimi Posted: 08 Jul 2015 06:02 AM PDT Bir Git deposuna (repository) erişmek için ya isim ve şifre kullanabiliriz ya da bir çift public/private anahtarı. Bu yazımda Eclipse ve Git Bash altında public/private anahtar ikilisinin bir git deposuna erişmek için nasıl kullanıldığını aktarmak istiyorum. Erişim için SSH protokolünü kullanıyorum. Anahtar ikilisinin ayrıca şifresi (passphrase) bulunuyor. Kullandığım işletim sistemi Windows 7. Git client olarak […]
|
|
2015 Yılına Geldik, Hala Spring’le Birlikte İnterface sınıf mı Kullanmak Zorundayız? Posted: 23 May 2015 04:48 AM PDT 2015 Yılına Geldik, Hala Spring’le Birlikte İnterface sınıf mı Kullanmak Zorundayız? başlıklı yazım.
|
|
JavaOne 2015 İçin Sunum Önerim Posted: 02 Apr 2015 04:22 AM PDT Bu sene sonunda San Francisco şehrinde yapılacak yirminci JavaOne konferansına konuşmacı olarak aşağıda yer alan sunum önerisini gönderdim. Sunum önerilerini 29 nisana kadar bu link üzerinden göndermek mümkün. EOF (End Of Fun) Özcan Acar
|
|
Eclipse Altında Birim ve Entegrasyon Testleri Nasıl Ayrı Koşturulur? Posted: 25 Mar 2015 01:26 PM PDT Çalıştığım projede aynı sınıfın entegrasyon ve birim testleri aynı paketin içinde yer alıyor. Maven ile birim testlerini yapıdan (build) önce, entegrasyon testlerini yapı ve deployment sonrası koşturmak mümkün. Bu şekilde testler ayırt edilebiliyor. Lakin Eclipse altında testleri koşturmak istediğim zaman, doğal olarak JUnit plugin testleri ayırt etmeden, beraber koşturuyor. Geliştirme esnasında bu sıkıntılı bir durum, […]
|
|
Posted: 19 Mar 2015 12:16 PM PDT Kod Redaktörlügü başlıklı yazım.
|
|
Posted: 27 Feb 2015 04:27 AM PST Yazılımda Otopilot başlıklı yazım.
|
|
20 Yaş, 30 Yaş, 35 Yaş ve Bugünki Programcı Ben Posted: 06 Feb 2015 05:15 AM PST Bu yazıyı kaleme alırken Can Yücel’in o güzel yazısından esinlendim. Onun yaptığı gibi yirmi, otuz ve otuz beş yaşında olan benleri coding dojo ya davet ettim. Maksat biraz yazılım üzerine sohbet etmekti. Ortaya çıkan bu oldu. Birlikte kod kata yapalım, eşli programlama süper dedim. 35 yaşımdaki ben iyi olur, ben varım dedi. 30 yaşımdaki ben, […]
|
|
JVM Nasıl Çalışır Yazı Serisi – JVM Stack Nedir ve Nasıl Çalışır? Posted: 08 Jan 2015 11:53 AM PST Java sanal makine bünyesinde (JVM – Java Virtual Machine) vücut bulan her thread ile birlikte thread e özel ve stack ismini taşıyan bir hafıza alanı oluşturulur. Stack bünyesinde thread in içinde bulunduğu (koşturduğu) metotlardaki lokal değişkenler, yapılan işlemler için gerekli parametreler (operand), işlem sonuçları ve metot giriş (invocation) ve çıkış (return) bilgileri yer alır. Bu […]
|
|
JVM Nasıl Çalışır Yazı Serisi – Java Dilinde Neden Göstergeçler (Pointer) Yok? Posted: 30 Dec 2014 12:51 PM PST Java’da göstergeçler var, ama C dilinde olduğu şekilde işlemiyorlar. Bu yazımda Java’da göstergeçlerin neden olmadığını aktarmaya çalışacağım. C dilinde aşağıdaki şekilde bir göstergeç tanımlaması yapilabilmektedir: Bu örnekte i isminde ve int veri tipinde bir değişken ve yine int veri tipine sahip ve ptr isminde bir göstergeç tanımladık. C dilinde göstergeçler bir hafıza alanına işaret ederler. […]
|
Posted: 12 Dec 2014 10:05 AM PST Neden Spring, JPA ve Diğer Çatılar ÖğrenilmeMEli başlıklı yazım.
|
|
Posted: 30 Nov 2014 04:06 AM PST Kişisel Gelişim başlıklı yazımda kullandığım metot ve araçlardan bahsetmiştim. Bu yazımda çok faydalı bulduğum bir aracı daha tanıtmak istiyorum. Yazının devamını okumadan önce sizden şunu yapmanızı rica ediyorum: Kağıt kalem kullanarak ya da bilgisayarınızda bir editör açarak yapmanız gereken şeylerin listesini çıkarın. Bu liste içinde mesai bitiminde sonra bakkaldan alacağınız ekmekten, iki hafta sonraki diş […]
|
|
Versiyon ve Sürüm Numaraları Nasıl Oluşturulur? Posted: 22 Nov 2014 01:15 PM PST Versiyon ve Sürüm Numaraları Nasıl Oluşturulur? başlıklı yazım.
|
|
Hangi Programlama Dilini Öğrenmeliyim? Posted: 19 Nov 2014 04:32 PM PST Hangi Programlama Dilini Öğrenmeliyim? başlıklı yazım.
|
|
Java Şampiyonluğu Nedir ve Nasıl Olunur? Posted: 17 Nov 2014 11:24 AM PST Ben 2009 senesinde Java sampiyonu olarak seçildim. Bilişim sohbetleri söyleşimde Java şampiyonluğu hakkında bilgi vermeye çalıştım. Bu yazımda kısaca Java şampiyonluğunun ne olduğunu tekrarlamak ve nasıl Java şampiyonu olunabileceği konusuna değinmek istiyorum. Dünya çapında yüz otuza yakın Java şampiyonu bulunuyor. Bu rakam aslında yüz altmış civarında, lakin bazı Java şampiyonları Oracle firması için çalışmaya başladıklarından […]
|
|
Posted: 14 Nov 2014 02:31 PM PST Kokan Kod – 1. Bölüm başlıklı yazım.
|
|
JVM Nasıl Çalışır Yazı Serisi – Çalışan Bir Java Uygulamasında Bytekod Nasıl Değiştirilir? Posted: 02 Nov 2014 08:30 AM PST Çalışan Bir Java Uygulamasında Bytekod Nasıl Değiştirilir? başlıklı yazım.
|
|
Posted: 26 Oct 2014 09:05 AM PDT Mimar Aslan ve Orhan Eripek tarafından sunulan Bilişim Sohbetleri‘ne konuk oldum.
|
|
Teknik Borç Nedir ve Nasıl Ödenir? Posted: 19 Oct 2014 03:08 AM PDT Teknik Borç Nedir ve Nasıl Ödenir? başlıklı yazım.
|
|
Başkalarının Kodu Okunarak Daha İyi Programcı Olunabilir mi? Posted: 30 Sep 2014 01:39 PM PDT Başkalarının Kodu Okunarak Daha İyi Programcı Olunabilir mi? başlıklı yazım.
|
|
JVM Nasıl Çalışır Yazı Serisi – Java String Nesnelerinin Hafıza Kullanımı Nasıl Azaltılır? Posted: 18 Sep 2014 10:51 AM PDT Java String Nesnelerinin Hafıza Kullanımı Nasıl Azaltılır? başlıklı yazım.
|
|
Çok Gezen mi Bilir, Çok Okuyan mı? Posted: 11 Sep 2014 02:00 PM PDT Çok Gezen mi Bilir, Çok Okuyan mı? başlıklı yazım.
|
|
Yazılımda Geviş Getirme Taktiği Nasıl Uygulanır? Posted: 05 Sep 2014 10:09 AM PDT Koyun, keçi, deve gibi hayvanlar otları çiğnemeden yutarlar. Daha sonra dinlenme esnasında yuttukları otları ağızlarına getirerek, çiğnerler. Buna işleme geviş getirme denir. Geviş getirme hayvanların evrim sürecinde düşmanlarına karşı geliştirdikleri bir savunma mekanizmasıdır. Bu tür hayvanlar düşmanlarından kaçabilmek için buldukları besinleri çiğnemden yutarlar. Daha sonra kendilerini güvende hissettikleri bir yer ve anda çiğnemeden yuttukları bu […]
|
|
Yazılımcılığın Ne Olduğunu Anlamamış Bilgisayar Mühendisi Posted: 03 Sep 2014 01:15 PM PDT Bu yazıyı okuduğumda, “yazılım kimlere kalmış” dedim ve bu yazıyı kaleme almaya karar verdim. Şimdi bu yazıyı alıntılar vererek, analiz etmek istiyorum. Kendimi bunu yapmak zorunda hissediyorum, çünkü yazı tam bir kargaşa ve tutarsızlıklar abidesi. Amacım kimseyi rencide etmek değil. Bu arkadaşımızın yazmış olduğu tezlerin mevcut ve müstakbel yazılımcılara ve yazılım sektörüne zarar verdiğini ya […]
|
|
Posted: 10 Aug 2014 11:09 AM PDT Başlama ve Bitirme Kriterleri başlıklı yazım.
|
|
5 Adımda Daha Kaliteli Yazılım Testleri Posted: 29 Jul 2014 11:13 AM PDT 5 Adımda Daha Kaliteli Yazılım Testleri başlıklı yazım.
|
|
Müşteri Gereksinimlerini Anladığımızdan Nasıl Emin Olabiliriz? Posted: 19 Jul 2014 05:26 AM PDT Müşteri Gereksinimlerini Anladığımızdan Nasıl Emin Olabiliriz? başlıklı yazım.
|
|
Programcının Hayatını Kolaylaştıran 18 Alışkanlık Posted: 05 Jul 2014 05:21 AM PDT Programcının Hayatını Kolaylaştıran 18 Alışkanlık başlıklı yazım.
|
|
Birim Testlerinde Beklentilerimi Daha Net Nasıl İfade Edebilirim? Posted: 09 Jun 2014 01:10 AM PDT Birim Testlerinde Beklentilerimi Daha Net Nasıl İfade Edebilirim? başlıklı yazım.
|
|
Posted: 04 Jun 2014 01:33 PM PDT Sözde Lean! başlıklı yazım.
|
|
En Basit Çözümü Oluşturma Yetisi Nasıl Kazanılır? Posted: 03 Jun 2014 06:39 AM PDT En Basit Çözümü Oluşturma Yetisi Nasıl Kazanılır? başlıklı yazım.
|
|
Posted: 30 Apr 2014 04:12 PM PDT Yeni kitabım Pratik Agile Pratik Programcı Yayınları tarafından yayımlandı. Detayları burada bulabilirsiniz.
|
|
Dağın Ayağına Gelmesini Bekleyen Birisi Posted: 09 Apr 2014 02:17 AM PDT Bir varmış, bir yokmuş. Evvel zaman içinde, kalbur saman içinde birisi varmış. Bu birisi çok inatçıymış. Birgün bir arkadaşı ile “ben dağa gitmem, dağı ayağıma getiririm” diye iddiaya girmiş. Başlamış dağın ayağına gelmesini beklemeye. Bir zaman beklemiş, bakmış dağın geldiği falan yok. Bu eninde sonunda ayağıma gelecek diye beklemeye devam etmiş. Yine aradan bir zaman […]
|
|
Standart Java API’ler Neden Tercih Edilmeli? Posted: 05 Apr 2014 05:43 PM PDT Standart Java API’ler Neden Tercih Edilmeli başlıklı yazıma bu link üzerinden ulaşabilirsiniz.
|
|
Posted: 02 Apr 2014 07:24 AM PDT Java dilini temelinden öğreten sanal bir kurs hazırladım. Bu kurs hakkındaki detaylı bilgiyi bu yazımda bulabilirsiniz.
|
|
Ne Zaman Test Güdümlü Yazılım Yapmalıyım? Posted: 27 Mar 2014 09:21 AM PDT Ne Zaman Test Güdümlü Yazılım Yapmalıyım? başlıklı yazım.
|
|
java.lang.IncompatibleClassChangeError: Implementing class Nedir ve Analizi Nasıl Yapılır? Posted: 15 Mar 2014 04:05 AM PDT Bu hata genelde bir interface ya da üst sınıf değişikliğe uğradıktan sonra, classpath içinde bu sınıfı eski haliyle implemente etmiş/genişletmiş bir sınıfın, üst sınıf tekrar kullanılarak derlenmeden kullanılması sonucu ortaya çıkan bir hata türüdür. Çalıştığım projede bir web uygulamasını deploy ederken hatanın şu hali ile karşılaştım: Bu hatayı analiz etmek için HibernatePersistence sınıfının 124. satırından […]
|
|
Posted: 08 Mar 2014 01:41 PM PST İdeal şartlar altında bir programcının savaş verdiği tek bir cephe vardır, o da müşteri gereksinimlerini önemlilik sırasına göre kodlamak. Çevik süreçlerde müşteriye 2-4 hafta süren çalışmalar ardından çalışır bir uygulama prototipi sunulur. Bu prototip müşteriye uygulamanın hangi seviyeye geldiğini, isteklerinin doğru uygulanıp, uygulanmadığını ve hangi değişikliklerin gerekli olduğunu anlama fırsatı verir. Buradan change request olarak […]
|
|
Posted: 21 Feb 2014 01:17 PM PST Geçenlerde öğrenci bir arkadaş fikrimi almak için bana bir soru sordu. Belli bir meblağ için iki ay boyunca fulltime bir yazılım evi için çalışmasının doğru olup, olmayacağı hakkında fikrimi sordu. Bu okulunu aksatır mı diye sordum. Cevabı evet oldu. Benim de cevabım belliydi. Yazılımda tek sorumluluk ismini taşıyan bir yazılım prensibi var. Birden fazla sorumluluğu […]
|
|
Posted: 18 Jan 2014 01:04 PM PST 2013 senesi için hazırladığım yazılımcı anketi sonuçlandı. Edindiğim verileri kullanarak Türkiye Yazılımcı Raporu 2013’ü hazırladım. Emeği geçen herkese teşekkür ederim.
|
|
Spring 3.x İle Gelen Yenilikler Posted: 12 Jan 2014 08:38 AM PST Spring 3.x İle Gelen Yenilikler başlıklı yazım…
|
|
Posted: 03 Jan 2014 05:43 AM PST Coca Cola’nın kaç türü var, bilirsiniz… Cola light, Cola zero, Cola classic…. Çevik süreçler için de aynı şey geçerli. Ben çevik süreçleri agile zero, agile light ve hardcore agile ya da classic agile olarak üç bölüme ayırıyorum. Agile Zero Çalışma ortamında çevikliğe dair hiçbir ibare yoktur. Belirtileri Projede hiçbir birim, entegrasyon ya da onay/kabul testi […]
|
|
Posted: 02 Jan 2014 01:00 PM PST Spring’in Varoluş Nedeni başlıklı yazım…
|
|
Yazılımcının Verimliliğini Artıran Eclipse Ayarları Posted: 01 Jan 2014 03:21 AM PST Çoğu projede yazılım geliştirme ortamı olarak Eclipse’i kullanıyorum. Bu yazımda yazılım yaparken verimliliğimi artırdığını düşündüğüm Eclipse ayarlarını sizinle paylaşmak istiyorum. Kullandığım Eclipse sürümü 4.3.1 Kepler. Hiç sevmediğim bir şey varsa, o da formatsız koddur. Bir Eclipse editöründeki bir kodu CTRL+SHIFT+F ile formatlamak mümkün. Ama bunu yazılımcı değil, Eclipse otomatik olarak yapmalı. Bu ayarı Window –> […]
|
|
Spring Çatısının Yazılım Geliştirme Filozofisi Posted: 31 Dec 2013 01:14 AM PST Özellikle nesneye yönelik programlama teknikleri kullanıldığında, nesneler arasında var alan bağımlılıklar çok karmaşık bir yapının oluşmasına neden olabilmektedir. Uygulama geliştirme esnasında bağımlılıkların kontrol altına alınmasına dair bir çalışma yapılmadığı taktirde, yazılımcının verimliliği ve uygulamanın kod kalitesi düşecektir. Kaliteyi artırmanın ve yazılımcının daha verimli olmasını sağlamanın bir yöntemi, tüm bağımlılıkların ve oluşan karmaşık yapının dış bir […]
|
|
Posted: 27 Dec 2013 01:26 AM PST Bir sene süren çalışmalarım ardından Pratik Spring isimli yeni kitabımı tamamladım. Yeni kitabım Pratik Programcı Yayınları tarafından e-kitap olarak PDF formatında satışa sunuldu. Kitap 18 bölümden oluşuyor. Ana bölüm başlıkları şunlar: 1.Bölüm – Spring Nedir? 2.Bölüm – Spring İle Tanışalım 3.Bölüm – Spring İle Nesne Yaşam Döngüsü Yönetimi 4.Bölüm – Konfigürasyon Yönetimi 5.Bölüm – Spring […]
|
|
Posted: 20 Dec 2013 02:27 AM PST Şimdi size sorsam, en çok sevdiğiniz üç yazılım kitabını yazarları ile sayabilir misiniz? Sayabilmeniz lehinize olurdu, çünkü bir sonraki iş görüşmenizde bu soruyla karşılaşma şansınız yüksek. Başıma geldiği için söylüyorum :) Bana son on beş yıllık yazılımcı iş hayatımda sorulan en ilginç soru buydu. Cevabım şu şekilde olabilir. Bu sorunun altında yatan mentalite çok başka […]
|
|
Spring Core Sertifika Sınavı Ardından Posted: 20 Dec 2013 01:06 AM PST Geçen sene katıldığım Spring Integration ve Spring Core kurslarının ardından bu senenin mayıs ayında Spring Integration sertifikasını almıştım. Katıldığım kurslardan sonra aklımda Pratik Spring Core kitabını yazma fikri oluştu. Kitabı tamamladım ve yakında pragmatikprogramci.com adresi üzerinden pdf formatında e-kitap olarak satışa sunulacak. Bu arada iki gün önce Spring Core 3.2 sertifika sınavına katıldım ve sınavı […]
|
|
Posted: 06 Dec 2013 10:35 PM PST KurumsalJava.com ve diğer blog sayfalarımda yazdığım yazıları bu e-kitapta bir araya getirdim. Beğeninize sunarım. Kitabı bu adresten edinebilirsiniz.
|
|
Posted: 12 Nov 2013 10:42 PM PST Bu anketi hazırlayarak, yazılım ve yazılımcılık hakkındaki düşüncelerinizi öğrenmek istedim. Yeterli veri elde ettikten sonra Yazılımcı 2013 Raporu’nu sizinle paylaşacağım. Türkiye Yazılımcı Raporu 2012’ye buradan ulaşabilirsiniz. Bu anket son bulmuştur. Türkiye Yazılımcı Raporu 2013’e buradan ulaşabilirsiniz. Loading…
|
|
JVM Nasıl Çalışır Yazı Serisi – Java Hotspot, Assembly Kod, Hafıza Bariyerleri ve Volatile Analizi Posted: 08 Nov 2013 07:30 AM PST Java kodu Java derleyicisi javac (compiler) tarafından bytekoduna dönüştürülür. Bytekod JVM e has bir yapıya sahiptir ve Assembly dili gibi düşünülebilir. Oluşan bytecode dogrudan işlemci üzerinde koşturulamaz. Derlenmiş Java kodunu koşturabilmek için mikroişlemci ile Java bytekodu arasında, bytekodunu mikroişlemci makine koduna dönüştürebilecek bir ara katmana daha ihtiyaç duyulmaktadır. Bu JVM (Java Virtual Machine) ismini taşıyan […]
|
|
Posted: 14 Oct 2013 07:09 AM PDT Uğur Umutluoğlu‘nun daveti üzerine aşağıdaki söyleşiyi gerçekleştirdik.
|
|
Posted: 03 Oct 2013 05:44 AM PDT Mikrodevre.com adresi altında elektronik ve mikro denetleyiciler hakkında edindiğim bilgileri paylaşacağım yeni bir blog oluşturdum. Bilginize… Özcan Acar
|
|
Posted: 09 Sep 2013 05:51 AM PDT Bir senior ve bir junior arasında yapılan konuşmaya kulak misafiri olalım: Senior: Sakın başkasının kodunu değiştirme! Ufak bir değişiklik ummadığın hataların oluşmasına sebep olabilir. Yaptığın değişiklik sonucu bir hata oluşmadı ise, kimse seni övmez. Ama hata olursa, herkes başına üşüşür. Bunu istediğini zannetmiyorum. Junior: Ama agile diye bir şey var, öyle kodu yeniden yapılandırmadan olmazki! […]
|
|
Posted: 25 Jun 2013 03:19 AM PDT Hiç diyet yaptınız mı? O zaman her diyetten sonra tekrar kiloları fazlasıyla geriye aldığınıza diyet sayınız adedince şahit olmuşsunuzdur. Yeme alışkanlıkları değiştirilmeden hiçbir diyetin başarılı olduğunu görmedim. Bu konuda epeyce bir tecrübeliyim diyebilirim. Tipik bir iş gününün yüzde %90 ından fazlasını masa başında geçiren birisi olarak, kilolarımı dengede tutmak için yapmadığım diyet ve spor türü […]
|
|
Posted: 21 Jun 2013 05:45 AM PDT İlk bakışta bir programcıyı senior yapan teknik bilgisidir. Yüksek seviyede teknik bilgiye sahip olmak için çok tecrübe sahibi olmak gerekir. Yüksek seviyede teknik bilgiye sahip bir şahsın senior olarak algılandığını düşünebiliriz. Lakin teknik bilgi senior olmanın sadece bir boyutudur. Senior mozaiğinin tamamlanması için birçok parçanın bir araya gelmesi gerekir. Kendisini senior olarak tanımlayan birçok programcı […]
|
|
Posted: 25 May 2013 10:58 PM PDT Şüphesiz açık kaynak (open source) filozofisi biz programcıların hayatını derinden etkiledi. Açık kaynağın bize sağladığı bariz iki avantaj var. Bunlar: Başkalarının, bu başkaları çoğu zaman usta olarak tabir edebileceğimiz yetenekli programcılar, yazdığı kodlara bakarak kendimizi programcı olarak geliştirebiliriz. Açık kaynaklı programları lisans bedeli ödemeden kullanabiliriz. İkincisi çok bariz olarak karşılaştığımız bir durum. Hibernate, Spring, Eclipse.. […]
|
|
SpringSource Certified Integration Specialist Sertifikası Posted: 20 May 2013 03:41 AM PDT Eylül 2012 de katıldığım SpringSource Certified Enterprise Integration Specialist kursunun ardından geçen hafta katıldığım imtihanı kazanarak SpringSource Certified Integration Specialist sertifikasını almaya hak kazandım. Resim 1: Kursa katılım belgesi Dört gün süren kursun içeriği aşağıdaki konulardan oluşuyor: Spring Remoting Spring Web Services REST JMS Transactional JMS XA Transactions Spring Batch Spring Integration Spring bünyesinde Spring […]
|
|
Posted: 11 Apr 2013 06:02 AM PDT Yazılımcılar detaylara olan sevdaları ile tanınırlar. Bir yazılımcı kullanılmak üzere yeni bir API (Application Programming Interface) geliştirdi ise ve kendisinden bu yeni API’nin nasıl kullanıldığının açıklanması istenirse, size detaylar içinde kaybolmanız ve oturum sonunda API’nin nasıl kullanıldığını anlamamanız garantisini veririm. Bir API’yi kullanmak nedir, önce bunun tanımlamasını yaparak başlamak istiyorum. Bir API ideal bir dünyada […]
|
|
Posted: 03 Apr 2013 07:43 AM PDT Son zamanlarda en çok merak edip, öğrenmek istediğim diller arasında geliyor Ruby. Ruby herkesin dilinden düşürmediği, dinamik veri tipli ve her şeyin istisnasız nesne olduğu bir programlama dili. 1993 yılında Yukihiro Matsumoto tarafından geliştirilmiş. 2006 senesinde Ruby on Rails çatısının oluşturulmasıyla popüler bir web programcılığı dili olmuş. Bu yazımda bir Java programcısının, yani benim Ruby […]
|
|
Posted: 22 Feb 2013 12:14 AM PST Birçok meslekte araç ve gereç sahibi olmadan iş yapmak mümkün değildir. Günlük hayatımızda da birçok araç ve gereci kullanırız. Örneğin bir resmi duvara asabilmek için bir çivi ve bir çekic kullanırız. Çoğu zaman işimizi gördükten sonra başarımız ile övünür, bir sonraki ihtiyacımıza kadar kullandığımız araçları hatırlamayız. Araçlar zamandan tasarruf etmek ve işimizi kolaylaştırmak için vardır. […]
|
|
Posted: 18 Feb 2013 02:13 AM PST BTSoru.com‘da bir soru sorulmuş. Tüm soruları kontrol ederek ihtiyaç durumunda başlığı, içeriği ve etiketleri düzenlemeye çalışıyorum. Bu soruyu incelerken verilen kod örneğini Struts kodu zannettim ve sorunun etiketini Struts olarak değiştirdim. Kısa bir zaman sonra soruya bir yorum yapan bir arkadaşımızdan bir uyari e-postası aldım. Arkadaş iletisinde etiketin asp.net-mvc olmasının daha anlamlı olacağını bildiriyordu. İlgisi […]
|
|
Posted: 17 Feb 2013 03:16 AM PST Programcı takım arkadaşı ile kodu gözden geçirme (code review) seansı yapıyor. Kodun içinde bulunduğu durumdan hoşnut değil, lakin bunu takım arkadaşına söylemiyor. Arkadaşının yanlış anlamasından mı korkuyor? Tüm yazılımcılar iterasyon sonunda bir araya gelerek geri bakış (retrospective) seansı yapıyorlar. Bazı programcılar boğazlarına kadar dolmuşken, bunun nedenini takım arkadaşlarıyla paylaşmıyorlar. Çok mu sabırlılar? Günlük stand-up toplantı […]
|
|
Java Generics Get ve Put Prensibi Posted: 30 Jan 2013 05:00 AM PST Java Generics and Collections kitabında Get and Put isminde bir prensipden bahsediliyor. Java Generics wildcard kullanımı bu prensip takip edildiğinde daha kolaylaşıyor. Prensip şöyle: Eğer bir yapıdan (liste, map vs.) nesne ediniyorsanız (get) extends wildcard, bir yapıya nesne ekliyorsanız (put) super wildcard kullanın. Bir yapı üzerinde bu iki işlemi birden yapıyorsanız, o zaman wildcard kullanmayın. […]
|
|
Programcılık Çıtası Yükseliyor Posted: 29 Jan 2013 10:21 AM PST Ben Java’nın ilk günlerinden beri bu dili kullanan bir programcıyım. 1998 senesinin bir günü kampüste laflarken bir arkadaşım yeni haberini aldığı Servlet teknolojisinden bahsetmişti. Bugün gibi hatırlıyorum: “vay… demek Java ile appletler harici web programcılığı yapılabiliyor….” demiştim. Java ile geçirdiğim ilk yıllarda hakim olmam gereken konular JDBC, Reflection, RMI ve Servlet gibi teknolojilerle sınırlı idi. […]
|
|
Posted: 04 Jan 2013 08:00 AM PST Yazılım camiasında son zamanlarda dikkat çeken bir değişim furyası var. Cevabı aranan soru şu: Yazılım ekibi nasıl daha verimli hale getirilebilir? Bu aslında organizasyonel bir değişimin gerekli olduğu bilincinin oluştuğu anlamına geliyor. Yöneticiler ekiplerini daha çevik hale getirmek için çeşitli yöntemlere başvuruyorlar. Bunların başında örneğin ekibin topluca eğitilmesi geliyor. Her eğitim şüphesiz ekibe ve bireylerine […]
|
|
Posted: 01 Jan 2013 12:58 AM PST Bu rapor Kurumsaljava.com‘da hazırladığım yazılımcı anketinden edindiğim verileri ihtiva etmektedir. Ankete son beş ay içinde beş yüze yakın yazılımcı katıldı. Ankette yer alan soruları yazılımcıların çalışma yöntem ve süreçlerine, kullandıkları araçlara ve bu meslekten beklentilerine ışık tutacak şekilde şekillendirmeye çalıştım. Raporun bundan sonraki her sayfasında ankette yer alan bir soru ve bu soruya ankete katılan […]
|
|
Neden Fonksiyonel Programlamayı Öğrenmek Zorundayız Posted: 30 Dec 2012 01:49 AM PST Daha dün gibi hatırlıyorum: Windows 95’in sahip olduğu işletim sistemi çekirdeğini (kernel) taskmanageri üzerinden şutlayabiliyordunuz. Akabinde tüm sistem çalışmaz hale geliyordu. Bu konularla ilgisi olmayanları kendine hayran bırakmak için fena bir yöntem değildi. Bu bahsettiğim bilgisayarlar birkaç MB hafızası olan, tek bir işletim birimine (CPU) sahip, bir düğmesine basıldığında işletim biriminin çalışma hızını ikiye ya […]
|
|
Nasıl Arkadaş Kazanır ve Diğer İnsanları Etkilersiniz Posted: 16 Dec 2012 12:19 AM PST Dale Carnegie tarafından 1937 yılından yazılan How To Win Friends and Influence People (nasıl arkadaş kazanır ve diğer insanları etkilersiniz) başlıklı kitap her yazılımcının mutlaka okuması gereken ve güncelliğini günümüzde de koruyan çok değerli bir kaynak kitap. Kitapta günlük hayatta takip edilmesi gereken bazı kurallar yer alıyor. Bunlar: Kimseyi eleştirmeyin, yargılamayın ve şikayet etmeyin Bir […]
|
|
Posted: 11 Dec 2012 01:12 PM PST Geçen cumartesiyi pazara bağlayan gece, saat 00:00 civarı KurumsalJava.com, BTSoru.com, BizimAlem.com ve diğer web projelerimin üzerinde yer aldığı sunucuların erişilemez oldukları haberini aldım. Akabinde gecenin bir yarısı hizmet aldığım ISP’nin yolunu tuttum. Tam, tamına 4 senedir bir düğmesine bile basmadığım, bu kadar zaman sorunsuz çalışmış olan firewall sistemlerinin neden çalışmadıklarını incelemeye başladım. Bugüne kadar birçok […]
|
|
Posted: 03 Dec 2012 12:45 AM PST KurumsalJava.com RSS Adresi degişmiştir. Lütfen http://www.kurumsaljava.com/feed/ olarak değiştiriniz.
|
|
Posted: 18 Nov 2012 02:01 AM PST Internetin bu kadar büyümesi ve özellikle Google gibi arama motorlarının günlük iş hayatımızın bir parçası haline gelmesi biz programcılar için ne kadar hayırlı oldu, bilemiyorum. Pek te hayırlı olmadığı kanısındayım. Açıklamaya çalışayım. Çalıştığım projede bir çalışma arkadaşımın masasında algoritmalarla ilgili kalınca bir kitap gördüm. Havadan, sudan konuşurken kendisi böyle kitapların artık gereksiz olduğunu, çünkü internette […]
|
|
Test Edebilme Uğruna Her Şey Mübahtır! Posted: 13 Nov 2012 09:44 AM PST Geçenlerde yine tartışması yapılıyor: private olan metotları nasıl test ederiz? Benim cevabım: “edemeyiz!” Karşıdan gelen cevap: “dediğim gibi, her şeyi test etmek mümkün değil demek ki!“. Benim cevabım: “her şeyi test etmek mümkün, private’i protected yaparsın, olur, biter.” Karşı tarafın cevabı: “kardeşim ortada OOP diye bir şey var, kafana göre nasıl öyle private bir metodu […]
|
|
Posted: 09 Nov 2012 01:05 PM PST Yazılım yaparken en büyük zaman kaybının nedeni, kodu değiştirip, derleyip, çalışır hale getirdikten sonra değişikliğin sonucunu test etmektir. Kodu değiştir/derle/çalıştır/dene süreci otuz saniyeden beş dakikaya kadar sürebilir. Günde bunu on sefer yaptığınızda bir saatlik bir zamanı boşa harcamış olursunuz. Bu sebepten dolayıdır ki EJB2 ve benzeri teknolojilerin yerine Spring gibi daha hafif yazılım yapmayı sağlayan […]
|
|
Posted: 30 Sep 2012 09:30 AM PDT Eşli programlama yapmak için illa iki programcının aynı mekanda olması gerekmiyor. Eclipse kullanıyorsanız Saros pluginini kurarak, uzak bir bilgisayardaki bir şahıs ile eşli programlama yapabilirsiniz. Uzaktan eşli programlama için neler gerekli? Java 6 Eclipse 3.6 ya da 3.7 Eclipse >> Help >> Install new Software menüsünden http://dpp.sourceforge.net/update Saros update sayfasını kullanarak gerekli plugini kurabilirsiniz. Kurulumun […]
|
|
Posted: 17 Sep 2012 12:17 PM PDT Editörü açtınız, public class yazarak yeni bir sınıf oluşturdunuz. Bu sınıfa yeni bir metot eklediniz. Başka bir şey yapan yeni bir metot daha eklediniz. Sınıf yavaş yavaş şismeye başladı. Birkaç refactoring yaptınız. Buradan yeni bir sınıf dünyaya gözlerini açtı. Bir sınıf, bir sınıf daha derken sınıf sayısı onlara ulaştı. Her sınıfın metot küfesi iyice ağırlaşmaya […]
|
|
Uzman ve Usta Yazılımcı Arasındaki Fark Posted: 17 Sep 2012 05:56 AM PDT Fanatik futbol severleri bilirsiniz. Takımları için yapmayacakları yoktur. Bu fanatiklik başka insanlara zarar vermeye kadar varabilir. Yazılımda da durum farklı değildir. Tek fark bu fanatikliğin insana zarar verecek seviyede olmamasıdır. Çok duymuşsunuzdur Java dili şöyle, Java dili böyle, diğer dillerden üstündür… diye. Neden bazı yazılımcıların böyle fanatizm olarak görülebilecek bir ilgi ve alaka ile bazı […]
|
|
Posted: 20 Aug 2012 08:12 AM PDT Her izcinin uyduğu bir kural vardır: “Kamp yaptığın yeri bulduğundan daha iyi bir şekilde bırak!” Yazılımcı olarak bu kuralı uygulamak istediğimiz taktirde, mevcut yazılım standartlarına uymayan kod birimlerini tereddüt etmeden yeniden yapılandırarak, uygulamanın bakılabilirliğini ve geliştirilebilirliğini artırmamız gerekir. Usta bir yazılımcının geride bıraktığı kodun kalitesi, işe başladığında bulduğu kodun kalitesinden her zaman daha iyidir. EOF […]
|
|
Posted: 20 Aug 2012 07:56 AM PDT Yazılım yapmayı zorlaştıran her zaman kod birimleri arasındaki bağimlılıklar ve bu bağımlılıkların yönetimi olmuştur. Bu bağımlılıkları tamamen yok etmek yazılım sistemini anlamsız kılarken, kontrolden çıkmalarına göz yummak yazılım sisteminin ölüm fermanı olabilir. Yazılım mühendisi bunu bilir ve gerekli gördüğü yerlerde DIP, ISP ve SRP gibi tasarım prensiplerini kullanarak kodu dokur. Yazılımcının kod yazarken devamlı uygulaması […]
|
|
Posted: 17 Aug 2012 04:18 AM PDT Bu yazıyı okuyunca daha önce yazdığım Melek Programcılar ve Şeytan Yatırımcılar başlıklı yazımı anımsadım. Orada genç girişimcilerin nasıl şeytan yatırımcılar tarafından üç kağıda getirilip, sömürüldüklerinden bahsetmiştim. Durumun başka bir boyutunu da paylaştığım yazı gösteriyor. Eğer devamlı hesabını yapacak isem, param yetiyor mu, ya da beş sene sonra hala yeter mi diye, o zaman kendime özel […]
|
|
Posted: 15 Aug 2012 07:53 AM PDT Size herhangi bir şey satmak için kapınıza gelen bir satış temsilcisine ne gözle bakarsınız? Ben bu durumla karşılaşınca, beynimde otomatik olarak şahsı başımdan savma rutinleri devreye giriyor. Birilerinin benim üstüme bu şekilde gelerek bana bir şey satması imkansız. Bu inisiyatifin benden kaynaklanması lazım. Yazılım sektöründe de durum anlaşılan farklı değil. Birileri biz yazılımcılara devamlı bir […]
|
|
Posted: 12 Aug 2012 12:58 PM PDT Her sektörün kendi guru, üstad, pir olarak görülen zatları var. Yazılım sektöründe de durum farklı değil. Şöyle başımızı kaldırıp devleşmiş bir üstada baktığımızda, bu adam nasıl bu kadar yetenek, kabiliyet, bilgi ve beceri sahibi olabildi diye bir soru aklımıza gelir. Aynı zamanda kendimizin bu devin yanında ne kadar küçük kaldığımızı görür, saklanacak bir yer aramamıza […]
|
|
Detayları Görebilmek Ya Da Görememek Posted: 10 Aug 2012 07:48 AM PDT Robert Martin Transformation Priority Premise – Transformasyon Öncelik Teorisi başlıklı yazısında yeniden yapılandırmaya (refactoring) karşı yöntem olan kod transformasyonuna değiniyor. Refactoring uygulamanın dışa gösterdiği davranış biçimini değiştirmeden kodun yeniden yapılandırılması anlamına gelirken, kod transformasyonu uygulamanın davranış biçimini yeniden şekillendirmek için kullanılan bir yöntemdir. Benim kod transformasyonlarını bilinçli bir şekilde algılamam kod kataları yapmaya başladığım zamana […]
|
|
Yazılımda Çeviklik İflas mı Etti? Posted: 09 Aug 2012 04:20 AM PDT Çevikliğin Böylesi başlıklı yazımı okudunuz mu? O yazımda çevik kelimesinin yerli yersiz her şey için kullanıldığını ve bu yüzden anlam erozyonuna ugradığından bahsetmiştim. Bu yazımda çevikliğin tanımını yapmaya çalışacağım. Martin Fowler bu link üzerinden ulaşabileceğiniz yazısında şöyle diyor: … lack of rigorousness is part of the defining nature of agile methods, part of its core […]
|
|
Gezen Defterin Hikayesini Biliyor musunuz? Posted: 03 Aug 2012 06:07 AM PDT 2009 yılında Enrique Comba‘nın aklına bir not defteri alıp, yazılım zanaatı akımında (Software Craftsmanship Movement) yer alan programcılara posta yoluyla gönderme fikri gelir. Her programcı deftere bu konudaki kendi düşünce ve tecrübelerini ekledikten sonra, defteri listede yer alan bir sonraki programcıya posta yoluyla gönderir. Bugün SocRaTes 2012 konferansında tanıştığım bir programcı 2010 senesinde bu defterin […]
|
|
Posted: 02 Aug 2012 06:00 AM PDT Yaptığım kataları KodKata.com‘da sizinle paylaştım. Her gün düzenli olarak kod katalarımı yapıyorum. Her gün değişik bir kata yapmaya gayret ediyorum. Kataları tekrarladıkça katanın öngürdüğü birçok işlem benim için rutinleşiyor. Zaman zaman katanın öngördüğü yoldan saparak, başka şeyler deniyorum. Bu yeni bir tasarım kararı olabiliyor ya da yeni bir refactoring metotunun kullanımı. Netice aynı olmakla beraber, […]
|
|
Posted: 30 Jul 2012 04:54 AM PDT Bu anket 31.13.2012 tarihinde sona erdi. Bu anketteki verileri ihtiva eden rapora bu link üzerinden erisebilirsiniz. Bu anketi hazırlayarak, yazılım ve yazılımcılık hakkındaki düşüncelerinizi öğrenmek istedim. Yeterli veri elde ettikten sonra Yazılımcı 2012 Raporu’nu sizinle paylaşacağım. Loading…
|
|
Posted: 26 Jul 2012 07:36 AM PDT Bir programcının tipik bir haftasının kırk saati patronu için çalışmakla geçer. Daha önceki bir yazımda bir programcının mesai saatlerinde kendisini geliştirmesinin mümkün olmadığını, ama mesai haricinde pratik yaparak programcılık yeteneğini geliştirmesi gerektiğinden bahsetmiştim. Gel gelelim günde sekiz saat çalıştıktan sonra eve gelip, pratik yapmak ya da kitap okumak kolay bir şey olmayabilir. Yemek yedikten ve […]
|
|
Bilgisayar Mühendisi mi, Yazılım Mühendisi mi? Posted: 26 Jul 2012 02:34 AM PDT İsmini açıklamadan bir üniversite ögrencisinin bana göndermiş olduğu e-posta iletisini sizinle paylaşmak istiyorum. Bana gelen e-postanın içeriği şöyle: Özcan Bey Merhabalar Ben XXX Üni. Teknoloji Fak. Yazılım Müh. okuyorum.Yatay geçişle YYY Üni.Müh Fak. Bilg. Müh. geçmek istiyorum ama kararsızım. Sizce hangisini seçmeliyim? Gelecekte hangisinde işsiz kalma ihtimalim daha az? YYY Üni. eğitimi daha iyi olur […]
|
|
Posted: 20 Jul 2012 02:18 AM PDT Programcılar tarafından yazılan metotların ve kullanılan değişken isimlerinin çoğu anonim, yani adı sanı belirsiz. Kullanılan isimler ilk bakışta kod bünyesinde olup bitenleri ifade gücünden aciz. Bu kodun okunabilirliğini düşüren bir faktör. Zamanımızın büyük bir kısmını kod okuyarak geçirdiğimizi düşündüğümüzde, seçilen isimlerin ne kadar önemli olduğunu ortaya çıkmakta. Anonim kod sadece metot ve değişken isimleri ile […]
|
|
Posted: 20 Jul 2012 01:02 AM PDT Yeni projem KodKata.com yayında. Kod Kata ve Pratik Yapmanın Önemi başlıklı yazımdan sonra günlük pratik yapmak için kullandığım kataları sizinle paylaşmak istedim. EOF (End Of Fun) Özcan Acar
|
|
Posted: 08 Jul 2012 02:10 PM PDT Bu yazımda Java programclarının bilmediği, doğru olarak kabul edip kullandığı ya da yanlış bildiği konulardan bahsetmek istiyorum. Hafıza Alanı Ayarları Genelde JVM için hazıfa alanı -Xmx -Xms parametreleri ile oluşturulur. -X ile başlayan parametreler standart JVM parametreleri değildirler, yani bu parametreleri JVM implemente etmek zorunda değildir. Durum böyle olunca -Xmx1024m şeklindeki bir parametre, eğer JVM […]
|
|
Posted: 07 Jul 2012 01:28 PM PDT Bugünkü günüm bir tweet göndererek başladı. Saat sekiz gibi Frankfurt’ta yapılan Code Retreat etkinliğine katıldım. Code Retreat 15-20 arası programcının bir araya geldiğı ve birlikte gün boyunca kod geliştirdikleri bir etkinlik. Etkinliğin formatı kısaca şöyle: Etkinlik 45 dakikalık, iki programcının bir araya gelerek eşli programlama (pair programming) yaptıkları altı oturumdan ve her oturum sonunda beş […]
|
|
Posted: 30 Jun 2012 06:06 AM PDT Java ve diğer dillerde kullanılan switch komutu OCP tasarım şablonuna ters düşmekle beraber, kodun bakımı ve geliştirilmesini zorlaştırmaktadır. Martin Fowler Refactoring isimli kitabında yer alan Video Store örneğinde “Replace Conditional with Polymorphism” refactoring metodu ile switch komutunun nasıl yok edilebileceğini göstermektedir. Robert C. Martin’in CleanCoders.com sayfasında Video Store örneğini daha geniş çaplı yeniden yapılandıran bir […]
|
|
Posted: 19 Jun 2012 05:16 AM PDT Biliyorsunuz yazılim sektörü sadece biz yazılımcılardan oluşmuyor. Bu sektörün proje yöneticisi, satış elemanı, testcisi gibi emekçileri de var. Bu meslek gurupları içinde teknik anlamda yazılımın nasıl yapılması gerektiğini bilen ya da bilmesi gereken biz yazılımcılarız. Bu sektördeki diğer meslek guruplarından bu konuda bir ümit beklemeyin. Durum böyle olmasına rağmen, bir yazılım projesinin nasıl yürütülmesi gerektiği […]
|
|
Neden Her Programcının Bir Blog Sayfası Olmalı? Posted: 06 Jun 2012 04:51 AM PDT Blog kelimesi Web Log kelimelerinin kısaltılmış halidir. Bir blogu dijital ortamda tutulan bir günlük olarak düşünebiliriz. Aşağıda sıraladığım sebeplerden dolayı her programcının bir blog sayfası olmalı: Blog bir programcının özgürce kendini ifade etmesini sağlar. Söyleyecek bir şeyi olan bir programcı blogu aracılığı ile okurları ile buluşur. Programcı okurlarından geribildirim niteliğinde yorumlar alır. Bu kendi düşüncelerini […]
|
|
Posted: 04 Jun 2012 04:32 AM PDT Geçenlerde bir okuyucumdan bir e-posta aldım. İletisinin bir bölümünde şöyle yazmış: “Mağrur programcı ustalar sizin gibi mi? Burnundan kıl aldırmaz. Onlara da şöyle diyorum: Mağrur olma padişahım senden büyük Google var“. Bunu okuyunca aklıma bu yazıyı yazmak geldi. Ninem bize ufakken “benlik gütmeyin yavrularım, güzel bir şey değil” derdi. Yıllar sonra ne demek istediğini anladım. […]
|
|
Melek Programcılar ve Şeytan Yatırımcılar Posted: 31 May 2012 02:42 AM PDT Melek yatırımcıları (business angels) bilirsiniz; hani şu yeni kurulmuş firmalara (startup) yatırım yapan şahıslar. Melek programcıları bilir misiniz? Bunlara gelmeden önce şeytan yatırımcıları açıklamam gerekiyor. Melek yatırımcıların yanında bir de şeytan yatırımcılar (business devils) vardır. Bunlar da melek yatırımcılar gibi yatırım yaparlar, ama niyetleri iyi değildir. Maksatları bellidir; kısa zamanda firmayı satıp (exit), para yapmak. […]
|
|
Neden Java Kullanıyorsunuz Sorusunu Sorulduğunda Hangi Cevabı Verirsiniz? Posted: 29 May 2012 04:57 AM PDT Bu soru BTSoru.com’da soruldu. Benim cevabım şu şekilde oldu: Her platformda çalışır; sunucu mimarisinden bağımsızdır. Otomatik hafıza yöntemine sahiptir. Otomatik exception handling mekanizmasına sahiptir. Statik veri tipleri kullanılır. Bu kodun Compiler tarafından optimize edilmesini kolaylaştırır, compile işlemi esnasında hataların ortaya çıkmasını sağlar, IDE bünyesinde auto completion yapılmasını mümkün kılar. Hangi platform olursa olsun bir int […]
|
|
JVM Nasıl Çalışır Yazı Serisi – Old Generation Parallel Garbage Collector Hatası Posted: 27 May 2012 04:34 PM PDT Eğer özellikle bir Garbage Collector türü seçimi yapılmadı ise, 2 GB ve üzeri ve Windows işletim sistemi ile çalışmayan sunucularda JVM otomatik olarak paralel çalışan Garbage Collector’ü kullanıyor (-XX:UseParallelGC). Bu Garbage Collector sadece Young Generation üzerinde paralel, Old Generation için kullanılan Garbage Collector ise dizisel (serial) çalışıyor. Her iki heap alanında da paralel çalışan Garbage […]
|
|
Yeni Bir Programlama Dilini Öğrenmenin En Kolay Yolu Posted: 25 May 2012 08:09 AM PDT Geçenlerde bir Abap kitabı aldım. Güya Abap ögreneceğim! Abap SAP tarafından geliştirilmiş bir programlama dili ve SAP’nın ERP sistemlerini programlamak için kullanılıyor. İlk yüz sayfayı hızlıca geçtim. İlk “Merhaba Dünya” programımı yazdım. Diğer dillerden fazla bir farkı yok. İşte bildiğin bir dil. Geriye 1150 sayfa kaldı. Gel de oku bakalım. Movitasyonum dibe vurmuş durumda. Masamda […]
|
|
JVM Nasıl Çalışır Yazı Serisi – Çöplerin Efendisi Posted: 17 May 2012 03:56 AM PDT Java programcısının çok sadık bir hizmetçisi var. Her türlü çöplüğü, pisliği arkasından devamlı toplar, hiç sesini çıkarmaz. Çöplerin efendisidir, ama bir o kadar da mütevazidir. Kimseye belli etmeden işini görür. Bu yüzden birçok Java programcısı onun farkında bile değildir. Ama o işini yapmasa Java programcısının hali çok vahim olur, C/C++ ile kod yazan meslektaşlarından bir […]
|
|
Posted: 14 May 2012 09:11 AM PDT Programcılık Sanat mı, Zanaat mı? başlıklı yazıma gelen yorumlar, programcılığın sanat olduğu yönünde. Bunun aksini düşünenler de var. Programcılığın bir sanat olarak algılanması subjektif ve bir yanılgıdır. Programcılığın bir sanat olmadığının altını bu yazımla tekrar çizmek istedim. Sanat ve sanat eserleri görecelidir. İnsanlik var olduğundan beri sanat vardır, ama hala bu konudaki tartışmalar son bulmamıştır. […]
|
|
Posted: 12 May 2012 10:27 AM PDT Herhangi bir Java sınıfından new operatörü ile bir nesne oluşturulduğunda, bu nesnenin bilgisayarın hafızasında konuşlandırıldığı alana Java Heap adı verilir. Java Heap JVM tarafından oluşturulur ve aşağıdaki hafıza alanlarından oluşur: Eden – new operatörü ile oluşturulan tüm nesneler önce bu hafıza alanında oluşturulur. Survivor – nesneler old heap hafıza alanına transfer edilmeden önce bir müddet […]
|
|
JVM (Java Virtual Machine) Nedir? Posted: 12 May 2012 10:18 AM PDT JVM (Java Virtual Machine – Java Sanal İşlemcisi) C++ dilinde yazılmış bir programdır. Bir Java programı javac.exe ile derlendikten sonra byte code ismi verilen bir ara sürüm oluşur. Byte code, ana işlem biriminin (CPU – Cental Processing Unit) anlayacağı cinsten komutlar ihtiva etmez, yani klasik Assembler değildir. Java byte code sadece JVM bünyesinde çalışır. JVM, […]
|
|
Matrix’de Yaşayan Programcılar Posted: 12 May 2012 04:52 AM PDT Hemen hemen her programcının Matrix filmini seyrettiğini düşünüyorum. Star Wars gibi Matrix filmi de biz yazılımcılar için bir kült. Biraz abartı da olsa fikir olarak çok enteresan, en azından bir yazılımcı için. Matrix’de kullanılan yazılım sistemi dikkat çekiyor. En çok ilgimi çeken dejavü olarak isimlendirilen yazılım hataları (bug) ve Neo’nun bir tren istasyonunda hapis kalması […]
|
|
Posted: 09 May 2012 11:34 PM PDT Bu sabah yanımda kocaman, Coca Cola pet sişeleri taşıyan TIR vari bir araç durup, yol soruyor. Sürücünün neden navigasyon aleti yok diye düşünürken, bu yazıyı yazma fikri oluşuyor kafamda. Şimdi birkaç saniyeliğine bir dünya hayal edelim; İçinde IPhone ve Android akıllı telefonların olduğu, ama app denen birşeyin bilinmediği, bilgisayarların olduğu, ama işletim sistemi diye birşeyin […]
|
|
Posted: 08 May 2012 09:15 AM PDT Türkiye’de genç programcı adaylarının kariyer planlaması şu şekilde: Üniversite »» Birkaç yıl programcılık »» Proje yöneticiliği »» Bölüm yöneticiliği »» Bölüm müdürlüğü Benim kariyer planlamam şöyle: Üniversite »» Ömür boyu programcılık Ben programcıyım, yönetici değilim! Üniversitede eğitimini almadığım birşey nasıl olabilirim? Neden programcıların çoğu bir yerlere yönetici ya da müdür olmak istiyor? Bunun açıklaması kolay: […]
|
|
Programcılık Sanat mı, Zanaat mı? Posted: 07 May 2012 11:12 PM PDT Çoğu zaman aklımda olan bir soru var: „Programcılık bir sanat mıdır yoksa bir zanaat mıdır? Biz programcılar sanatkar mıyız yoksa zanaatkar mıyız? Vikipedi’ye baktığımızda sanat ve zanaat için aşağıdaki tanımlamayı yapmakta: Sanat en genel anlamıyla, yaratıcılığın ve hayalgücünün ifadesi olarak anlaşılır. Tarih boyunca neyin sanat olarak adlandırılacağına dair fikirler sürekli değişmiş, bu geniş anlama zaman […]
|
|
Ekibin Dikkati ve Saygısı Nasıl Kazanılır? Posted: 05 May 2012 01:11 AM PDT Her programcı yeni bir ekibe dahil olduğunda kendisini ispatlamak zorundadır. Bu gerçekleşene kadar ekip içindeki diğer programcılar yeni programcıyı dikkate almazlar. Birilerinin ekibe dahil olduğunu beyinlerinin en arkasında çalışan bir thread ile belki farkederler, ama bunu dikkate almadan günlük işlerine devam ederler. Yeni programcıya kendisini ispatlayana kadar pek ekibin bir parçası olarak bakmazlar. O yokmuş […]
|
|
Eşli Programlama, Code Review, Code Retreat ve Adada Yaşayan Programcılar Posted: 15 Apr 2012 12:54 PM PDT Bir programcıyı alıp bir adaya koysanız, diğer insan ve progcılarla bağlantı kurmasını engelleseniz, kendi başına çalışmasını ve kendisini geliştirmesini isteseniz, bu programcı programcılık konusunda nasıl bir gelişme sağlardı? Eğer programcıya o imkanı sağladıysanız ve kitap okuma alışkanlığı varsa bol bol kitap okuyacaktır. Kitap okumaktan canı sıkıldığında kod yazacaktır. Kod yazmaktan canı sıkıldığında tekrar kitap okuyacaktır. […]
|
|
İnşaat ve Yazılım Mühendisleri Arasındaki Fark Posted: 15 Apr 2012 12:58 AM PDT İnşaat mühendisleri: Sıkıysa çok dikkatli çalışmasınlar. En ufak bir yanlış statik hesap yorumlaması bile binanın yıkılmasına sebep olabilir. Binayı sadece bir kez inşa edebilirler. Netice hoşlarına gitmeyince, boz yeniden yap yapamazlar, yani tek bir şansları var. İnşaatın maliyeti çok yüksektir. Herşey buna odaklı önceden planlanır ve uygulanır. İnşaat mühendisi ne yapacağını önceden en ince detayına […]
|
|
Posted: 14 Apr 2012 08:53 AM PDT Batan projeleri ben batan gemilere benzetiyorum. Batmaya meğil gösteren bir gemi nasıl bunu belli ediyorsa, batmaya meğilli bir yazılım projesi de parmak kaldırıp, dikkat ben batıyorum der. Bir projenin batacağı nasıl anlaşılır? Şöyle: Big design up front olarak isimlendirilen, kahin vari, bugünden yarının nasıl olacağını bilme kibiri ile tüm yazılım mimarisi ve tasarımının yazılım öncesi […]
|
|
Kod Kata ve Pratik Yapmanın Önemi Posted: 07 Apr 2012 03:28 AM PDT Bizim ailede müzisyen geni var, babamdan bana geçmiş olsa gerek. Babam çok iyi bir ses sanatçısıdır. Keşke benim de onun kadar güzel sesim olsa diye düşünmüşümdür her zaman. Ama ne yazık ki yaratıcının benimle olan planları başka türdenmiş. İyi bir dinleyici olduğumu düşünüyorum. TSM parçalarını seslendirmeye çalıştığımda babam, detone olmadığımı söyler. Ama sesimin ne kadar […]
|
|
Posted: 05 Apr 2012 01:25 PM PDT Son zamanlarda yazılımla yakından ya da uzaktan ilişkisi olan herkesin ağzında olan kelime; çeviklikten bahsediyorum. İngilizce de agile, lean gibi kavramlar kullanılıyor ve artık her şey için kullanılmaya başlandı. Gören de zannederki artık her proje çevik yazılım yöntemleri ile yapılıyor, her şey yolunda. 2010 senesinde Londra’da yapılan Domain Driven Design exChange konferansında Eric Evans, yazılımda […]
|
|
Programcılar yazar olsalardı keşke! Posted: 28 Feb 2012 02:44 AM PST Birçok programcının büyük bir büroda çalıştığını düşünelim ve böyle bir ortama girdiğimizi. Programcı olduklarını bilmiyoruz, ne yaptıklarını da. Bu çalışanların ne yaptığını düşünürdük? Büyük ekranlarda devamlı birşeyler yazdıklarını gözlemleyip yazar olduklarını düşünürdük belki. Birşeyler yazana yazar denir. Bu bir roman, bir ders kitabı ya da bir yemek tarifi olabilir ya da bir kod parçası. Dışardan […]
|
|
Posted: 30 Dec 2011 01:25 AM PST SOLID (Single responsibility, Open-closed, Liskov substitution, Interface segregation ve Dependency inversion) yazılım tasarım prensipleri için kullanılan bir kısaltmadır. Yazılım yaparken SOLID uygulandığı taktirde bakımı ve geliştirilmesi kolay yazılım sistemleri oluşturmak mümkündür. En verimli hali test güdümlü yazılım ile uygulanır. S SRP Single Responsibility Principle Her yazılım biriminin (sınıf, nesne, metot) tek bir […]
|
|
Parametrik Konstruktör (Parameterize Constructor) Posted: 29 Dec 2011 02:40 AM PST Bir sınıf konstruktörü bünyesinde oluşturulan nesne, bu sınıfın test edilmesini zorlaştırır. Bunun bir örneğini EmployeeManager sınıfında görmekteyiz. Sınıf değişkeni olan dao konstruktör bünyesinde oluşturulmaktadır. EmployeeManager sınıfının test edilebilmesi için EmployeeDao‘nun kullanılması zorunludur. EmployeeDao burada dolaylı bir bağımlılık teşkil etmektedir. Büyük bir ihtimalle EmployeeDao sınıfı çalışır durumda olan bir veri tabanına ihtiyaç duymaktadır. Bu durum EmployeeManager […]
|
|
Metot Düzenleme (Compose Method) Posted: 29 Oct 2011 11:52 AM PDT |
|
Yeni Sınıf Oluşturma (Extract Class) Posted: 29 Oct 2011 10:55 AM PDT Bir sınıfın yüzlerce ya da binlerce satırdan oluşmasının ana sebeplerinden birisi bu sınıfa birden fazla sorumluluğun yüklenmiş olmasıdır. Single Repsonsiblity (SRP) prensibinden de bildigimiz gibi her sınıfın sadece ve sadece bir sorumluluk alanı olmalıdır yani sınıf sadece bir iş yapmalıdır ve bu işlemi iyi yapmalıdır. Aşağıda yer alan Order sınıfı SRP ile uyumlu değildir. Yeni […]
|
|
Stable Abstractions Principle (SAP) – Stabil Soyutluk Prensibi Posted: 26 Oct 2011 01:05 PM PDT Bu yazıyı PDF olarak edinebilirsiniz.
|
|
Stable Dependencies Principle (SDP) – Stabil Bağımlılıklar Prensibi Posted: 26 Oct 2011 01:00 PM PDT Bu yazıyı PDF olarak edinebilirsiniz.
|
|
Acyclic Dependency Principle (ADP) – Çevrimsiz Bağımlılık Prensibi Posted: 26 Oct 2011 12:52 PM PDT Bu yazıyı PDF olarak edinebilirsiniz.
|
|
Common Closure Principle (CCP) – Ortak Kapama Prensibi Posted: 26 Oct 2011 12:38 PM PDT Yazılım sistemi müşteri gereksinimleri doğrultusunda zaman içinde değişikliğe uğrar. Meydana gelen değişiklerin sistemde bulunan birçok paketi etkilemesi, sistemin bakılabilirliğini negatif etkiler. CCP’ye göre yapılan değişikliklerin sistemin büyük bir bölümünü etkilemesini önlemek için, aynı sebepten dolayı değişikliğe uğrayabilecek sınıfların aynı paket içinde yer alması gerekir. CCP daha önce incelediğimiz, sınıflar için uygulanan Single Responsibility (SRP) prensibinin […]
|
|
Koşullu Mantığın Komut İle Değiştirilmesi (Replace Conditional Dispatcher With Command) Posted: 26 Oct 2011 11:11 AM PDT Strateji tasarım şablonu için bakınız… Open Closed Principle tasarım prensibi için bakınız…
|
|
Metodu Metot Nesnesine Dönüştürme (Replace Method with Method Object) Posted: 24 Oct 2011 11:20 AM PDT Metodu Metot Nesnesine Dönüştürme (Replace Method with Method Object) refactoring metodu aşağıdaki durumlarda kullanılabilir: Çok sayıda lokal değişken Yeni Metot Oluşturma (Extract Method) refactoring metodunun kullanımını engelliyor. Uzun bir metot bünyesinde tanımlanan lokal değişkenlerin kapsama alanı (scope) geniş yani lokal değişkenler metodun sonuna kadar kullanılıyor. Metot SRP tasarım prensibi ile uyumlu degil yani refactor etmek […]
|
|
Posted: 20 Oct 2011 01:19 PM PDT Bu refactoring oturumu bünyesinde mevcut sınıfı aşağıda yer alan refactoring metotlarını kullanarak yeniden yapılandırdım: Koşulları Parçalarına Ayırma (Reverse Conditional) Yeni Metot Oluşturma (Extract Method) Geçici Değişkenlerin Sorguya Dönüştürülmesi (Replace Temp with Query) EOF (End Of Fun) Özcan Acar
|
|
Geçici Değişkenlerin Sorguya Dönüştürülmesi (Replace Temp with Query) Posted: 19 Oct 2011 10:06 AM PDT Bir metot bünyesinde bir işlemin sonucu geçici bir değişkende saklanabilir. Aşağıda yer alan kod örneğinde basePrice geçici bir değişkendir ve ihtiva ettiği değer fiyat * adet şeklinde hesaplanmaktadır. Replace Temp with Query refactoring metodunu kullanılarak geçici değişkenin değerini elde etmek için kullanılan yapı yeni bir metot bünyesinde taşınır. Geçici değişkenin kullanıldığı diğer alanlar metot ismiyle […]
|
|
Parametrele Değer Atamasının Kaldırılması (Remove Assignments to Parameters) Posted: 16 Oct 2011 12:52 PM PDT Metot imzasında yer alan parametrelere metot bünyesinde değer atanmamalıdır. Bu gibi atamalar istenmeyen sonuçlar doğurabilir. Remove Assignments to Parameters refactoring metodu kullanılarak bu tür parametre değer atamaları geçici degişkenlere yapılmalıdır. Yukarda yer alan metot Remove Assignments to Parameters uygulandığı taktirde aşağıdaki yapıya sahip olacaktır. Metot bünyesinde result isminde yeni geçici bir değişken tanımlanmış ve böylece […]
|
|
Yeni Metot Oluşturma (Extract Method) Posted: 16 Oct 2011 08:59 AM PDT Uzun metotları daha okunabilir ve kompak hale getirmek için Extract Method refactoring metodunu kullanabiliriz. calculatePrice metodu bünyesinde ülkeye bağlı olarak katma deger vergisi oranı (taxRate) tespit edilmektedir. Bu işlemi aşağıdaki şekilde başka bir metot bünyesine alarak, calculatePrice metodunu küçültebiliriz. Bu refactoring metodunu kullanırken seçtiğimiz metot isimlerinin, işlemin nasıl yapıldığını değil, hangi işlemin yapıldığını yansıtmasına dikkat […]
|
|
Koşulları Parçalarına Ayırma (Reverse Conditional) Posted: 15 Oct 2011 10:34 AM PDT TaxCalculator sınıfı, uygulamanın kullanıldığı ülkeye bağlı olarak katma değer vergisini ihtiva eden fiyatı hesaplamak için kullanılmaktadır. calculate gibi metotlarda karşılaştığımız en büyük sorunlardan birisi if/else blokları içinde mantıksal operatörler kullanılarak bir takım koşulların tanımlanması ve bu koşullara bağımlı olarak bazı işlemlerin yapılmasıdır. Bu tür bir programlama tarzı ne yazık ki uzun ve anlaşılması zor metotların […]
|
|
Posted: 09 May 2011 02:47 AM PDT Bu aralar bir Corba projesinde çalışıyorum. Corba teknolojisinde interface tanımlama dili olarak IDL kullanılıyor. Eğer bir Corba servisine erişimi sağlamak için size bir IDL verildi ise, bu IDL´i kullanarak client sınıflarını oluşturabilirsiniz. Bu işlem için aşağidaki sınıfı oluşturdum. Bu implementasyon Sun JDK bünyesinde bulunan com.sun.tools.corba.se.idl.toJavaPortable.Compile ve IBM JDK bünyesinde bulunan com.ibm.idl.toJavaPortable.Compile sınıflarını kullanarak client sınıflarını […]
|
|
Posted: 06 May 2011 09:50 AM PDT Bugün Amazon.com’dan sipariş ettiğim Kindle DX geldi. Tek klime ile harika. Daha önce uzunca bir zaman Irex Iliad kullandım. Ama Kindle DX onu arattırmayacak sanırım :) Teknik Özellikleri Boyutları 264 x 180 mm x 9,7 mm Ekran 9,7 Inch (24,6 cm) 824 x 1200 Pixel 150 ppi Hafıza 4GB CPU ARM 11 532 MHz Bateri […]
|
|
Posted: 28 Apr 2011 03:20 AM PDT Elipse altında Subversion pluginini kullanıyorsanız, bir Subversion repositorisine bağlanmak için kullandığınız şifreyi nasıl değiştirebileceğinizi merak etmiş olabilirsiniz. Eclipse altında bu şifreyi değiştirmek mümkün değil, çünkü plugin şifreyi %APPDATA%\Subversion\auth (Linux altında ~/.subversion/auth) altında saklıyor. Bu dizini sildiğiniz taktirde, tekrar şifreyi girme panelini görebilirsiniz.
|
|
Posted: 24 Apr 2011 11:10 PM PDT Dün kızıma lego parçalarından oluşan bir set aldım. Bu sabah beraber lego parçalarından kaleler yaparken birşeyin farkına vardım. Yazılım mühendisleri olarak çok soyut şeylerle ugraşıyoruz. Artık soyutluk seviyesi öyle bir hal almış ki, geçenlerde kendimi CPU içide yer alan registerlerin Assembler kullanılarak programlanmasından bahseden bir programcı hakkında “bu kadar low level işlerle uğraşılır mı ya” […]
|
|
Posted: 24 Apr 2011 12:43 AM PDT 4.4.2011 tarihinden itibaren İsviçre’nin Zürich kentinde bulunan Credit Suisse bankası için freelance danışman olarak çalışmaya başladım. Banka bünyesindeki uygulamaların çoğunu IBM Mainframe sistemleri üzerinde çalışan PL/1 uygulamaları oluşturuyor. Bu uygulamalar Iona firmasının Corba ORB (Object Request Broker) ürünü kullanılarak diğer sistemler tarafından kullanılır hale getirilmiş. Webservis teknolojilerinin gelişmesi ile Corba teknolojileri yanında Webservis teknolojileri de […]
|
|
Posted: 17 Apr 2011 02:42 AM PDT Yaklaşık 10 aylık bir çalışmanın sonunda 1 şubat 2011 tarihinde İşbankası Corebanking projesindeki görevimi tamamladım. Corebanking projesi, İsbankası’nın 2 sene önce başlatmış olduğu, Cobol ile geliştirilen Mainframe sistemlerinden açık sistemlere (Java, J2EE) geçişi öngören bir proje. Projenin nihayi amacı uzun vadede bankanın alt yapısını tamamen açık sistemlere taşımak ve Mainframe sistemlerini devre dışı bırakmak. Danışman, […]
|
|
Posted: 26 Oct 2010 01:13 AM PDT Danışman olarak çalıştığım bir projenin modüllerini Maven2 kullanacak şekilde yeniden yapılandırdım. Birçok JAR ve WAR dosyası bir araya gelerek büyük bir EAR dosyası oluşturdu. JAR ve WAR’ları oluştururken bir sorun yaşamadım, lakin EAR dosyasını alırken durum farkli idi. EAR projesi için maven clean install komutunu kullandığımda aşağıdaki hata oluşuyordu: EAR dosyası birçok JAR ve WAR’dan […]
|
|
Posted: 25 Oct 2010 11:21 PM PDT Bug ingilizce dilinde böcek, bilgisayar dillerinde bir program hatası anlamına geliyor. İlk program bug’ı 1947 yılında Grace Murray Hopper’in Harvard Üniversitesi’nde kullandığı Mark II Aiken isimli röle (relay) (resim 1) bazlı hesaplayıcıda (primitif bir bilgisayar) bulundu. Resim 1 9 eylül 1947 tarihinde hesaplayıcının programlandığı şekilde çalışmadığı, sorun çıkardığı görüldü Yapılan araştırma üzerine F panelindeki 70 […]
|
|
Posted: 23 Oct 2010 09:25 AM PDT Çoğu zaman programcı adaylarının piyasada en çok talep gören programramlama dilini seçip, bu dili öğrendikleri malum. Bu doğal bir seçim; talep olan yerde arzın bedeli olur. Bu bedel programcının iyi bir maaş ile hayatını sürdürmesi anlamına gelir. Bilindiği üzere son zamanların en popüler ve talep edilen dili Java. İnternetteki birçok istatiktik Java’nın bir numara olduğunu […]
|
|
Common Reuse Principle (CRP) – Ortak Yeniden Kullanım Prensibi Posted: 24 Jul 2010 12:41 PM PDT Bu prensip hangi sınıfların aynı paket içinde yer alması gerektiği konusuna açıklık getirir. CRP’ye göre beraberce tekrar kullanılabilir yapıda olan sınıfların aynı paket içinde olması gerekir. Bu yazıyı PDF dosyası olarak aşağıdaki linkten edinebilirsiniz. EOF (End of Fun) Özcan Acar
|
|
Posted: 24 Jul 2010 12:20 PM PDT Mevcut bir sınıf hiyerarşisini ya da sınıfın yapısını değiştirmeden, oluşturulan nesnelere yeni özelliklerin eklenme işlemini gerçekleştirmek için Decorator tasarım şablonu kullanılır. Alt sınıfların oluşturulması yöntemiyle, sınıflara yeni özelliklerin eklenmesi, daha sonra sisteme eklenecek alt sınıflar için değiştirilmesi zor kalıpların oluşmasını beraberinde getirir. Bu durumda, üst sınıflarda tanımlanmış olan bazı özellikler statik ve alt sınıflar için […]
|
|
K.Maraş Sütçü İmam Üni. – Bilge Programcı – Nasıl Uzman Yazılımcı Olunur ? Posted: 02 Jul 2010 10:47 PM PDT 25 mart 2010 tarihinde K.Maraş Sütçü İmam Üniversitesi’ne bir sunum yapmak için davet edildim. Seminer videosunu, resimleri ve sunumu bu yazıda bulabilirsiniz. Özcan Acar Sunum dosyasını PDF olarak aşağıdaki linkten edinebilirsiniz. EOF (End Of Fun) Özcan Acar
|
|
Posted: 26 May 2010 07:42 AM PDT Bir Java sınıfının hangi Java compiler versiyonu ile derlendiğini görmek için javap komutu aşağıdaki şekilde kullanılır. thumbler.Story sınıfı için major number 50, minor number 0 görünmektektedir. Aşağıdaki listeden bu sınıfın hangi Java compiler versiyonu ile derlendiğini anlamak mümkündür. * Java 1.2 uses major version 46 * Java 1.3 uses major version 47 * Java 1.4 […]
|
|
Bilge Programcı – Nasıl Uzman Yazılımcı Olunur? Seminerinden İzlenimler Posted: 22 May 2010 04:00 AM PDT 24 mart 2010 tarihinde Elazığ Fırat Üniversitesi’ne bir sunum yapmak için davet edildim. Seminer videosunu, resimleri ve sunumu bu yazıda bulabilirsiniz. Özcan Acar Sunum dosyasını PDF olarak aşağıdaki linkten edinebilirsiniz. EOF (End Of Fun) Özcan Acar
|
|
Posted: 12 Mar 2010 03:21 AM PST 15 mart’dan 30 mart 2010’a kadar, üniversitelerde ücretsiz KurumsalJava.com seminerleri düzenlemek üzere İstanbul’da bulunacağım. İlgilenler bana acar[AT]unitedinter.net adresinden ulaşabilirler. ___________________________ Özcan Acar Bilgisayar Mühendisi Sun Java Champion Sun Certified Architect (SCEA 5) http://www.ozcanacar.com http://www.KurumsalJava.com
|
|
Posted: 06 Mar 2010 10:26 AM PST Java ile yazılımı tam anlamıyla kavramak isteyenler mutlaka bu kitabı okumalı!
|
|
Java JVM’i (Java Virtual Machine) Anlamak Posted: 06 Mar 2010 09:59 AM PST Java JVM’i tam anlamıyla kavramak isteyenler mutlaka bu kitabı okumalı! Sun sayfalarından PDF olarak edinebilirsiniz.
|
|
Posted: 06 Mar 2010 09:52 AM PST Java dilini tam anlamıyla kavramak isteyenler mutlaka bu kitabı okumalı! Sun sayfalarından PDF olarak edinebilirsiniz.
|
|
Posted: 23 Feb 2010 03:39 AM PST Java_tr grubunda aşağıdaki yer alan soru soruldu. Bu soru ve benim bu konudaki düşüncelerim aşağıda yer almaktadır. Java’da bulmaca sevenlere; Aşağıda ki kod parçası için çıktı ne olur, “finalized” yazar mı? Constructor’ýnda exception fırlatmış bir nesnenin finalize işleminden geçmesini bekler misiniz? Benim verdiğim cevap şu şekildedir: Java’da finalize() kullanılması doğru değildir, çünkü JVM’in finalize metodunu […]
|
|
Java’da Final Anahtar Kelimesi Posted: 17 Feb 2010 03:21 PM PST Java’da final anahtar kelimesi aşağıda yer alan yapılar için kullanılabilir: Final sınıf değişkenleri: Final olan bir sınıf değişkenine sadece bir kere değer ataması yapilabilir ve bu atama sadece sınıf konstrüktöründe gerçekleşebilir. Final metot parametreleri: Final olarak tanımlanmış bir metot parametresine sadece bir kere değer atanabilir. Metot parametrelerinin tamamen final olarak tanımlamış olmalarında büyük fayda vardır. […]
|
|
Posted: 06 Feb 2010 02:22 AM PST Java 1.5 ile kullanıma sunulan ve covariant return type ismini taşıyan bir yapı mevcuttur. Java 1.5 öncesi bir alt sınıf, bir üst sınıfın sahip olduğu metodu yeniden implemente etmek (method overriding) istediginde, bu metodun geri döndürdüğü veri tipinin, üst sınıftaki metot ile aynı olması gerekmekteydi. Bunun bir örneği aşağıda yer almaktadır. Soyut (abstract) olan AbstractController […]
|
|
Java Enum ile Singleton Tasarım Şablonu Posted: 02 Feb 2010 12:32 AM PST Daha önceki bir yazımda Singleton tasarım şablonunun ne olduğunu ve Java’da nasıl kullanıldığını yakından incelemiştik. Bu yazımda Java 1.5 den itibaren kullanıma sunulan Enum sınıfı ile singleton tasarım şablonunun nasıl kullanılabileceğine değinmek istiyorum. Öncelikle küçük bir örnek üzerinde singleton bir nesnesinin nasıl oluşturulacağına bir göz atalım: MySingleton sınıfının sahip olduğu konstruktör private olduğu için bu […]
|
|
Oracle’ın Sun ve Java için stratejik planları hakkında ip uçları Posted: 01 Feb 2010 11:20 PM PST JUG (Java User Group) e-posta listesinde olduğum için bana ulaşan bir e-postayı sizlerle paylaşmak istedim. E-posta Oracle’ın Sun ve Java için stratejik planları hakkında ip uçları verebilir… ———————————– This is the only statement that I am aware of thus far: “Oracle plans to increase investment in Java, Sparc, Solaris, and MySQL technologies which is expected […]
|
|
Posted: 15 Jan 2010 07:48 AM PST DBUnit JUnit ile entegre edilerek entegrasyon ve regresyon testlerinin JUnit testleri olarak implemente edilmesi mümkündür. DBUnit JUnit entegrasyonu aşağıdaki şekilde gerçekleştirilebilir. Bilgibankası olarak örnekte HSQLDB kullanılmıştır (bakınız HSQLDB JUnit entegrasyonu). Verilerin dbunit-dataset.xml dosyasında tanımlanmıs olması gerekmektedir. setUp() metodu her test öncesi JUnit frameworkü tarafından koşturulacağı için istenilen veriler test öncesi bilgibankasına eklenmiş ve regresyon testleri […]
|
|
Posted: 15 Jan 2010 07:36 AM PST Oluşturduğum entegrasyon JUnit testlerinde, testler öncesi verilerin bilgibankasına aktarılması gerekiyor. Aşağıda yer aldığı şekilde JUnit sınıfı bünyesinde HSQLDB serveri standalone modda çalıştırılabilir ve DBUnit ile veriler bilgibankasına eklenebilir.
|
|
SCEA 5 (Sun Certified Enterprise Architect) Kiti Posted: 09 Jan 2010 09:09 AM PST Daha önceki yazımda bildirdiğim gibi kısa bir zaman önce SCEA 5 sertifikasını aldım. Bugün Sun tarafından gönderilen sertifika kiti bana ulaştı. Kitin içeriği aşağıda yer alan resimlerde görülmekte.
|
|
SCEA 5 (Sun Certified Enterprise Architect) Posted: 29 Dec 2009 02:54 PM PST Bugün itibariyle SCEA 5 (Sun Certified Enterprise Architect) sertifikasını almış bulunuyorum. Bir seneye yayılan sertifikasyon sürecinde üç değişik sınav yaparak, bu sertifikayı edindim. Gerçekten kolay değildi, bir de JEE 5 alanında uzman olduğumu düşünürdüm ;-) SCEA 5 sertifikası Sun tarafından sunulan Java sertifikasyon programının en en son kademesinde bulunan ve yazılım mimarisi ile uğraşan yazılımcıların […]
|
|
Türkiye’den İlk Java Champion Özcan Acar Posted: 22 Dec 2009 03:20 PM PST Bugün Java Champion olarak seçildim. Benim için çok mutlu bir gün, çünkü bir Java yazılımcısının edinebileceği en yüksek ünvanlardan birisi Java Champion ünvanıdır. James Gosling, Bill Burke, David Flanagan ve Josh Bloch gibi tanınmış sahışların Java Champion ünvanına sahip olduklarını ve dünya çapında 100 civarında Java Champion ünvanına sahip yazılımcının olduğunu düşünürsek bu ünvanın ne […]
|
|
Posted: 21 Dec 2009 02:38 PM PST Sürücü üzerinde (disk) ya da hafıza (memory) da yer alan ve verinin depolandıktan sonra alındığı ön belleğe write through cache ismi verilmektedir. Bu şekilde veri deposuna eklenmiş olan veri ön belleğe de eklenmiş olur. Write through cache sayesinde verilerin, veri deposuna eklenme performansı artırılmazken verilerin tekrar edinilme işlemi hızlandırılmış olur.
|
|
Posted: 09 Dec 2009 02:09 AM PST 21.7.2009 tarihinden itibaren Schwäbisch Hall (Almanya) şehrinde bulunan Kreditwerk firması için JEE danışman ve yazılım mimari (freelancer) olarak işe başladım. 40 iş günü olarak anlaşdığım proje’de bugün itibariyle 5,5 ayı doldurmuş bulunuyorum :) Bu son iki yılın projelerinde az rastlanan bir durum değil. Projeye 40 ya da 60 iş günü olarak alınırsınız ve performansınıza ve […]
|
|
Intercepting Filter Tasarım Şablonu Posted: 09 Dec 2009 01:23 AM PST Front Controller tasarım şablonunda, kullanıcıdan gelen isteklerin (request) merkezi bir yerde toplanarak, işlem yapıldığını daha önce görmüştük. Intercepting Filter tasarım şablonu ile, kullanıcının isteği (request) işleme alınmadan önce filtreler kullanılarak süzgeçten geçirilir. Örneğin bir filtre ile kullanıcının işlem öncesi login yaptığını konrol edebiliriz. Filtremiz, session (HttpServletSesion) içinde login bilgilerini bulamadığı taktirde, kullanıcıyı login sayfasına yönlendirebilir. […]
|
|
Reuse-Release Equivalence Principle (REP) – Tekrar Kullanım ve Sürüm Eşitliği Posted: 09 Dec 2009 01:03 AM PST Program modülleri paketler (packages) kullanılarak organize edilir. Paketler arasında sınıfların birbirlerini kullanmalarıyla bağımlılıklar oluşur. Bunun bir örneği resim 1 de yer almaktadır. Eğer paket B bünyesindeki bir sınıf paket A bünyesinde bulunan bir sınıf tarafından kullanılıyorsa, bu paket A’nin paket B’ye bağımlılığı olduğu anlamına gelir. Bu tür bağımlılıkların oluşması doğaldır. Amaç bu bağımlılıkları ortadan kaldırmak […]
|
|
JPA Anotasyonları ve Dinamik Tablo İsmi Posted: 25 Nov 2009 12:54 AM PST Projelerde komponent tabanlı çalışmaya özen gösteriyorum. Komponent olarak geliştirdiğim bir modülü, konfigürasyon değişikliği yaparak başka bir projede kullanabilmeliyim. Komponentler kodun tekrar kullanımını (reuse) ve programcının daha az kod yazmasını mümkün kılar. Komponent bünyelerinde Hibernate kullanarak, komponent verilerini bilgibankasında sakliyorum. Şu an geliştirdiğim JugTR.org projesinde JPA anotasyonlarını kullandım. Aşağıda blog kayıtlarını temsil eden Blog Entity sınıfı […]
|
|
Apache ile Tomcat Arasında Reverse Proxy Oluşturma Posted: 22 Nov 2009 05:13 AM PST JugTR.org projesi Tomcat içinde deploy edilen bir Java 6 web aplikasyonu (Servlet 2.5 spec). Bu aplikasyona http://www.jugtr.org adresi üzerinden ulaşabilmek için Tomcat’in 80 numaralı port üzerinde çalışması gerekmektedir. Kullandığım server üzerinde 80 numaralı portta Apache çalışmakta. Bu durumda Tomcat’i 80 numaralı port üzerinde çalıştırmam mümkün değil. 80 haricinde herhangi bir port seçerek, JugTR.org aplikasyonunu deploy edebilirim, […]
|
|
Posted: 21 Nov 2009 05:25 AM PST Geçen hafta Belçika’da düzenlenen Devoxx konferansına katıldım. Java ile ilgilenenlerin mutlaka katılması gereken bir konferans. Bir hafta boyunca değişik konularda, konularında uzman şahısların sunum yaptıkları bu konferansta James Gosling, Robert C. Martin, Chris Richardson, Scott Ambler gibi ustaları dinleme ve onlarla sohbet etme fırsatı bulabiliyorsunuz. Aşağıda yer alan fotografları Devoxx’da çektim. Resim 1 Resim 1 […]
|
|
Posted: 17 Nov 2009 06:15 AM PST YAGNI = You Ain´t Gonna Need It = İhtiyacın Olmayan Birşeyi Oluşturma! Extreme Programming prensiplerinden birisi olan YAGNI, JUnit test karşılığı olmayan ve ihtiyaç duyulmayan program kodunun programcılar tarafından oluşturulmamaları gerektiğini ifade eder. Test güdümlü çalışıldığı taktirde YAGNI prensibi uygulanmış olur. Testlerin olmadığı yerde YAGNI vardır :) EOF ( End Of Fun) Özcan Acar
|
|
Posted: 17 Nov 2009 05:58 AM PST KISS = Keep It Simple, Stupid (KISS) = Mümkün Olan En Basit Çözümü Seç! KISS prensibine göre bir programcı, mevcut bir sorunu çözerken mümkün olan en basit çözümü seçmelidir. En basit çözüm genelde en optimal çözümdür. Genelde programcılar bir sorunun en basit çözümünü basit ve yetersiz gördüklerinden daha karmaşık çözümler üretirler, ama bilmezler ki KISS […]
|
|
Posted: 17 Nov 2009 05:20 AM PST DRY = Don’t Repeat Yourself = Kendini Tekrarlama! DRY prensibine göre programcının kodlama esnasında kod tekrarlarından (code duplication) sakınması gerekmektedir. Kodun kendini tekrarlaması (örneğin copy-paste metodu kullanılarak) yazılım sisteminin genelde bakımını ve geliştirilmesini zorlaştırır. Bunun önüne geçmek için azimle DRY prensibinin uygulanması gerekmektedir. EOF (End Of Fun) Özcan Acar
|
|
Posted: 17 Nov 2009 01:43 AM PST Herhangi bir araç kullanmadan UML sequence diagramı çizmek istiyorsanız, Websequencediagrams.com sitesini bir deneyin :) EOF (End Of Fun) Özcan Acar
|
|
Interface Segregation Principle (ISP) – Arayüz Ayırma Prensibi Posted: 17 Nov 2009 01:08 AM PST Birbiriyle ilişkili olmayan birçok metodu ihtiva eden büyük bir interface sınıf yerine, birbiriyle ilişkili (cohesive) metotların yer aldığı birden fazla interface sınıfı daha makbuldür. ISP uygulanmadığı taktirde, birden fazla sorumluluğu olan interface sınıflar oluşur. Zaman içinde yüklenen yeni sorumluluklarla bu interface sınıflar daha da büyür ve kontrol edilemez bir hale gelebilir. Bunun bir örneğini resim […]
|
|
Test Güdümlü Yazılımın Tasarım Üzerindeki Etkileri Posted: 17 Nov 2009 12:37 AM PST Yazılımcı olarak çalıştığım projelerde geleneksel ve çevik yazılım süreçleri hakkında tecrübe edinme firsatı buldum. En son kitabım bir çevik süreç olan Extreme Programming hakkındadır. Edindiğim tecrübeler doğrultusunda çevik süreçlerin, klasik yazılım süreçlerine nazaran bakımı ve geliştirilmesi daha kolay yazılım sistemlerinin oluşturulmasında daha avantajlı olduğunu söyleyebilirim. Bu yazımda sizelere test güdümlü yazılım sürecinin, yazılım tasarımı üzerindeki […]
|
|
Posted: 17 Nov 2009 12:31 AM PST Daha önceki bölümlerde Abstract Factory tasarım şablonu ile değişik nesne ailelerinden nasıl nesneler üretildiğini incelemiştik. Builder tasarım şablonu da Abstract Factory tasarım şablonunda oldugu gibi istenilen bir tipte nesne oluşturmak için kullanılır. İki tasarım şablonu arasındaki fark, Builder tasarım şablonunun kompleks yapıdaki bir nesneyi değişik parçaları bir araya getirerek oluşturmasında yatmaktadır. Birden fazla adım içeren […]
|
|
Service Locator Tasarım Şablonu Posted: 30 Oct 2009 03:01 AM PDT Business Delegate örneğinde, Service Locator Tasarım şablonunun nasıl uygulandığını görmüştük. Service Locator, işletme (business) katmanında bulunan komponentlerin lokalizasyonu için kullanılır Bu yazıyı PDF olarak edinebilirsiniz. EOF (End of Fun) Özcan Acar
|
|
Business Delegate Tasarım Şablonu Posted: 30 Oct 2009 02:55 AM PDT Modern yazılım sistemleri birden fazla katmandan oluşur. Bu katmanlar her zaman aynı server üzerinde mevcut olmayabilir. Bu durumda bir katmandan diger katmana ulaşmak için remote call olarak isimlendirilen RMI operasyonları yapılır. Örneğin EJB teknolojisi ile hazırlanan komponentler birden fazla server üzerinde hizmet sunabilir. Bu komponentlere bağlanıp, işlem yapabilmek için RMI kullanılır. EJB sistemlerinde bazı işlemler […]
|
|
Dependency Inversion Principle (DIP) – Bağımlılıkların Tersine Çevrilmesi Prensibi Posted: 29 Oct 2009 02:23 AM PDT Bu prensibe göre somut sınıflara olan bağımlılıklar soyut sınıflar ve interface sınıflar kullanılarak ortadan kaldırılmalıdır, çünkü somut sınıflar sık sık değişikliğe uğrarlar ve bu sınıflara bağımlı olan sınıflarında yapısal değişikliğe uğramalarına sebep olurlar. Resim 1 de görülen yapı DIP prensibine ters düşmektedir, çünkü RemoteControl sınıfı somut bir sınıf olan TV sınıfına bağımlıdır. TV bünyesinde meydana […]
|
|
Liskov Substitution Principle (LSP) – Liskov’un Yerine Geçme Prensibi Posted: 29 Oct 2009 02:05 AM PDT Barbara Liskov tarafından geliştirilen bu prensip kısaca şöyle açıklanabilir: Alt sınıflardan oluşturulan nesneler üst sınıfların nesneleriyle yer değiştirdiklerinde aynı davranışı göstermek zorundadırlar. LSP’ye göre herhangi bir sınıf kullanıcısı, bu sınıfın alt sınıfları kullanmak için özel bir efor sarf etmek zorunda kalmamalıdır. Onun bakış açısından üst sınıf ve alt sınıf arasında farklılık yoktur. Üst sınıf nesnelerinin […]
|
| You are subscribed to email updates from KurumsalJava.com – Özcan Acar. |
To stop receiving these emails, you may unsubscribe now. |
| Email delivery powered by Google |