Build araçları: Phing, Grunt veee Gulp

Neredeyse 20 yıldır hep başıma gelir, spesifik bir iş için debelenip dururken bir tool’a (kütüphane de olabilir) rastlayıverirsin ve “işte bu” dersin. İşte gulp da bunlardan bir tanesi.

Gulp bir build sistemi, grunt gibi. Bunlar ne iş yapar bilmeyenler için; kısaca sürekli yaptığınız işlemleri otomatize ederler. Daha önceleri ant, phing gibi sistemlerden fellik fellik kaçtım uzun süre, benim için en güzel build tool’u bash script’leri idi.

Build araçlarından kaçmamın ana nedeni ilk kurulumu ve bakımının çok vakit alması. Evet, tek proje üzerinde çalışıyorsanız onlarsız olmuyor ama benim gibi sürekli yeni projelere geçiyorsanız ve küçük ekiplerle çalışıyorsanız build tool’u konfigüre etmeye ayırdığınız kaynak size kazandırdıklarını karşılamıyor (vakit = nakit).

Ancak özellikle front-end development’taki gelişmeler build araçlarını zorunlu hale getiriyor. Sanırım grunt’ın bir anda popüler olmasının en büyük nedeni buydu. Biraz profesyonelleşen herkes LESS, SaSS, ScSS, Coffeescript gibi yardımcılara kayıyor ister istemez. Ek olarak bu dosyaların sıkıştırılması, birleştirilmesi vb. bir sürü ihtiyaç ortaya çıkıyor ve ister istemez böyle bir araç arayışına giriyorsunuz.

Gulp’a gelmeden önce daha önceki Phing ve Grunt deneyimlerimi paylaşayım.

Phing

Phing’i tercih etme nedenim build işlemlerinde back-end’e öncelik vermemdi, bu tamamen son çalıştığım projemin (Fotoğraf Arşiv Sistemi) ihtiyaçları doğrultusundaydı. Web tabanlı bir uygulama olarak en fazla 5-10 kişinin aynı anda login olmasını beklediğim için kaynaklarımı front-end optimizasyonuna yönlendirmek bu proje için pek mantıklı bir tercih değildi.

İlk başlarda bash script’leri işimi görürken bir noktadan sonra bu işi daha kolay halledebilir miyim diye arayışlara başladım…

Bu açıdan bakınca, kodu PHP’de yazdığıma göre en makul build sistemi yine PHP’ye özel yazılmış olan Phing diye düşündüm.

Buradaki gıcıklık; PHP’nin diğer birçok uygulaması gibi phing de java’nın ant’ından çakma bir araç olduğu için PHP geliştiricilerinin (en azından benim) alışkın olduğu pratiklikten çok uzaktı. En başta komutları XML ile veriyorsunuz.

XML bana göre dünyanın en gereksiz icatlarından biri. Anti-KISS: Klasik java yaklaşımı, düzenli ve iyi tanımlanmış olsun diye eşşek yüküyle ekstra iş – 3 satır data tanımlayacağım diye 500 satır XML… JSON’ın gözünü seveyim…

(Yani tamam hakkını da yemeyelim ama gerçekten kullanım alanı kısıtlı)

Netekim denedim, attım çöpe döndüm bash script’lerime ve sabır diledim içimden, shell scripting bilmeyenlere…

Grunt

Grunt sürekli karşıma çıkıp çıkıp duruyordu, açıkçası önyargıyla yaklaştığımı itiraf etmeliyim. Shazam Türkiye ekibinde işe başlayınca kabiliyetlerini bizzat görmüş oldum: Herşeyi yapıyor mübarek.

O kadar tutulan bir araç ki her tür ihtiyacınıza bir plugin bulabiliyorsunuz en kötü javascript’le kendi plugin’inizi yazıyorsunuz (nodejs sağolsun) ve hakkaten işini yapıyor.

En güzel tarafı da konfigürasyon dosyası JSON formatında! Süper…

….

Fakaaaaat…..

Bu cins araç ilk başlarda insanı büyüleyerek ciddi sorunlarını fark etmenize engel oluyor…

Grunt’ın Sıkıntıları

Özellikle Shazam’ın binlerce satırlık build konfigürasyonunda daha ilk günden beni rahatsız eden birşeyler vardı, yani bu böyle olmamalı bir yanlışlık var dedim hep kendi kendime, günlerce tekrar düzenledim, grupladım, comment’ler yazdım organize etmek için, ama ne fayda…

…ve laravel 5.0’ın screencast’lerini izlerken Gulp’ı kullandıklarını fark ettim. Laravel komunite olarak hakikaten dikkate aldığım bir grup. Eğer herhangi bir “şeyi” tercih ediyorlarsa bakmaya değerdir…

* Zend’in tam tersine :) Zend Framework komünü birşeyi kullanıyorsa hemen kaçacaksın oradan :)

Gulp’u inceleyince bir anda o başta bahsettiğim ampül yandı kafamda! Adamlar da fark etmiş bu sıkıntıyı nedenini buldukları gibi çözümünü de icat etmişler (bkz. gavur yapmış)

Grunt’ın iki tane çok önemli sıkıntısı var:

1. Konfigürasyon ağırlıklı build dosyası

Phing ile ortak sıkıntısı bu, özellikle build işlemleriniz uzadığında upuzun konfigürasyon dosyasını okumak, organize etmek tam bir ölüm (Tecrübe ile sabittir). Aslında Phing’den daha iyi en azından yine bir miktar kod yazabiliyorsunuz.

Her işin konfigürasyonunu ayrı ayrı tanımlayıp en son işlemlerin hangi sırayla çalışacağı tanımlıyorsunuz, bu da okunabilirliği (readability) berbat hale getiriyor. İnsan ister istemez build script’ine dokunmaya korkar hale geliyor.

2. Öküz gibi yavaş.

Bunu daha kibar tarif etmenin yolu yok, cidden çok feci… Temel nedeni yapılan işlerin (task) birbirinden bağımsız, birbirleriyle alakasız tanımlanması. Gulp’un bu tür işleri nasıl handle ettiğini görünce daha iyi anlaşılıyor.

Gulp

Peki bir anda beni Gulp’a aşık eden olay nedir?

Yazımın başlarına dönersek, build işlemlerimi bash script’leri ile yapmayı tercih ettiğimden bahsetmiştim. Gulp’un I/O operasyonlarını handle etme şekli unix shell’leri ile aynı: Pipe kullanıyor…

Aslında shell scripting ile ilgili ayrı bir yazı yazmak lazım ama, bizim sektörde çalışan kişilerin kesinlikle shell scripting bilmesi gerektiğine inanıyorum. awk, sed, sort, uniq, tail, head, grep vb. komutları kullanarak I/O ile ilgili birçok işi çok daha kısa sürede ve daha hızlı bir şekilde yapabiliyorsunuz.

(öğrenmesi biraz zor, kabul)

Shell Scripting ve Pipe’lar (Streaming)

Pipe’ların güzel tarafı programlar birbirine eklenen tesisat elemanları gibi birbirine bağlanabiliyor, su borusu nu takıyorsun vanaya, vanadan başka boruya vs. derken en sonda şelale yapıveriyorsun (ya da ben abartıyorum). Her komut inputu önceki programdan alıp işleyip çıktısını öteki programa veriyor…

Klasik programlamada dosyayı aç, satır satır oku, belleğe al, bir algoritmaya göre sırala vs. işlemlerinin aksine hem çok kolay yazılıyor hem de inanılmaz hızlı çalışıyor.

Detaylı teknik bilgi için şu dokümanı tavsiye ederim: https://github.com/substack/stream-handbook

Çok basit bir örnek; bir text dosyasını okumaya başlıyorsun, satırları sort komutuna veriyorsun sıralıyor, onu da head komutuna veriyorsun ilk 10 satırı gayet hızlı bir şekilde veriyor. I/O yönlendirildiği için temp dosyalara birşeyler yazmaya, hafızaya herşeyi yüklemeye vs. gerek kalmıyor.

Gulp da benzer bir mantık kullanıyor, örneğin LESS dosyasını CSS’e compile ediyorsun çıktısını direkt compress eden script’e yönlendiriyorsun. Yine temp dosya yok, garip garip konfigürasyonlar yok…

Code over Configuration

Konfigürasyon demişken Gulp’un ikinci olayına gelelim: Konfigürasyon değil javascript ile kodluyorsunuz bütün build işlerini.

Bizler programcıyız, konfigürasyon yerine program yazmaya başladığınız zaman adrenalini yemiş Hulk gibi oluyoruz. Gulp nodejs’in streaming ve non-blocking I/O kabiliyetlerini kullanarak harika bir iş başarmış bu anlamda.

Sonuç…

Özetle gulp’a bir göz atın derim. Aşağıdaki kısa slayt gösterisi de olayı ve felsefesini özetliyor:

http://slides.com/contra/gulp#/

Gönül ister ki daha civcivli bir post yazayım bu konuda ama malum iş-güç :) Gerisi artık size kalmış…

 

1 Yorum

Leave a Comment.