Search Results for: java'dan sonra

Java SE’den Sonra Ne Öğrenelim? İş Arayanlara Öneriler

Java ,

Sıklıkla, “hocam Java SE’yi biliyorum, şimdi üzerine ne öğrenmeliyim?” gibisinden sorulara muhatap oluyorum. Bu soruları soranların büyük bir kısmı ya yeni mezun ya da bir şekidle Java tarafına geçiş yapmaya çalışan ve kariyerinin başında olan, farklı teknolojileri kullanan yazılımcı arkadaşlar. Dolayısıyla bu konuyu hızlıca açıklığa kavuşturalım.

Bence öncelikle Java SE’yi bildiğinizden emin olun! Bu blogu takip edenler bilirler ki, bir başkasına sistematik olarak anlatamayacağınız şeyi bilmiyorsunuz demektir. Dolayısıyla bu blogda yazılmış Java öğrenmek üzerine pek çok yazıya ve Java Dersleri sayfasına bakılabilir. Eğer kendinizı Java SE konusunda çok iyi hissetmek istiyorsanız Java SE sertifikasyonunu almayı deneyebilirsiniz. Bu size neresinden baksanız altı ayınıza malolur ama sizi hem kendinize güven hem de iş bulma açısından çok güzel bir noktaya getirir. (Bu noktada bu blogda sertifikasyon konusu üzerine pek çok yazı yazıldığını hatırlatmak isterim.)

Mobil kısmı bir tarafa bırakırsak, kurumsal yani enterprise Java’dan bahsettiğimizde öncelikle web tarafından başlamakta fayda var gibi görünüyor. Java EE’nin web tarafında sonuçta servlet, JSP ve JSF var. Servlet ve JSP’lerin kullanımı gittikçe düşüyor. Özellikle servletlerin kullanımı düşüyor gibi görünse de hem aslında her şeyin temelinde olmasından dolayı hem de webin en temel protokolu olan HTTP’yi öğrenebilmek için servlet APIsini bilmekte fayda var. Bu sayede HTTP’nin yapısını, komutlarını, istek (request) ve cevap (response) nesnelerini, headerlarını, oturum (session) yapısını ve cookieleri öğrenmiş olursunuz. Sonrasında kullanımı servletlerden çok daha yaygın olan JSPlere geçip, EL ve JSTL’i de ele alıp, Java’da web tarafının temellerini güzelce öğrenebilirsiniz.

Temeller üzerine web tarafında kurgulanacak yapı bence MVC’dir. MVC, web tarafının en temel mimari kalıbı olup, hemen her web frameworkü tarafından uygulanmaktadır. Bu anlamda belki de en kolay öğrenilecek MVC frameworkü Spring MVCdir. Hem basit hem POJO yapısı hem de ayrı bir view teknolojisi barındırmaması açısından öğrenilmesi son derece kolaydır. Spring MVC’nin controller yapılarını ögrenerek ve JSP kullanarak hızlıca web uygulamaları yapabilirsiniz.

Eğer sertifika yolunda ilerliyorsanız, Java SE sertifikasından sonra Java’nın web teknolojilerinin sertifikasını almayı düşünebilirsiniz. Bu da sizin altı ay ya da bir senenizi alabilecektir, aklınızda bulundurun.

MVC konusunda Struts’ı da düşünebilirsiniz. Nispeten eski bir teknoloji olmasına rağmen hala pek çok yerde, özellikle 2000li yılların başında geliştirilmiş projelerde kullanılıyor. Spring MVC tabi olarak çok daha popüler ama Struts mimari açıdan daha şeffaf, arka planda ne olup bittiğini anlamak açısından daha keyifli ve ufuk açıcıdır. Her halükarda iyi bir MVC frameworkü hem size temel mimariyi öğretecek hem de CVnizde güzel duracaktır.

Spring MVC’ye çok iyi bir MVC alternatifi JSF olabilir. JSF aynı zamanda bir view teknolojisi de olduğundan pek çok farklı JSF bileşen kütüphanesi vardır. JSF öğrenmek demek aslında biraz da bu kütüphanelerden birisiyle çalışmak demektir. Bu anlamda öncelikle Java EE ile gelen referans JSF implementationu (mojorra) ile başlayıp sonrasında Türkiye’den arkadaşlarımızın başarıyla geliştirip, yazılım sektöründe sundukları Primefaces ile devam etmek güzel olacaktır. Bununla birlikte JSF, hayat döngüsü (life-cycle) Spring MVC’ye göre daha karmaşık ve soyut olduğundan, ayrıca event, validation vb. yapıları da deklaratif olarak hallettiğinden ögrenilmesi Spring MVC’ye göre daha zordur ve uzun zaman alır. Lakin bence JSF, Spring MVC’den çok daha güçlü ve hızlı geliştirmeye elveren bir teknoloji olduğundan, vakti olan ve zoru sevenlerin Spring MVC yerine JSF ile devam etmelerinde fayda vardır. Zaten piyasadaki eğilim de daha çok JSF yönündedir. Bu yüzden JSF’e giriş yapmış bir Javacının iş bulmada pek zorlanmayacağını düşünüyorum.

İster JSF ister Spring MVC kullanın, öğrenmeden kaçamayacağınız bir konu daha var: Nesneler arasındaki bağımlılıkları yönetmek için dependency injection (DI). İster Spring DI’yi öğrenin ister daha iyi bir alternatif ve yapı olan Java CDI öğrenin ama sadece web tarafında geliştirme yapsanız bile yüksek bir ihtimalle bir DI yapısı kullanacağınızı unutmayın.

Web tarafını müteakiben öğrenilecek bir başka konu da veri tabanı ile iletişimde bulunan kalıcılık (persistence) katmanına yönelik teknolojiler olabilir. JDBC, java SE’nin bu konudaki en temel bileşeni. Dolayısıyla JDBC’yi pişirmek, hatta Spring’in JDBC desteğini kullanmak ve orada DAO kalıbını uygulayacak şekilde programlarınızı kurgulamak bence iş bulmada çok temel bir kazanımdır.

JDBC’den sonra JPA’e girişmek, piyasada en çok kullanılan kalıcılık çerçevelerinden birini kullanmak anlamına geleceğinden iş bulma ihtimalinizi çok arttıracaktır. JPA, temelelrinin öğrenilmesi zor olmayan ama içine daldıkça karmaşıklaşan bir teknoloji olduğu içın temel eşleştirme (mapping) yapıları, EntityManager APIsi ile transaction yönetimini bilseniz size çok avantaj sağlayacak bir duruma gelebilirsiniz.

JPA ile uğraştıktan sonra gerektiğinde Hibernate’in native API’si ile de rahatlıkla uğraşabilirsiniz. Hibernate, JPA’den daha eski bir yapı ama kavramsal oalrak aynı işi yapıyorlar hatta çok benzer şekilde yapıyorlar. Bu yüzden bu durum iş bulma ihtimalinizi çok arttıracaktır.

Zorunlu olmamakla beraber, bütün bu konularla uğraşırken ilgili tasarım kalıplarını da yavaştan ele alıp, o konularda da bir şeyler öğrenirseniz mükemmel olacaktır.

Tabi yukarıda bahsettiğim teknolojilerde belli bir noktaya gelmek sizin bir senenizi rahatlıkla alacaktır. İşin içine sertifikasyonu da sokarsanız, sadece ilk yani Java SE sertifikasını almak bile rahatlıkla 6 ayınızı alabilir. Bu biraz da ne kadar vakit ayırabildiğinizle ilgili bir durumdur. Ama bence her halukarda bu korkulacak bir durum değildir çünkü gerek okulunuzun son senesinde, gerek ise okuldan sonra hasbel kader girdiğiniz ama çok da mutlu olmadığınız ilk işinizde kendinizi bu konularda geliştirecek zaman bulabilirsiniz.

Gördüğüm şu: bilen, iyi bir hedefe ve vizyona sahip ve kendine güvenen kişiler, iş tecrübeleri olmasa bile çok güzel işler bulmaya devam ediyorlar.

Toplam görüntülenme sayısı: 8696

Java Yavaş mı? : Java’nın Performansı Üzerine – IV

Java ,

Bir önceki yazıda Monte Carlo simulasyonu ile Pi sayısını hesaplama ve asal sayı bulma amaçlı iki algoritma üzerinden C++ ile Java’nın performanslarını karşılaştırmıştım. Sağolsun bazı okurlarım düşüncelerini iletirken, iki okurum da iki algortimayı kendi makinaların da deneyip sonuçlarını benimle paylaştılar. İki okurumun da sonuçları, benim elde ettiğimin tersine çıkmış durumda, yani onların elde ettiği ölçümlerde bu iki algoritmada C++, Java’dan daha hızlı çalışmış. Hatta kendileri benim bu sonuçları alırken nasıl bir konfigürasyona sahip olduğumu da sordular. Bu durumda ben de bu serinin dördüncüsü olarak yazdığım yazıyı bir öteye itip, araya bu yazıyı aldım.

Öncelikle açıkçası şunu ifade etmem gerekir ki benim “Java Yavaş mı? : Java’nın Performansı Üzerine” yazı dizisinde ispatlamaya çalıştığım şey Java’nın C++’tan hızlı olduğu değildir. Derdim hangisinin hızlı olup olmadığını da anlamak değildir. Bu yazılarda anlatmaya çalıştığım şey öncelikle “hız” kavramının muğlaklığı ve “dilin hızı” ile “uygulamanın hızı” kavramlarının arasındaki fark ve bu noktada mimarinin önemidir. Ve malesef bunlar, bu işin pratiğini yapanların kafasında çok da aydınlanmış kavramlar da değiller. Sonrasında ise hedefim, Java’nın yavaş olduğu iddiasının içinin dolu olmadığını göstermektir. Bunu da olabildiğince delilli yapmaya çalışıyorum, bu blogda devamlı yaptığım gibi. Zaten aşırı ideolojik bir ülkede olmamızdan dolayı üzerine kafa patlatılmış, delilli cümlelerle konuşma yerine kahvehane seviyesinde, bilgilesizce edinilmiş fikirlerle tartıştığımız için, bu dizide ben “Java yavaş” cümlesinin de tam da bu cinsten bir ifade ve delilsiz ve mesnetsiz bir inanış olduğu göstermeye çalışıyorum. Öte yandan 90’lı yılların başından bu yana bu sektörde olan birisi olarak zaten sadece iki algoritma çalıştırmakla diller arasında gerçek bir performans kıyaslaması olamayacağını biliyorum.

Bu açıklamadan sonra şimdi ben kendi kullandığım configürasyonlardan bahsedeyim.

  • Makinam, 16 GB RAM ve 8 çekirdekli i7 CPU’ya sahip, üzerinde El Capitan OS çalışan bir MacBook Pro.
  • C++ için  GNU g++ (GCC) 4.9.2 20141029 kullandım. Derleme komutu ise: g++ -O3 -std=c++11 -o SieveOfAtkin.out SieveOfAtkin.cpp
  • Java için ise Java(TM) SE Runtime Environment (build 1.8.0_45-b14), Java HotSpot(TM) 64-Bit Server VM (build 25.45-b02, mixed mode). Java ile compile ederken de çalıştırıken de hiç bir flag kullanmadım, tamamen varsayılan seçenekler geçerliydi.

Sieve Of Atkin algoritması için farklı n girdisi için mili saniye cinsinden yukarıdaki Java ve C++ konfigürasyonlarının sonuçları aşağıdadır. 5 defa çalıştırma sonucunda elde edilen ortalama çalışma süreleri şunlardır:

Program

10^6

 10^7 10^8 10^9

2*10^9
SieveOfAtkin.cpp

g++ -O3 -std=c++11

7

 69 1,021 18,434

46,246
SieveOfAtkin.java

16

 84 1.025 18,507

47,752

Yukarıdaki tablodaki ölçümlerden Java için olanları tekrar etmedim, verileri daha önceki ölçümlerdir. Sadece C++ ölçümlerini tekrar ettim, çünkü okurlardan C++ ölçümlerine itiraz edenler olmuştu. Makinamdaki C++ derleyicisini yeniledim. C++ kodunu Compile ederken de “-O3” flagini kullandım. Bu şekilde C++ ölçümlerinin ciddi olarak iyileştiği görülüyor. Bu sonuçları Java açısından yorumlarsak, Java’nın yavaş olmadığı, C++ ile başa-baş bir performans sergilediği görülüyor.

Daha önceki ve şimdiki C++ ölçümlerini kıyaslamak gerekirse, kullandığım farklı opsiyonlarla performanslar aşağıdaki gibi olmaktadır. Bu sonuçlardan özellikle “-O3” performans flaginin ciddi bir etiye sahip olduğu anlaşılıyor. Fakat merak ettiğim şey neden bu flagin varsayılan halde geçerli olmadığı? Uzun süredir C++ ile ilgilenmediğim için belli ki bu konulara detaylıca bakmam gerekli.

Program

10^6

 10^7 10^8 10^9

2*10^9
SieveOfAtkin.cpp

GNU g++ (GCC) 4.9.2

18

 218 2,461 34,871

82,059
SieveOfAtkin.cpp

GNU g++ (GCC) 4.9.2

“g++ -O3 -std=c++11 -o“

7

 69 1.021 18,434

46,246

 

Öte taraftan benzer ölçümleri uzun süre C ve C++ ile çalışmış bir arkadaşımdan da yapmasını istedim. Sağolsun Sieve of Atkin algoritması için detaylı ölçümler yapmış. Her farklı n girdisi için 3 ayrı çalıştırma yapmış ve ortalamasını ile beraber kaydetmiş. Elde ettiği ölçümler aşağıdaki gibi:

10^6
Konfigürasyon

1. run

 2. run 3. run Ort.
GNU GCC (Release) -O3 -std=c++11

59

 54 62 58
Java

74

 90 75 80

 

10^7
Konfigürasyon

1. run

 2. run 3. run Ort.
GNU GCC (Release) -O3 -std=c++11

408

 396 411 405
Java

386

 385 382 384

 

10^8
Konfigürasyon

1. run

 2. run 3. run Ort.
GNU GCC (Release) -O3 -std=c++11

3,782

 3,851 3,772 3,802
Java

3,430

 3,415 3,388 3,411

 

Arkadaşım, n = 10^9 için bir kaç farklı C++ compilerı kullanarak çok farklı sonuçlar elde etmiş.

10^9
Konfigürasyon

1. run

 2. run 3. run Ort.
GNU GCC mingw32-g++ (Debug)  -O2 -std=c++11

39,818

 40,140 39,764 39,907
GNU GCC (Release) -O2 -std=c++11

37,604

 37,598 38,642 37,948
GNU GCC (Release) -O3 -std=c++11

37,751

 37,642  37,816 37,731
Visual C++ 2010 (Debug)

69,142

  – – 69,142
Visual C++ 2010 (Release) /Ox (Maximum Optimization)

49,072

 – – 49,072
Java

34,619

 34,418 34,409 34,482

 

2*10^9
Konfigürasyon

1. run

 2. run 3. run Ort.
GNU GCC (Release) -O3 -std=c++11

75,175

 – – 75,175
Java

67,552

 – – 67,552

 

Arkadaşımın ölçümleri elde ettiği makinasının konfigürasyonu da şöyle:

  • Intel Core i7-2670QM CPU @ 2.2GHz 8 GB Bellek
  • 64 Bit Windows 7 İşletim Sistemi (service Pack 1)

 

Yukarıdaki ölçümler, farklı makinalarda ve farklı compilerlarla yapılmış olması açısından Java’nın performansı noktasında daha objektif sonuçlar verdiği kesin. Benzer şekilde, bu sonuçlar Java ile C++’ın algoritmik performanslarının kıyaslanabilir olduğunu gösteriyor. Elde ettiğimiz sonuçlar, bu iki dil arasında CPU’yu çalıştırma noktasında çok da fazla bir performansının farkının olmadığını, eğer varsa da, girdi arttıkça performansın Java lehine ilerlediğini gösteriyor. Sonraki yazılarda bu fark üzerine konuşacağız.

Bol performanslı günler dilerim.

 

Toplam görüntülenme sayısı: 1168

Java’nın Performansı: Java Yavaş mı?

Java , , , ,

Uzun süredir yazmak istiyordum Java’nın performans ve optimizasyon konuları üzerine. Nasip 2014 yılının başınaymış.

Java ilk çıktığı andan bu yana genel olarak “yavaş” olmakla suçlanmakta ya da en azından yavaş oluşundan dem vurulmaktadır. Bu tür ifadelerin bir kısmı ciddi tecrübelere dayanmakla birlikte pek çoğunun ezbere edilen cümleler olduğunu ifade etmekte fayda var.

Öncelikle “yavaş” olmak üzerine eğilelim ve “yavaş” olmaktan ne kastediliyor ona bakalım. Java’nın neyi yavaş? Java ile geliştirilen yazılımlar mı yavaş yoksa dil olarak Java mı yavaş olan? Yoksa ikisi de mi? Şunu teslim edelim ki bir yazılım sisteminin performansı hangi dili ya da teknolojiyi kullandığından ziyade, nasıl bir mimari ile kurgulandığıyla ilgilidir. Donanım ve yazılım altyapısının nasıl kurgulandığı, farklı sub-systemler arası haberleşmeler, ön bellek (cache) kullanımı gibi mimari kararlar, çoğu zaman çok performanslı kod yazmaktan daha önemlidir. Çünkü sağlıklı kurgulanmış bir mimari ile çok mütevazi dil ve araçlar kullanarak, son derece performanslı yapılar oluşturulabilir. Örneğin yüzlerce hatta binlerce sunucunun paralel bir şekilde nasıl çok yüksek bir ölçeklenebilirlik (scalability) oluşturabildiğini ya da  ön bellek kullanımının performansı nasıl arttırdığını görmek isterseniz Facebook’un mimarisine bir göz atın derim. Bu amaçla buraya, buraya, buraya, buraya, buraya ve de buraya bakabilirsiniz. Bu şekilde PHP ile yazılmış bir web önyüze, C++ ve Java gibi dillerle yazılmış servis yapılarına ve MySQL üzerinde çalışan bir veri tabanı yapısına sahip dev bir mimarinin, örneğin 2011 sonu itibariyle saniyede 60 milyon sorguyu (query) nasıl karşıladığını, dahası bu sorguların %90’ının daha veri tabanına gelmeden ön bellek (cache) üzerinden nasıl cevaplandığını hayretle öğrenebilirsiniz. Yukarıda verdiğim linklerin sonuncusunda zaten Facebook’dan teknik bir uzman bir strateji olarak, bilenen ve yaygın kurumsal (enterprise) web, uygulama, veri tabanı, dosya vb. sunuculara tonla lisans ücreti ödemek yerine, AR-GE yaparak, kendilerine uygun bir mimariyi nasıl geliştirmeye para ayırdıklarını açıklıyor.

Zaman zaman rastlıyorum. Bir süre önce geliştirilmiş bir uygulama artık performans sıkıntısı yaşamaya başlıyor. Yazılımı geliştirenler biraz sistemi inceleyip, performansını iyileştirici işler yaptıklarında sistemin davranışı çok değişiyor, çok daha performanslı davranmaya başlıyor. Nedir yaptıkları? Muhtemelen dil seviyesinde değil de mimari seviyedeki iyileştirmelerle bu sonuç elde ediliyor. Elbette bu iyileştirmelerin dile uzanan kısımları da var ama çoğunlukla JVM parametrelerinde ya da uygulamanın topolojisine uygulanan değişiklikler, rahatlıkla uygulamanızın performansını çok ciddi boyutta rahatlatabilir.

Biraz da dil olarak Java’nın yavaşlığından ya da performansından bahsedelim. Java gerek CPU kullanımı dolayısıyla da zaman, gerekse bellek tüketimi açısından, selefi olan C ve C++ dillerinden daha problemlidir. Dolayısıyla Java temelde C ve C++ ile kıyaslanmaktadır. (Bunun sebebi de Java’nın da temelde bu iki dil gibi genel amaçlı olma ve özellikle iş yazılımları geliştirmede kurumsal ihtiyaçları karşılama iddiasındadır. İşin açıkçası, bu iddiada Java’nın çok önde oluşu su götürmez bir gerçektir.)  Çünkü bu diller, yapı olarak Java’dan çok farklılar. Bir başka deyişle Java, temelde C/C++’tan elde edilen tecrübe üzerine ve web gibi yeni gelişmelere cevap için geliştirildiğinden, tasarımı sırasında alınan örneğin (işletim sistemi ve donanımdan oluşan) platformdan bağımsız olması gibi özelliklerinden dolayı, tabiatı itibariyle daha yavaş çalışmaya meyilli olması normaldir. Burada “meyilli” kelimesini özenle kullandım çünkü, çıkışından bu yana Java derleyicileri (compiler) ve run-time ortamı olan JVMleri ile ilgili o kadar çok çalışma ve yenilik yapıldı ki, bunlar sayesinde kulağınıza inanılmaz gelecek ama Java kodunuzun, eşleniği olan C/C++ kodu kadar hatta daha hızlı çalışması mümkün hale geldi.

Yapısal olarak Java’yı C/C++’tan ayıran dolayısıyla da yavaş kılma ihtimali yüksek olan özelliklerini sıralamak istersek:

  • Platform bağımsız olması sanırım en önde gelir. Java nihayetinde JVM denen sanal bir makine, bir yazılım içinde çalışıyor, dolayısıyla, platformdaki kaynaklara yani CPU, bellek, threadler, hard disk, soketler vs. erişimi dolaylı yoldan olmaktadır. Bu da tabiati icabı bu erişimleri yavaş kılmakta. Tüm bu sıkıntılara Java’nın platformdan bağımsız olması için katlanıyoruz. Böyle bir durum söz konusu olmadığında Java kaynak kodunu doğrudan native koda derleme imkanınız var. Nitekim JVMlerin pek çoğunda bulunan JIT derleyicisi (Just-in-time compiler), kritik kod bloklarını anında-görüntü modunda, native koda çevirir. Bu durum tabi olarak aslında Java kodunun C kadar hızlı çalışabileceği fikrini aklımıza getiriyor. Facebook’un PHP ile yaptığı da bu aslında, PHP ile yazıp, native koda derleyip, native hızında çalıştırmak, eskiden bu yana bilinen bir taktiğin PHP’ye uygulanması, belli ki işe yarıyor.
  • Java nesne-merkezli bir dildir. Dolayısıyla Pascal ya da C gibi yordamsal dillerde int ya da float gibi basit tiplerle ama bölük-pörçük olarak ifade ettiğimiz yapılar Java’da daima çok daha bütünsel ve anlamlı olarak nesnelerle ifade edilir. Basit tipleri manipule etmek, nesneleri manipule etmekten daima çok daha kolaydır. Çünkü nesneler, bir ya da daha fazla basit tipi bir araya getirir ve bu veriler üzerinde çalışan fonksiyonlara da sahip olur. Bu yüzden nesneleri oluşturmak, yönetmek ve sonunda da bellekten silmek kesinlikle çok daha fazla kaynak isteyen bir iştir. Nesneler tabii olarak basit tiplerden çok daha fazla yer kaplar, nesneleri yazılımın katmanları, veri tabanı gibi diğer alt sistemler arasında gezdirmek daha fazla CPU ve belleğe ihtiyaç duyar. Java’da 8 basit tip dışında her şeyin nesne olduğunu, örneğin String’in bir nesne olduğunu, sıra dışı durumların (exceptions), dizilerin, iş alanı kavramlarının, kısaca her şeyin bir nesne olduğunu düşünün. Nesnelerin bir kalıtım hiyerarşisine sahip olduğunu (siz oluşturmasanız bile Java APIsindeki sınıflarda zaten derin hiyerarşiler vardır) ve nesneler üzerindeki metotların polymorphic olduğunu da düşünün.  Dolayısıyla Java’nın özellikle run-time ortamının daha fazla iş yaptığı ve bunun da Java’yı hantal kılacağı söylenebilir.
  • Java’da devamlı nesne oluşturmak zorunda oluşumuz, zamanı gelince nesneleri ortadan kaldırmak gibi bir derde de sebep oluyor. Malum, metotlarla ilgili run-time yapıları stackde tutulur. Yani run-timeda metotlar açıldıkça, JVM, yerel (local) değişkenlerini kendilerine has bellek alanı olan stackde tutar. Metotlarda oluşturduğunuz değişkenler, Java’nın 8 tane olan primitive tipinden ise, bu tür değişkenlere referans oluşturamadığınızdan yani bu basit türden olan değişkenler farklı metotlara ancak değerleri kopyalanarak geçildiklerinden, bu türden olan değişkenlerin ömrü, en çok içinde tanımlandığı bloğun/metodun ömrü kadardır. (Scope kurallarını hatırlayın.) Ama bir metot içinde nesne oluşturduğunuzda, stack sadece o metodun referansını tutar ve metot bittiğinde referansı temizlenir. Eğer nesnenizi, metot bitmeden farklı metotlara geçmişseniz, aynı nesneye yeni referanslar oluşturmuş olursunuz ve bu durumda o nesnenin ömrü, kendisine ulaşan referansların ömrüyle belirlenir. Yani bir nesneye referans olduğu müddetçe o nesne bellekte kalmaya devam eder. Bu durum da çok bilinen memory leak problemine sebep olur. (Bazılarımızın yaptığı gibi nesne oluşturmamak bellek problemine çare olabilir ama bu durumda da “Java görünümlü C” kullanıyor durumuna düşülecektir.) Özellikle iş uygulamalarının bolca nesne oluşturmaya yatkın yapısı, bu tür uygulamaların nihayetinde performans ve ölçeklenebilirlik problemleri yaşamasına sebep olmaktadır. Dolayısıyla bellek yönetimi Java’da ciddi bir problemdir ve bu hem JVM hem de geliştirilen yazılımlar açısından dikkatli bir şekilde ele alınmalıdır.

Internet’te pek çok yerde Java’nın yavaşlığı hakkında yazılar, benchmarklar ve tartışmalar bulursunuz. Mesela burada ve burada olduğu gibi. Ben, bunca yıllık tecrübemden sonra şunu rahatlıkla söyleyebilirim: Yavaş olan Java programcıları, Java değil. Javacılar olarak, kaliteli ve hızlı çalışacak kod yazmada o kadar geriyiz ki, ben malesef, senelerdir Java kodu yazan kişilerin JVM’in yapısı ya da ne bileyim ArrayList ile LinkedList’in uygun kullanım yerleri hakkında olması gerekenden çok daha az hatta hiç bilgi sahibi olmadıklarına, alışa geldikleri şekilde kod yazdıklarına çok sıklıkla şahit oluyorum. Elalemin saniyede binlerce transactionı başarılı bir şekilde çalıştırdığı Javayla biz yazılım geliştirdiğimizde, çok daha küçük sayılarla ifade edilen yüklerde bile sıkıntı çekebiliyoruz. Facebook’un ön tarafta PHP, arkada MySQL ile sağladığı performansın çok cüzi bir kısmını biz önde Java arkada Oracle DB ile sağlayamıyoruz. Unutmayın, ben bu ülkede “Oracle yavaş” diyenleri bile gördüm.

Şu bir gerçek: En temelde yukarıda saydığımız sebeplerden dolayı, C ve C++ gibi native çalışan dillerin gelişi güzel yazıldıklarında sağladıkları performansı Java’da sağlamak için, Javacıların,  C/C++ yazılımcılarından daha bilgili ve maharetli olması gerekli. Bu anlamda gelişi güzel yazılmış C kodu ile Java kodu arasında performans olarak örneğin 100 kat fark varsa, iyi yazıldıkları durumda bu farkın çok azaldığı hatta Java derleyicilerinin ve JVM’in yapısından dolayı, Java kodunun daha performanslı hale geldiğinden çok sıklıkla bahsedilir. Dolayısıyla Javacılar, mimari, algoritmik karmaşıklık gibi seviylerde çok iyi olmakla birlikte Java dilini de çok verimli kullanmak zorundalar. Aksi taktirde çok sıklıkla karşılaştığımız sıkıntılı durumlara düşmek işten bile değil.

Yazımızı, Java’nın temelde “hızlı çalışma” için ortaya çıkmadığını hatırlatarak son verelim. Javacılar için modulerlik, lowly-coupled, highly-cohesive dolayısıyla da daha rahat değişebilen yapılar ortaya çıkarmak, etkin, hızlı çalışan kod yazmaktan pek tabi daha önemlidir. Ama bu Java kodunun son derece yavaş ve hantal olması anlamına gelmez. Gerektiği kadar hızlı ama düzenli bir mimari ve kod yapısı her zaman tercihe şayandır. Biraz bilgi ve gayret ile son derece hızlı ve ölçeklenebilir Java yazılımları geliştirmek çok da zor değildir.

İyi bir performansa sahip Java kodu için aslında aslında yapmamız gereken ilk şey, bu durum hakkında bir farkındalığa sahip olmaktır.

“Hızlı” Java kodlu günler dilerim 🙂

Toplam görüntülenme sayısı: 3133

Her Zeki Öğrenci, Programcı mı Olmalı?

BT, Kariyer, Kültür, Bilgi ve Düşünce, Yazılım Mühendisliği , , , ,

Serbest çalıştığım için, değişik vesilelerle, çok farklı çalışma ortamlarında çok farklı geçmişe sahip BT çalışanlarıyla karşılaşıyorum. Karşılaştığım kişilerin pek çoğuyla, bazen eğitim bazen de danışmanlık faaliyetleri sırasında, onların programcılık bilgi ve tecrübe düzeylerini, yaklaşımlarını vb. öğrenecek kadar mesai harcıyorum. Gördüğüm şu: Progamcılık, “nev-i şahsına münhasır” bir meslek ama bizzat programcı olmak isteyenler ve bunun için çalışanlar, bu durumdar haberdar değiller.

İnsanın kendisini tanıması ve kendi meziyetlerine en uygun mesleği seçmesi, hayatında yapacağı en iyi işlerden birisi. Ve bu çok zor birşey, bunun farkındayım. Ama toplum niye vardır ki? Ana-baba, okul çevresi, etrafımızdaki büyükler vs. niye vardır ki? İdeoloji haline gelmiş kalıpları insanlara dayamak için mi yoksa her bireye, kendisini ve çevresini tanıma imkanı vermesi için mi? Belli ki toplum, aileler, okul vb. çevreler pek çok kişiye, zeki olmasından yola çıkarak, Bilgisayar Mühendisi olmasını öğüt veriyor. Bunu lise yıllarımda ben de yaşadım. Ama bu öğütün doğru kişilere verilip verilmediğinden ise emin değilim. Neden durup duruken bu konuyu ele aldım? Çünkü işim vesilesiyle karşılaştığım kişilerin pek çoğunun hayatlarını, farklı dillerde program yazarak kazanmalarına ya da kazanmayı planlamalarına karşın, programcılığın gerektirdiği zihni ve davranışsal yetkinlikleri haiz olmadıklarını ve dahası bu gerçeğin de farkında olmadıklarını gözlemliyorum. Yani kendilerini tanımadıkları gibi kendilerine ideal olarak gördükleri işin tabiatıyla ilgili en ufak bir fikirleri de yok böyle kişilerin. Sonuç: Mutsuz çalışan ve verimsiz iş ortamı.

Programcılık, çok hırs, sabır ve odaklanma isteyen bir iş, yüksek seviyede soyut düşünme yetkinliklerine ihtiyaç duyuyor. Düşünmenin farklı seviyelerinden habersiz, bu seviyeler arasında hızla inip çıkamayan kişilerin iyi bir programcı olması zor. Bir iş sürecini kodlarken, iş kuralları vb. çok sayıda faktörü göz önüne alamayan, bunların arasındaki etkileşimleri sistemli bir şekilde çözemeyen birinin iyi programlar yazması da zor. Odaklanma sorunu yaşayan, 3-5 saatlik bir sürede, çok faktörlü bir problemi hem kavramsal olarak analiz edip hem de son derece kısıtlayıcı ve tamamen matematiksel bir notasyon olan bir programlama dili ile gerçekleştirecek ve bunu yaparken de performans vb. noktaları da gözden kaçırmayacak bir zihne sahip değilseniz, vasat bir programcı olmaktan öteye geçemezsiniz. Tüm bunları yaparken, ufak bir virgülü unutmanız dolayısıyla da programınızın derlenmemesi ya da doğru çalışmaması da sizin motivasyonunuzu bozmamalı. Hataları tek tek bulup, iğneyle oya işler gibi ilerleyeceksiniz. Her adımda çok ufak bir ilerlemeye sevineceksiniz. Bulamazsanız Google’dan envay çeşit aramayla sorununuzu çözmeye çalışacaksınız. Bulunca kendinizi iyi hissedip bir sonraki probleme odaklanacaksınız ve bu döngü böyle her gün saatlerce devam edecek. Bu her zekaya ya da kişiliğe göre bir durum değil.  Aslında bu bir zeka sorunu da değil. Bu bir kişilik özelliği, bu şekilde çalışmayı çok sevmek, bundan haz duymak zorundasınız. Aksi taktirde böyle hastalıklı bir çalışma şekli kimseye cazip gelmezdi. İyi programcı zekidir ama tersi doğru değildir. “Kötü programcılar zeki değildir” denemez. Bu bir zeka ve kişilik yapısı sorunu. Zekayı, sosyal zeka, uzaysal zeka gibi kategorilere ayırdığımızda ne demek istediğim anlaşılacaktır. Nasıl mimar olmak, estetik ve uzaysal bir zeka gerektiriyorsa ve estetik yönü eksik olan zekaya sahip bir kişinin, ismi Einstein da olsa, bir mimar olarak başarılı olması çok zorsa, üniversite giriş sınavından en yüksek puanı almak ya da ilk bilmem kaça girmek, iyi bir programcı olmak için yeterli değildir. Hele, ezberci eğitim ve sınav sisteminin insanları ayırt etmek için kullanıldığı Türkiye gibi bir ortamda, liseden birinci olarak mezun olmak ya da üniversite sınavında yüksek puan almak, kesinlikle bu meslekte başarılı olmak için bir işaret değildir. Ben zihin ve davranışsal yapısı programcılığa çok uygun ve bu yüzden de çok başarılı pek çok meslek yüksek okulu mezunu programcı tanıdım örneğin. Çocukların üniversiteden önceki hayatlarında bilgisayar ile çok uğraşmaları, örneğin en zor ve en yarışmacı oyunları çok başarılı bir şekilde oynuyor olmaları da onların iyi birer programcı olacaklarını göstermez. Çocuğun zekası buna elverse bile davranışsal özellikleri onu bu meslekte başarısız kılabilir. Ben programcı olmak isteyen ve zeka yapısı buna son derece uygun olduğu halde çalışma yapısı, yani davranışsal özellikleri programcılığa uymadığı için bölümünde ya da mesleğinde başarısız olan insanlar da tanıdım. Bu insanlar, kendilerine yol gösterilmemesinin ya da yanlış yol gösterilmesinin bedelini ödüyorlar açıkçası.

Dolayısıyla

  • Çevrenizini sizi çok zeki olarak betimlemesi,
  • Bilgisayar Mühendisliği’nin ya da programcılığın çok prestijli, “rocket-science” cinsinden afili bir algı yaratıyor olması,
  • Devam ettiğiniz dershanedeki rehber hocanızın “bu puanla Bilgisayar Mühendisliği’ne girersin” demesi
  • Bilgisayar vb. oyunları oynamayı çok seviyor olmanız hatta onlarda çok başarılı olmanız

sizin iyi bir programcı olacağınızı göstermez.

Bilgisayar Mühendisliği okuyan pek çok üniversite öğrencisinin bu yanlış içinde olduğunu çok sık gözlemliyorum. Onlara, Bilgisayar Mühendisliği okumanın, kendilerini otomatik olarak programcı yapmayacağını, bu bölümde programcı olmak dışında, iş/ihtiyaç analisti ya da sistemci gibi, başka BT mesleklerine yönelik yetkinlikleri kazanmanın da mümkün olduğunu ve araştırıp bu mesleklere yönelirlerse çok daha başarılı ve mutlu olacaklarını, uygun dille anlatmaya çalışıyorum.

Geçen gün, oğlumun, Avusturya’da okuyan bir arkadaşıyla bir sene sonra tekrar karşılaştık. Geçen sene onunla, Bilgisayar Mühendisliği okumaya karar verdiği ve 1. sınıf öğrencisi olduğu için, Java ve programcılık üzerine hızlı bir sohbet yapmıştık. Aradan geçen sürede Java ile programlama dersi almış. Görüştüğümde bana, bu desten kaldığını ve Java’nın çok zor olduğunu, sırf bu kalmadan dolayı farklı bir bölüme geçtiğini söyledi. Ben de onu “Java’dan kaldığı için” tebrik ettim ve zararın neresinden dönülse kardır dedim. Benzer süreci oğlum da yaşamıştı çünkü. O da lisede, meslek olarak kendisine, benim mesleğimi seçmiş  (valla bu benim suçum değil 🙂 Ben taa ortaokul yıllarından itibaren onu felsefe, sosyoloji, din ya da tarih gibi düşünsel bir alana yöneltmeye çalışmıştım ama o bilgisayar diye tutturmuştu) ve lisans eğitimine, ABD’deki bir üniversitede Computer Science ve Mathematics çift ana dal ile başlamıştı. İlk dönem C, ikinci dönem de Java kullanılan başlangıç seviye programlama ve algoritma dersleri aldı. Çok iyi hatırlıyorum, ikinci dönem aldığı Java dersinde proje yaparken sık sık Skype vasıtasıyla konuşurduk. Ve bu konuşmaların birinde, yukarıda anlattığım programlama döngüsünü ima ederek “bu iş hep böyle mi yapılır?” diye sordu bana. Ben de “evet, bu durum programlamanın en temel özelliğidir” diye cevap verdim. Bana o anda, bu mesleğin kendisine göre olmadığına karar verdiğini söyledi. Daha sonra, o dönem almış olduğu mikro ekonomi dersi ile ekonomiyi çok sevidiğini de farkettiğini bana söyledi. Ekonominin konuları, ele aldığı olgular dünyası, bunları ele alış şekilleri ve içindeki sosyalliğin tam kendisine göre olduğunu farketmişti ve 1. sınıfın yazında Computer Science  yerine Economics ile yoluna devam etmeye karar vermişti. Şimdi 2. senesini bitirdi, çok mutlu ve çok başarılı. Oğlum zeki mi zeki, soyut düşünce sistemi kuvvetli mi evet kuvvetli. Ama programcılığın vazgeçilmez olan “tırmalama” unsuru, aşırı a-sosyal problem çözme kültürü ona göre değildi belli ki. Ve tabi ki bir diğer şansı da Türkiye’de bir üniversiteye gitmiyor olmasıydı.

Keşke, ailelerimiz ve okullarımız, gençlere, kendilerini ve mesleklerini tanımada daha fazla yardımcı olabilse. Keşke üniversitelerimiz, kendini ve bölümünü tanıyan gençlere, meslek seçmede bir şans daha verse de daha mutlu bireyler yetişse. Keşke üniversitelerdeki bölümlerimiz, öğrencilere öğretirken,  eğitim ve öğretimi sadece akademik bir faaliyet olarak görmese ve öğrencileri, mesleğin tabiatı hakkında daha fazla aydınlatsa, onları gerçek dünyaya daha fazla yaklaştırsa.

Toplam görüntülenme sayısı: 2260

1 2