Google Chrome Çizgi Romanı

Üç-dört gün önce yavaş yavaş basına sızan ve salı sabahı resmi olarak download'a hazır hale gelen Google Chrome, sanırım bir süre browser dünyasının yeni gözdesi olacak... Şimdi, ben Chrome'un memory yönetimini nasıl daha iyi yaptığını, java scriptleri nasıl daha etkili yönettiğini, nasıl hızlı açıldığını, nasıl güzel olduğunu anlatmayacağım... Ben asıl eğer bakmadı iseniz, Google Chrome'un Çizgi Romanı'ndan bahsedeceğim... Henüz bakmadı iseniz hemen ve aceleyle Google Chrome Comic linkine tıklayın... Sayfaları nasıl okuduğunuzu anlayamayadan 38 sayfa çizgi romanı, zevkle bitirdiğinizi farkedeceksiniz... Benim gibi özellikle çizgi roman hastası olanlar için bulunmaz bir nimet... Baloncuklardaki kısa yazılar, uzun uzun düzyazı paragrafların yerini alıyor... Renk olarak mavi ve beyaz tonlarının kullanılması, gözü yormadan bir anlatım sağlıyor... Bir de adamlar oturup her konu için figürler yapacaklarına, bu figürleri çizgi roman havasında nefis bir şekilde aktarıyorlar...

Bakalım daha başka ne yenilik yapacaklar... 

Hudson'ın mimarı ile bir söyleşi

Bir hayli uzun zamandır bloguma herhangi bir şey yazamıyordum.. Araya yaz tatilim, IBM Websphere ile ilgili performans problemleri ve tuning işlemleri girince bu kadar uzun bir ara vermek zorunda kaldım... Ben de blog yazılarıma bu şekilde bir söyleşi ile döneyim dedim...

Kohsuke Kawaguchi'ye, Hudson projesini ortaya çıkaran, ve şu anda tam zamanlı olarak bu işe vaktini ayıran kişiye, Hudson hakkında aklıma gelen bazı soruları sorma fırsatı buldum.. J1 sırasında bu soruları sormuştum, Hudson ve yürüttüğü diğer Sun projeleri ile ilgili J1'de görevli olduğu için biraz rötarlı olarak cevap verdi, ben de bu soru ve cevapları orijinal hali ile (ingilizce olarak) aşağıda sizlerle paylaşmak istedim... Cevapları okudukça açık kaynak projelerde izlenmesi gereken tavrı ve bir açık kaynak projesi etrafında oluşan atmosferi daha yakından anlayabileceksiniz... Çok içten ve yeterli (baştan savma değil) cevaplar beni yeterince memnun etti... Sorular ve cevaplar hakkında yorumlarınızı bekliyorum...

İşte Koshuke'ye yönelttiğim sorular ve cevapları

Question 1 - Who is Kohsuke Kawaguchi, can you briefly give some information?

Answer - OK, I'm a software engineer working for Sun Microsystems. Lately I'm spending more and more time on Hudson, but before that, I was (and am) in a part of Sun that does JavaEE, and I've been mostly working on XML. So I've been involved in technologies like JAXP, JAXB, and JAX-WS, and their implementations.

I'm originally from Japan, and in the United Status for 7 years now. At home, I have a 3-year old daughter who deprives me of my programming time.


Question 2 - Where did this Hudson idea came from? We know you think the name "Hudson" to serve you as servant. But why did you need another Continuous Integration Server?

Anwer - It started when I was working on the JAXB RI. At that time we had 3 people (including me) who's working on the code, and we are all busy checking in changes every day, but I'm very bad at making sure all my changes are committed. So from time to time, my colleagues discovered that they can't build the RI after they update from the CVS repository.

So I started developing some shell scripts, which essentially does what my colleages do (pull from CVS, do a build), but do it much more frequently. So I can be notified by that program before my colleagues catch that problem.

I also wanted to implement some web application, because I work in the JavaEE group and we do servers! I was not very happy with the webtier technology, and I thought I had a better idea. So another motivation was to try out my idea for real, to see if it works. This became Stapler
eventually.

And so I was thinking about how to turn this little app into a webapp, and I was greatly inspired by now deceased CI application called "Damage Control." So I started mimicking its UI, but by using Java and Stapler.


Question 3 - Wakaleo consulting is running a poll about CIServers in this link, Hudson at the top, what do you think about this, this poll reflects the recent usage of CIServers? (BTW, I voted for Hudson)

Answer - You have to take any poll with a grain of salt, but seeing more adoption is a motivator for any open-source developer, I think.

In any case, I try not to worry too much about those polls. It's more fun to think about features to implement, and making people happy by fixing bugs quickly. Adoption should follow if I do a good job.


Question 4 - In Nabble Forums, you are replying every post, on your own. Is this task, a little bit hard to maintain?

Answer - But for me, interacting with users directly is very important. First, it's a motivator --- open-source development is just like any other volunteer effort. We do this because we want to see happy faces, and in our context that means helping people through e-mails.

Another reason it's important is often it gives me insights about where are rough edges. If you see multiple people making the same mistake, that means your software is wrong, not them. The only way to get a good sense of where they are is to do the user support yourself.


Question 5 - What do you think about the community around Hudson, how many committers do you have (not bug reporters)?, translators are one of them?

Answer - According to Ohloh, I have 69 contributers. This includes people doing translations and plugin developments.

One thing I'm trying with Hudson is a different way of running a community. Traditionally in open-source community, the bar for a commit access is rather high. You have to start by sending in patches, helping users, and do those things for a long time, while anxiously waiting for the day you are offered a commit access.

That makes sense for high-profile projects like Linux kernel, where there are tons of wanna-be developers that you have to chase away by a stick, but for most of open-source projects that are small, that's completely wrong trade off.

Most of the time, we struggle to get even one more committers. If you can even get one guy who's potentially interested in helping the development, you should be very happy. Having a high bar to contribution is only going to discourage that. That's not what you want.

So in Hudson, we give away commit access very liberally, which is reflected in a larger number of committers. The plugin system really works well here, because it eliminates a part of the reasons why there's such a high bar to the entry; namely, to make sure people you'll have to work with are nice people.

So far I think this model is going well.


Question 6 - What do Sun think about Hudson? because you are an employee of SunMicrosystems? And I don't think that Sun didn't notice Hudson.

Answer - We are talking to various people internally at Sun to figure out how it fits with our broader strategy. So stay tuned for more on this in the future.

And lots of Sun projects are built and tested on Sun. So in a sense it's already used widely as one of the tools.


Question 7 - What is the maturity of Hudson in your viewpoint? I mean Hudson now can compete with CruiseControl, but is it enough to say Hudson is mature enough?

Answer - It's hard to think of software as maturity. I think there's no question that it's quite usable --- otherwise not so many people would be using it. But there are a lot of issues and RFEs filed, so there's no doubt that there are more work ahead.

I think that's one thing I really like about the tool development; IMO, there's really no such thing as "mature enough" in tools. There are nearly infinite room of improvements in any front, and it's fun to make a tool better.

I still have a lot of feature ideas and I do hope to implement them in time.


Question 8 -What is the chance of Hudson, against some proprietary CIServers such as Bamboo, BuildForge, AntHill?

Answer - I think Hudson already marginalized several commercial offerings. Even if you are charging for a product and spending that money to hire developers and/or designers, that alone is not a sufficient recipe for successful software.

In a long run, I think an open-source project prevails, especially in the tools market. For example, GCC dominates the C compiler market. Subversion and CVS dominates the VCS market. It's very hard to compete with the eco-system of an open-source software development, and we are starting to see some commercial interests around the development of Hudson.

So I think Hudson is so far on the right track for the world domination. We'll just have to keep working hard.


Question 9 - What is the distribution of Hudson usage all over the world? Do you have any reference list?

Answer - Hudson tends to be run behind a firewall, so it's very hard to accurately know who's using. But judging from Ohloh and time of the day when people send in e-mails, there is a large adoption in Europe and the U.S.

I think additional translation would help us reach broader audience. Being from Japan, I know that the localization makes a real difference in some regions.

Eclipsist 2008 - İTÜ Kampüsü

Güzel bir İstanbul sabahında her ne kadar Sarıyer-Levent sapağını iki kere kaçırıp, Ayazağa'dan dolanarak ulaşsam da, gerek 4 senedir herhangi bir üniversite kampüsüne girmemiş olmam, gerekse Eclipse (favorim) konferansına ilk kez katılıyor olmamdan dolayı gayet heyecanlıydım ve bu heyecanımla İTÜ kampüsüne daldım...

Girişte eski dostları gördüm, birkaç da yeni dost tabi, sohbetimiz koyuydu, eski günlerden yeni teknolojilere.. En azından konferansta konuşulanlarla ilgili fikirlerimi paylaşabilecek birilerinin olması güzeldi...




Konferansı Naci Dai sunuyordu, Mike Millinkovich (Executive Director of Eclipse Foundation) ile güzel bir başlangıç yaptık. Sunum, açık kaynak projelerin nasıl para kazandıklarından, açık kaynak topluluğunun sağcı ve solcularına kadar güzel bir bilgi yelpazesi ile başladı. Sonra topluluğun (community) satılamayacağından bahsedip MySQL'in 1 milyar dolarlık satışını örnek verdi, sanırım çaktırmadan biraz sitem etti :). Son olarak hakikaten Eclipse'in kendi etrafında oluşturduğu o muazzam ekosistemi ve bileşenlerini anlattı, yani topluluğun sadece committer (developer)'lardan oluşmadığını, partner'lerin de farklı metodlarla bu ekosistemin birer parçası olduklarını anlattı.. Bir an kendimi ne kadar güzel bir yapı olan Eclipse ve etrafındaki partner'lerinin ilişkisini düşünürken buldum.. Eclipse altyapısını kullanarak IDE'ler ve teknolojiler geliştiren partner'ler aynı zamanda finansal destek sağlıyorlar, ve Eclipse hala bireylere ücretsiz olarak dağıtılıyor... İnanılmaz... Mike'ın da dediği gibi sanırım biz henüz Açık Kaynak konusunda "inkar" safhasından "kullanım" safhasına yeni geçiyoruz, "katılım" safhası önümüzde bizi beklese dahi, bu bile büyük bir adım....

Tam iyi başladık derken, iki tane iskandinav arkadaş (sanırım), Eclipse Open Financial Market Platform (OFMP) dedikleri ve Lüxemburg'da tahminimce 3-4 şubeli bir bankada uyguladıkları Victoria isimli sıkıcı (bence) bir projeden bahsettiler, sunumun tek ilgi çekici yanı projenin ileriki milestone'larında sistemin tüm portlarını OSGi teknolojisi ile bağlayacak olmalarını söylemeleri oldu. Bir bankacılık projesi ve tamamiyle OSGi üzerinde, görülmeye değer...

Daha önce IBM'deki arkadaşlarımdan duyduğum Jazz ve Rational Team Concert (RTC) ile ilgili sunum henüz Jazz ve üzerinde geliştirilen RTC'nin biraz daha zamana ihtiyaçları olduğunu ama Application Lifecycle Management (ALM) konusu ile ilgili gayet güzel adımlar atmış olduklarını gösterdi.. Tabi Jazz'ı dinlerken bu tür bundled bir Eclipse'in şu an projede neleri kolaylaştıracağını düşünmeden de edemedim.

Öğleden sonra, ikinci sunum Naci Dai'nindi, geleceğin hem mobil, hem desktop, hem de kurumsal ölçekli projeleri için yepyeni bir kapı açan bir projeyi anlattı, OSGi framework ve temelinde bulunan Eclipse Equinox... Önümüzdeki sene Nokia'nın Eclipse Equinox kullanarak, 2 milyon telefonu piyasaya süreceğini söyledi.. WAS 7.0 ve Weblogic 10'un yine Equinox teknolojisi üzerine oturtulduğunu da ekledi... OSGi kendi kapsülü ve bundle'ları ile tamamiyle yeni bir davranış gösteriyor... Gerçekten izlenmesi gereken bir proje gibi görünüyor...

Kısacası güzel bir konferans oldu, en azından Eclipse ile biraz daha yakın pozisyonda bulunmak, ne hissedildiğini ve ne yapılmaya çalışıldığını anlamak adına gayet güzel bir deneyim oldu. Ama katılımın 100-150 kişi civarında kalması ve havanın ve yolların açık olmasına rağmen bu sayının geçilememesi biraz üzücü idi..

Yeni bir Hudson Plugin'i - CI Game

Bu plugin'i ilk gördüğüm zaman, yüzüme geniş bir gülümseme yayıldı. CI Game ha, çok zekice :) açıkçası uzun süredir, bu tarz bir olay düşünüyordum.. Gerek yapılandırmaların sık sık bozulmasından, gerekse yapılandırmaları bozan insanları kafamda sürekli bir sıraya sokmaya çalışmak gibi bir psikopatlıktan dolayı, acaip hoşuma giden bir plugin oldu..

Tabi hiç zaman kaybetmeden, indirip Hudson'a entegre ettim.. Erken-derleme işi için aktif hale getirdim. Çünkü elimde, SVN ilişkisini Hudson'ın kontrol ettiği (People listesinin doldurulması açısından) tek iş bu idi. Diğer işlerde şimdilik SVN bağlantısını, svn task'ları ile ant scriptleri götürüyor.

Oyunun mantığı çok basit, bu eklentiyi yüklediğiniz zaman, sol navigasyon barında "Leader Board" diye bir link ortaya çıkıyor.

Bu linkte tıkladığınızda bir "Skor Tahtası" ile karşılaşıyorsunuz. Skor tahtasında developer'ların bir listesi var (Hudson'ın SVN commitlerine bağlı olarak oluşturduğu People listesinden üretiliyor), bu liste bir skorlama sonucu oluşturuluyor, skorlama ise çok basit :

• Sürüm bozan her developer -10 puan
• Bozuk bir sürümü istediğiniz kadar bozabilirsiniz 0 puan
• Hatasız çıkarılan her sürüm +1 puan
• Her başarısız yeni test -1 puan
• Her başarılı yeni test +1 puan

Buna göre liste oluşuyor.. Ve bu listeye bakarak, en azından bir fikir sahibi olabiliyorsunuz. Puan kazanmanın birçok yolundan birisi de, herkesin hemfikir olduğu sık sık commit yapılması, yani büyükçe bir değişiklik kümesini 3 gün üzerinde çalışıp, tek defada commitleyip, +1 puan almak yerine, bunu mantıklı 3 altkümeye bölüp hergün bir altkümeyi commitleyip, toplamda +3 puan almak sanırım daha lezzetli..



Sürekli Entegrasyon Sistemi'ni eğlenceli hale getirmek adına, çok güzel bir plugin...

Hudson'ı Taşımak

Sürüm Sistemi'nizi (benim durumumda bu Hudson oluyor), daima sistemlerinizden ayrı bir makine üzerinde yürütmelisiniz. Yani, Hudson'ın kurulu olduğu makine üzerinde Uygulama Sunucusu (eğer kullanıyorsanız) veya veritabanı olmamalıdır. Neden? Çünkü eğer ağır, CPU tüketen testler çalıştırıyorsanız ve bu testleriniz uzun sürüyor ise bu makine üzerinde darboğazlar oluşmaya başlar, böylece siz "kaş yaparken göz çıkarmış" olursunuz. Ya da bir anda memory yetersizliğinden dolayı makine kasılmaya başlar ve sistemde hizmet veremez hale gelirsiniz.

Kısacası, bu tür risklerden kurtulmak adına Hudson'ı ayrı bir makine üzerinde yürütmelisiniz.

Hali hazırda Hudson'ı farklı bir makinede çalıştırıyorsanız, bu yazının devamını sadece Hudson'ı nasıl yedekleyebileceğinizi öğrenmek için de olsa okuyabilirsiniz.

Eğer Hudson'ı bizim gibi ortamlarınızdan birisi ile içiçe kullanıyorsanız, aşağıdakileri sırasıyla uygulayarak migrasyonu tamamlamış olursunuz.

1 - Çevresel klasör ve dosyaların arşivlenip aktarılması

İlk yapılması gereken işlem, aşağıda listede olan (benim aklıma gelenler bunlar, unuttuğum var ise lütfen ekleyin) dosya ve klasörleri arşivlemektir ve yeni Sürüm Makinesi üzerinde açmaktır.

• Yapılandırma Scriptleri
• Artefaktlar (JAR, SQL, XML, HTML (EBML))
• Yerel Repository (Yapılandırma Scriptlerinizde kullanıyorsanız)
• ANT, Maven, PMD, SVNKit, JDK, Tomcat gibi araçlar (Şükür ki unzip yeterli)

2 - HUDSON_HOME klasörünün arşivlenip aktarılması

Versioning a Hudson job configuration isimli yazıda Hudson'ın hangi kısımlarını yedeklemenizin yeterli olacağı, olası bir felaket anında nelere dikkat etmeniz gerektiği yazılı... Özellikle bu tür yedeklerin Repository'de tutulmasının çok faydalı olacağı da ayrıca belirtilmiş.

Eğer Hudson'ı uzun bir zamandır kullanıyorsanız (mesela 2 yıl), bir hayli birikmiş yapılandırma geçmişi ve çalışma alanı dosyalarınız olacaktır. Bunların kapladığı yer ise repository'nize bağlı olarak gigabyte'ları bulabilir.. Fakat, bir acil durum anında, veya bir migrasyon sonrasında büyük ihtimalle bu dosyalara ihtiyacınız olmayacak, dolayısıyla yukarıda linkini verdiğim yazıda da belirtildiği gibi aşağıdaki komut Hudson'ın tüm konfigürasyonunu "workspace" ve "builds" olmaksızın tek bir dosyaya yedekleyecek, ve benim örneğimdeki gibi, sıkıştırılmış dosyanızın boyutu 700 MB'dan 25 MB'a inecektir.

tar --create --gzip --file=hudson.tgz --exclude='workspace/*' --exclude='builds/*' .hudson/

Bu dosyanızı yeni Sürüm Makinesinde açmanız yeterli olacaktır.

3 - Ortam Değişkenlerinin Düzenlenmesi

Dosyaların taşınması işleminden sonra karşılaşabileceğiniz ilk sorun Ortam Değişkenleri'nin bulunumaması olacaktır. Dolayısıyla konfigürasyon dosyalarında veya profil dosyalarında bu değişkenleri bulup düzenlemeniz gerekecektir (Mesela Tomcat kullanıyorsanız, JAVA_HOME değişkeni büyük olasılıkla catalina.sh içerisindedir, ya da HUDSON_HOME değişkeni .profile dosyasına yazılır, veya Tomcat içerisinde webapp altında war dosyası içerisinde web.xml'de belirtilmiştir. Daha detaylı bilgi için tıklayınız). Aşağıda önem sırasına göre ortamınızda değiştirmeniz gerekebilecek değişkenleri listelemeye çalıştım, unuttuğum olabilir, eklerseniz sevinirim.

• HUDSON_HOME (Önemli)
• JAVA_HOME
• ANT_HOME
• MAVEN_HOME

4 - Hudson Pluginlerinin Yüklenmesi Sorunu

Benim yaşadığım ufak bir problem ve çözümü ile Hudson'ı başarılı bir şekilde çalışır hale getirebilirsiniz. Hudson'ın başlangıcı esnasında aşağıdaki gibi bir hata alırsanız

SEVERE: Failed to load a plug-in jabber
hudson.util.IOException2: Failed to initialize
at hudson.PluginWrapper.load(PluginWrapper.java:253)
at hudson.PluginManager.(PluginManager.java:90)
at hudson.model.Hudson.(Hudson.java:332)
at hudson.WebAppMain$2.run(WebAppMain.java:155)
Caused by: java.lang.NoClassDefFoundError: hudson/plugins/jabber/im/IMMessageTargetConversionException
at hudson.plugins.jabber.im.transport.JabberPluginImpl.start(JabberPluginImpl.java:23)
at hudson.PluginWrapper.load(PluginWrapper.java:250)
... 3 more

Yapmanız gereken, [HUDSON_HOME]/plugins dizininde daha önce yüklediğiniz pluginlerin oluşturduğu dizinleri silmektir. Sadece hpi uzantılı dosyaları bırakmanız yeterli.

5 - Doğru JDK kurulması

Mevcut Sürüm Sistemi makinesi ile yeni kullanacağınız Sürüm Sistemi makinesinin işlemci, işletim sistemi ve bunun gibi bazı farklarından dolayı aynı JDK'yı kullanamayabilirsiniz, bu nedenle yeni Sürüm Sistemi makineniz için doğru olan JDK'yı indirip ayarlamayı unutmayın.

6 - Locale ayarlarının düzenlenmesi

Eğer yeni Sürüm Makineniz, hakikaten yeni kurulmuş ise, çok büyük ihtimalle dil ayarları (locale) yapılmamış olacaktır. Bu nedenle taşımanız gereken ayarlardan bir tanesi de dil ayarları olacaktır.

7 - Sürüm numaralarının düzenlenmesi

Eğer geçmiş yapılandırmaları tamamen temizleyip, bembeyaz bir sayfa açmak istiyorsanız, sürüm numaralarını da sıfırlamanız gerekiyor. Yapmanız gereken [HUDSON_HOME]/jobs klasöründe ilgili işin içerisine girip nextBuildNumber dosyasının içeriğini 0(sıfır) yapmak...

Son Söz

Yukarıda belirtilen işlemlerin dışında Sürüm Sisteminize özel bazı yüklemeler yapmanız gerekebilir. Benim yaptığım migrasyonda SVN Client kurulumu bu tür bir yükleme idi..

Bunların sonunda, şu an Sürüm Sistemini 4 CPU ve 8 GB bir makine üzerinde taşıdım, ileride birim, kabul ve entegrasyon testleri de devreye girdiğinde bu makine tüm bu işleri kaldırabilecek güçte olacaktır. Bunun rahatlığıyla artık kodlar üzerinde yapılabilecek diğer işlemlere başlayabilirim.

Sürekli Entegrasyon Pratikleri - II

Sürekli Entegrasyon Pratikleri - Bölüm 2


Sürekli entegrasyon sistemleri ile ilgili kazanımlarımı ve uygulamalarımı bu ikinci bölümde anlatmaya devam ediyorum. Serinin birinci bölümünü bu linkte bulabilirsiniz.

Bu yazıda size bir adet pratik anlatacağım ve bir adet de tavsiyede bulunacağım. Önce pratik,


Pratik - SCM Kontrolü Mekanizmasını kullanarak kodların erken derlenmesini sağlayın

Benimde yaklaşık olarak bir aydır uyguladığım bir pratik. Özellikle, belirli saatlerde çıkardığınız sürümlerde kodlara bağlı olarak derleme hataları ile karşılaşıyorsanız, ve her seferinde (sabırla) developer'ları arayıp, onlara kodların neresinde hata olduğunu, neyi düzeltmesi gerektiğini anlatıyor ve kodlarını SCM sistemine yeniden eklemelerini istiyorsanız. Tam size göre bir pratiği anlatacağım.

Tabi bu konuyu anlatmadan önce şunu belirtmeliyim, bu pratiğin bir diğer yöntemi (aslına bakarsanız, önerileni) lokal yapılandırmalardır.


Nedir lokal yapılandırma (private build)?

Developer kodlarını commit'lemek istediğinde, lokalinde bir yapılandırma çalışır, kodların bağımlılıklarına bağlı olarak bazı modülleri (veya uzatmadan hepsini) check-out eder, ardından derleme ve birim testi işlemlerini çalıştırır, ve eğer herhangi bir hata ile karşılaşılmazsa kodların commit edilmesine izin verilir.

Neden lokal yapılandırma yerine erken-derleme pratiğini tercih ettim?

Sebebi çok açık, bu tür yaklaşımlar (private build gibi), developer'ların bazı davranış biçimine (çevik geliştirme) sahip olmasını gerektirir. Benim bulunduğum ekipte bu tür bir yapıyı kurmak şimdilik zor olacağından, bu sistemi ileri bir tarihe erteleyip, bunun yerine sunucu tarafında çalışıp derleme ve test işlemlerinde oluşabilecek bir hatayı erken bulan bir sistem olan erken-derlemeyi tercih ettim.

Dezavantajı yok mu bunun?

Var, aslına bakarsanız kesinlikle büyük bir dezavantajı var. SVN'e bozuk kod gönderilmesi, her ne kadar erken uyarı sistemi ile developer'lar uyarılsa da, diğer bağlı modüllerin, bu bozuk kodu check-out etmesine ve sonra belki de saatlerce sorun ile uğraşmasına sebep olacaktır. Yani, ne olursa olsun BOZUK (BROKEN) KODU COMMIT'LEMEYİN...

Eee uzatma da, nasıl yapılacağız onu anlat

Hudson (favorim) kullanarak nasıl yapılabileceğini kısaca anlatacağım.

• Öncelikle, sürüm scriptlerinizden kodları derleyen (varsa, birim testlerini yapan) kısmı çıkarıp, ayrı bir dosya olarak kaydedin, unutmayın bunların dışındakileri yapmanıza gerek olmayabilir.
• Sonra Hudson üzerinde yeni bir iş yaratın, ve bu dosyayı bu iş ile ilişkilendirin. İşin güzel yanı, check-out işlemini Hudson'a bırakacağız, SCM kontrolünü devreye alarak..
• SCM kontrolünü isteğe bağlı olarak saatte bir, veya yarım saatte bir olarak ayarlayın...
• Ve son olarak da bozuk yapılandırmalarda commit işlemini gerçekleşteren developer'lara e-posta atma seçeneğini işaretleyin.

Ve bu kadar, artık Hudson yarım veya bir saatte, belirttiğiniz SCM yolunu kontrol edecek, herhangi bir değişiklikte yapılandırmayı çalıştıracak ve başarısız olduğu durumda e-posta aracılığı ile bilgilendirme yapacaktır... Erken uyarı sistemimiz artık çalışıyor.

Var mı yaşadığın güzel bir örnek?

Evet, bu blogu yazmadan birkaç saat evvel, bir toplantıdaydım, toplantıdan çıkıp yerime geçtim, e-postalarımı kontrol ederken Build failed in Hudson: XXXXX #14 konulu bir e-posta gördüm, sadece bana değil birkaç developer arkadaşıma da atılmıştı (erken-derleme ile ilgili Hudson üzerinde oluşturduğum işin otomatik attığı e-posta). Tabi bir saat olmuştu geleli.. Sonra e-postanın içerisinde ismi geçen developer'ları aradım, acaba bu bilgilendirme ellerine ulaştımı diye, haberimiz var, zaten düzeltip gönderdik dediler. Bunun bana nasıl bir haz verdiğini size anlatamam. Ben olmadığım durumda sistem çalışıp, insanları uyarmıştı... Sanırım sistem artık bir sürekli entegrasyon sistemi oluyordu.


Tavsiye - Öğrenmeyi kolaylaştıran ve güzelleştiren bir yöntem önerebilirim..

Öğretin, en azından öğretmeye çalışın.

İbrahim'in bu linkteki blogunu okumanız herşeyi anlatabilir. Öğrenirken, öğretmeye çalışarak, kendisini pekiştiriyor.

Hudson artık Türkçe

Eveet, uzun zamandır yapmayı planladığım projeyi hayata geçirdim. Bundan yaklaşık 30 sürüm önce Kohsuke'nin duyurduğu olayı yani Hudson'ın lokalizasyonunu, nihayetinde vakit ayırıp gerçekleştirebildim.

Onlarca property dosyası, bir o kadar html dosyası nihayetinde Hudson'ın Türkçe lokalizasyonunu başlatmanın inanılmaz hazzı, büyük yüzdesini de bitirmek de cabası. Resmi olarak changelog'da yayınlandığı için ben de burada anons edebiliyorum. Her ne kadar changelog içerisinde Jesse Glick'in bahsettiği Türkçe lanetine yakalandı isem de, Fransızca, Japonca, Almanca ve Rusça'dan sonra Hudson'ın bir dili de artık Türkçe... Artık Hudson'ı 1.190 versiyonundan sonra, eğer lokaliniz Türkçe ise, Türkçe kullanabileceksiniz..

Hudson'ı Türkçe kullanmak isteyenler, deneyin ve çeviriler ile ilgili yorumlarınızı bana gönderin. Tek yapmanız gereken, Hudson'ın bu versiyonu ve sonrasını indirip, deploy edip ardından lokalinizi Türkçe'ye çekmek.. Ben bir çevirmen değilim, sadece bir açık kaynak gönüllüsüyüm... Dolayısıyla, daha iyiye tabiiki hep beraber götüreceğimizin farkındayım. Bu nedenle yorumlarınızı bekliyorum...

(Düzeltme : Sadece yorumlarınızı değil, aynı zamanda katılımlarınızı da bekliyorum)