Neden Laravel kullanmıyorum

Yaptığım projelerde,
süreçleri, işlemleri birbiri ile güzelce anlaşabilecek şekilde yapmaya gayret ederim. Birbirleri ile tam bir otomasyon ile anlaşamayan her bir süreç ileride sorun çıkarıp, projenin aksamasına sebep olabilir. Bununla birlikte her çıkan sorun bir geriye dönük ilgi gerektirerek ek maliyet çıkardığı istenmeyen bir durum oluşturur.

Bu yüzden projeleri kodlarken kullandığım araçları seçerken biraz “kıl” davranırım.

Kullanılan araç bana hız kazandırıyor mu ?
Yeni bir versiyonu çıktığında geçmişe yönelik desteği nasıl ?
Bir sorun çıktığında bu sorunu google araması ile çözüme ulaşabiliyor muyum ?
Kim tarafından geliştiriliyor ? canı istediği zaman commit yapan birisi tarafından mı geliştiriliyor.

Mevzu teknoloji ve yazılım ise, “daha iyisi” olmayacağını bilecek kadardır bu işi yapıyorum,
Hani framework daha iyi ? sorusunun cevabı bence yoktur,
Hangi bilgisayar daha iyi sorusunun cevabı bence spesifik değildir,
En iyi programlama dili hangisi sorusuna cevap aramak vakit kaybıdır benim için.

“İhtiyacımı görecek en iyisi hangisi ?” sorusunu sormak bizi daha çabuk çözüme ulaştırır diye düşünüyorum,

En iyi programlama dili hangisi yerine “linux ortamında konsol işlemleri yapacağım hangi dil kendini bu konuda geliştirmiş ?”

Web tarafında api isteklerine cevap verecek bir proje yapacağım, hangi dil bu konuda gelişmiş ? diye sormak bence en iyisi.

Firma olarak Windows Ce kullanan el terminali yazılımından , Facebook uygulamasına kadar bir çok sektöre çözüm üretiyoruz. Kullanacağımız araçları, “bu platform için en verimli araçlar hangileri ?” sorusunu sorarak seçiyoruz.

En iyi dil PHP’dir diye diretseydik, windows ce kullanan bir el terminaline kod yazamayacaktık. Yada en iyi dil .net’dir deseydik, Linux sunucusunda Bash script ile çözebileceğimiz bir başka sorun için .net ile çözüm aramaya çalışacaktık.(çözüm bulamayacaktık.)

Yazılım geliştirme içerisinde Fanatikçe karar almanın faydadan çok zarar getireceğini düşünüyorum.

Çok yakın bir tarihe kadar PHP ‘nin en büyük sorunlarından birisi gelişmiş ve genele yayılmış bir paket yöneticisinin olmaması idi,

 

logo-composer-transparent

her ne kadar resmi olarak çıkmasa da çok yakın bir geçmişte composer oluşturularak, php’nin bu eksiği çok büyük ölçüde giderildi.

Bu işte sözü geçen büyük firmalar bile kendini composer içerisine eklediği için topluluğun composer konusunda ciddi olduğunu da görmüş olduk.

Composer sayesinde artık proje içerisinde kullanacağımız repolara çok daha kolay şekilde ulaşıyoruz.
Tek bir dosya üzerinden repoları yönetip projemize dahil edebiliyoruz.

Composer ile popüler olan bir çok repo, bir kişinin geliştirmekte olduğu “şeylerden” uzaklaşıp farklı sorunlar ile karşılaşan insanların pull requestleri ile birlikte gelişip büyüyor. Bu sayede kendi içinde bir hata takip ve dokümantasyon sistemi oturmuş oluyor.

Yani kullandığınız araçların sorunlarına ve çözümlerine direk o araçların github sayfalarından ulaşabiliyoruz.

bununla birlikte, composer bize php’nin oop gücünü daha iyi kullanmamızı sağlıyor, kullandığı autoload mimarisi sayesinde gerçek bir mvc deneyimi yaşayabiliyoruz.

Bu işe başladığımda ve devamında etrafımda hep kaliteli yazılımcılar olduğundan ötürü,

“OOP dediğin şey çok kullanılan fonksiyonların, sınıf dosyaları içine konulup lazım olunca çağrılması değil mi canım”

fikrinden kurtulmak çok uzun sürmedi benim için.

Bu yüzden Kendi Frameworkümü kendim yazdım dediğim dönemler sadece 1-2 proje ile sınırlı kaldı 🙂

Konunun en başına dönecek olursak,

Yaptığınız proje çevre şartları değişmediği sürece sorunsuz şekilde çalışmalıdır, “Kitap gibi çalışıyor” deyiminin hakkını vermelidir.

Daha önceki bir yazımda, Müşteriye göre şekillenmek konusuna değinmiştim.

İsteklere göre şekillenmek için çok esnek bir yapıya sahip olmanız gerekiyor. Projenizin,  sonradan gelen isteklere göre şekillendirirken kırılmaması çok önemli bir faktör olarak ilk sıraya çıkıyor.

Kullandığınız her bir aracı bir lego parçası gibi düşünebilirsiniz,

ne kadar ufak parçalar ile çalışırsanız, o kadar esnek projeler üretebilirsiniz ve projenin alacağı şekil, sizin hayal gücünüze kalacağı için ortaya muazzam işler çıkabilir.

İşte bu yüzden composer çıktığından bu yana, tek bir framework’e bağlı kalmak yerine, frameworklerin güzel tarafları ile daha esnek araçlar üretebileceğini düşünüyorum.

Gelelim bu durumda Laravel’i neden kullanmadığıma,

1- Sadece ben, hep ben, ben olmuşum laravel !

Laravel Tek ADAM projesi, bunu ben değil Laravel’i yazan arkadaş diyor,

 

Laravel asla bir community projesi olarak başlamadı.

Tek bir geliştiricinin “Php ile Ruby gibi yazsak nasıl olur ?”  fikri üzerine, yine benim az önce bahsettiğim şekilde ufak araçların composer ile bir araya getirmesinden ibaret.

CodeIgniter‘ın geliştirilmesinin durdurulmasının ardından, ortaya çıkan, “basit, günü kurtaran bir framework” ihtiyacını karşılayabilecek yetkinlikte bir framework laravel.

Yani beni, geçmişe yönelik destek ilgilendirmiyor, günü kurtarmak için yazılım yapıyorum laravel ile yapıp geçeceğim diyorsanız Laravel tam size göre.

2- Biz bir aileyiz ama kararları ben veririm! 

Opensource topluluğuna göz kırpan bir projeyi temelden ilgilendiren kararları tek adam tarafından alınması sonucu ortaya çıkan sonuçları geçmişte gördük,

Mesela Pardus’un sonunun başlangıcı, topluluk redmine istediği halde jira’da direten proje başları sayesinde olmuştu,

Yine Ubuntu’da , pencere butonlarının topluluğun istememesine rağmen sağda değilde solda diretilmesi örnek olarak verilebilir, Söz ubuntu’dan açılmışken, ubuntu firmasının unity’den tutunda arama bilgilerinizin başkaları ile paylaşılmasına kadar olan bir yelpaze bile ortaya çıkan şey Open Source olsa bile kararı biz vereceğiz! diretmesinden başka bir şey değil.

Ubuntuyu birinci işletim sistemi olarak kullanmayı bırakmama sebepte bu tutumlarıdır. Benim gibi bir çok kişi var.

hal böyle olunca,

projeye gelen pull request’leri bile merge etmek yerine kendisi copy paste ile sisteme ekleyen bir adam’a ne kadar güvenebilirim ?

https://github.com/laravel/framework/graphs/contributors bu linkten de görebileceğiniz gibi laravel’in büyük bir kısmı @taylorotwell tarafından yazılmış gözüküyor.

adam fırsat bulduğu her platformda “Ehe naber ? laraveli ben yaptım, benim bu proje” demekten kendini alamıyor.

3- Versiyonlama sorunları.

Can alıcı kısım bu aslında.  Laravel Semantic Versiyonlama ile yazılmıyor, örnek verecek olursak,

bir yazılımın 1.2.4 versiyonu ile 1.2.5 versiyonu arasında çok büyük değişiklikler olmaz, yani siz bu aracı kullanırken 1.2.4 versiyonunu 1.2.5 versiyonuna yükselttiğinizde projenizin çalışmasına devam etmesini beklersiniz.

Laravel’de durum böyle değil, 1.2.4 versiyonunda desteklediği bir kütüphaneyi yada metodu, 1.2.5 versiyonunda komple kaldırmış ve yerine bambaşka bir metod eklemiş olabiliyor. Böyle olunca bu gün yazdığınız kod, laravel güncellendikten sonra tamamen çalışmaz hale gelebiliyor.

Mesela, Python 2 varken ve halen geliştirme süreci devam ediyorken, Python 3 çıkmasının ve onunda geliştirilmesinin sebebi budur,

yada Opencart 1.5.5.6 sürümü varken Opencart 2.0.0.0 ‘ın çıkmasındaki sebep budur,

köklü değişiklikler olduğunda sizin ürününüzü kullananların “mağdur” olmaması için bu tarz versiyonlama sistemi kullanılır. Bu her şeyden önce “saygı” sorunudur.

Temel amacımız sorunsuz çalışan bir sistem ise, bu şekilde “ya ruby’de şu özellik var, laravelde neden yok demesin millet, bende bunu ekleyeyim o zaman” diyerek kafasına göre versiyonlama yapan bir adamın ortaya çıkardığı üründen ne kadar fayda bekleyebiliriz ?

 

4- Kullanıcıların sorun çıktığında çözüme ulaşmasının önünü tıkamak.

Geçtiğimiz günlerde Laravel, github üzerindeki issüeleri sildi ve artık sorunları forumlardan sorulmasını istedi.

Hem kafana göre versiyonlama ile işler yapacaksın, hem sorun çıktığında “buralar çok karışık oluyor” gerekçesi ile çözüm yollarını tıkayacaksın.

Benim hızlıca çözüme ulaşma kriterim de burada çuvallıyor, üstelik “Laravel Auth Problem”, “Laravel Orm Problem” gibi çok genel aramalarda çıkan sonuçların içinde bir de hangi versiyon olduğunu aramak zorundayım.

 

5- Standart üretme çabası ile saçmalama.

Php ‘de interface olarak kullanılan şeyleri alıp, bunların adına Contracts diyor.

Php’nin adı çıkmış bir kere, Çok dağınık, düzensiz kod yazılmasına izin veriyor, hali hazırdaki interafece özelliğinin adını değiştirip yeni ve ayrı bir sistem gibi sunalım gibi bir düşünce hakim.

Bu hem kısa hem de uzun vadede çok daha büyük sorunlara gebe kalacak bir düşünce, topluluk desteğini hiçe sayıp her şey “benden” geçecek dedikten sonra, kullandığınız her aracın contratsını yazacaksınız demek tutarsızlık.

Laravel ile kodlama yaparken yine kör dövüşü yapıp, ben contracts yazmam diyorsanız Laravel kullanmanın anlamı ne o zaman ?

Hali hazırda Composer paketleri içerisinde görüp beğenip kullanmak istediğiniz bir aracın kendi interface’i, bundle’ı yada provider’i varken neden laravel’de contracts yazayım ? (yoksa)

Ben composer ile çekip $repo = new repoClass(); diye her yerden ulaşabileceğim bir aracı, neden sadece laravel içerisinde çalışacak bir hale sokmak isteyeyim ?

“Kırk Küp Kırkınında Kulpu Kırık Küp” gibi bir metni, “kirk-kup-kirkininda-kulpu-kirik-kup” şeklinde url formatına çevirecek bir araç kullanmak için, composer.json’a tek bir satır ekleyerek istediğim yerden çağırıp kullanmak yerine neden sadece laravel’de çalışan bir şeye dönüştüreyim ?

Hızlı sonuç alma fikri nerede kaldı ?

Yine aynı şekilde, $nesne = new Nesne(); demek varken, neden make gibi bir metod ile ide dostu olmayan bir yöntem kullanayım ?

6- Kalıplara sokarken özgünlüğünü yitirme.

Projeyi parçalara ayırarak oluşturmayı legolara benzetmiştim,

Laravel’de aslında parçalara ayrılmış repolardan oluşuyor ancak yukarıda saydığım şeylerden ötürü her bir parça kendi özgürlüğünü bırakıp laravel’in diretmelerine maruz kalıyor.

Siz güncel paketleri bir araya getirdiğinizde ortaya çıkan şey şu olurken :

6177_lego_builders_of_tomorrow_box

Aynı işi laravel yaptığında ise ortaya şöyle bir şey çıkıyor :

 

lego-castle-70404-kings-castle-box

 

Laravel’de size lego sunuyor ama sunduğu parçalar Laravel’in baştan düşündüğü şeylerin dışına çıkamıyor. Böyle olunca da Laravel Programcısı oluyorsunuz, Php ile alakanız kalmıyor, Laravel’in ürettiği çözümlerin dışına dahi çıkamıyorsunuz.

Senelerdir Visual Studio illetine mahkum kalan .net tayfası için aynı şeyleri söylemedik mi ? (kendim de visual studio kullanıyorum, windows ce ‘ye sadece VS2008 ile yazılım üretebiliyorsunuz :'( )

7- Destek, Destek, Destek.

Zend Framework 1 , ilk olarak 2007 yılında yazıldı, zamanla üzerine yeni versiyonlar eklendi, semantik bir versiyonlama kullandığı için ilk versiyonda yazılan (2007 yılında) bir yazılım bugün bile sorunsuz çalışabiliyor,

üstelik Zend Framework 2  adında yep yeni bir sürüm çıkmasına rağmen hala Zend Framework 1 için güncellemeler yapılıyor.

Bir diğer Framework olan Symfony, bir kaç gün önce LTS sürümünü duyurdu.

Ama laravel’in kendi sitesinde bile 4. sürümünden öncesi için dokümantasyon bile yok.

8  – Taklitler aslını yaşatır.

Ruby ‘den esinlenerek tek bir adamın inisiyatifinde olan Ruby çakması bir yapı kullanacağınıza, aynı basitlikte ve gerçekten topluluk tarafından geliştirilen Ruby’e geçmeniz daha faydalı olacaktır, üstelik MVC nedir sorusuna verecek az çok cevabınız varsa Ruby’nin öğrenme süresi size çok ama çok basit gelecektir.

 

 

 

Sonuç olarak ;

Yazdığım kodun ileride de sorunsuz çalışmasını istediğim için,

Günü kurtarmak için kod yazmadığım için,

Kullandığım araçları  “Herkes bunu kullanıyor, demek ki en iyisi bu” gibi bir argüman ile seçmediğim için,

Benim yazacağım kodun standardını bir topluluk değil de keyfe keder kararlar alan birisinin belirmesinden rahatsız olduğum için,

İstediğim zaman istediğim yeni araçları ekleyebilmek istediğim için Laravel Kullanmıyorum.

 

Peki ya çözüm önerisi: 

Elbette var,

ilk tavsiyem, kendini ispat etmiş, bu işe yatırım yapmış frameworkleri kullanın (Yii, Zend, Symfony gibi) , framework seçerken “en hızlısı buymuş” diye seçmeyin, Hız değişkeni en son dikkat etmeniz gereken faktör.

Diğer tavsiyem, yine kendini ispat etmiş toplulukların desteklediği paketleri ihtiyacınıza göre birleştirin. Girin Github’a bakın, Php’nin yüksek versiyonları ile geliştirilen projelerde neler kullanılmış inceleyin.

Mesela firma olarak kullandığımız yöntemden örnek vereyim,

Zend FW 1’in route yapısını sevmiyorum, bunun yanında view olarak Zend Framework 1’in harika olduğunu düşünüyorum,

Database katmanında ORM kullanma taraftarıyım, çünkü projesini yürüttüğüm firma 2 gün sonra bir şirket kararı olarak bundan sonra “Mysql yerine Mssql” kullanmak istiyoruz dediğinde oturup tüm sorguları elden geçirmek istemiyorum,

hatta yıl olmuş 2015 neden hala sql kodu ile uğraşayım ki ? Bu yüzden Doctrine kullanmak istiyorum,

Symfony’nin Route yapısı harika, kendim route katmanı oluşturana kadar bu iş için yine symfony tayfasının yaptığı Silex adında micro framework var onu kullanırım. Üstelik Silex için hemen hemen tüm çevre birimler için (redis, elastic search, doctrine  vs vs) provider mevcut.

Bu anlattığım yapı için başka bir blog yazısı yazacağım.

 

İyi kodlamalar.

 

Ekleme 1 : (02.04.2015)

Bu yazıya bir ekleme yapmak istemiyordum,
İçerisinde küfür geçmeyen tüm yorumları yayınlama gibi bir kuralım vardır.
Ama artık, yazıyı okumadan sadece yazının başını ve sonunu okuyarak yorum yapan üstelik bu yorumlarında da yazı içerisinde söylediğim şeyleri bana sanki söylememişim gibi sav olarak sunan yorumları artık onaylamayacağım.
Okuma yazma bilmeyen insanların yorumları, bu yazıya ve konuya bir şey kazandırmayacaktır.

Teşekkürler.

2 Aralık 2014 Tarihinde yazıldı

  • Ismail Savran

    Devamını sabırsızlıkla bekliyorum :).

    • aligundogdu

      En kısa zamanda, teşekkürler 🙂

  • MS

    güzel bir yazı olmuş eline sağlık.

    • aligundogdu

      Teşekkür ederim.

  • Güzel bir yazı olmuş eline sağlık. Laravel’i severek kullanıyorum. Tarzı gerçekten hoşuma gidiyor ancak dikkat çektiğin noktalar beni de rahatsız ediyor.

    • aligundogdu

      Teşekkürler.

  • erayaydin

    Uzun süredir laravel(hem firmada hem kişisel projelerde) kullanıyorum. Fakat dediğiniz şeyler benim de gözüme çarptı. Zaten açıkça görülüyor laravel/framework deposundan, büyük çoğunluğunu Symfony oluşturuyor. Adam Symfony paketlerini alıp birleştirip kendine göre bir yapı kurmuş.

    Bu yüzden de Laravel kullanmak yerine, Symfony Componentları ile diğer depoları UYGUN(:D) bir şekilde birleştirmeyi düşünüyorum. Aslında dediğiniz gibi profesyonel frameworkleri kullanabiliriz ama hak verirsiniz ki tüm projelerde bu componentlara ihtiyaç olmuyor.

    Sadece temeli baz alan, her projede uygulamak zorunda kaldığım kısımlarda(route, log, request handler vs.) bu yapıyı kullanmayı düşünüyorum. Bu konu hakkındaki görüşünüz nedir?

    • aligundogdu

      Aynen bende sizin gibi düşünüyorum, Bir micro framework üzerine composer ile çatı geliştirme hakkında blog yazıyorum, bu hafta içerisinde bitmiş olur.
      Teşekkürler.

      • Nezih

        Bu konu hakkında bir makale yayınlamayı düşünüyor musunuz ?

    • Abi tavsiyesi: Yapmayın 🙂 Ya da yapın vazgeçtim öğretici oluyor 🙂

  • Alişan

    öncelikle yazınız çok güzel teşekkürler.ama büyük projelerde illaki framework ihtiyacı oluyor.ben 1.5 yıl symfony kullandım ve laravele yeni başladım ve o kadar rahat kod yazıyorum ki.framework beni sıkmıyor.adam kasılıyor fln diyorsunuz da ben yazsam ben de kasılırım tek başına framework yazmışsınız ve birden inanılmaz tutuluyor.benim düşüncem de bu yönde.yine de güzel bir yazı teşekkürler.

    • Selman Tunç

      rahat olması artı özellik ama uzun vadede ilerisi olan bir fw değil , bence symfony e dön 🙂

    • aligundogdu

      Teşekkür ederim.

  • Berat Dogan

    Boyle bir yazi icin tesekkur ediyorum. Yalniz olmadigimi bilmek sevindirdi beni. Daha once de surada sitemimi dile getirmistim.

    Acilan PR’lari bile keyfiyen birisi var bu projenin basinda. Basinda derken, tek basina demek istedim. 🙂

  • Selman Tunç

    klavyene sağlık ,laravel ajans işi zaten günü kurtarmak için

    • aligundogdu

      Teşekkürler.

  • yusufyilmaz472

    “Hız değişkeni en son dikkat etmeniz gereken faktör.”
    Bu cümleye kadar kısmen bazı noktalarda hak vermeye başlamıştım.Geleceği görüp büyük projelere imza atarken laravel kakalayıp kötüleyip, hız ve performansı en son faktör olarak görebilirsiniz.

    Laravel 4 Eloquent ORM tek başına, Doctrine + Zend den daha perfomanslı işler çıkartırken siz patron Taylordan şikayetçi olmaya devam edebilirsiniz.Üstelik hertürlü cache aracınızı kullanabilirsiniz.

    Zend 2 + Doctrine Entityleri ile boğuşmaktan yorulmadınızmı?Zend in her versiyonda daha fazla saçmalattığı route prosedürlerini,service locater zımbırtılarını anlamaya çalışarak harcadığınız zamana emeğe yazık.

  • Ahmet Karakılçık

    Elinize sağlık, güzel yazı olmuş, benzer sebeplerden Laravel’i bırakmış biri olarak, hep Yii2 stable versiyon çıktığı gün asla Laravel kullanmam diyordum Yii2 çıktığı günden itibaren de sözümü tutuyorum 🙂

    • aligundogdu

      🙂

  • Sadece Laravel değil bir çok konuda tecrübe kokan bir yazı olmuş teşekkürler.

    • aligundogdu

      Yorumunuz için teşekkürler 🙂

  • electrocoder

    Yazınız çok akıcı ve ilgi çekici olduğu için bir çırpıda okudum. Teşekürler.

  • gnykspr

    Yazı kendini yenilemeden birbiri ardına akıvermiş, ben de laravel kullanıyorum. Zira bazen, insanların düşünceleri arasında boğulmak gibi geliyor. Bu niye böyle olmamış vs gibi soruları başkalarının fikirlerinden sorguluyor insan.

  • Yokyokyok

    Yazı güzel. Ufak bir şey ekleyeceğim; bağlaçların yazımında (de/da) ciddi sıkıntıların var.

  • Damra Koç

    LA-RA-VEL

  • tayfunerbilen

    Hoş ve dürüst bir yazı olmuş, eline sağlık 🙂

  • Selahattin Ünlü

    Laravel’in uzun süre geliştirilecek projelerde kullanılması hakikaten temele koyulmuş bir dinamit etkisi yapabilir. Zira Ocak ayında çıkacak olan güncelleme ile frameworkün yapısı başlı başına değişiyor. Geriye dönük destek de yok sürekli “Uygun adım ileri marş” şeklinde bir koşuşturma var. Laravel’i severek kullanan biri olarak benim de canımı sıkan, üzen bir mevzu.

    En azından Laravel 5’ten itibaren geriye dönük destek oluşturulması lazım yoksa sıkıntı 🙂

  • Muazzam yazı olmuş hocam, valla eline koluna sağlık. Son zamanlarda kodlama yaparken “ulan ben napıyorum” sorusu altında bunların hepsini kendime sorar vaziyetteydim. Yazınızı da göründe “demek ki problem bende değilmiş” dedim. Günü kurtarmak için “muazzam” bir fw laravel. Ama sadece o kadar.

    • aligundogdu

      Teşekkür ederim.

  • borantula

    Yazılımsal konuların bazılarında katılıyorum ancak fazlaca yanlı bir yazı olduğu kanısındayım. Tabii başlığı “Neden Laravel Kullanmıyorum” olduğundan makul bu şekilde olması ancak tamamına katılmam zor. Uzunca bir yorum hazırladım 🙂

    Bazı noktalarda merak edip araştırdım benzer tartışmalardan, durum bahsettiğin gibi olsa da yorumlaması diye düşünüyorum. Muhtemelen çoğu kişi bu kadar araştırmadan “aaa böyleymiş çok fena” diyeceğinden hatta facebook laravel grubunda çoktan dediğinden bi kaç maddenin kaynağını yazayım karşı argüman olsun 🙂 Bu arada ordaki yorumlara da bekleriz 🙂

    Öncelikle bu reddit threadini okuyabilirsiniz. http://www.reddit.com/r/PHP/comments/1vvn9p/downsides_of_laravel_serious_ones_this_time/

    “One man show” tweeti mevzuusu:
    https://github.com/container-interop/container-interop/issues/1 şurdaki tartışmalardan sonra atılan bir tweet imiş. Konu abuk tartışmalar ve “buna ne isim koysak” tartışmasının abuk uzamasından sonra yazılmış. Tartışmayı biraz okudum, cidden meşhur sezen aksu tartışmasını aratmıyor.

    “Merge etmiyor copy paste ile kendi commiti gibi gösteriyor”:
    Ayrıntılı bir açıklama ile neden bu şekilde yaptığını kodu issuenun sonunda açıklıyor. Zaten görebilirsiniz 3 aylık bir zamandan sonra vakit bulup ilgilenebilmiş. https://github.com/laravel/framework/pull/2094#issuecomment-33189343

    Issueların taşınması mevzusu:
    Laravel maalesef codeigniter gemisini terkedenler ve daha önceden codeigniter ile php geliştirmeye adım atanların adresi oldu 4 versiyonu ile birlikte popülerleşmesiyle. Issuelara baktığımızda bu nedenle çok abuk sabuk basit maddelerin de oluyor ve ciddi bir zaman ayırmadan bunları kontrol edebilmek mümkün olmasa gerek. Symfony, JetPack gibi ticari yanları da güçlü sistemlerin bunun için destek ekipleri var ancak Laravel yapısı için daha çok kişi tarafından cevap verilebilecek forum üzreinden destek mantıklı bir çözüm olabilir. Bu sıralar üzerinde çalıştığım bir başka sistem olan ProcessWire da yıllardır bu şekilde ilerliyor ve küçük çapta bir komunite ile bile oldukça sağlam bir destek sağlanıyor.

    Backwards compatibility konusunda kısmen katılıyorum. 3’ten 4’e elbette upgrade edemedim, çok farklıydı yapılar. 3 daha çok codeigniter benzeri bir yapı iken 4 bir ekosistem olmaya doğru adımdı.
    4’ten 4.1’e oradan 4.2ye geçmek çok sıkıntılı olmadı üzerinde çalıştığım projelerde, yalnızca bazı kullandığım paketler patlamıştı basit nedenlerden. 5.0da da apayrı bir structure’a doğru geçiyor muhtemelen eski projeleri yükseltmek mümkün olmayacak. Ayrıca bazı şeyleri kendi dilinde bir kalıba sokma ve her sürümde değişme olayına da katılıyorum, genç bir framework olmasına bağlıyorum şimdilik.

    • aligundogdu

      Fikirleriniz ve bu uzun yorumunuz için çok teşekkürler 🙂
      Yazdığım argümanlara, güzel argümanlar ile cevaplar var.

      • borantula

        Rica ederim. Ayrıca son paragrafta yazdığım 4.2den 5’e geçişin pek mümkün olmayabileceği kısmını da araştırdığımda 5-6 maddelik çok da sıkıntılı gözükmeyen bir iş listesi ile aynı klasör yapısını koruyarak 5 versiyonunu kullanmak mümkün görünüyor. http://laravel.com/docs/master/upgrade#upgrade-5.0

  • Finalde önerilen çatıları kullanacak bilgideki arkadaşlar zaten bu tercihi yapabilecek durumda olan arkadaşlar. Zend veya Phalcon arasında kalırsa mesela tercih ederken argümanlarını belirler ve devam eder.

    Benim sorum şu :

    1) prosedürel yapıdan nesne yönelimli programlamaya yeni geçecek arkadaşlar için köprü olabilecek alternatif çatı hangisi (kendini toplarsa CodeIgniter belki).
    2) cehaletten doğan cesaret eğrisine göre ( http://www.inploid.com/embedded/images/34fc4948-4eed-427b-9d11-c8c18a47d010.jpg ) 1 kişilik değil 1000 kişilik ekip olsa ne değişir. Adam “login olamadım” deyip hata raporu gönderebiliyor. 1. maddede belirttiğim hedef kitlenin bunu yapması gayet doğal. Bu durumda adam ne yapsın?

    3) laravelin olduğu kadar diğer çatılarda da kalıplara uygun kod yazılmaması büyük sorun. Bu sorun aşıldığında çatılar arasındaki geçişlerin çok daha basit olacağı aşikar. Genelde verdiğim örnek : PHPOffice/* kütüphaneleri düzgün kodlanmış her çatıya uygulanabiiyor. Buna benzer yazım teknikleri (SOLID ve DESIGN PATTERNS yanında PSR uygunluğu) özendirilmesi daha doğru bir seçim olmaz mı?

    4) laravel güzel taylor kötü ise mysql -mariadb , open office – libre office , mambo – joomla ilişkilerinde olduğu gibi paravel adında ve çekirdek kadrosu daha güçlü eşzamanlı bir proje geliştirilemez mi?

    5) programlama dilleri arasındaki duvarlar incelirken, aynı dildeki çatıların bir birisi arasında geçişi için gerekli standartlar çoğalamaz mı (composer paket yönetimi çokça kullanılmaya başlandı. Güçlü E-ticaret yazılımlarından magento kendi paket yöneticini bırakıp composere doğru gidiyor http://devdocs.magento.com/guides/v1.0/install-gde/install/composer-clone.html#instgde-prereq-compose-install)

    • aligundogdu

      Soruların ve yorumların için teşekkür ederim.

      Sorular bana sorulmuş sanırım,

      Öncelikle bu yazı “Laravel Neden Kötü ?” değil Benim” neden laravel kullanmadığım” üzerine,
      Laravelin kullanım ve öğrenme üzerine olan kolaylığını yazı içerisinde belirttim,
      “Benim” kriterlerime göre laravel alıp kullanıp üzerine yatırım yapabileceğim bir çatı değil.

      Bu yüzden bu sorulara ancak kedi üzerimden cevap verebilirim;

      1-) Yeni geçecek arkadaşlar araştırıp kendileri karar versinler, bu yazıyı da ortada en azından fikir olması için yazdım zaten, Sizde varsa blog sayfanızda “Laraveli neden kullanıyorum” Temalı bir yazı yazabilirsiniz.
      Hatta direk adıma cevaben bunu yapan arkadaşlar da yok değil :
      örnek 1 :http://blog.guvenatbakan.com/aliye-cevaben-neden-laravel-kullaniyorum/

      2-) Soru kendi kendini çürütüyor aslında, ben yazıdaki Genel konulu sorular için Auth sorunu gibi örnekleri tamamen çok genel olması açısından vermiştim,
      Yani adı üstüne genel sorunlar farklı versiyonlar için de ayrıca filtrelemeye ihtiyaç duyacak.
      Yine bu örnek üzerinden devam edecek olursak, Laraveli kullanacak ama auth sorunu yaşayacak kadar acemi cesareti olan birisi yüzünden diğer tarafta bir üst level sorun yaşayanların önünün tıkanması yine saçma, Başta buna zaten semantik bir versiyonlama yapmayarak zemin hazırlayan “Tek adam piskolojisi”

      Bu durumda adam ne yapsın ? sorusuna cevap, her şeyle tek başına ilgilenmeye çalışmasın işte diye cevap verebilirim. Asıl sorun da bu zaten, Adam pull requestlerin copy paste yapılması için bile “ilgilenemedim” demiş, olay yine kendi üzerinden döndürüyor.

      1000 kişi olursa, iş bölümü paylaşım gibi şeyler yapılır ister istemez, ortada zaten zend gibi symfony gibi örnekleri var. Topluluk dediğimiz şey böyle şeyler için var.
      Topluluk olması için de 1 kişiden fazla olması gerekiyor.

      Sanırım gelen tepkilerin sebebi de bu benim anladığım kadarı ile,

      Topluluk kavramı soran ile cevaplayan sayısı ile alakalı, soran sayısı yükselirken, cevap verecek sayısı yükselmiyorsa burada sıkıntılar ve karmaşa doğuyor, bu da her ne kadar benim fikrim olmasa da “Laravel günü kurtarma framework’ü” tezini doğruluyor. Tekrar ediyorum bu benim fikrim değil, zira bu yazıda da teknik olarak eleştiri kısmına girmedim, tamamen genel hatlarına değindim.

      3-) Yazımda da bu dediğinizi öneriyorum zaten. Temas ettiğimiz kısım aynı.

      4-) Taylor ile de bir husumetim yok aslına bakarsan, Muhatabım Taylor değil zaten, ben 1. maddedeki “Laravel Hakkında” araştırma yapan kişiler için fikir vermesi için bu yazıyı yazdım, en nihayetinde Türkçe içerik olması açısından eko sistem için bu tarz yazıların olması taraftarıyım,
      İyi yada kötü her konuda bu işe kafa yoran insanların İçerisinde hakaret olmayan Türkçe içerik üretmesi sektöre yeni girenleri yada kafa karışıklığı olanların fikirlerini netleştirmesi açısından yararlı olacaktır diye düşünüyorum.

      Yoksa zoruna gidenin borusuna gitsin gibi bir ibare de Türkçe içerik ancak, sözü söyleyenin iq seviyesini ortaya koyma dışında başka bir işe yaramıyor.

      Genelde bütün örnekler bu şekilde geliyor,

      Madem laravel tek kişi o zaman birisi laravel’i forklayıp çoğaltsın,
      kesinlikle buna katılıyorum,
      Mesela, Mysql üzerinden danışmanlık hizmeti verip araçlar üreten kadro mysql oracle’a satıldıktan sonra gidişatı beğenmeyip, mariadb’yi çıkardılar, mysql’e desteklerini kesmediler ama mariadb ile de mysql’den daha iyi bir durum ortaya koydular,
      Aynı şekilde mysql üzerinden örnek verirsek yine ondan forklanan percona var, (twitter kullanıyor)
      diğer tarafta open office ve libreoffice var.
      Burada bende aynını düşünüyorum, beğenmiyorsan forkla.

      Fakat yazıda da değinip üzerine durduğum konu şu, Composer var, Laravel sıfırdan kodlanmış bir çatı değil, benim yazıda dediğim gibi her şeyin kullanışlı araçlarını bir araya toplayan gayet kolay ve kullanışlı bir çatı, bu durumda laraveli forklamak yerine insanlar benzer çatılar oluşturma yoluna gidiyor,
      Phpmasters’sın haftalık repo listelerinde laravel gibi forklanan ve oluşturulan çatıları görmek mümkün.

      5-) Yazıda anlattığım şeyde bu zaten, composer diye bir şey varken, bir aracın holiganlığını yapmaya gerek yok,
      her çatının kendi dinamiklerini öğrenene kadar zorluk çekileceği aşikar, burada dikkat edilecek husus, gelişime kendini kapamadan ayakları yere sağlam basan yenilikleri takip edebilmek.
      Size uyan en uygun yöntemi seçip ilerlemek, Bu bugün elinizdeki proje için Laravel olur, başka bir proje için composer ile inşa edilmiş başka bir yapı olur.

      Ek olarak Katıldığım şöyle bir fikir var,

      “Kendi yapısını kuramayacak insanlar için laravel geçiş için mükemmel bir platform,”

      • Bende hızlı cevabın için teşekkür ederim.
        “Neden laravel kullanmıyorum” sorusunu seninle beraber bizde sorduk bu cevaplar onun için. Zira senin kendine sorduğun soruya verdiğin cevap için “ya aslında laravel süper ya ortaya dikine karışık ne giseelll” gibi bir yaklaşımdan bakmak değil amacım.

        Benim önerim sadece laravel özelinde değil genel olarak toplulukları uygun yerlere yönlendirmek.

        Laraveli kullanmazken alternatif olarak symfony önerdiğin için böyle bir cevap ihtiyacı hissettim. Sorularım sadece sana değil aynı zamanda “bize”.

        Umarım ülkemizdeki geliştiriciler daha “farkında” tercihler yapmaya devam ederler.

  • gatbakan

    Selam arkadaşlar,

    Eğer başıma birşey gelmeyecekse, ben Ali’ye cevaben bir yazı yazmıştım. Şu an baktım Ali’ye çok büyük destek var, korktum ama yine paylaşacağım: http://blog.guvenatbakan.com/aliye-cevaben-neden-laravel-kullaniyorum/

    Baştan not: Benim yazım Ali’yi yanlışlamak için değil. Neden kullandığımı açıklamak için 🙂

  • Emrullah

    Laravel’de proje geliştirme süresi gerçekten hızlı ama dediğiniz geri geri uyumluluk sıkıntıları malesef var ayrıca bi arkadaşımızın dediği gibi Symfony yi alıp kendine göre değiştirmiş sanki eleman 🙂 ben 6 yıldır yazılımcı olarak çalışmaktayım bugune dek php ve .net ile projeler geliştirdim tabi .net çok az ve .net konusundada çok da iyi olduğumu söyleyemem ancak php kısmında ise bugüne dek codeigniter dan aldığım memnuniyeti diğer framework’lerden alamadım ancak onunda geliştirmesi durduruldu yakında 3.0 versiyonu çıkıcak gibi bir sürü belirsizlik var bir yazılımcı olarak proje geliştirirken eğer framework kullanmamız gerekiyosa kullanıcağımız framework’de tutarlılık aramamız şart yoksa büyük sıkıntılar bizi bekliyor ama tutarlılık iyi ama performans kötü olan bir framework üde kullanma taraftarı değilim mesela Zend gibi , bunları yanyana koyduğumuzdada bana göre ne .net ve diğerleri nede php ve kütüphaneleri mantıklı geliyo özellikle benim gibi %95 web uygulamaları geliştiriyosanız tek tavsiyem Ruby On Rails dir hem tutarlı hemde performans açısındanda makul . Kimseye ders vermek gibi bir niyetim yok sadece kendi yaşadıklarım ve tecrübelerime göre düşüncelerimdir bu aslında anlatmak istediğim Neden .net veya php Kullanmıyorum dur.

  • Gerçekten güzel bir konu tebrikler emeğine sağlık.

  • selçuk

    Merhaba, konu hakkında laravel topluluğundan fikirlerini istedim merak ediyorum onlar ne düşünüyor. Elimden geldiğince yazını ingilizce özetleyerek sordum: http://laravel.io/forum/12-21-2014-why-i-am-not-using-laravel belki cevapları incelemek istersin 🙂

    • aligundogdu

      Teşekkürler.

  • OzanKurt96

    Emeginize saglik, ancak bence baskalarini kendinizden daha ileride gormeye katlanamadiginiz icin laravel kullanmiyorsunuz. Laravel bazi seyleri sekillendirmis ve sadece Taylor tarafindan yazilmis olabilir. OpenSource olan hersey istek dogrultusunda editlenebilmektedir. Yeterli programlama bilginiz varsa buni basarip custom bir laravel yaratabilirsiniz. Taylor binlerce satiri tek basina yazarak bir harika yaratmistir bence. Saygi duymak gerekir.

  • hataayiklama

    Laravel’in “ben dünyanın en performanslısıyım, en verimlisiyim, en özelleştirilebiliriyim” gibi bir iddiası yok. Ben kullandığım zamanlarda süreci hızlandırması amacıyla kullanıyorum. Ki zaten Taylor Otwell da neredeyse her röportajında bundan bahsediyor. “as simple as possible, as fast as possible” diye sayıklıyor adam. Yeterli zaman, ihtiyaç ve ekip olduğunda paralelinde zend veya symfony’de ya da ihtiyaçsa java’da geliştirmelere devam edilir zaten.

    Bunu dünyanın tüm startupları yapar. Twitter yıllarca ruby on rails’de hizmet verdi. Onlar bilmiyor muydu, ror’un eksiklerini… Zamanı gelene kadar devam ettiler, sonra da java’ya geçtiler. Ancak bu tip frameworklerin amaçları size full-stack development sunmaktan ziyade, sizi olabildiğince hızlı bir şekilde production ortamına sokmak oluyor.

    Yazının başında kendiniz cevabı vermişsiniz zaten;
    >“İhtiyacımı görecek en iyisi hangisi?” sorusunu sormak bizi daha çabuk çözüme ulaştırır diye düşünüyorum.

    Kaldı ki, eğer bu yazı sürekli “ille de laravel” diyen yazılımcılara ise laravel fanboyluğu yapan “bağnaz” yazılımcılardan koşarak uzaklaşılması gerekir. Ciddiye alınması ise klavye israfından başka şey değildir.

  • erkin

    Merhaba. Acaba symfony’de geriye yönelik uyum var mı? Mesela şuan laravel 3 sürümünün dokümasyonu bile yok varsa bile 2 nin yok. Symfony’de de zendeki gibi uyum var mı yoksa sadece zend mi öyle ? symfony 1 ile yazdığım kod symfony 2 de yada 3 de çalışacak mı?

    • Özgür Ak

      ZF1’den ZF2’ye geçişte bir uyumluluk yoktu. ZF3 geliyor, onda da yine uyumluluk olup olmayacağı belli değil. SF2’den SF3’e geçişte -paylaşılanlara göre- de bir uyumluluk olmayacak gibi gözüküyor. Bu sadece Laravel’e özgü bir konu değil ama Laravel diğerlerine nazaran biraz abartmış durumda.

      Burda üzerinde durulması gereken nokta geriye yönelik uyumluluktan ziyade LTS(Long Term Support)’nin olup olmamasıdır.

      Uygulamalarınızı Object Oriented Principles, Desing Pattern, SOLID ‘e uygun şekilde yazmanız durumunda yeni versiyona geçirmeniz kolay olacaktır. Aksi takdirde eliniz kolunuz bağlanır, hayli zorlanırsınız.

  • Pingback: Şu sıralar aklımdakiler #2 | Levent Bali()

  • Nurullah

    Yii seçmekte doğru bir karar verdiğimi bu güzel yazınızla tescil etmiş oldum. Teşekkür ederim.

  • Özgür Ak

    Yazı için teşekkürler. Muhtemelen Laravel’i takip eden herkesin kafasında var olan soru işaretlerine değinmişsiniz. Fakat konu başlıklarına katılmakla beraber bu kadar karamsar olmanıza katılmıyorum.

    Konuya sadece Laravel ve Taylor açısından bakmamak gerekiyor.

    Laravel’in en büyük sorunu Codeigniter’dan geçiş yapanlar ve ilk framework’leri Laravel olan insanların sahipleniyor olması. Github üzerinden “login olamıyorum”, “db’den veriyi çekemedim”, “for döngüsünü kuramadım”, “blade’e datayı gönderemedim” vb saçma sapan şeklinde devam eden issue’lar açmaları ve gönderilen PR’ların belirtilmiş olan standartlara uymaması(Bu sorunlardan dolayı arada kaliteli issue’lar ve PR’lar da kaynıyor). Bu nedenle Taylor tarafından Community önemsenmiyor, kafasına göre takılıyor yorumları yapılmasına neden oluyor. Şu an Taylor projeyi lead ediyor, bir kaç kişi daha destek veriyor. Temennimiz(Taylor’da kesin bir şekilde söylemese de ima ettiği) 5.0 ‘la birlikte SemVer’e geçiş yapacağı ve versiyonlamanın daha stabil bir hal alacağı, projeye başkalarının da dahil edilerek gerçek anlamda bir community projesi olması yönünde.

    Bence Laravel kullananların öncelikle düzgün php, yazılım geliştirme, oop, solid, mvc vb kavramları iyice çözmeleri gerekiyor, sonra da projenin ucundan tutmaları gerekiyor. Laravel forumlarına/gruplarına(türkçe, ingilizce) baktığınız zaman sorulan soruların yarısından fazlası framework dokümanında açık açık ifade edilmiş konulardan(soruları soranlar tarafından dokümanlar okunmamış) ve laravel’le alakası olmayıp doğrudan php ile alakalı konulardan oluşuyor.

    Hiç bir şekilde bir dilin ya da framework’un taraftarı olmamak gerekiyor. Diller ve framework’ler araçtır, işinizi görüp görmediği önemli. Bugün Laravel olur, yarın başka bir framework olur, hatta gün gelir farklı bir dil olur ama bu sorunlar hep devam eder.

    Son olarak “Laravel tu kaka, ben kendi framework’ümü yazıcam o daha iyi” diyenlerden olmamak gerekiyor.

  • Öncelikle Laravel’i pek anlamadan yazılmış bir yazı…

    Hele “Yii, Zend, Symfony gibi” dediğin yer çok fena 🙂

    * Yii 1’de mühendislikten eser yok, ameleler yazmış, Yii 2 çıkana kadar mevsimler geçti insanlar yaşlandı.

    * ZF1’i öğrenmesi acayip zordu saçma sapan eksikleri çok yavaş tamamladılar vs. yıllardır kullanıyorum üzerine kaç tane alt-framework yazdım sonlara doğru kullanılabilir hale geldi ama ZF2’de tam sıçtılar. Stratejileri tamamen sertifika, eğitim ve IDE satmak üzerine olan çakal bir altyapıdır kendisi, yıllarımı verdim, biliyorum da konuşuyorum…

    * Symfony2 efsanedir, Fabian Potencier PHP’nin bana göre kurtarıcılarındandır, çok da iyi bir mühendistir, ama öğrenmesi (learning curve) pek kolay değil. Laravel’in tek alternatifi Symfony’dir bana göre (projelerin geneli için). Hiç kullanmadım o ayrı 🙂 Ama takip ederim…

    Laravel’in en büyük silahı laracasts’dir, dokümantasyonudur, PHP camiasına mühendislik öğretme başarısıdır…

    Seçmeme nedenlerini de madde madde yorumlayayım:

    1. Tek adam olmak: Symfony ile ZF community projesi olarak mı doğdu pardon? Hatta rails?

    2. Totaliter olmak: Linux’un kernel’ına patch’leri nasıl kabul ediyor Linus Torvalds?

    3. Versiyonlama stratejisi: Lafım yok, eyvallah… Zamanla düzelecektir, nispeten yeni bir framework.

    4. Sorun yaşayanları sallamamak (?): İşte bu benim laravel’i tercih etme nedenlerimden biri. Helal olsun! Bug report edeceksen unit testini yaz da report et diyor adam, bence süper. Komponenti kullanmayı bilme sonra git bug diye report et, yanlış olan bu zaten. Sorular için stackoverflow var, forum var…

    5. Standart üretme: Denizliler ne der bilmem de İzmirliler de çekirdeğe çiğdem diyo biz bişey diyo muyuz 🙂 Bu maddeyi başka bir framework’le karşılaştırırsan belki anlayabilirim ama bana yanlış anladığın bir nokta var gibi geldi… Autoloader’ı ayarla new Nesne() diye kullan engel olan mı var? Ha bazı mallıklar var eyvallah, o da Laravel5’te düzelecek inşallah.

    6. Lego mego: Configuration over convention / convention over configuration tartışmalarını anımsattı bu bana. Peki Zend Framework çok mu çıkabiliyor? Cevap veriyorum: HAYIR (tecrübeyle sabittir). Komponentini yaz sonra laravel’e bağla ek bi class yazacan altı üstü?

    7. Destek destek destek: Zend’in verdiği desteği yemişim debugger’la satır satır okudum ben koca framework’ü hangi destek 🙂 Ama genel anlamda katılıyorum eyvallah, biraz daha zamana ihtiyacı var bunun için…

    Şimdi şunu diyeyim önce; Laravel 3’le 4 arasında bi alaka yok, laravel4 ve üstünü ayrı bir framework gibi düşünmek lazım…

    Zaten Laravel’in patlaması v4’ten sonra oldu. L5 bile epey farklı aslında, umarım patlamaz o konuda ben de tırsıyorum biraz.

    Ama sonuçta L4 bile uzun süre iş görecek kalitede bir ürün… ZF’den iyi olduğuna kalıbımı basarım, Symfony halen çok sıkıcı Yii2’yi bilmiyorum…

    Model layer’ında kavramlar birbirine girmiş gibi geldi bana…

    Eloquent da bir ORM, laravel’de SQL’le yapacan diye bişey yok…

    ActiveRecord olur kendisi.

    Sen data-mapper tarzı bir ORM olan Doctrine’i tercih ediyorsun, çok istiyosan Laravel’de de kullanırsın, öğrenene kadar setup’ı biraz uğraştırır sadece.

    ORM’lerin de avantajları dezavanytajları vardır, seneyle alakası yok bunun. Web uygulamalarının belki %90’ı için avantajlıdır eyvallah ama ORM yeni ve moderndir SQL eski ve modası geçmiştir gibi değerlendirmek pek doğru değil bence.

    Laravel 4’ün gıcık yanları:

    – IDE desteği zayıf, ama ide helper yazmış bi eleman, ayarlayınca halloluyor…

    – Internal’larını anlamak biraz zor, her framework’ün zordur gerçi ama facade vs. bir sürü design pattern kullandığı için iyice zorlaştırıyor. Laravel5’te epey bir yol kat ettiler bu konuda, heyecanla bekliyoruz.

    – Blade başarılı ama gereksiz bana göre. PHP template language kendisi zaten ekstra bi template diline ne gerek var desem de front-end developer’lar bu tarz tercih ediyor, çok kritik değil.

    PHP developer’lar genelde alaylı olduğu için kodu okumak anlamak iyice can sıkıcı oluyor.

    Ama güzel tarafı çok da anlamaya gerek yok. ZF’ye 4-5 tane alt-framework yazdım diyorum şu ana kadar herşey muallak çünkü dokümantasyon berbat.

    Laravel diğer framework’lerin 1 tık ötesinde.

    Sadece framework’ü vermiyor öğretiyor da, laracast olmadan laravel olmazdı.

    Framework seçmi kriterleri doğru da yargılama yanlış bence…

  • Batıkan Senemoğlu

    Yazınızı okudum elinize sağlık hak verdiğim noktalar var. Fakat;

    “Yine aynı şekilde, $nesne = new Nesne(); demek varken, neden make gibi bir metod ile ide dostu olmayan bir yöntem kullanayım ?”

    demişsiniz ama bu noktada ortaya ioc ve dependency injection konusu devreye giriyor herhangi bir containerda tutmadan metodlarınıza nesneleri inject edip bunu tdd ile uygun hale getirmeyi başka nasıl düşünüyorsunuz ki, silex dediğiniz yapıda aslında pimple denilen fabien potencier’ın kendi geliştirdiği container’ı kullanıyor.

    ide dostu konusuna gelince keza ben php geliştirirken jetbrains phpstorm kullanıyorum ve indireceğiniz küçük bir idehelper ile beraber laravellerin Facade yapısından kaynaklı olan (tamamen framework ile alakalı değil) bu problemi ortadan kaldırabilirsiniz.

  • sezen aksu

    bu sayfadaki yazilarin hepsini okudum ve ali, sen haksizsin ****. seni kiniyorum, ve sana laflar hazirladim.

  • Anıl Ünal

    > Yine aynı şekilde, $nesne = new Nesne(); demek varken, neden make gibi bir metod ile ide dostu olmayan bir yöntem kullanayım ?

    Çünkü test edilebilirlik, singleton gibi methodlarla, sınıfları istediğin zaman singleton haline getirebilmeni ve antipattern durumlardan kaçınmanı ve bunun gibi birçok özellik sağlıyor. Make dediğin olay, Laravel’in IoC konteynerine bindlenmiş bir sınıfın instancesini almak. Eğer sen bu sınıf üzerinde belirli bağımlılıklara sahipsen, bunları tek yerden yönetebiliyorsun. Misal, aşağıdaki örneği ele alalım.

    $form = new Form(new BootstrapDecorator());
    $form->generate(‘input’);

    gibi hayali bir method yazmış olalım. Sen konteyner kullanmadığın zaman, birçok yerde new Form(new BoostrapDecorator()) yazacaksın. Eğer bir dic kullanırsan, bunu 1 defa yapıp, sadece implementasyonu değiştirmen yetecek.

    App::bind(‘Form’, function($app) {
    return new Form(new BoostrapDecorator());
    });

    İstersen, `App::singleton` kullanarak o sınıfı singleton haline getirebileceksin. Ayrıca, IoC, resolve durumlarında event fırlatıyor. Bunlar hep işe yarar şeyler.

    App::resolving(‘Form’, function($foo)
    {

    //Form oluşturuldu eventi
    });

    Sınıf içerisinde new kullanıyorsanız birşeyleri yanlış yapıyorsunuz. Sınıf dışında new kullanıp nesneleri oluşturup constuctor üzerinden enjekte ediyorsanız, bir DI container kullanmanız çok daha yararlı oluyor. Amaç, sağda solda new yazılan şeyleri derleyip toplayıp bir konteyner üzerinden yönetmek. Bu kötü birşey değil, aksine olması gereken ve tüm popüler frameworklerde olan birşey.

    > “OOP dediğin şey çok kullanılan fonksiyonların, sınıf dosyaları içine konulup lazım olunca çağrılması değil mi canım”

    Değil. Aslında şuan PHP geliştiricilerin OOP sandığı şey bile OOP değil. Mesela PHP’de bir Json verisini validate etmeniz gerekecek. Gidip (new JsonValidator($json))->succeeds() gibi şeyler yapıyor genelimiz. Aslında bu OOP değil. $json, gerekli bilgiyi kendi içerisinde barındırmalı ve bir JSON verisi olduğunu belirtmeli, çünkü nesne olmasını sağlayan şey bu. (Yoksa bir string oluyor) En klasik halde şunun çalışması gerekiyor: $json->validates()

    Bunu ileri götürüp, Json’u Json yapan, attributelere de biraz akıl ekleyebiliriz. Mesela tüm integer attributeleri çarpan ve sonucu Array formatonda döndüren bir json fonksiyonu yazsak:

    $json->attributes->filter(function($attribute) {

    return $attribute->isInteger() === true;

    })->each(function($attribute) {

    return $attribute * $attribute;

    })->convert(function($converter) {

    return $converter->toArray();

    });

    böyle birşey olur ve bu OOP olur. Neden? Çünkü bu JSON nesnesi, JSON formatındaki zekaya sahip bir nesne. Kendini validate edebiliyor, iterate edebiliyor, diğer formatlara dönüştürebiliyor. Öteki türlü JsonConverter($json)->toArray() gibi şeylerin OOP ile bir ilgisi yok. Bilginin sınıflara dağıtılıp primitive types üzerinde işlem yapmasını sağlar sadece.

    > CodeIgniter‘ın geliştirilmesinin durdurulmasının ardından, ortaya çıkan, “basit, günü kurtaran bir framework” ihtiyacını karşılayabilecek yetkinlikte bir framework laravel.

    Hangi özelliklerini basit buldunuz? Sizin kullandığınız frameworkün yapıp Laravel’in yapamadığı ne var?

    > Versiyonlama sorunları.

    Çünkü Laravel yeni bir proje ve daha çekirdeği tam oturmadı. Laravel 3’te tüm sınıflar statikken, Laravel 4 ile __callStatic üzerine yoğunlaşılmaya başlandı. Şuan Laravel 5’in getirdiği şey ise, Laravel 4 geliştiricilerinin sıklıkla yaptığı şeylerin (örn App altında namespace tanımlamak, klasik form requestlerinin formrequest sınıfına taşınması, fonksiyon enjeksiyon, klasör yapısının baştan tasarlanması) gibi şeyler. Backwards compatibility iyi birşey değil. PHP BC konusunda direttiği için eski özellikleri falan silinemiyor ve API’yi ilk yazılmış haliyle kalıyor.

    > Ruby ‘den esinlenerek tek bir adamın inisiyatifinde olan Ruby çakması bir yapı kullanacağınıza, aynı basitlikte ve gerçekten topluluk tarafından geliştirilen Ruby’e geçmeniz daha faydalı olacaktır,

    Sanırım yazım yanlışı var. Ruby yerine Rails olmalı bu kısım.

    > “Kırk Küp Kırkınında Kulpu Kırık Küp” gibi bir metni, “kirk-kup-kirkininda-kulpu-kirik-kup” şeklinde url formatına çevirecek bir araç kullanmak için, composer.json’a tek bir satır ekleyerek istediğim yerden çağırıp kullanmak yerine neden sadece laravel’de çalışan bir şeye dönüştüreyim?

    Böyle birşey yok. İstediğin kütüphaneyi indirip, Laravel’in IoC konteynerine bindledikten sonra kullanabilirsin. Eğer IoC kullanmak istemiyorsan, zaten autoload işini composer hallediyor. new VendorPackage; yazarak istediğin yerde kullanabiliyorsun. Kim diyor Laravele özel ayarlar yapılacak diye? İstediğin tüm string manipulation sınıflarını composer üzerinden yükleyip kullanabilirsin. Biraz daha flexibility istersen, IoC binding/service provider/Facade oluşturup (new VendorPackage)->slug($slug) yerine Package::slug($slug) haline getirebilirsin.

    > Geçtiğimiz günlerde Laravel, github üzerindeki issüeleri sildi ve artık sorunları forumlardan sorulmasını istedi.

    Ne var bunda? Hem forum, hem chat, hem issue trackerlar karışıklığa yol açıyor olabiliyor. Hem de komponentler hep farklı repolarda bulunduğu için tek yerde toplamak istedi belki?

    > LTS

    Bu konuda kesinlikle katılıyorum. Zaten en çok eleştirilen yönlerinden birisi bu Laravel’in. İleride diğer frameworkler gibi uzun süreli LTS desteği olacağını düşünüyorum, ama dediğim gibi core çok fazla değişiyor ve tam olarak oturtamadılar halen.

    Birde, Laravel 4 veya 5 olması sizi şaşırtmasın. Laravel 1 ve 2 zaten hiç olmadı. 3 çok kısa bir süre kaldı ve API olarak çok kötüydü. 4 iyi derecede toparladı. Şimdi tüm methodları statik olan 3’e LTS vermekte akıl karı olmazdı zaten.

    • aligundogdu

      Yorumun için teşekkürler, eline sağlık.

  • Burak

    devamı geldi mi acaba ? bu arada yazı için teşekkürler, on numara yazmışsınız

    • aligundogdu

      Maalesef,
      Composer ile ilgili bir yazıya başladım fakat henüz fırsat bulup son haline getiremedim 🙁

      kısa bir süre içerisinde gelecek.

      • Burak

        Peki şuan kullandıgınız fw nedir? Ben tam uzman değilim o yüzden hangisinini kullansam bilmiyorum? Hangisini önerirsiniz?

        • aligundogdu

          Silex + Doctrine ile beraber büyük ölçüde Zend1 ‘i kapsayan bir yapı kullanıyorum. Symfony Öneririm.

          • Burak

            Symfony için türkçe kaynak bulamadım da var mı bildiğiniz bir yer ?

          • aligundogdu

            Kendi dökümantasyonları gayet yeterli, Türkçe kaynak hiç aramadım açıkçası.

  • Grafikri Serhan

    Laravel biraz inceledim saçma gelmişti. Sırf popülerliği açısından sürekli merak ediyordum. Belki bizim görmediğimiz ama yapımcılarının gördüğü bazı şeyler vardır diye. Tüm merakımı bu yazı ile gidermişsin. Eline sağlık.

  • efe engin çöloğlu

    5. maddeye hitaben google da bir araştır lütfen. böylece interface vs değilde dizaynın contract yapısını olduğunu görebilirsin.

    Design by contract

  • en son soyleyecegimi en basta soyleyeyim, durum aslinda su; “javascript bilmiyorum ama jquery biliyorum”..

    “larabok”, php’nin, tarihinde basina gelen en buyuk felakettir! en basitinden, larabok/public/htaccess’e asagidaki sacmalagi yazabilecek duzeyde basiretsiz sozde gelistirici ot’kafali egoistleri yazdigi ve php bilmeyen lamerlerin, “yoo cok hozlo yoo, bon yozbon zoyorotcoyo gordom” seklinde argumanlar uydurup, kullandiklari bir framebok’tur.

    # Redirect Trailing Slashes…

    RewriteRule ^(.*)/$ /$1 [L,R=301]

    turkce’si su; ben adam gibi bir routing yazamadim, sen eger uri “/” ile bitmiyorsa, ne var yok her uri’nin arkasina / ekle ve 301 response code ile redirect yap.

    and then, the little lamer’s story begins.. once upon a time, the little lamer heard about an holly great shit that called as larabok just becos of coming up in some seminars or hacktons or stupid meetings. watched laracats, attended laracons.. so the little lamer loved too but tooooo much and decided to use it in any time in -any project-, cos it was a very popular framebok. he was very happy and started simply to code..

    and then, the little lamer thought about this fuckin’ case saying; “yoo bo noyo opdoyt yopmoyo yoo”… he was confused but actually brain-fucked cos his accent was lapsed..

    neyse, daraldim. yukaridaki olaya donelim.

    yukarda ben yuzbine kadar test ettim diyen pe-has-peci olmaktan ote gidememis lamerle aramda gecen konusmadan sadece bir bolum;

    – surumler arasinda cok buyuk farklar olabiliyor, misal 1.0.0 dan sonra 1.0.1 yuklesen uygulamada ciddi sorunlar ortaya cikiyor.

    – ya ben onu 1.0.0 ile yazmisim ve calisiyor zaten neden surum yukselteyim. illa surum yukseltmem gerekirse ust surumle -yeni- bir uygulama yazarim.

    yahu insaf! adama demezler mi, ulan ..cik agizli, mal misin da, misal 6 ayda yazdigin uygulamayi, sirf senin kullandigin boktan sey sadece ufak bir guncelleme yapamiyor diye (dikkat buyurun, 1.0.0 dan 1.0.1 a yukseltme. yani . . ), bir 6 ay daha ugrasip tekrar mi yazican? hem de ayni seyle yazarim diyo ya la!

    bu konusmadan (mulakattan) sonra sahsin ismi dahil tum girdileri sildim ram’den ancak cach’de kalan kisimlari sonradan farkettim, ttl’leri biraz fazla vermisim, o da benim hatam.. neyse, tam onlari da silicektim, dur dedim, not alayim ani olsun ve bir a4’e not aldim, ordan aktariyorum ve vay anasini diyorum sayin seyirciler, vay anasini…

    neyse, ufakligin da dedigi gibi..

    // see the attachment

  • Ben composer ile çekip $repo = new repoClass(); diye her yerden ulaşabileceğim bir aracı, neden sadece laravel içerisinde çalışacak bir hale sokmak isteyeyim ?

    Şu cümlenden sonra bu adam OOP yazılım mimarileri ve sıklıkla kullanılan desenlerden bir haberdir dedim kendimce. UnitTest bilseydiniz muhtelen böyle düşünmeyecektiniz.

    Laravel PHP dünyasındaki en iyi frameworkler arasında.

    Kullanıcıların hasretle beklediği LTS sürümü ise 5.1 sürümü ile gelecek.

  • Evren Demir

    Türkiyede böyle ayran gönüllü bir insan olmaması gerçekten neyin ne olduğunu bilen bir yazılımcı gerçekten gururumu okşadı. Yazınız için tebrik ederim. Zend Framework ve Symfony laravelin sunduğu herşeyi fazlasıyla ve gelecek kaygısını düşündürmeden sunuyor.

    • aligundogdu

      Çok teşekkür ederim.

  • Ozan Azize Uykun

    O zaman sizlere Yerli PHP Framework olan ZN Framework 2’yi incelemenizi rica edeyim. Geliştirilmesi devam etmektedir.

    Gist: https://github.com/znframework
    Site: http://www.zntr.net

    • gatbakan

      Elinize saglik, basarilarinizin devamini diliyorum.

  • Salih Bilgin

    Anlatım için teşekkürler. Sadece kullanmama değil birde öneriler harika olmuş. Bilgilendirmeler ve yeni yönlendirmeleriizi bekliyoruz :).

  • Omur

    Çok mantıklı ve kaliteli açıklamalar yapmışsın.Fakat günümüzde php yi modern prensiplere ulaştırmaya en yakın framework sanki laravel miş gibi bir koku var.Spring framewoekde de böyle bir dikey zıplayışla ortaya çıkmıştı javanın da gelişmesine sebep oldu fakat spring javadan apayrı bir hale geldi ve java onu defacto standartı olarak kabul etti.Tıpkı senin laravel phpden uzaklaşmaya başladı tesipitinde olduğu gibi.Demek istediğim bazı tespitlerin senin sanki istikrara girişimcilikten ve yenilikten daha fazla önem vermenden kaynaklanan mantıklı ama fazla tutucu sebeplerden dolayı gözüne çarpıyor gibi..Tabi senin de dediğin gibi hangisi iyi demek yerine hangisi işime gelir gözüyle bakmalı bence de.Teşekkürler

  • Savaş YILDIRIM

    Bir projede; “CodeIgniter desteği yok artık. Geliştirilmesi durdu. Kullanmayalım bence” dediğimde işverenin cevabı harikaydı; “Sizin onlardan ne eksiğiniz var? Oturun, siz geliştirin o zaman. Hatta onlar yerine siz devam edin. Biz de (yatırımcı olarak) destekleyelim…”

  • Eline sağlık. Düşüncelerime tercüman olmuşsun.

  • Burak Selvi

    Çok güzel bir yazı olmuş, ellerinize sağlık.

  • ecarpar

    Bende tam laravel’e mi geçsem isminide çok duyuyorum, neymiş bu yaa kurcalıyım şunu biraz derken karşıma çıktı..
    anladığım kadarıyla aslında bi naneye yaramayan PHP yi ciddi anlamda bilenlerin pekte ihtiyacı olmayan, işleri bir nebze kolaylaştırma amaçlı hazırlanmış ancak kendi kalıplarından çıkılmasına izin vermeyen, bir nevi PHP yi Ms in dilleri gibi kendi içinde zorunlu tutmaya çabalayan ancak devamında destek olmayan ve devamlılığıda olmayan, tırttan bir şey olduğunu anladım yazınla.
    Vakit kaybetmeme engel olduğun için teşekkür ederim.

  • Chico Goldwire

    2 gündür yeni başlayacağım(ve uzun süre devam etmesini planladığım) bir proje için hangi framework’ü kullanayım diye araştırıyordum. Daha önce codeigniter kullanmıştım. Acaba onu mu tekrar kullanmalıyım diye düşünürken Laravel ile karşılaştım. Biraz araştırdım her yerden karşıma çıkmaya başlayınca laravel öğrenerek bu FW ye mi gireyim diye düşünürken yazınıza denk geldim.

    Yazınızda geçen tek adamlık vurgusu, eski sürümlerle olan senkronizasyon problemleri ve özellikle de çözüme giden yolların kapanması (ki bu eylem bencelliğin zirve noktasıdır) laravel kararımı değiştirdi.

    Kısa sürede basic versiyonu yazılacak ve fakat uzun süre gelişimi devam edecek bir proje için hangi Framework’ü önerirsiniz? (Object Oriented PHP yazmaya yeni başlıyorum)

    • aligundogdu

      Kısa sürede öğrenme kısmı göreceli olsa bile artık fazlası ile tutorial ve kaynak olduğu için symfony önerebilirim.
      yine aynı şekilde symfony’in mikro hali olan silex’i de tavsiye ederim ama ikinci tavsiyem içerisinde her bir parçayı kendiniz oluşturacağınız için yeni başlayan birisi için zorlayıcı olabilir.

      http://www.sitepoint.com/introduction-silex-symfony-micro-framework/

  • Ahmet

    Ali hocam makale için teşekkürler. Yorumlarda dahil baştan sona büyük bir beğeniyle okudum ve bir çok şey öğrendim. Sık kullanılanlara ekledim sayfanızı:) Biraz alakasız olacak ama ben şöyle bişey sorayım. Mesela herhangi bir yazılım dilini veya framework öğrenirken yazılı veya görsel kaynakları takip ederek öğrenirken ezberci bir yaklaşımla öğreniyor insan. Hal böyle olunca sorunlara çözüm üretmek veya yazılım geliştirmekten bir hayli uzağında kalınıyor. Ezberci bir yazılımcı değilde bir yazılım geliştiricisi olmak adına nasıl öğrenmeyi tavsiye edersiniz?

    • aligundogdu

      Ellerini kirleterek öğrendiğin bilgi daha kalıcı olur.

      Temel bilgiyi aldıktan sonra direk proje geliştirmeye başlayıp, her sorunda araştırma yaparsan daha sağlıklı öğrenebilirsin.

  • Tahir Uyanık | DOYUK

    Makaleyi sonuna kadar dikkatlice okudum. Düşüncelerine katılıyorum.
    Devamını dilerim.
    Paylaşım için teşekkürler.

  • Kaliteli ve akılcı bir eleştiri yazısı olmuş. teşekkür ediyorum.

  • Baser

    Ağzına sağlık. Ayrıca en iyisi küçük te olsa kendi frameworkünüzü yazmak ve kullanmaktır. Başkalarına ne kadar bağımlı olursanız süprizlere o kadar açık olursunuz.

    • aligundogdu

      Eğer yazmaktan kastınız herşeyi sıfırdan yazmak ise buna katılmıyorum,
      Ben composer ile güvenilir repoların bir araya getirilerek yapı kurulması taraftarıyım.

  • Ümüt DEMİR

    Yazınızı büyük bir beğeni ile okudum, Sürekli vurguladığım ve cevap vermekten sıkıldığım konularla ilgili güzel cevaplar verilmiş… Bu konular açılınca sizin yazınızın linkini veriyorum ve bu konudaki görüşlerim bu makalede özetlenmiş durumdadır… Sizinde benimde zamanını daha güzel şeyler için harcayalım mı? gibi yapıcı önerilerde bulunuyorum… Ayrıca makaleniz içinde size teşekkür ederim.

  • Larastorage

    Yazıyı yazan arkadaşı samimi bulmuyorum çünkü sadece kendisini destekleyenlerin yorumlarını yayınlayıp karşıt görüşte olanların yorumlarını yayınlamıyor.

  • Ali Osman Şen

    Devamını bekliyorum

  • onur

    Diğer frameworkleri incelemedim ama laravel eloquent dışında çöp gibi duruyor.

  • Hüseyin Gülşen

    php öğrenmeye yeni başladım bi bakim şu laravel nedir diğer frameworkler nasıl derken yazınıza ulaştım . Baştan sonra satır kelime atlamadan okudum. Sayenizde daha sonra nelerle karşılaşabiliceğimi öğrendim teşekkür ederim. Sizlere bir sorum olucak şu anda bir proje geliştirmeye çalışıyorum ve frameworkler çok karmaşık geliyor bir wordpress alt yapısını framework gibi kullanmam ne kadar doğru olur ?

  • Muhammet Ali ÖZKAYA

    Laravelden bende nefret ediyorum. Yazdıklarınız kanıtı olsa gerek.

  • Ahmet Yüzücü

    Bu güne kadar endüstri 4.0 uygulamaları geliştirdim. Bu aralar Web tabanlı bir proje geliştirmek için kolları sıvadım ve ihtiyaçlarımı karşılayacak bir framework araştırmasına koyuldum. Haliyle önüme bir sürü seçenek çıktı. Okuduğum her yazıda karar verdiğim framework’ün yerini başka bir framework aldı.

    Araştırma sürecinde Laravel için yapılan LTS eleştirilerine rağmen Laravel’i kullanmaya karar vermiştim. Bu makale o eleştirilere kulak tıkamamam konusunda beni ikna etti. Ne de olsa hayatın her alanında tek adama muhtaç kalmamak lazım.

    Tek adam projesinin keyfi uygulamalarının vereceği zarardan korunmamızı sağladığınız için teşekkür ederim.


Wordpress altyapısı üzerine Prodium Teması kullanılmıştır. Prodium bir Projekod \r Temasıdır.