Ayın Olayları - Aralık 2007

(06.12.2007) - SourceForge.net sitesi, açık kaynak uygulamalara servis ve destek verilebilmesi için SourceForge Marketplace adı altında yeni bir bölüm açtı

SourceForge.net Marketplace adresinden erişebileceğiz bu yeni bölüm, açık kaynağı kapsamlı kullanan projelere ücret karşılığı servis ve destek sağlayamak isteyenlere fırsat tanıyor. Yaklaşık bir senedir üzerinde çalışılan proje, açık kaynak dünyasında nasıl para kazanılabileceğini bize bir kez daha gösteriyor.. Daha önce de Collabnet'in de denediği bu servis olayında neden SourceForge.net'in daha başarılı olabileceğini O'Reilly'nin Reputation: where the personal and the participatory meet up isimli makalesinden okuyabilirsiniz. Matt Asay ise bu olayı açık kaynak dünyasına yapılan bir jest olarak gördüğünü SourceForge.net puts its commercial hat on isimli yazısında anlatıyor. Bu konu ile ilgili diğer makaleleri aşağıda bulabilirsiniz...

Sourceforge Launches Open Source Marketplace
Can Sourceforge marketplace open the cash drawer?
SourceForge Adopts eBay-like Sales Model for Open-Source Software
eBay Marketing Director Joins Open Source Company VA Software
SourceForge Opens Marketplace for Open Source Services

(10.12.2007) - RedHat, açık kaynak IDE'si olan JBoss Developer Studio'yu piyasaya sürdü

Aslında çok önemli bir olay olmasa da, RedHat'ın JBoss'u almasından sonra attıkları adımları dikkatlice takip ettiğim için yazmak istedim. Bu senenin Mart ayında Exadel ile (ki bilenler Exadel'in hünerlerini bu olayı daha farklı görecektir) yaptıkları anlaşma ile bu alanda yaptıkları çalışmanın hangi boyutlarda olduğunu hissettirmişlerdi. Sacha Labourey ile yapılan bu röportaj bu adımları daha net anlatacaktır. Neyse, nihayet JBoss Developer Studio piyasada, tabi çıkarılan ürün ile ilgili bazı tartışmalar da yok değil. Bakalım bundan sonra ne olacak? Bununla ilgili diğer haberleri aşağıda bulabilirsiniz..

Exadel and JBoss partnership
Red Hat's Open Source IDE
JBoss Tools 2 and JBoss Developer Studio released



(31.12.2007) - Son Söz

Eveet, bir seneyi de bu şekilde bitirdik, bu blogu okuyan ve okumayan herkese; "Umarım umduğunuzdan daha iyi bir yıl sizleri bekliyordur, ideallerinizi kaybetmeyin yeter"

Nihayet Websphere

Evet, uygulama sunucularımızı değiştirmeye karar vermemizden bu yana 8 ay geçti ve 5 aylık araştırma/analiz ve karar verme ve yaklaşık 3 aylık bir çalışma sonunda tüm ortamlarımızı JBoss uygulama sunucusundan, Websphere uygulama sunucusuna geçirmiş bulunuyoruz.. Geçişi planlı ve düzenli yapmaya özen gösterdik.. Ortamları Development'tan Production'a olacak şekilde geçirdik, üzerinde testler yaptık sorunları giderdik, elimizden geldiğince doküman hazırladık... Tabi, bu sürenin geçiş için biraz uzun olduğunu düşünebilirsiniz, ama uygulamamız basit bir J2EE uygulamasından öte Aurora Altyapısını kullanan çok kapsamlı bir proje, dolayısıyla geçişin kontrollü ve zamanlamasının Sürüm Sistemine uygun olmasına özen gösterildi.. Tabi bazı önemli modüllerin geçişlerinde rastlanılan, çözülmesi zaman alan problemlerden dolayı geçişi ötelemek zorunda kaldık, ama dediğim gibi nihayetinde dört ayrı ortamımızı (bir anlamda proje yaşam döngüsünün dört safhasını) Websphere uygulama sunucusuna geçirdik.

Bu geçiş esnasında JIRA'yı bir sürekli dokümantasyon sistemi olarak kullandık, sorunlar ve çözümleri mümkün mertebe buraya kaydettik. Daha sonra aynı hatalarla yeniden karşılaştığımızda burada yazan çözümler bize bir hayli yardımcı oldu.

Özellikle Jakarta Slide projesi bizi bir hayli zorladı, inanılmaz taklalar attık, ve hala bazı sorunlar yaşıyoruz.. Bunun dışında IBatis ve Hibernate kullanan uygulamalarımızda konfigürasyonel değişiklikler yapmak zorunda kaldık. Yine Quartz ve Log4j araçlarının uygulamaya entegrasyonunun yapıldığı konfigürasyon dosyalarında database'e bağlanma şekillerinde bazı değişiklikler yaptık. Aurora altyapısında çok fazla zorlukla karşılaşmadık..

Yapılan bu çalışma aslında bir bahar temizliği niteliğinde oldu, 3 senedir kullandığımız sistemi yeniden öğrenme ve mümkün yerlerde yeniden şekillendirme şansımız oldu.. Bazı kullanılmayan ve gereksiz olan modülleri temizleyip, bazı şeylerin daha da netleşmesini sağladık. Bu bize sistem üzerindeki esneklik ve hakimiyetimizi geliştirme fırsatı verdi.

Tabi çalışmamız burada bitmiyor, geçiş tamamlansa dahi, performans iyileştirme çalışmaları bitmez gibi görünüyor. Bunun dışında yapılan çalışmanın kapsamlı bir "how-to" dokümanına çevirilmesi hem bizim, hem de bu işi daha sonra yapacakların hayatlarını çok fazla kolaylıştıracaktır. Her neyse, bir açık kaynak savunucusu olarak, JBoss'tan vazgeçmek biraz zor olsa da, yazılım yaşam döngüsü içerisinde açık kaynak kullanacak çok fazla yer var, en azından uygulama sunucusu katmanını IBM'e bırakabiliriz :) ...

Hudson ve pluginleri

Sürekli Entegrasyon, gerçekten hafife alınmaması gereken bir kavram, tabi bu tür işleri yaparken hangi araç ya da araçları kullandığınız da önemli...
Geçen gün okuduğum Continuous Integration anti-patterns isimli bir makalede yazılan yapılmaması gerekenler, ya da bizi yanlışlara sürükleyen ortak hatalar listesi, kullandığım CI Server aracını yeniden takdir etmemi sağladı... Tabi ki Hudson'dan bahsediyorum. Bir CI Server'ın yapması gereken herşeyi yapmaya çalışıyor, en azından bunun için uğraşı veriliyor. Ve özellikle kendini, pluginleri ile ön plana çıkarıyor... Üzerinde düşünüldükten sonra bazı pluginler Hudson'ın içerisine konuluyor, diğerleri ise plugin olarak entegrasyonu size bırakılıyor... Peki Hudson'ı bu kadar ön plana çıkaran pluginler nelerdir?


Source Code Management Plugin'leri

CVS ve SVN Hudson'ın içerisinde geliyor. Bunun dışında pluginler ile getirdikleri Accurev [Tutorial sayfası], ClearCase [Tutorial sayfası], Mercurial [Tutorial sayfası], Perforce [Tutorial sayfası], StarTeam [Tutorial sayfası]

Repository Browser Pluginleri

FishEye ve Sventon Hudson'ın içerisinde geliyor. Bunun dışında Polarion [Tutorial Sayfası] plugini mevcut.

Job Tipleri

Halihazırda Ant, Maven, Maven 2, free-style jobları ile gelen Hudson, bunların yanında Batch Task [Tutorial Sayfası], Gant [Tutorial Sayfası], MSBuild [Tutorial Sayfası] ve NAnt [Tutorial Sayfası] pluginleri ile yapabileceği iş türlerini artırıyor.

Code Coverage Pluginleri

Clover [Tutorial Sayfası], Cobertura [Tutorial Sayfası] ve Emma [Tutorial Sayfası] pluginleri ile code coverage konusunda çeşitlilik sağlıyor.

Code Convention Pluginleri

FindBugs [Tutorial Sayfası], Task Scanner [Tutorial Sayfası] ve Violations [Tutorial Sayfası] pluginleri code convention ile ilgili tool'ları kullanıp, raporlamaları yayınlamanızda oldukça yardımcı oluyor, özellikle Violations plugini PMD ve CheckStyle gibi araçların raporlarını harmanlayıp güzel bir arayüz sağlıyor..

Notification Pluginleri

İçerisinde gelen mail notification olayını ve RSS desteğini saymazsak Google Calendar [Tutorial Sayfası], IRC Plugin [Tutorial Sayfası] ve Jabber [Tutorial Sayfası] pluginleri bilgilendirme için kullanılabiliyor

Issue Management Pluginleri

JIRA [Tutorial Sayfası] ve Trac [Tutorial Sayfası] pluginleri bu konuda yardımcı olabilir.

Testing Pluginleri

JUnit entegrasyonu içerisinde bulunan Hudson'ın diğer test pluginleri, JavaTest Report [Tutorial Sayfası] ve NUnit [Tutorial Sayfası]

Diğer Pluginler

Bu pluginlerin dışında sürüm işlemlerini geliştirmek, güçlendirmek ve daha rahat yönetmek adına bazı pluginler yapılmıştır ki bunlar bazen gerçekten çok kullanışlı olabiliyor. Bu pluginler ise Build-timeout [Tutorial Sayfası], Japex - [Tutorial Sayfası], java.net uploader [Tutorial Sayfası], Locks and Latches plugin [Tutorial Sayfası], Naginator [Tutorial Sayfası], Plot Plugin [Tutorial Sayfası], Port Allocator [Tutorial Sayfası], SCP [Tutorial Sayfası], Text-finder [Tutorial Sayfası], URL Change Trigger [Tutorial Sayfası], VMware [Tutorial Sayfası] ve Xvnc [Tutorial Sayfası]. Tabi bunların ne iş yaptığını anlamak için sayfaları dolaşmanız gerekiyor.

Üffff amma çok plugin varmış...

Peki bu kadar plugin ile nasıl başa çıkacağım mı diyorsunuz? Bunu da düşünmüş adamlar, Hudson'ı benim daha önce yazdığım bu yazıda veya daha güncel olan Hudson dokümanında belirtildiği şekilde kurduysanız, Manage Hudson > Manage Plugins dediğinizde önünüze açılacak ekranda pluginlerinizin bir listesini bulacaksınız. Bu listede Plugininizin adını, versiyonunu bulabilir, silebilir, veya yeni plugin ekleyebilirsiniz. Yeni plugin eklemek için ise Plugin Download sayfasından yüklemek istediğiniz plugini bulup indirdikten sonra (unutmayın uzantısının hpi olması gerekiyor), manage plugins sayfasında bulunan Upload Plugin kısmını kullanarak ekleyebilirsiniz. Pluginleri kullanmak için yukarıda yazdığım listede pluginin hemen yanında bulunan "Tutorial Sayfası" linkini kullanabilirsiniz.

Tutorial sayfası size yetmedi veya eksik, ya da bir sorun olduğunu düşünüyorsunuz, o zaman Hudson'ın forumlarına girip, bu konuda yapılan tartışmalara bakabilirsiniz. Umarım faydalı bir yazı olur..


Not : Pluginleri gruplandırırken kategori isimlerini ingilizce bırakmamın sebebi ise bir çevirmen olmamamdan dolayı anlamlarını kaybetmelerini istemememdir :))

Blog yazma ve okuma

Blog yazmak kişinin kendisine kazandırdığı kadar, okuyanlara da alabildikleri kadar kazandırır.

Blog yazma ve RSS okuma ile ilgili inanılmaz güzel iki video...

Blog nedir? Neden yazılır?


RSS nedir? Nasıl okunur?

Ayın olayları - Kasım 2007

Bu aydan itibaren yeni bir tür yazıyı bu blogda yazmaya çalışacağım.

Okuduğum yazılardan, kulağıma gelenlerden, ay içerisinde olan önemli olayları, çok hafiften kendi yorumumu katarak (anlamayabilirsiniz bile :)), dünyanın dört bir yanındaki blog ve haberlere linklerini vererek yazacağım(her link farklı bir yazıya gidiyor). Bu tür bir yazı türünü yazma sebebim ise hem bu olayları ve dünyanın bu konulara bakışını size aktarmak, hem de kendi kütüphanemde bu tarz bir bilgiyi tutmaktır. Bu konularda sizin de yorumlarınızı bekliyorum. Umarım güzel olur.

(05.11.2007) - Google Android API'sini açıkladı

Daha önceden sinyalleri verilen Cep Telefonu API'si(platformu) Google Android adı altında piyasaya açıklandı. Google'ın 2005 Ağustos ayında bünyesine dahil ettiği Android ile geliştirdiği ve Open Headset Alliance olarak duyurduğu bu oluşum bir hayli konuşulacak. Bu konu ile ilgili kimileri google telefon için istek listesi hazırladı, kimileri gelecek nesil mobil işletim sistemi olarak gördü, kimileri ise adaptasyonun bir savaşa dönüşeceğinden dem vurdu. Google Android'le birlikte sistem açıklarının da geleceğini yazan bir yazıyı buradan okuyabilirsiniz.

Bununla ilgili aşağıdaki haberler ilginizi çekebilir.

What does Google's Open Handset Alliance announcement tell us about iPhone third-party apps?
Google says no phone, just a spec
Google Gang Unveils Open Source 'Gphone' Platform: Android
FCC chairman supports Google's Open Handset Alliance
Will virus writers take aim at Google Android?

ve Android hakkında yazılmış preview'leri okumak isteyebilirsiniz.

Android is out: First Looks
Google Releases Android SDK Preview
Analysis: Long odds for Google's ambitious Android
Google Android Developers: Start Your Coding
Google Android: Initial Impressions and Criticism
A developer's perspective on Google's Android

Ya da Android ile ilgili hırslandırmalar ile ilgili aşağıda linkler bulabilirsiniz..

Android Developer Challenge

(06.11.2007) - RedHat ile Sun aralarında Açık Kaynak Projeler konusunda anlaşma yaptı

RedHat, Sun ile birlikte, Sun'ın yürüttüğü Açık Kaynak projelere katkıda bulunmak için, Sun'ın katılımcı sözleşmesini imzaladı. Bu anlaşma beraberinde tartışmaları da getirdi. Tartışma özellikle OpenJDK üzerine yoğunlaşırken, RedHat'ın OpenJDK kullanarak kendi JDK'sını yapmayı planladığı şeklinde yorumlandı. Bu durumu iddia edenlerin yanında buna karşı çıkarak birleşmenin iyi yönde olduğunu, mevcut OpenJDK'nın geliştirileceğini savunanlar da oldu. Özellikle Tom Marble'ın "Red Hat and OpenJDK" isimli yazısı, RedHat'ın OpenJDK'yı nasıl Linux Distribution'a eklemek istediği ve bunun faydaları hakkında gayet güzel tüyolar vermesi ile dikkatleri çekti. Kişisel bloglarda ve haber sitelerinde büyük yer alan bu olay ile ilgili değişik linkleri aşağıda bulabilirsiniz.

Red Hat and Sun Collaborate to Advance Open Source Java Technology
Red Hat joins the Free Java Party in a big way
Red Hat and Sun sign deal to collaborate on Java
Red Hat and Sun Collaborate on Java
Red Hat Joins the OpenJDK
Welcome, Red Hat!


(14.11.2007) - RedHat ile Hyperic, Açık Kaynak System Monitoring projelerinde ortak çalışma kararı aldı

Açık kaynak dünyasında uzun süredir kullanılmakta olan Hyperic ile RedHat arasında ortak çalışma anlaşması imzalandı. OpenJDK konusunda Sun ile anlaşma yapan RedHat hemen ardından bu hamlesiyle, JBoss'un alınmasından sonra oluşan dinginliğin yerini bir hareketliliğe bıraktığının sinyallerini verdi. Bu konu ile ilgili aşağıdaki linkler ilginizi çekebilir.

Red Hat and Hyperic Extend Collaboration on Open Source Systems Management Technology
Red Hat + Hyperic = Common open-source systems management platform
Hey Red Hat, where's the love for Hyperic?
Red Hat & Hyperic Finally Made Me Happy


(14.11.2007) - Sun ve Dell arasında, Dell makinelerde Sun Solaris ve OpenSolaris işletim sistemi desteği olması konusunda anlaşma yapıldı

Donanım konusunda tercih sebebi olmayan Sun, bu açığını yazılım kısmındaki gücü ile kapatma konusunda oldukça iddialı. Öncelikle işletim sistemini yaygınlaştırmaya çalışan Sun, bununla ilgili Microsoft ve IBM'den sonra Dell ile de bir anlaşma yaptı. Bu anlaşmayı yapma sebeplerinden biri olarak da Solaris kullanıcılarının Dell'i tercih ettiğini ve bu tür destek taleplerinin bir hayli fazla olduğunu gösterdi. Bu anlaşma ile ilgili yazılmış kişisel blogları ve diğer linkleri aşağıda bulabilirsiniz.

Dell and Sun Microsystems Announce Solaris 10 Distribution Agreement
Solaris and Dell... and Virtualization, Of Course
The gods must be crazy: Dell and Sun link up
Dell to Offer Solaris - Partnering like its 1999
Dell to Offer Sun's Solaris, OpenSolaris in Servers

(27.11.2007) Verizon network'ünü açmaya karar verdi

Google'ın Android'i piyasaya açıklamasının ardından bir ay geçmeden Amerika'nın en büyük ikinci hücresel yayın sağlayıcısı olan Verizon ani bir kararla CDMA olan networkünü, kriterlerine uyan tüm aygıtlara açmaya karar verdi. İster Google'ın baskıları olsun, isterse oluşan fırsatlar havuzuna yatırım yapma isteği olsun; ileriye yönelik çok gerçekçi bu adım, beraberinde yorumları da getirdi. Bu hareketin pozitif olduğunu ileri sürenler kadar göstermelik olduğunu ileri sürenler de oldu. Bu konu ile ilgili diğer linkleri aşağıda bulabilirsiniz.

Verizon Goes 'Open'
Verizon Wireless To Open Its Network, Platform
Why Verizon Went Open & What It Means
Verizon Wireless marches into the open

Kötü misal emsal olmaz mı?

İş arkadaşlarımdan birisi ile yaşadığım ilginç bir diyalog, etrafımdaki insanların açık kaynak ile aralarında ne kadar ince bir iplik olduğunu ve bunun hangi durumlarda çabucak kopabileceğini bana gösterdi.

Diyaloğumuzun konusu, kullandığımız ürünlerden biri olan Jakarta Slide (linke tıklayınca görecekleriniz hoşunuza gitmeyebilir) idi. Arkadaşım, özellikle Websphere'e geçiş esnasında bize çok fazla sıkıntı yaratan bu ürün ile, aktif olarak kod geliştiriyordu ve yaşadığımız sıkıntılarla birebir muhattap oluyordu. Anlayacağınız dert yanması gereken birileri var ise yaşadığımız entegrasyon sorunlarından dolayı ben ve o'dur. Bu işi Slide ile yürütmeli miyiz sorusunu sorduğumuz sıralarda Roland Weber'den "[ANNOUNCEMENT] Jakarta Slide is retired" başlığı ile bir mail geldi ve mail içeriği ise şöyleydi;

The Apache Jakarta PMC is sorry to announce the retirement of the Jakarta Slide subproject. After it's last release in December 2004, development activity was significantly reduced and came to a total standstill this year. Without a minimum developer community that can release security fixes, we have no choice but to retire Slide. We'll keep at least one of the mailing lists open for a transition period, so users can discuss alternatives and migration away from Slide. Further use of the Slide codebase is discouraged.

One alternative to Slide is provided by the Apache Jackrabbit project. Jackrabbit has a healthy, active developer community and provides, among others things:
- a server-side content repository
- a WebDAV server component for access to the repository
- a WebDAV client component
Please visit http://jackrabbit.apache.org/ for more information.

We apologize for the inconveniences.

Bu maili okuduktan sonra alternatifler üzerine daha çok düşünmeye başladık. Tam bu noktada arkadaşımın Slide'a ve dolayısıyla Açık Kaynağa olan güvenini kaybettiğini gördüm ve diyaloğumuzda da bu konuda ne kadar kararlı olduğunu hissettim. Böyle hissetmesinin sebebi her ne kadar ürünün emekli olmaya karar vermesi olsa da (destek ve yardım bulamayacağını düşünmesi), bu ürünü tercih eden ve entegrasyonunu gerçekleştiren kod geliştirme ekibinin de gerek kodlama şekli ile, gerekse verdiği destek ve çalışma şekli ile bu ürüne olan güvenin sarsılmasında büyük payı vardı.

Ben her ne kadar arkadaşımı kötü misalın emsal olmaması gerektiğine inandırmaya çalışsam da, o incecik iplik kopmuştu ve yeniden oluşturulması gerekirdi.

İşte bu noktada açık kaynağın, açık kaynak topluluğu dışındaki kod geliştiricilerin gözünde itibarını sağlaması (arkadaşımın yeniden açık kaynağa güvenmesi) ve organik yapısı itibariyle açık kaynak olabilmesi için

1. Aktif bir topluluğun açık kaynak proje üzerinde aktif olarak (bulgu girme, testleri yapma) uğraşması
2. Açık kaynak projenin değişik sistemlerle entegrasyonu ile ilgili dokümantasyonun olması
3. Kod geliştirmenin devam etmesi ve sürümlerin çıkması
4. Açık kaynak projenin mevcut sisteme entegrasyonunun layığıyla yapılması gerekir.

Slide yukarıda atılan mail ile bir yeniden doğuş olmayacağını ve yazdığım maddelerden ilk üçünü artık yapamayacağını (3. madde 2004'te sona ermişti, 2. madde forumlar aracılığı ile zar-zor ilerliyordu) söylüyordu, geliştirdiğimiz projede 4 .madde de zaten sağlam olmadığı için, Slide'ı artık açık kaynak bir ürün olarak görüp, açık kaynağı bununla yargılamanın bir manası yok. Benim görüşüme göre slide sadece kodlarını bulabileceğiniz bir doküman yönetim sistemi aracıdır.

Yukarıda belirttiğim maddelerin önemini, sadece kodlarını açık kaynak hale getirerek bir başarasızlık hikayesi yaratan Xara ile ilgili bu yazıyı okuyarak anlayabilirsiniz.

Size bilmem ama bence kötü misal emsal olmaz, olmayacaktır da...

WikiPediaVision ile canlı canlı Wiki takibi

Wiki ile uğraşmak gerçekten çok eğlenceli, wiki sayfaları oluşturmak kadar birilerinin oluşturmasını izlemek de güzel, bizim projedeki Twiki loglarını izlediğim için biliyorum. Bu konu ile ilgili, RSS'lerimi okurken bulduğum bir siteyi sizinle paylaşmak istedim. Laszlo Kozma isimli Helsinki Teknoloji Üniversitesi mezunu bir arkadaş, twittervision ve flickrvision sitelerinden esinlenerek (ki ben bu siteleri dahi bilmiyordum) wikipedia üzerinde yapılan değişiklikleri canlı canlı görebileceğiniz bir site yapmış, WikiPediaVision adını verdiği bu sitede http://en.wikipedia.org sayfasındaki son güncellemeler (recent changes) ile GoogleMaps API'yi birleştirip, oturup izlenebilecek bir site yapmış.. Henüz BETA versiyonu, ama bu haliyle dahi çok zevk alınabilecek bir yapısı var. Eh bize de "Eline Sağlık" demek düşüyor.

Yazılım Zirvesi

Perşembe günü IBM'in Yazılım Zirvesi'ne gittim. Gayet güzel bir ortamda IBM'den arkadaşlarımızla hoş sohbetler yapma fırsatı bulduk.

Özellikle Oracle'ın BEA'ya yaptığı teklif ve bu teklifin kabulu durumunda oluşacak fırsatlar ve eğer teklif kabul edilirse ve Oracle bu satın almayı gerçekleştirirse oluşacak rekabet ortamından bahsettik. Tabi IBM'in bu konuya bakışı üzerine de konuşma fırsatımız oldu.

Daha çok ürün tanıtımı şeklinde geçen zirvede, Erkan'ın AppScan, Deniz'in Websphere Ailesi, Arden'in Webshere XD ve Nail'in BuildForge sunumlarına katılma şansım oldu. Özel ilgim olduğu için olsa gerek bunlardan özellikle BuildForge sunumuna katılmak için uğraştım. BuildForge ürününü içeren Rational ailesi ile ilgili şahsi düşüncem piyasada yazılım geliştirme yaşam döngüsünü ürün ailesi olarak çözmeye çalışan önemli bir ürün olduğu yönünde. Fakat bu tür bir çözüm eğer herhangi bir sisteminiz yok, bu işe yeni başlıyorsanız uygulanması büyük fayda getirecek bir çözüm. Hmm, bir de ITIL standardlarına uygunluğu var. Bunun dışında eğer zaten bu tür bir sistem kullanıyorsanız, kullandığınız ürünü değiştirmenin avantajlarını/dezavantajlarını iyice ortaya koymanız gerekiyor. Şahsi görüşüm, Hudson'ın geliştirilme hızını da işin içine koyarsam BuildForge'un Hudson'dan daha üstün olmadığı yönünde. En azından bizim yürüttüğümüz sürüm sistemi ve ortamları için...

Internette kitap bulma

Maillerimi karıştırırken 2005 Haziran ayından bir mail ilgimi çekti, maili çok sevdiğim bir arkadaşım Çağlar atmıştı ve internetten nasıl ebook bulunabileceğini anlatıyordu, daha doğrusu kullanışlı bir blogu bizimle paylaşıyordu...

Verdiği blog Find free ebooks with Google (Electronic Books) idi. Ben de bu ipucunu, hem unutmamak hem de sizlerle paylaşmak için buraya yazmak istedim.

Google'da ebook bulmak için yapmanız gereken Google'ı açıp, aşağıdaki "sözcük öbeğini" (ne demekse...) yazmak.

-inurl:htm -inurl:html intitle:"index of" +("/ebooks"|"/book") +(chm|pdf|zip)

Eğer bu kitabın herhangi bir şey ile ilgili olmasını istiyorsanız, bunun sonuna mesela " + "open source"" yazın..

Bir deneyin. Umarım yardımcı olur..

Ant'ı görselleştirme

Geçen gün Visualizing Data: Self-Documenting Ant files isminde bir yazı okudum... Ant scriptlerinin görsel olarak daha rahat anlaşılabilmesi için kullanılabilecek yöntemlerden bahsediyordu.. Üzerinde biraz düşündüğümde, yapılabilecek görsel bir sunumun ant'ı ne kadar anlamlı yapabileceğini rahatça söyleyebilirim. Bunun yanında okuması ve anlaması kolay olan Ant scriptleri bu scriptlerle çalışmayı da kolaylaştıracaktır.

Bununla ilgili kullanılabilecek yöntemleri; antpretty, ant'ın projecthelp özelliği, antdoc, ant2svg ve grand olarak belirtmişti yazar... Fakat benim en çok dikkatimi çeken AntDoc oldu.. Bu nedenle bu yazıda AntDoc'tan bahsedeceğim.

Öncelikle, AntDoc açık kaynak değil ama bedava, fakat uzun süredir geliştirilmiyor.. Dolayısıyla bunu hayata geçirdikten sonra ileride (belki güncellenmediğinden dolayı) vazgeçmek zorunda kalacağız, ama en azından dokümantasyon yapmış olacağız. Ve bu tür davranışlara bir kere alıştınız mı, bırakması çok zor olur.

Konumuza dönelim, JavaDoc hakikaten önemli bir kavram, hangi pakette, hangi sınıfların bulunduğunu, metodlarının neler olduğunu ve ne iş yaptığını bilmemiz açısından önemli. Bana göre yazılan koda biraz da hava katıyor. Tam anlamıyla kod olduğunu “bak bu da benim dokümantasyonum” diyerek kanıtlıyor. Bu noktada bizim en çok uğraştığımız konu olan ant scriptlerinin de buna benzer bir dokümantasyonunun olması normal olacaktır. Sistem büyüdükçe script sayısı artar, sirkülasyon devam ettikçe, herkese bunların ne iş yaptığını anlatmanız gerekir. Bunun yerine ant dokümantasyonu yaparsanız, herşey daha kolay olacaktır.

AntDoc'u hayata geçirmek için birkaç pakete ihtiyacımız var, bunlar Jakarta RegExp(1.5), Saxon(8.9 çalışmıyor, bunun yerine AntDoc download sayfasındaki 6.2.2 kullanmanız gerekiyor), JDOM(1.0), Log4j(1.2.15) ve AntDoc(0.8). Bu paketleri ANT_HOME altında lib klasörüne kopyalamamız başlamak için yeterli.

AntDoc'u kullanmak için öncelikle taskdef tanımını scriptimize eklememiz gerekiyor.

<taskdef name="AntDoc" classname="org.ed.pack.ant.AntDoc"/>

Ardından en basit haliyle aşağıdaki örnek task'ı scriptine eklemeniz Ant'ı dokümante etmeniz için yeterli olacaktır.

<antdoc destination="antdoc" buildfile="${ant.file}"></antdoc>

Bu task, antdoc klasörü altında, çalıştırılan ant dosyasının dokümantasyonunu HTML formatında hazırlayacaktır. AntDoc taskının özellikleri tabiiki bu kadar değil, filtering, filesetler ve daha bir çok özellik var. Ben sadece basitçe nasıl hayata geçirebileceğimizi anlatmaya çalıştım. Detaylı kullanım ile ilgili dokümantasyonu bu linkten bulabilirsiniz.

Bu noktada faydalı olabilecek birkaç önerim olacak;

• Ant dokümantasyonunu sürüm işlerinden ayrı bir şekilde yapmak istiyorsanız, bu taskı başka bir scripte koyup, buildfile dosyasına dokümante etmek istediğiniz ant scriptinin adını yazmanız yeterli.
  

• Bunu Sürekli Entegrasyon sistemine günlük çalışan bir ant işi olarak ekleyip işlerin otomatik çalışmasını sağlayabilirsiniz.
  

• Bunun yanında dokümantasyonun sadece ant scriptinde değişiklik olduğunda güncellenmesini istiyorsanız aşağıdaki ant scriptini kullanabilirsiniz.

<target name="DocumentAntScript" depends="antdoc.checkIfRequired" unless="antdocBuild.notRequired" description="build API documentation for build file">
<taskdef name="AntDoc" classname="org.ed.pack.ant.AntDoc">
<antdoc destination="antdoc" buildfile="${ant.file}">
</antdoc>

<target name="antdoc.checkIfRequired">
<uptodate property="antdocBuild.notRequired" targetfile="antdoc/index.html" srcfile="${ant.file}">
</uptodate></target></taskdef>
</target>

• Yukarıdaki blok, oluşturulan ant dokümantasyonu index.html dosyası ile ant scriptinin tarihlerini karşılaştırıp eğer script güncellendi ise dokümantasyonun oluşturulmasını sağlar.

Evet, ant scriptlerinizi dokümante etmeniz bu kadar kolay. Umarım yardımcı olur...

Eee twiki nasıl gidiyor?

Twiki'yi kurdum ama henüz hayata geçiremedim. Yani, eğer hayata geçirmek resmi olarak tüm çalışma ekibinize "Dikkat, dikkat... dokümantasyon yapabilmeniz için artık yeni bir dostunuz var, evet twiki artık yaşıyor.. Wiki ile herşey daha güzel, lütfen siz de kullanın.." demek ise hayır henüz hayata geçirmedim.

Bunun dışında kod geliştiren arkadaşlardan sorunlar geldikçe bunları çözüp hazırladığım Sıkça Sorulan Sorular kısmına ekledim ve geliştirmeye çalışıyorum. En azından bu şekilde bir içeriğin oluşması için uğraşıyorum. Sürekli entegrasyon, konfigürasyon yönetimi ve sürüm yönetimi ile ilgili terimleri, tanımları bu wiki içerisinde dokümante etmeye çalışıyorum. İbrahim'in de katkılarıyla projede çalışan, iş hayatında yeni olan yazılımcılara wiki'nin ne demek olduğunu ve ne işe yaradığını anlatmaya çalışıyoruz, bu zaman zaman çok güç olabiliyor. Ama inanın, piyasaya yeni katılan yazılımcılar bu tür kavramlara adapte olmakta eskilere göre daha becerikli olabiliyorlar. Sebebi, gerek henüz tüm kavramlarla kafalarının karışmamış olması olsun, gerekse işleri en başından düzgün yapabileceklerinin bilincinde olmak olsun, açıkçası iyi gidiyorlar.

Twiki'nin sitesindeki skinleri indirdim, hiçbirisi default (pattern) skin kadar iyi değil.. Herkesin kullanımına açılmadığı için henüz plugin ihtiyacımız ortaya çıkmadı, ama çıkarsa da kendimi rahat hissediyorum, çünkü twiki'yi seçme sebeplerimden bir tanesi de plugin bolluğu idi.

Bunların yanında zaman zaman neden Confluence yerine Twiki'yi tercih ettiğime dair sorular ile karşılaşıyorum. Düşünseninze Sun bile wiki'sini Confluence üzerine götürüyor. Çok da beğendiğim bir ürün.. Ama sebep şu, ben hem projenin web sayfası olsun, hem de wikimiz olsun istiyorum. Bu konuda Confluence yetersiz kalıyor, wiki konusunda değil elbette, hem wiki hem web sayfası olabilme konusunda, yapılamaz mı? uğraşmak lazım.. Ama Twiki bu konuda gayet esnek, birden fazla web'e sahip olabilirsiniz, mesela yazılımcılar için bir arayüz (web sayfası), aynı zamanda son kullanıcı için bir arayüz, ve hatta konfigürasyon yönetimi için bir arayüz.. Ve hepsinin dokümantasyonu...

Twiki ile şimdilik bu kadar. Umarım daha ilerilere götürebiliriz.

Çok fazla açık dosya var (too many open files)

Çok fazla açık dosya var hatası, genellikle sunucularda sıkça başımıza gelen bir konu, çünkü uygulama sunucuları, üzerlerinde hiçbirşey olmasa dahi birçok dosya ile aynı anda çalışır. Bu konu ile ilgili RedHat EL3 üzerinde SSH Client kulanarak uygulama sunucularını yönetirken sıkça yaşadığımız bir sorunun çözümünü burada size sunmaya çalışacağım.

Sorun : Websphere açılmaya kalkıştığında zaman zaman "too many open files" diyerek operasyonu durduruyor. Bunu başka zaman da yapıyor...

Çözüm :

"ulimit -n" ile kaç tane açık dosyaya izin verildiği bilgisini kontrol edin. Ben de bu sayı 1024 idi.

root rolüne bürünüp bu değeri değiştirmeniz birşey ifade etmeyecek çünkü bunu geçici olarak değiştirmiş olacaksınız. Bir sonraki SSH bağlantınızda bu eski haline yani 1024'e dönüşmüş olacak. Ve hatta aşağıdaki yöntemi denerseniz zaten değiştiremeyeceksiniz.

ulimit -n
1024
su - root
ulimit -n 4096
exit
ulimit -n
1024

Bu noktada uğraşmamız gereken iki tane dosya var, bunlardan bir tanesi, makine reboot olsa dahi, kullanıcı limitlerinin korunması için kullanılan "limits.conf" dosyası (/etc/security altında), diğeri ise SSH protokolü ile yapılan bağlantıların tüm konfigürayonunu tutulduğu "sshd_config" dosyası (/etc/ssh altında)... Bu dosyaları düzenlememiz gerekecek, bunu yapmak için root olmamız gerektiğini belirtmeme gerek yok sanırım.

limits.conf dosyasına aşağıdaki iki satırı eklememiz gerekiyor.

USER_NAME soft nofile 4096
USER_NAME hard nofile 4096

USER_NAME burada Websphere çalıştırdığımız ve açık dosya hatasını aldığımız kullanıcı...

Tabi bu değişiklik tek başına yeterli olmayacak, bu nedenle sshd_config dosyasında da "UsePrivilegeSeparation" parametresini eğer comment'li ise comment'ten kurtarıp değerini ise "no" yapmamız gerekiyor. Bu her açtığımız SSH bağlantısında açık dosya limitini sistem değerlerinden okumamızı sağlayacak.

Son olarak bunun devreye girmesi için SSH servisini "service sshd restart" komutu ile restart etmemiz gerekiyor. Bundan sonra SSH Client ile bir terminal açtığımızda yukarıda belirttiğimiz kullanıcının limiti, dosyada belirtilen sayı olarak belirlenmiş olacak. Bu da "too many open files" hatasını belki bir süre daha almamızı sağlayacak.

Umarım yardımcı olur.

Kodlama Standardı

Kullandığımız uygulama sunucuları ya da yazdığımız kodlar ile ilişki halinde olan araçlar sürekli olarak bir devinim içerisindedirler. Performans iyileştirmeleri, sorun giderilmesi, daha hızlı çalışabilme, sistem kaynaklarını doğru kullanma gibi konularda sürekli kafa patlatırlar. Ya da yeni bir donanım çıkar, eski donanımızdan daha hızlı çalıştığını iddia eder. Bunlar bizim dışımızda gelişen performans ve açık giderilmesi çalışmalarıdır. Bir de bize düşen performans ve kod düzenlemeleri vardır ki, kısa vadede yük getiriyor gibi görünse de uzun vadede işlerin yolunda gitmesini sağlar. İşte uygulanması gereken metodun adı Kodlama Standardıdır. Juan Carlos Herrera The Human Side of Security and Performance yazısında developer'ın bir insan olduğu ve her insan gibi hata yapabileceğinden bahsediyor. Doğru ama aynı zamanda bunlar için önlem alınabileceğinden de bahsediyor. Bunun için de öncelikli olarak kullanılan API'nin iyi bilinmesi gerektiğinden bahsediyor. Yapılabilecek performans hatalarına aşağıdaki örnekleri veriyor.

"About Performance common mistakes are poor algorithm design, wrong use of try/catch, primitive debugging techniques (a lot of "System.out.println"), etc.."

Tabi bütün bu bahsedilenlerden sonra bu tür standardları tek tek takip etmek, veya büyük ölçekli bir projede herkesin bu tür kurallara uyup uymadığını kontrol etmek manuel takip edilecek bir süreç olmuyor. Bunun için piyasada Code Convention araçları mevcut. Findbugs, PMD ve CheckStyle bu ürünlerin başında geliyor. Bu üç ürün birçok yönden benzerlik gösteriyor, IDE plugin desteği, sürüm sistemi ile entegrasyon, kural havuzu gibi... Ama bazı yönlerden birbirlerine karşı avantaj sağlıyorlar. Ama işin güzel yanı, üçü de kod standardına sahip olmanızı sağlıyorlar.

Her proje ekibinin belli kod yazma standardları vardır. Bir kurala dahi sahip olmak ileride size büyük avantajlar getirir, ki bu avantajlar bazen hayat kurtarır.

BEA-090402 ve boot.properties dosyası

Weblogic Admin Server'ın Admin şifresini değiştirdikten sonra bu hata ile ikinci kere karşılaşıyoruz. İlk seferinde kolayca çözmüştük ama bu sefer bizi bir hayli zorladı.

Hata mesajı gayet açık, diyor ki

Authentication denied: Boot identity not valid; The user name and/or password from the boot identity file (boot.propePublish Postrties) is not valid. The boot identity may have been changed since the boot identity file was created. Please edit and update the boot identity file with the proper values of username and password. The first time the updated boot identity file is used to start the server, these new values are encrypted.

Bu hatayı aldığınızda

1 - boot.properties dosyasını açıp password alanına şifreyi açık açık yazın. Sunucuyu restart ettiğinizde bu dosya şifrelenecek ve sunucu çalışmaya başlayacaktır. boot.properties dosyası eğer açılış scriptlerinde "-Dweblogic.system.BootIdentityFile" parametresi ile belirtilmemiş ise, altında olacaktır.


2 - Sorunu yukarıdaki şekilde çözemezseniz, o zaman sunucunun embedded LDAP'ı ile ilgili bir sorun oluşmuş olabilir (Büyük ihtimalle de cacheleme ile ilgili). Yapmanız gereken, / klasörü altındaki ldap klasörünün ismini değiştirmek, sunucu yeniden açıldığı zaman bu klasörü oluşturacaktır. Ve sorununuz çözülecektir (Yani en azından biz sorunu bu şekilde çözdük).

Umarım yardımcı olur.

Dokümantasyon ve Twiki – II (TWiki)

Aşağıdaki adımları izleyerek RedHat EL3 üzerine Twiki 4.1.2 kurulumunu tamamladım. Twiki'nin çalışabilmesi için Apache ve Perl'ün Linux üzerinde bulunması gerekiyor. Neyse ki, bunlar yüklü, Apache 2.0.46 ve Perl 5.8.0. Hmm bu arada kurulum bir miktar linux bilgisi ve sistem yöneticiliği gerektiriyor, zaman zaman root şifresine ihtiyacınız olacak. Eğer bu tür yeteneklerim yok diyorsanız, VMDebianStable linki işinizi görecektir, kendisi yaklaşık 350 MB. Ben uzak durdum tabi. Şimdi Twiki'yi kurmak için neler gerektiğini sırası ile anlatayım. Anlatım esnasında belirtilen tüm lokasyonlar kurulumu yaptığımız makinenindir.

• Twiki4.1.2 linkinden Twiki'yi indirin. Yaklaşık 5,5 MB.

• /var/www/twiki klasörünün içerisine bu zip'i açın.

• Twiki'nin çalışmasında aksama olmaması için bazı CPAN modüllerinin yüklenmesi lazım. Bu CPAN'ların listesini bu linkte bulabilirsiniz. Bunları tar.gz formatında http://cpan.perl.org/ sitesinden indirip ardından “make” komutu ile yapılandırabilirsiniz. Fakat daha kolayı var, bu linkten RPM'leri indirin, sonra bunları twiki makinesine kopyalayın, sonra bunları kopyaladığınız klasör altında "rpm -ivh *" komutunu çalıştırın. Evet hepsi bu, gerekli tüm CPAN modülleri kuruldu.

• Apache ayarlarının yapılması lazım. Bunun için TwikiApacheConfigGenerator linkine girip, formu doldurmamız gerekiyor. Bu formu doldururken birkaç hususa dikkat etmeniz gerekiyor,

  • Eğer ayarları lokalden yapmayacaksanız, IP listesine IP'nizi ekleyin.

  • Yine konfigürasyon ayarlarını yapacak kullanıcıların listesini kullanıcı listesine ekleyin.

  • Login Manager seçin, sakın none'da bırakmayın. Login sayfası kullanacaksanız, TemplateLogin'i seçin, diğeri zaten anlaşılır. Ben TemplateLogin seçtim.

  • mod_perl'ü enable etmeyin, bunun dışında diğer ayarlara dokunmasanız da olur.

    • No you do not need mod_perl. mod_perl needs to be installed on your Apache installation for you to be able to use it and you need a lot of RAM. mod_perl compiles all the perl code ONCE and keep it in RAM. This speeds up the execution of TWiki by at least factor 2. But mod_perl also keeps all variables in RAM so the programs must be written with great care. The TWiki core and the default plugins are pretty mod_perl safe now. But some other plugins do not work with mod_perl. I recommend to start a new TWiki installation without. And once it works you can try and activate it. Read the topic ModPerlUnix for more information. This ApacheConfigGenerator is a helper that generates a working apache config also for mod_perl but you need to know more about it to use it. As a beginner, run without.

• Update config file dedikten sonra aşağıda oluşan bilgileri twiki.conf isimli bir dosyaya koyun, ve bu dosyayı da /etc/httpd/conf.d altına koyun. Apache'nin konfigürasyon dosyasında bulunan Include conf.d/*.conf satırı, bu conf dosyasının otomatik olarak okunmasını sağlayacak.

• “chmod 644 twiki.conf” ve “ chown root:root twiki.conf” komutlarını conf.d klasörü altında çalıştırmamız gerekiyor.

• Apache konfigürasyonunu bitirdikten sonra ilk ayarları yapacak olan kullanıcıyı yaratma kısmına geldik. “htpasswd -c /var/www/twiki/data/.htpasswd oguz” komutu ilk kullanıcımızı yaratıyor. Eğer “-c” parametresini kullanmazsak, yeni kullanıcıyı bu listenin sonuna ekliyor. Aksi takdirde, bu dosyayı sıfırlıyor. “-c” yerine “-D” kullanırsak kullanıcıyı siliyor. Twiki kurulumu bittikten sonra yaratılan her kullanıcı bu dosya içerisine eklenecek.

• /var/www/twiki/bin klasöründeki LocalLib.cfg.txt dosyasını LocalLib.cfg'ye çevirmek ve ardından içerisinde twikiLibPath parametresini doğru bir şekilde düzeltmek gerekiyor...

• SDosyalar üzerinde bazı yetkilerin verilmesi gerekiyor. Bu yetkileri SettingFileAccessRightsLinuxUnix linkinde bulabilirsiniz.

• Son işimiz Apache'yi ayağa kaldırmak olacak. “service httpd start” yazıyoruz ve ardından http:///twiki/bin/configure yazarak konfigürasyona geçiyoruz.

• Bundan sonraki ayarları Run Configure For The First Time linkindeki bilgiler ışığında yapabilirsiniz

• Bunun dışında tam kurulum dokümanını TwikiOnRedHat linkinde bulabilirsiniz.

Umarım memnun kalırsınız...

Dokümantasyon ve Twiki – I (Dokümantasyon)

Açık kaynak bir araç kullanmayı planlıyorsam, önce bu aracın web sayfasını açıp linkinden benim konfigürasyonuma en uygun olanı bulur ve aracı indiririm. Ardından ana sayfa da bu aracı varolan sisteme nasıl entegre edeceğime dair bir doküman ararım. Genelde “Installation Guide”, “How to Configure” veya “Get Started” linkleridir bu ve bunu adım adım takip ederek entegrasyonu yaparım. Yaptığım entegrasyon işinde bana yardımcı olan bu dokümanlar, çoğunlukla bir Wiki aracı ile yapılmış olur. Ama sonuçta orada bir doküman vardır ve her zaman “güle güle ve dokümanlar için teşekkürler” diyecek bir sebep ortaya çıkar.

Hadi bakim ye yemeğini, yoksa sana Dokümantasyon yapma cezası veririm...

Fakat çoğu zaman doküman hazırlamak hem iş analistleri için, hem de kod geliştiriciler için bir eziyet haline gelir. Bunun sebebi ise gerek projenin geliştirilmesi esnasında zaman ile ilgili sıkıntıların olması, gerekse dokümantasyonun zaman zaman gereksiz olarak nitelendirilmesidir. Ama bu düşüncelerin aksine, dokümantasyon doğru yapıldığı takdirde kod geliştirme sürecini hızlandırır. Hele proje ekibinde rotasyon veya sirkülasyon söz konusu ise dokümantasyon hayat kurtarabilir.

Diyelim ki kabul ettim neyi dokümante edeceğim ?

Neyi dokümante etmeyeceğiz ki? Merak etmeyin, istenildiğinde dokümante edilmeyecek hiçbirşey yoktur. Ama ben yine de birkaç örnek vermeye çalışayım. Önce yazdığımız kod kümelerinin ne iş yaptığı ile ilgili birer cümlecik yorumlar yazabiliriz. Metodun ne iş yaptığı, ne zaman ve kim tarafından yazıldığı ile ilgili küçük birkaç cümle zamanı geldiğinde hayat kurtaracaktır. Ya da projede daha önce kimsenin kullanmadığı bir API kullandığımızı varsayalım. Bunu nasıl kodumuza entegre ettiğimizi dokümante edersek, ileride aynı entegrasyonu yapmak isteyen başka bir developer zorlanmayacak ve üstüne üstlük bize dua edecektir. Bu da önemli bir dokümantasyondur. Devam edelim, mesela bir modülde aktif olarak çalışıyoruz, hazırladığımız bir önyüz var, bu önyüzü dokümante edebiliriz, bunun bir süre sonra bize zaman kazandırdığını fark edeceğiz. Bunlar kod geliştirenlerin yapabileceği dokümantasyona küçük, basit örnekler.

Ama sadece onlar mı dokümantasyon yapacak? Kesinlikle hayır. Konfigürasyon ve Sürüm Yönetimi ile uğraşıyorsanız, dokümantasyonunuz hayati önem arz eder. Mesela, yazılan projenin değişik safhalarının tutulduğu (DEV, ALFA, BETA gibi) değişik ortamlar vardır. Bu ortamların konfigürasyonları değişiklik gösterebilir. Bunlar dokümante edilirse, kod geliştiren arkadaşlar için çok yararlı bir kaynak olur. Veya, projenin geliştirilmesi, sürümün yönetilmesi, kodların tutulması ve sistemin çalışması ile ilgili kullanılan tüm araçların hangi versiyonlarının kullanıldığı bir doküman hazırlarsak, bu hem bizim için, hem de projenin diğer parçalarında çalışan arkadaşlar için çok yararlı, ekstra telefonları engelleyen bir hizmet haline gelir.

Evet dokümantasyon bir hizmettir. Bizim Gözümüzden Açık Kaynak adlı yazımda da belirttiğim gibi, açık kaynağın para kazandığı hizmetlerden birisi Dokümantasyondur..

Dokümantasyon yapmak için araç var mı araç? Olmamııı...

Peki nasıl yapacağız bu dokümantasyonu? Nasıl yapacağız sorusunun cevabını başkaları nasıl yapıyor sorusundan çıkan cevap ile karşılayabiliriz. Sun dokümantasyon sayfalarını wiki tabanlı bir uygulama olan Confluence üzerinden yayınlıyor. Bununla ilgili güzel bir klibi Sun ve Wiki adlı yazımdan izleyebilirsiniz. Confluence ile ilgili güzel bir yazıyı da bu linkte bulabilirsiniz. Wikipedia dünyanın en büyük ansiklopedisi yine wiki motoru üzerine kurulu. O halde sanırım sorumuzun cevabı wiki motorları. Wiki motorları ile ilgili (tarih olarak biraz eski olsa da) güzel bir karşılaştırmayı Which Open Source Wiki Works For You yazısından bulabilirsiniz. Ya da Open Source Wiki Engines in Java linkinde diğer alternatifleri bulabilirsiniz.

İnceleyebildiğim kadarı ile bunlar içinde dört tane ürün ön plana çıkıyor, bunların başında Confluence geliyor, diğer üç alternatif ise Twiki (Kullanım yaygınlığı açısından), PmWiki (kurulum kolaylığı açısından), MediaWiki (en.wikipedia.org'un alt yapısı olması açısından, ya da Gönenç'in eklemesi ile Alfresco'nun da altyapısı)..

Confluence ile ilgili birkaç kelime yazmak gerekirse, kurulumu gerçekten kolay bir araç. Birkaç adım ve kurulum sihirbazı ile herşeyi rahatlıkla halledebiliyorsunuz, kişisel kullanmak isterseniz, siteden kişisel lisans talep ediyorsunuz, ardından elinizin altında 2 kayıtlı kullanıcı sahibi olan ücretsiz bir Confluence aracınız oluyor. Eğer gerekli lisans ücretini öderseniz 50, 500 veya sınırsız kullanıcı ile bir Confluence'ınız olur. Lisans ücreti de çok fazla değil ($2200, $4000 veya $8000). Ama diğer tüm wiki motorlarının ücretsiz olduğunu varsayarsak pahalı diyebiliriz. Bu nedenle ben daha çok Twiki üzerine yoğunlaştım, ve nihayetinde Twiki'yi hayata geçirdim. Twiki'nin kurulumu ve hayata geçirilmesi esnasında yaptıklarımı, karşılaştığım sorunları bir sonraki yazımda detaylı olarak yazacağım.

Son olarak belirtmekte çok büyük fayda var, kod geliştiren arkadaşlar, sistemi yöneten arkadaşlar ve son kullanıcılar arasında iletişimi en iyi sağlayan şey iyi kullanılan, interaksiyon içeren wiki sayfalarıdır.

Sun ve wiki

Wiki yazmak bilginin paylaşılması ve devamlılığı açısından oldukça önemlidir. Etrafınızda yüzlerce wiki engine var. Bunlardan en bilinenleri Twiki, en.wikipedia.org 'un kullandığı MediaWiki ve Confluence . Ama bizi ilgilendiren Sun'ın wiki sayfası. Sun'ın wiki sayfası Confluence ile yapıldı. Şimdilik içeriği yavaş yavaş doluyor. Ama Sun'dan bazı arkadaşlar Sun'da dokümantasyonun hızlı bir tarihçesini anlatan güzel bir video hazırlamışlar. "Publishing @ Sun" bol bol göreceğiniz bir slogan. Keyifle izlenecek bir gösteri. Aşağıdaki filmi izlemekte sıkıntı yaşarsanız, bu linkten izleyebilirsiniz.

Bizim gözümüzden açık kaynak...

Yaklaşık bir hafta süren Mersin-Ankara tatilimden yeni döndüm, gayet güzel geçen bir aile ziyaretleri silsilesinden sonra insan açıkçası kendini pek bir toplamış olarak buluyor... Annenin yemekleri, kayınvalidenin börekleri ve sonu gelmez tek yönlü kalori alışverişi... En nihayetinde ayağımın tozuyla toplulukta ne var ne yok diye RSS'lerimi karıştırırken daha önceleri de canımı sıkan ve yeniden aklıma gelen bir konu oldu ve birkaç kelimeyi bu konu ile ilgili olarak yazma ihtiyacı hissettim.. Açık kaynak uygulamalara nasıl bakıyoruz?...

Açık Kaynak mı? Muhakkak bedavadır alalım...

Başlamadan önce Açık Kaynağın ne olduğunu/olmadığını anlamamız gerekiyor. Birincisi açık kaynak bedava olmaktan öte özgürlük ile daha çok bağdaşır.Yani kod geliştirirken, dağıtırken veya kullanırken özgür olabilmek açık kaynağın getirdiği fırsatlardır. Bunun getirdiği bir sürü avantaj vardır ki, bunlar için ayrı ayrı bir sürü yazı yazılmıştır. Yani bu yazıyı okumaya devam etmeden önce kafanızdaki açık kaynak=bedava eşitliğini bir süreliğine bırakmanız veya kafanızda biraz gerilere itelemeniz gerekiyor.

Hayır!! Açık Kaynak bu şirketin kapısından içeri adım atmayacak!! Bu kadar...

Zaman zaman etrafımızda, çalıştığımız yerde görürüz, Açık kaynak öcüymüş gibi bir tavır sergilenir.Bu tavır genellikle büyük ölçekli, kurumsal şirketlerde gösterilir. Ve en temelde iki sebebi (ya da öyle olduğu söylenir) vardır. İlki, güvenlik açıklarından dem vurulur.. İkincisi, destek ve dokümantasyon olmadığından yakınılır.

Öncelikle güvenlikten bahsedelim. Güvenlik açığı heryerde olabilir. Sisteminin mükemmel işlediğini düşünen bankalarda dahi güvenlik açıkları vardır. Her programda olduğu gibi açık kaynak uygulamalarda da güvenlik açıkları vardır. Ama uygulamada geliştirme/kullanma olarak katılımcı sayısı (ki bu açık kaynak topluluğu oluyor) fazla ise güvenlik açıkları zaman içerisinde bulunmuş ve düzeltilmiş/düzeltiliyordur. Eğer bundan yana çok şüphe duyuluyorsa kodlar nasıl olsa elimizde bakabiliriz değil mi? Bu noktada sanki kapalı kaynak kodlar biraz daha güvensiz gibi duruyor (içeride ne olup bittiğini bilmememiz açısından).

Destek ve dokümantasyona gelirsek, açık kaynak uygulamalar ölçeklerine bağlı olarak ücret karşılığında destek ve dokümantasyon sağlarlar. Tabi açık kaynağı bedava olarak niteleyip, ardından "nereden çıktı bu masraf" dersek afallarız tabi... Yukarıda da belirttiğim gibi açık kaynak her zaman bedava anlamına gelmez. JBoss lisans ücreti ödemezsiniz, ama JBoss ON için CPU başına bir lisans ücreti ödemek zorundasınızdır...

Nasıl yani açık kaynak hiç mi para kazanmıyor?

Açık kaynak uygulamalar Microsoft'un aksine lisans ücreti talep etmezler, bunun yerine dokümantasyon ve destek, zaman zaman da yardımcı entegre modüller asıl para getiren kısımlardır. Bununla ilgili Matt Asay'in Open Road'daki "Why Microsoft fears open source more than other proprietary vendors do" yazısı lisanslama ve dokümantasyon/destek arasındaki farkı ve bununla ilgili Microsoft ve Açık Kaynak arasındaki görüş farklılıklarını çok güzel anlatmış. Bir göz atmakta fayda var.

Eee iyiymiş bu açık kaynak

Açık kaynak trendi özellikle Sun CEO'su Jonathan Schwartz'ın katkıları ve vizyonu ile önce OpenOffice, sonra OpenSolaris ve ardından OpenJDK ile ivme kazandı. Sun'ın bu çabasına yakın zamanda IBM de OpenOffice.org topluluğuna katıldığını açıklayarak bir anlamda destek oldu. Sonra sırası ile birçok geniş ölçekli program trend değiştirip kodlarını açma kararı aldılar. Bunun en son örneği ise VMWare oldu. RedHat Fransız Eğitim Bakanlığı ve İsveç'te büyük ölçekte bir ilaç portali olan Fass.se'nin tüm server'larını (IBM ve Solaris'ten) RedHat Linux'e geçirdi.

Biz ne yapıyoruz peki?

Bu kadar yazıdan sonra etrafımda neler olduğunu bir toparlarsam, sırasıyla aşağıdaki sonuçları çıkarabilirim.

1.Hala açık kaynak bir uygulama gördüğümüzde kalitesiz ve ucube muamelesi yapıyoruz (Ve hatta lisanslı ürünlerin web sayfalarını inceleyip, aynı ürünün açık kaynak bir şekilde yapılamayacağına kendimizi inandırıyoruz)
2.Açık kaynağın bedava olmaktan öte paylaşımcı, sürekli geliştiren ve öğretici bir topluluk olduğunu anlamakta zorlanıyoruz.
3.Biz geliştirdiğimiz uygulamaları sanki dünyada kimse yazamazmış gibi, kodları kapalı ve lisanslı satmaya çalışıyoruz. (Tamam bu biraz fazla oldu, ama öyle)

Yukarıda yazdığım sonuçlar ile kimseyi suçlamıyorum..Sadece dünyanın yöneldiği trendi hala görmemekte ısrar ediyoruz. Benim vurgulamak istediğim nokta bu.

Hmm tabi bunları söyledikten sonra şunları da ekleyeyim, OpenOffice kullanıyorum, Sun Server'lar üzerine Solaris 9 yerine OpenSolaris veya RedHat kuralım diye her fırsatta ısrar ediyorum. Firefox favorim. Eclipse'ten daha iyi bir IDE tanımıyorum. Konfigürasyon Yöneticiliğini yaptığım projenin Kaynak Kodları Subversion'da (Starteam'den geçtik) tutuluyor. Sürüm sistemi Hudson/CruiseControl ve Ant kullanılarak yapılıyor. Vesaire, vesaire, vesaire...

Sistem-Sistemci-Alt Sistem üçgeninde yaşananlar...

Daha önce yazdığım Developer sadece kod mu yazar? adlı yazıda daha önceden kod yazma geçmişimin avantajlarını kullanarak piyasanın istediği, beklediği veya önem verdiği developer modeli ile ilgili tüyolar vermeye çalışmıştım. Ya da en azından benim gözümden faydalı developer nasıl olabiliri anlatmayı denemiştim.

Şimdi ise developer'ların kodlarını gerçek sisteme alırken karşılarına çıkan ve kodları gerçek sisteme çıkana kadar yanlarında yürüyen, daha sonra onlar kodlarını orada bırakıp ayrıldıklarında bu kodların asayişini , sistemle iyi ilişkiler içinde yaşamasını sağlayan, sorun olduğunda bu sorun ile developer'ı ilişkilendirebilen bir grup insandan bahsedelim. Sistem yöneticisi veya sistemci olarak tabir edilen bu insanlar, bir sistemin vazgeçilmezleridir. Developer'lar şöyle olmalı, böyle olmalı diye ahkam kestik ama sistemcilerin de sahip olması gereken bazı özellikler olmalıdır.


Buzdağının suyun altında parçası mı var?...

Bunların en başında üzerinde uzman olduğu, yönettiği sistemi en kuytu köşesine kadar bilmeli, veya öğrenmeye azimli olmalıdır (yazının bazı yerlerinde bu tür esnemeler olabilir, eğer sadece bilmeli deyip bıraksa idim olmazdı, çünkü hiçbirimiz herşeyi bilmiyoruz, ve daha okuyacak, öğrenecek çok şey var). Sistemin özelliklerini ve yapılabilecekleri bilmek sorunları çözebilmek ve kavrayabilmek adına çok önemlidir. Sistem buzdağı gibi tabir edilebilir, sistemin herkesçe bilinen bazı özellikleri, bazı işlevsellikleri vardır. Sistemci bunları bilmez ise kendini kötü hissetmesi sağlanır!?!?! Ama iş sadece bunları bilmek ile kalmaz. Bu yüzeydeki kısımları bilmesi, sadece günü kurtarmasını sağlar. Ama buzdağının suyun altında kalan kısmını bilir ise kütlenin büyüklüğüne ve yoğunluğuna bakarak, ne tarafa gidebileceğini, ne kadar sürede eriyeceğini veya kaç kişiyi taşıyabileceğini anlayabilir.

Sistem-Alt sistem ilişkisi...

Sistemcinin bilmesi gereken konulardan birisi de yönettiği sistem üzerinde çalışan (üzerinde çalışsın diye programlanmış olan) alt sistemlerin (uygulama sunucusu üzerinde bir uygulama olabilir, oracle üzerindeki SP'ler olabilir, SQL Server üzerinde tablolar olabilir, IBM P575 üzerinde Oracle 10g olabilir, olabilir de olabilir) sistemi üzerinde nasıl çalıştığını, eğer yanlış çalışıyorsa alternatif çalışma yöntemlerinin ne olabileceğini bilmelidir. Örneğin Oracle IBM üzerinde performanssız çalışıyorsa, hem Oracle tarafı; alt sistemini, ana sistem üzerinde çalıştırmak için ince ayar yapar, hem de IBM ana sistemi Oracle alt sisteminin daha performanslı çalışması için ince ayar yapar. Bu profesyonel bir sistem-alt sistem örneğidir. Windows makinenize kurduğunuz Eclipse IDE'sinin çok yavaş çalıştığını düşünürseniz, önce Eclipse IDE'sinin VM ayarlarını artırmayı veya azaltmayı denersiniz, sonra Windows'unuza biraz daha sanal bellek ayırırsınız. Bu çok daha amatör bir sisem-alt sistem örneğidir.

Sonuç olarak, sistem ve alt sistem arasında bir performans kaybı var ise hem sisteme, hem de alt sisteme aynı özenin gösterilmesi lazımdır, ve bu özenin gösterilebilmesi için de sistem yöneticisinin kendi ana sistemini yüzeysel bilginin ötesinde tanıması gerekir.

Bugün olmaz randevum var...

Sistemci olmanın getirdiği en ironik durum ise tüm sorumluluğun size ait olduğu bir sisteme istediğiniz zaman müdahele edemeyecek olmanızdır. Sistemde bir operasyon yapmanız gerekiyorsa, öncelikle bu sistemle uzaktan yakından, az ya da çok ilişkisi olan herkese en müsait zamanın ne olacağını sorup, teyit aldıktan sonra bu işi yapmanız gerekiyor. Bu durumda da operasyonu yapabileceğiniz bir Cumartesi gecesi saat 01:30 için "bugün gelemem, çok önemli bir randevum var, evlenmem gereken birisi ile buluşacağım" diyemezsiniz.

Yedekleme mi? Neyi? Niye?...

Sistemci iseniz yapmanız gereken ilk şey her tür değişiklikten önce sistemin kendinize özgü bir yedeğini almanızdır. Yedek alınmadan yapılan operasyonlar, herhangi bir güvenlik ipi olmadan 400 metre yükseklikte, yağlanmış bir ip üzerinde saatte 20 km hızla koşmaya çalışmaya benzer.. Anlayacağınız, yedek alınmadan yapılan ve başarı ile tamamlanan tüm operasyonlar, meleklerden tarafından korunmuş, ermişler tarafından okunmuştur, ya tamamiyle şans işi, veya dünya dışı varlıkların bir ürünüdür. Abartı bir tarafa, işini bilen sistemciler, daima yedekleme yaparak çalışırlar, hiçbirimiz borsada değiliz, riskin bize kazandıracağı herhangi birşey yok...

Hani Alkış...

Bir sistemin bu kadar çok cefasını çeken, gecesi gündüzü olmayan, ve sistemlerinin alt sistemlerle mürüvvetini görmekten mutluluk duyan sistemcileri hatırlamak... Bununla ilgili olarak System Administrator Appreciation Day sayfası bu tür bir işi görüyor, 9. senesini kutladığımız Sistem Admin'lerini Koruma, Kurtarma ve İyi Bakma günü (bir miktar geçmiş olsa da) hepimize hayırlı uğurlu olsun.

Son Söz..

Sistemci olmak büyük özveri gerektirir. Mesai saati kavramı sistemciler için yapılmamıştır. Aynı zamanda saat gibi tıkır tıkır çalışan bir sisteminiz varsa, sakın böyle bırakmayın, inanın sisteminiz ile ilgili bilmediğiniz daha bir sürü şey var (çok iddialı oldu). Eğer herşeyi bildiğinizi düşünüyorsanız, sizin sisteminizin benzeri daha bir sürü sistem var, dostu/düşmanı iyi tanımak lazım.

Hudson ve JBoss

Hudson kullanım kolaylığı, göze hoş görünebilmesi ve bir çok diğer nedenden dolayı (Hudson ile Sürekli Entegrasyon) açık kaynak topluluğu içerisinde sık kullanılır oldu. Uzun süredir Hudson kullanan JBoss, hudson sayfasında sürümlerini herkesin göreceği hale getirdi. Bu da bir anlamda Hudson'a yapılmış bir jest. Ne de olsa JBoss açık kaynak topluluğu içerisinde gayet iyi bir şöhrete sahip. Bu linke tıklayarak JBoss'un hudson sayfasını görebilirsiniz.

Hudson ile ilgili gelişmeleri Kohsuke Kawaguchi'nin blog'larından bulabilirsiniz.

Confluence içerisinde WYSIWYG Editör sorunu

Geçenlerde düşünüyordum da Blog yazmak ile Wiki sayfası hazırlamak birbirine o kadar yakın gibi görünen iki kavram ki... Zaman zaman bunların içeriklerini birbirine karıştırabiliyoruz. Ben de düşündüm ve bir confluence kurup diğer referanslarımı buraya atmaya karar verdim.

Confluence ile ilgili daha fazla bilgiyi Mustafa Tan'ın "Confluence-I" adlı yazısında bulabilirsiniz.

Biraz download biraz uğraşıdan sonra Confluence hazırdı. Tomcat'i çalıştırdım, ve confluence'a ilk adımımı attım.. Karşıma çıkan adım adım kurulumdan sonra admin hesabı yaratılmış bununla sisteme girilmiş demo bir space üzerinde bulunuyordum. Birkaç gün editledim, karıştırdım, ama bir süre sonra birşeylerin yokluğunu hissetmeye başladım. Sonra farkettim ki WYSIWYG (What You See Is What You Gain) editörüm yoktu, sadece wiki markup language ile editleme yapıyordum. Garip olan buna yabancı olan birinin bunu bir hata olarak görmeyip devam edebileceği ihtimali idi.

Neyse, biraz araştırmadan sonra bununla ilgili bir forum kaydı buldum (okumak için tıklayın). Burada dediğine göre kurulum esnasında oluşan bir problemden dolayı atlassian-bundled-plugins.zip dosyasını açması gereken yere açmıyormuş, hatta bununla ilgili bir de issue varmış (CONF-7750). Tabi bu dosyayı bulmak zor olmadı, çünkü confluence'i download ederken war/ear şeklinde olanı indirmiştim ve unzip ettiğim klasör içerisinde buldum. Bunu alıp Confluence'in data klasöründe bundled-plugins klasörüne açtım (bir hayli jar var) ve tomcat'i restart ettiğimde artık confluence wiki sayfalarımı Ne Görüyorsan Odur editörü ile editliyebiliyordum.

Başka daha garip bir durum ise o kadar jarı bundled-plugin'ine açamadığına göre acaba daha başka neleri göremiyordum.

Apache HTTP Server üzerinde Subversion : can't locate API module structure "dav_svn"

Subversion, CVS'in açık kaynak topluluğunun ihtiyaçlarına artık yetmediği bir zamanda sanki bir anda CVS'in küllerinden doğmuş (biraz abartılı oldu değil mi? Ama güzel oldu) ve açık kaynak topluluğunun yardımına yetişmiştir. Tabi birkaç yerde (Mozilla, OpenSolaris) CVS'ten SVN'e değil de Mercurial'a geçiş olmuşsa da sanırım bir süre daha Subversion dominanat olacak. Neyse, bu şekilde bir toplulukta Subversion'ı her şekilde çalışır hale getirebilmeyi tüm konfigürasyon yöneticilerinin bilmesi gerektiğinden hareketle Subversion'ı birkaç şekilde ayağa kaldırmayı deniyordum.

Svnserve ile herhangi bir sorun yaşamaksızın Subversion'ı hayata geçirdim, sonra sıra Apache üzerinde çalışır hale getirmeye geldi. Bu arada belirteyim ilk önce Subversion 1.4.4 ve Apache Web Server 2.2.4 ile çalışmaya başladım. Adım adım httpd, the Apache HTTP server linkinde istenilenleri yapmaya başladım.

httpd.conf'a gir
LoadModule olarak svn dav zımbırtılarını ekle

Ekledikten sonra devam etmeden önce bir bakmak istedim so dosyalarını yükleyecek mi? Apache server'ı restart ettim ve çat, bahsettiğin so'yu bulamıyorum, yok öyle bir so, bana yalancı mı diyorsun (can't locate API module structure).

Garip geldi, iki üç kere kontrol ettim, dosya orada.. httpd.conf dosyasına eklemem gereken satıra baktım önce LoadModule diye bir keyword, sonra so dosyasını verilecek isim ve sonra so dosyasının yeri. Sonra Subversion'ın Apache ile uyumsuz olup olmayacağı sorusu geldi aklıma, adamlar ön yüzde yazmışlar.

If you plan to install the mod_dav_svn Apache module, note that Apache 2.0 and Apache 2.2 are not binary-compatible. Thus there are two types of Subverison...

Tamam dedim, Apache 2.0 kurdum, denedim cık, aynı hata, Subversion'ı yeniden indirdim onu kurdum. Aynı hata, delirmek üzereyim. Sonra yeniden Apache 2.2 kurdum ve son kez httpd.conf dosyasını açtım, şöyle bir göz atmak için, gözüme birşey takıldı... LoadModule olan tüm kısımlarda benim so ismi dediğim kısım da module ile biterken benimkiler (son iki satır) normal bitiyor.


LoadModule include_module modules/mod_include.so
#LoadModule info_module modules/mod_info.so
LoadModule isapi_module modules/modPublish Post_isapi.so
LoadModule log_config_module modules/mod_log_config.so
LoadModule mime_module modules/mod_mime.so
LoadModule dav_svn modules/mod_dav_svn.so
LoadModule authz_svn modules/mod_authz_svn.so

sonlarına _module yazdım ve restart ettim. Evet ondan sonra çalıştı.

Bu durumda ortaya bir kaç tane yorum ve sonuç çıkıyor.

1. Gözden kaçırdığım bir ayrıntı birkaç saatime mal oldu.
2. Tamam SVN kitabında istenenleri birebir yapsaydım bu hata da olmayacaktı. Ama yaptığımız iş nedeniyle hiçbir zaman yazılanları birebir yapma imkanımız ya da birebir yaptığımızda çalışırsa "hah tamam" diyebilme lüksümüz yok.
3. Hataya baktığımda dav_svn'in bağlı olduğu so dosyasının yerini bulamıyorum diye algılamıştım.
   
4. Eğer bu "_module" postfix'i bu kadar önemli ise bir yerlere "bak bunu yazmayı unutursan Oğuz gibi olursun" denmeli

Sun nohup script

Unix/linux makinelerde çoğu aracı çalıştırmak için shell scriptleri kullanırız. Mesela JBoss'u açmak için run.sh veya CruiseControl'ü çalıştırmak için cruisecontrol.sh, veya kendi yazdığımız ve loglarını takip ettiğimiz shell scriptleri.

Bu scriptleri kullanırken ben en çok nohup komutunu kullanırım gerek arkaplanda çalışsın diye gerekse scriptin outputunu herhangi bir dosyaya almak istediğim için. BigAdmin'deki amcalardan bir tanesi bu işi biraz düzene sokmak adına bir tane nohup.sh yazmış. Automatically Saving Program Output With a nohup Script linkinde belirtilen yöntemleri izleyip nohup.sh ile scriptinizi çalıştırırsanız. /var/ klasörü altında scriptinizin adı ve o günün tarihi ile kombine edilmiş bir log dosyası hazırlayıp saklıyor. İnanın bu tür bir işlem çok faydalı olabiliyor.

Hudson ile Sürekli Entegrasyon

Sürekli Entegrasyon (Continuous Integration) konusu herkesin dikkatlice üzerinde durması gereken hayati bir konudur. Geliştirdiğiniz proje eğer Agile Development tarzında bir proje ise sürekli entegrasyon daha bir önemli hale gelir. Çünkü bulunduğu yer, developer ile client arasında, proje için olmazsa olmaz bir pozisyon olacaktır.

Sürekli entegrasyonu sağlamak adına en çok kullanılan araç CruiseControl'dür... Biz de açıkçası projemizde yaklaşık 3 yıldır CruiseControl kullanıyoruz. Ama bu yazıda size birçok açıdan daha avantajlı, kullanımı kolay başka bir araç olan Hudson'dan bahsedeceğim.

Hudson'ın en göze çarpan ve beni bu yazıyı yazmaya iten özelliği kurulumunun ve hayata geçirilmesinin çok kolay olması. Yani sadece bir web server üzerine deploy etmeniz çalışmaya başlamanız için yeterli. Bu yazıda basitçe hudson'ı Tomcat üzerinde nasıl hayata geçireceğimizi ve yapılabilecek bazı ayarları anlatmaya çalışacağım.

Kurulum

Çalışan bir Tomcat'e (5.0 ve üstü) sahip olduğunuza emin olduktan sonra, hudson'ı bu linke tıklayarak indirmeniz gerekiyor. Aynı Tomcat üzerine birden fazla hudson çalıştırmak isteyebilirsiniz, farklı iş türlerini gruplamak için olabilir, her ne kadar hudson'ın tab sistemi buna benzer bir yapıya sahip olsa da, gruplamanın dışında CI Server'ı restart, redeploy etmeniz gerekebilir. Bu durumda yapmanız gereken iki iş var

• hudson.war dosyasının ismini değiştirmeniz,
• Değiştirdiğiniz war dosyasının web.xml'ini açıp HUDSON_HOME değişkenine bir değer atamanız gerekiyor.

Bu şekilde birden fazla hudson'ı aynı Tomcat üzerinde çalıştırabilirsiniz.

Konfigürasyon ve Püf Noktaları

Eğer hudson'ı kapsamlı bir projede kullanacaksanız, Tomcat üzerine hudson'dan başka bir uygulama deploy etmeyin, böylece Tomcat'in JVM ayarlarını hudson için özel olarak ayarlayabilirsiniz.

Güvenlik : Hudson ile ilgili yapabileceğiniz önemli konfigürasyon ayarlarından bir tanesi de güvenlik ile ilgili olan ayardır. Her ne kadar çok gelişmiş bir güvenlik sistemi olmasa da, hudson'a yapacağınız birkaç ayar ile developer'ların job'ları (Hudson içerisinde iş için kullanılan kavram) sadece görebilme ya da konfigüre edebilme yetkisine sahip olabilmesini sağlayabilirsiniz. Bunun için sırasıyla

• Tomcat üzerinde hudson'ı yönetebilmesini istediğiniz kullanıcıları tanımlayın ve bunları "admin" rolü ile bağlayın
• Son olarak hudson'ın web sayfasını kullanarak Manage Hudson >> System Configuration linkini kullanın ve Enable Security kısmını tikleyin.
  

Hudson default olarak güvenlik opsiyonu açık bir şekilde gelir (herkes herşeyi yapabilir), yukarıdaki ayarları yaptığınızda sadece sizin hudson rolüne uygun görüp tanımladığınız kullanıcılar job'ları çalıştırabilir/konfigüre edebilir veya hudson'ı konfigüre edebilir, diğerleri sadece job'ların ne durumda olduğunu görebilir. Daha çok bilgi için buraya tıklayın.

Yedekleme : Hudson'ı yedeklemek istiyorsanız yapmanız gereken sadece web.xml içerisinde HUDSON_HOME klasörü için belirlediğiniz klasörü yedeklemektir. HUDSON_HOME>jobs klasörü altında bulunan tüm klasörler birer job'dır, bu job'ları kopyala/yapıştır ile başka hudson'lara aktarabilirsiniz.

Haydi işe koyulalım...

Konfigürasyon ayarlarını kurcaladıktan sonra sıra geldi birşeyler üretmeye. Daha önce de belirttiğim gibi hudson kurulumu ve yönetimi kolay bir sürekli entegrasyon aracı. Bunun en iyi örneğini job tanımlama ve yönetme esnasında görebilirsiniz. Hudson ana sayfasında New Job linkine tıkladığınızda 4 değişik job türü yapabilme ve bir tane de varolan bir job'ı kopyalayabilme opsiyonunu göreceksiniz. Bu job türleri kısaca

Maven2 : Maven2 ile geliştirdiğiniz projelerinizi kolayca entegre edebilirsiniz.
Matrix Build : Aynı sürümü birden fazla ortamda birden fazla parametre ile denemek isterseniz.
External Job Monitoring : Sistemde çalışan cron job'ları da takip edebileceğiniz kullanışlı bir job
Free-Style Software : Ayarlarını istediğiniz gibi değiştirebileceğiniz job tipi, benim üzerinde duracağım job da bu.

Free-Style Software'i seçtiğinizde karşınıza bir sürü ayar çıkacak, bunlardan birkaç tanesini anlatmaya çalışacağım, diğerlerini yanlarında bulunan soru işareti ikonuna tıklayarak siz bulabilirsiniz. Build kısmında shell, windows bat, ant build veya maven build'leri çalıştırabilirsiniz. Ant scriptlerini çalıştırmak için Build kısmında invoke top-level Ant targets'ı seçmeniz ve Targets kısmına ant'a girdiğiniz parametreleri yazmanız gerekiyor (mesela ant -f build_deneme.xml için targets kısmına -f build_deneme.xml yazmanız gerekir) Bunu yaptığınız zaman job'ınız bu scriptinizi çalıştıracak durumda beklemeye başlar. Bundan sonra job'lar kısmında bu projenizi göreceksiniz. Yanında "Schedule a build" ikonu ile birlikte.

Sürekli Sürüm (Gecelik, Saatlik)

Ama asıl önemli olan bunu nasıl zamanlanmış iş olarak ayarlayıp, gecelik sürüm, saatlik sürüm haline getirebileceğinizdir. Hudson burada da işimizi çok kolaylaştırıyor. Build Triggers kısmında Build Periodically kısmına tıkladığımızda önümüze free text bir alan açılıyor (Schedule). Buraya yazacağınız syntax ile birlikte bu job'ı zamanlanmış hale getirebilirsiniz. Yan yana yazılan 5 alan bize zamanlama yapma olanağı verir.

MINUTE(Dakika) HOUR(Saat) DOM(Gün) MONTH(Ay) DOW(Haftanın Günü)

Bu alanlar sırasıyla

Dakika : 0-59
Saat : 0-23
Gün : 1-31
Ay : 1-12
Haftanın Günü : 1-7

Mesela her gece saat 21:00'de çalıştır diyebilirsiniz,

0 21 * * *

veya hem gece saat 21:00'de hem de pazartesi-çarşamba öğleden sonra çalıştır diyebilirsiniz,

0 21 * * *
30 12 * * 1,3

Ya da sadece pazartesi akşam 18:00'de çalıştır diyebilirsiniz.

0 18 * * 1

Bahsettiğim ayarları yaptığınızda artık sürekli sürüm sistemine sahip olmuş oluyorsunuz. Bunun yanında isterseniz sürümü manuel de başlatabilirsiniz.

Bunların yanında hudson'ın bize sunduğu daha bir dolu özellik var. Bunlardan biri de plugin ekleyebilme özelliği. Şu anda JIRA, FindBugs gibi önemli olabilecek pluginlerin yanında irili ufaklı bir sürü plugin var ve geliştiriliyor. Pluginleri bu linkte bulabilirsiniz. Bu pluginlerle birlikte sürüm ve entegrasyon sisteminizi daha güçlü ve daha efektif hale getirebilirsiniz.

Ölçek farketmeksizin; eğer sürüm sisteminizi, bir issue tracking tool'u ve file versioning system ile entegre ederseniz , hatırı sayılır bir sisteme sahip olursunuz.

JConsole ile Performans Gözlem - Part 2

JConsole'un en önemli ve en kullanışlı tablarından birisi Memory tabı.. Memory'nin grafiği size durumun nasıl gittiğini anlatır. Neler olabileceğine dair fikirler verir. Figure 3'te gördüğünüz grafik sıradan bir Heap Memory'nin yaklaşık yarım saatlik süreçteki akışını göstermektedir. Grafiğin hemen altında yeşil renkle gördüğünüz sütunlar, değişik memory kısımlarını göstermektedir. Sırasıyla Survivor Space, Young Space, Old Space, Permanent Space, Code Cache Space'tir. Altlarındaki yatay çubuklar ise üzerlerindeki sütunların toplamlarını göstermektedir. Eğer JVM tune ediyorsanız, bu parçalar hakkında bilgili olmanızda fayda olacaktır. Bu parçalar hakkında yüzeysel birer açıklama yapayım.
Survivor Space : Swap Space gibidir, hafıza içerisinde yeri değiştirilecek nesneler için kullanılır.
Young Space : Hafızada süre olarak yeni olan objelerin tutulduğu yerdir. Minor GC bu kısımda yapılır.
Old Space : Göreceli olarak hafızada daha uzun süre yer alan nesneler burada tutulurlar. Major GC dediğimiz ve yapıldığı sürede JVM'in başka birşey yapamadığı Garbage Collection burada yapılır.
Permanent Space ve Code Cache Space : Bu kısımlar JVM için ayrılan yerin dışında yer kaplarlar ve mesela statik yüklenen class'lar burada tutulur.
Bu kısımların nasıl efektif kullanılacağı ile ilgili bilgileri
Tuning the Java Runtime System
tagtraum industries
A Collection of JVM options
linklerinde bulabilirsiniz.

Bu bilgilerin yanında kolonlara tıkladığınızda o kolonlarla ilgili bilgileri JConsole'u çalıştırdıktan sonra geçen zamana ait olarak görebilirsiniz. GC Time kısmında kaç kere Major GC (Yukarıdaki) yapıldığı ve ne kadar sürdüğü ve kaç kere Minor GC (Aşağıdaki) yapıldığı ve ne kadar sürdüğü görülebilir. GC'nin ne olduğu, nasıl izlendiği ile ilgili arkadaşım ve meslektaşım Mustafa Tan'ın Java Hafıza Problemleri ve GCViewer yazısı iyi bir kaynak olabilir.

Figure 3

Threads tabı bir diğer hayat kurtaran tabdır. Yani en azından bizim için öyle olmuştur. Figure 4'te gördüğünüz ekranlarda JVM içerisinde yer alan thread listesini ve bunun tomcat ile ilgili olan (yani web servlet aracılığı ile gelen) thread listesini görebilirsiniz. Aşağıdaki filter kısmına thread ile ilgili belirleyici bir kaç harf giriyorsunuz ve ta-tam, thread'leriniz listeleniyor. Bundan sonra yapmanız gereken sadece hangi threadin detayını görmek istiyorsanız ona tıklamak. Eh artık biraz da stack trace'den neler çıkarabileceğimize kalıyor iş.

Figure 4

MBean'ler ve invocation'ları ile ilgili bilgileri Figure 5'teki MBeans tabında bulabilirsiniz. Bu tab içerisinde soldaki navigasyonda erişebildiğiniz mbean'leri ve bu mbean'lerin metodlarını bulabilirsiniz. Eğer az çok JBoss'un JMX console'una aşina iseniz, bu ekran sizin için hayli güzel şeyler içerebilir. Ben örnek olarak Threading'i seçtim. e

Figure 5

Son tabımız ise Figure 6'da da gördüğünüz gibi VM tabı, biraz summary tabına benzesede burada bulacağınız bilgiler de gayet kullanışlı olacaktır. Bu bilgiler sırasıyla, JVM'in hangi Java versiyonu ile çalıştığı bilgisi, çalışan JVM'in process numarası (name kısmında @ işaretinden hemen önce), kullandığınız JVM argümanlarının tam bir listesi, çalışan JVM'in classpath'i boot classpath'i gibi faydalı bilgiler bazı diğer makine konfigürasyonu bilgileridir.

Figure 6

Bu yazıya ek olarak belirtmekte fayda göreceğim birkaç nokta var. JDK 6.0 ile birlikte gelen JConsole içerisinde JVM'in makine üzerinde yarattığı CPU yükünü takib edebiliyorsunuz. Yani yeni bir özellik olarak CPU izleyebilme eklenmiş. Summary tabı ile VM tabı birleştirilmiş. Bunun yerine ilk açtığınızda karşınıza Memory, Threads, CPU ve Classloading'den oluşan dörtlü basit bir monitor geliyor. Hmm bir de JDK 6.0 üzerindeki JConsole'a yazılmış birkaç tane eklenti gördüm. JDK 5.0'daki JConsole'da yoktu, ya da ben rastlamadım.

Bu kadar kolay ve rahat kullanılabilen bir aracın neler yapabildiğini anlatmaya çalıştım. Bu durumda şunu söyleyebilirim, ne şekilde olursa olsun, sistemleri gözlemlemek, hem sistemin doğasını anlamanıza yardımcı olur, hem de sistemi mevcut durumundan daha iyi bir düzeye getirmek için elinizde bulgular olmasını sağlar.