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.