Giriş yapmadınız.

Duyuru

TÜRKÇE KİTAP DUYURUSU:
Laravel 5 : Laravel 5.1 Güzelliği (Türkçe)
Vue.js 2 : Vue.js 2 Majesteleri (Türkçe)

#1 02.06.2015 11:50:04

Arda
Üye
Yer: İstanbul
Kayıtlı: 08.03.2013
Mesajlar: 178
Website

Örnek Laravel Projesi: WhatTheTag

Laravel 5 için tamamen Koding üzerinde yazdığım örnek uygulama WhatTheTag yayında!

https://arda.pw/whatthetag-a-sample-lar … plication/

https://github.com/Ardakilic/WhatTheTag

Bu uygulamanın temel crud işlemleri, query scope'lar, resim yükeleme ve yönetme, 3. parti paket yönetimi, gulp ile asset yönetimi gibi pek çok konu için örnek teşkil edeceğini düşünüyorum.

Uygulamanın resimlerine örnek olarak GitHub sayfasını veya bu imgur albüm linkini ziyaret edebilirsiniz.

Umarım hoşunuza gider smile


PacktPub'dan çıkan kitaplarım: Laravel Application Development Blueprints, Laravel Design Patterns & Best Practices.
Türkçe çıkan kitabım: Raspberry Pi

Çevrimdışı

#2 02.06.2015 13:15:07

Aristona
Üye
Yer: Kastamonu
Kayıtlı: 08.02.2013
Mesajlar: 173
Website

Yanıt: Örnek Laravel Projesi: WhatTheTag

Laravel-tr organizasyonu altına forkladım.

Katılmadığım bir nokta var. Asset yönetimi konusunda herşeyi concatleyip tek dosya içinde tutmak doğru bir yaklaşım değil. Uygulama büyüdükçe frontendi gereksiz derecede yavaşlatıyor. Asenkron yükleme yapamıyorsun. Yükleme sırasına bağımlı kalıyorsun, Ne zaman yeni bir dosya oluştursan onu gulp'a dahil etmen gerekiyor ve bunun gibi sıkıntılar. Mesela, jQuery en üstte yükleniyor, ama sayfanda jQuery bağımsız birşey var. Onun çalışması için mutlaka jQuerynin yüklenmesi beklenecek. Bu yüzden DOM'a bağlı kalmayı ben doğru bulmuyorum.

Diğer önerilerim ise şunlar:

1. Controller logic çok fazla. Bunun yerine Repository kullanabilrsin. Bir modelinde getsTagsByID gibi bir method vardı. Onun asıl yeri Repository olmalı.

2. Validation kurallarını controller içinde tutmak reusabilityi bitiriyor. Ben şahsen bu yaklaşımla devam edemediğim için Laravel validatorunu extend edip kendi validator kurallarımı yazdım. Sende App\Services\Validators\PhotoValidator.php gibi bir dosya oluşturup, kuralları burada tanımlayabilirsin. Request sınıfı içerisinde de (belki bunu middlewareye attach edebilrsin, bilmiyorum)  bu sınıfı validatore pass edebilirsin.

Benim 2 tane kural listem oluyor. Birisi create için, diğeri update ve dependency olan işlemler için. (örneğin bir resmi kategoriye ekleyeceksin, category_id kuralı CategoryValidator'un dependency (yani exists:categories,id|integer gibi şeyler) buradan import edilyor. Açıkcası Laravel neden böyle bir yaklaşımı builtin vermiyor anlamış değilim.

3. Laravel 5'te bildiğim kadarıyla validation işlemi Request sınıflarında gerçekleşiyor.

4. Admin controllerde dönen işlemler çok fazla. Örneğin: "Croppa::delete(public_path().'/uploads/'.$photo->image);" ve ""$photo->tags()->sync($tagIds);" satırları Model Observer/Event kombinasyonu ile yapılmalı. Çünkü, ileride kullanıcılara da upload desteği vereceksen aynı kodları copy paste etmen gerekecek. En son olarak, photo oluşturma olayını Command olarak tutardım. Controllerde sadece new App\Commands\PhotoCreateCommand($params) çalışırdı. Hem duplication sıfırlanıyor hem de ileride kolayca kuyruğa alabilirsin bu işlemleri gerekirse.

Benim yapım şöyle:

// Middlewares
'App\Http\Middleware\AttachObservers',

//AttachObservers.php
Photo::observe(new \Aristona\Observers\PhotoObserver);

// Controller
$command = new Aristona\Commands\PhotoCreateCommand();

//PhotoCreateCommand
$photo = new Photo;
...
$photo->save();

//PhotoObserver
PhotoObserver extends AbstractObserver
public function saved($photo)
{
     $this->event->push('Aristona\Events\Photo\SyncTags')->queue();
 }

//EventEmitter
Eventleri execute et, kuyruğa çevir vs.

Belki daha iyi bir yöntem vardır, ama bu yapıyla controller sınıflar son derece temiz kalıyor. Birde, tüm fonksiyonaliteyi modele yıktığın için, ileride birisi PR atarken, arkaplanda neler olduğunu bilmek zorunda olmuyor. Tagların senkronize olmasını falan sen zaten ayarlamış oluyorsun.

Just my 2 cents.


"Eğer 6 ay önce yazdığın kodları gördüğünde utanmıyorsan, kendini yeterince hızlı geliştiremiyorsun demektir."

Site: http://anilunal.com/
Blog: http://aristona.github.io/

Çevrimdışı

#3 02.06.2015 18:07:47

Arda
Üye
Yer: İstanbul
Kayıtlı: 08.03.2013
Mesajlar: 178
Website

Yanıt: Örnek Laravel Projesi: WhatTheTag

Aristona yazdı:

...

Teşekkürler fikirlerin için @Aristona , açıkçası biraz daha geç çıkaracaktım ama biraz da seninkiler gibi görüş alayım ona göre şekillensin dedim ve çıkarayım dedim, bazı kısımları öyle bırakmayı kasten tercih ettim. Çok kafa yormadım yani. Gelen standart yapıdan çıkmamaya ve de "hiç laravel bilmeyenin bile bakınca anlayabileceği bir yapıda" bırakmaya çalıştım.

Assetlerde haklısın, ama async task çok yok (admin datatables'ları haricinde hiçbir yerde yok hatta), Her şeyi ayrı js yaparsam da request sayısı artacak. Zaten production'da bu assetler sunucu yönetmeyi bilen kullanıcılarca vhost ayarlarıyla tarayıcıya cacheletileceğinden büyük bir sıkıntı olacağını ben şahsen düşünmüyorum. Ayrıca uygulama o css / js lerin en az %80'ini açılan herhangi bir sayfada kullanıyor. Bu sebeplerden biraz da bu yüzden css ve js'i tek dosyada birleştirmeye karar verdim. Aslında admin.js diye ayrı bir js yapacaktım sonra vaz geçtim. İlerde belki yapabilirim bilmiyorum. Gulp'ı zaten bu kodu yazmadan önce hiç kullanmamıştım, front-end developer arkadaşlarım hallediyordular sağ olsunlar smile

getsTagsByID dediğin metod eğer şuysa doğrudan veritabanıyla konuştuğu için, ve de ilerde aynı metod adı ile başka bir arkaplan işlemleri ile aynı kapıya çıkma gibi bir durumu olmadığından modelde kalmasını tercih ettim şahsen. Repository pattern'e sokarsam bunun için biraz gereksiz işlem gibi olmaz mı sanki?

Hah evet, validate'lerde haklısın, $this->validate($input, $rules) diye oluyor, hiç aklıma gelmedi oraları yazarken, L4 kafası işte, yakında bi commit gelir ona smile Validator facade'ı ile de oluyor ama. Yazılan kod yanlış veya ilerde deprecate olacak bir kod/yol değil yani.

Validation kuralları için aslında ben l4'de modelde veya birden fazla yerde ortak kullanılacaksa autoload eden bir dosyada değişken / metod vs. olarak tutuyordum. Belki bunları da o şekilde da yaparım bilmiyorum. Bunun gibi ufak ebatlı uygulamada abartı kaçabilir mi acaba ?

Model observer olabilir aslında güzel fikir (Y). Aslında ilk düşünmüştüm, ama neden bilmiyorum düşünürken sluggable da çalışırsa acaba 2 kere çalışır mı diye incelerken sonra ne yalan söyliyim amaan dedim vaz geçtim big_smile . Yeniden denerim.

Bunları kalanları bir araya getirmek de laravel 5.1 ' e geçiş sırasında olsun smile

Aklına geldikçe pull request de alabilirim bu arada smile

Fikirlerin ve incelemen için yeniden teşekkürler!

Son düzenleyen Arda (02.06.2015 18:10:46)


PacktPub'dan çıkan kitaplarım: Laravel Application Development Blueprints, Laravel Design Patterns & Best Practices.
Türkçe çıkan kitabım: Raspberry Pi

Çevrimdışı

#4 02.06.2015 20:04:09

Aristona
Üye
Yer: Kastamonu
Kayıtlı: 08.02.2013
Mesajlar: 173
Website

Yanıt: Örnek Laravel Projesi: WhatTheTag

Arda yazdı:
Aristona yazdı:

...

Teşekkürler fikirlerin için @Aristona , açıkçası biraz daha geç çıkaracaktım ama biraz da seninkiler gibi görüş alayım ona göre şekillensin dedim ve çıkarayım dedim, bazı kısımları öyle bırakmayı kasten tercih ettim. Çok kafa yormadım yani. Gelen standart yapıdan çıkmamaya ve de "hiç laravel bilmeyenin bile bakınca anlayabileceği bir yapıda" bırakmaya çalıştım.

Daha iyi olmuş erken paylaştığınız. Evet belli oluyor bazı yerlerde. smile Benim önerilerim Laravel'e yeni başlamış birisi için zor gelebilir ilk etapta, bu konuda haklısınız.

Arda yazdı:

Assetlerde haklısın, ama async task çok yok (admin datatables'ları haricinde hiçbir yerde yok hatta), Her şeyi ayrı js yaparsam da request sayısı artacak. Zaten production'da bu assetler sunucu yönetmeyi bilen kullanıcılarca vhost ayarlarıyla tarayıcıya cacheletileceğinden büyük bir sıkıntı olacağını ben şahsen düşünmüyorum. Ayrıca uygulama o css / js lerin en az %80'ini açılan herhangi bir sayfada kullanıyor. Bu sebeplerden biraz da bu yüzden css ve js'i tek dosyada birleştirmeye karar verdim. Aslında admin.js diye ayrı bir js yapacaktım sonra vaz geçtim. İlerde belki yapabilirim bilmiyorum. Gulp'ı zaten bu kodu yazmadan önce hiç kullanmamıştım, front-end developer arkadaşlarım hallediyordular sağ olsunlar smile

Projeye göre değişiyor. Yaptığın proje çok küçük ve minimalist. Benim bahsettiğim biraz daha enterprise uygulamalar için.

Benim Gulp çıkmadan önce Grunt kullanmaya başlamıştım. Komple tüm workflowumu değiştirmiştim bir günde Grunt sayesinde. Kendi Gruntfile dosyamı yazıyorken sabaha kadar çalışmıştım farkında olmadan. smile Genellikle Grunt ve Gulp gibi araçların syntaxları çok basit oluyor. İstersen Laravel'de elixir var, onun syntaxı çok daha kolay.

Arda yazdı:

getsTagsByID dediğin metod eğer şuysa doğrudan veritabanıyla konuştuğu için, ve de ilerde aynı metod adı ile başka bir arkaplan işlemleri ile aynı kapıya çıkma gibi bir durumu olmadığından modelde kalmasını tercih ettim şahsen. Repository pattern'e sokarsam bunun için biraz gereksiz işlem gibi olmaz mı sanki?

Ben modellerde sadece propertyleri/relationları/scopeleri vb. tutuyorum. O tür methodları repository içinde tutuyorum. Buna belki karşı çıkan olabilir ama öteki türlü model dosyası çok büyüyor.

Arda yazdı:

Hah evet, validate'lerde haklısın, $this->validate($input, $rules) diye oluyor, hiç aklıma gelmedi oraları yazarken, L4 kafası işte, yakında bi commit gelir ona smile Validator facade'ı ile de oluyor ama. Yazılan kod yanlış veya ilerde deprecate olacak bir kod/yol değil yani.

Şuan geliştirdiğim proje haricinde Laravel projesi geliştirmedim son 1 yıldır. Başladığımda Laravel 4.0 vardı, 5.0'a güncelledim çıktığı zaman, ama Form Requestleri kullanmak için büyük değişiklikler yapmam gerekiyordu o yüzden özellikle Request özelliğini fazla kullanamadım. Kendim ona benzer birşey yazmıştım. Ama bildiğim kadarıyla Form Requestlerin amacı tamamen validationla ve diğer boilerplate işlerle ilgili.

Arda yazdı:

Validation kuralları için aslında ben l4'de modelde veya birden fazla yerde ortak kullanılacaksa autoload eden bir dosyada değişken / metod vs. olarak tutuyordum. Belki bunları da o şekilde da yaparım bilmiyorum. Bunun gibi ufak ebatlı uygulamada abartı kaçabilir mi acaba ?

Benim bildiğim bazı kişiler model içinde attribute oluşturup tutuyorlardı, ama o yöntem benim hoşuma gitmiyor. Öyle tutunca, mesela atıyorum resmi kategoriye ekleyecekken kategori validationunu almak için Category modeline erişmek gerekiyor. Birde şu soruya tam olarak cevap veremiyorsun. O işlem modellemi alakalı yoksa validationlamı alakalı. Nereye bakacak mesela başka bir geliştirici PR atmak için. O yüzden ben özel bir namespacede tutuyorum ruleleri. Temiz oluyor.

Arda yazdı:

Model observer olabilir aslında güzel fikir (Y). Aslında ilk düşünmüştüm, ama neden bilmiyorum düşünürken sluggable da çalışırsa acaba 2 kere çalışır mı diye incelerken sonra ne yalan söyliyim amaan dedim vaz geçtim big_smile . Yeniden denerim.

Bunları kalanları bir araya getirmek de laravel 5.1 ' e geçiş sırasında olsun smile

Aklına geldikçe pull request de alabilirim bu arada smile

Fikirlerin ve incelemen için yeniden teşekkürler!

Hepimiz aynı şeyi yapıyoruz. smile Çok iyi olacak diye kendimizi fazla zorlamaya gerek yok. Zaten proje ilerledikçe atılması gereken adımları görüyorsun.

Event ve observer patterni öğrenince uygulamaya yaklaşımın biraz daha farklılaşıyor. Sanırım Laravel 5.1'den sonra Observer ile attributeleri de observe etme desteği gelecek Laravel'e. O zaman attributeleri de izleyip event bindleyebileceğiz. Örneğin users.authority değeri değiştiğinde email at gibi şeyler. Business logic dediğimiz kısımları bu eventlere listener atayarak yapmak çok iyi oluyor. (Örneğin, birisi Moderatör olduysa, Moderatör el kitabını email attırma gibi işler.) Kocaman fonksiyonun içinde if/else yazarak zorlanmıyorsun. Ne yapılması gerekiyorsa isimlerini event emittere gönderiyorsun, gerisini o hallediyor. Scale olmana da yardımcı oluyor bu yöntem. Image resize gibi resource yiyen event işlerini başka sunuculara paylaştırabiliyorsun.

Tabi bunlar benim fikirlerim, yapmak zorunda değilsin. Şu hali de iyi uygulamanın.

PR atabilirim, ama Github'u çok az kullanmaya başladım son zamanlarda, o yüzden ne zaman olur veya olurmu hiç bilmiyorum. Kendi projelerimi bile yarım bıraktım. sad

Son düzenleyen Aristona (02.06.2015 20:10:55)


"Eğer 6 ay önce yazdığın kodları gördüğünde utanmıyorsan, kendini yeterince hızlı geliştiremiyorsun demektir."

Site: http://anilunal.com/
Blog: http://aristona.github.io/

Çevrimdışı

#5 03.06.2015 08:36:19

MURATSPLAT
Yönetici
Yer: Antalya
Kayıtlı: 06.05.2014
Mesajlar: 642
Website

Yanıt: Örnek Laravel Projesi: WhatTheTag

@Aristona'nın repository olmalı görüşüne biraz fazla iddialı bir görüş gibi görünüyor. İlk zamanlar ben de ' ne gerek var! ' diyordum. Eğer tabloları önbelleğe atıyor ve özellikle ön kısımda bazı yerlerde aynı modelleri  önbellekten çağırıyorsanız, denetleyici ya da view'lere composer ile veri düğümlediğiniz sınıflarda karmaşa oluyor. Bunun yerine CRUD işlemlerini tümünü bir repository üzerinen yapmak daha mantıklı oluyor. Composerler , Denetleyiciler, Middleware  gibi sınıfların veritabanına erişmek için tek bir repository nesnesini kullanmaları, bazı işlemleri yapılması için yapılan kod tekrarını azaltıyor, cahing yapılacaksa bunun daha kolay ve basit olmasını sağlıyor.

Ayrıca @Aristona'nın belirttiği gibi eventlar ile modellere ve ya uygulama için bazı nesnelere müdahale etmek çoğu zaman daha pratik oluyor. Bazı problemleri takla atmadan çözmenize yardımcı oluyor..

Mesala bir çoklu dil  için bir eklenti yazmıştım. O eklentiği her denetkeyicide set etmek yerine tek bir method ile düm denetleyicilerin miras aldığı soyut bir sınıfa yazıp kurucuda çağırıyorum.

        /**
         * to set wrapper by multilang event
         * 
         * @param integer $lang_id
         */
        private function setMultilangWrapperByEvent($lang_id = 1) {
            
            $events = App::make('events');
            
            /* setting wanted lang by using event */    
            $events->listen('multilang.wrapper.creating',function(MultiLang $event) use($lang_id) {
                
                $event->getWrapperInstance()->setWantedLang($lang_id);    
            });
        }   

Event driven programming  problemlerin çözümünü çok kolaylaştırıyor.

Çevrimdışı

#6 03.06.2015 11:00:59

Arda
Üye
Yer: İstanbul
Kayıtlı: 08.03.2013
Mesajlar: 178
Website

Yanıt: Örnek Laravel Projesi: WhatTheTag

@Aristona, resmi kategoriye ekleyecekse relation'dan da yürüyebilir ?

Örneğin;

User::find(1)->photos()->create(['key'=>'value']);

veya

Photo::find(1)->user()->update(['key'=> 'value']);

gibi ? Relate edecek modellerde relation sütunları otomatik doluyor.

Eğer ayrı modele gitmek istenmiyorsa validation'un exists metodu ile exists:users,id gibi de yazılabilir sanki. Bu sayede modele erişmeden doğrudan tablodan kontrol edilebilir.

-------

Teşekkürler @muratsplat, lakin yeniden değinmem gerektiği gibi bu uygulamada elimden geldiğince sade bırakmaya, ve de "laravel bilmeyenin bile bakınca neyin nerden geldiğini neden olduğunu anlayabileceği şekilde bırakmaya" çalıştım, ve de repository veya observer'ların burada fazla kalacağını düşünüyorum. Repository pattern'in gerekeceğini düşünmüyorum burada. Repository pattern'in asıl amacı abstraction sağlamak ve de controller'ın konuştuğu diğer bileşenlerden, misal eloquent ile doğrudan konuşmasını ayırd etmek. Bir PhotosRepository yapılır ve de buradaki metodlar önceden set edilen Eloquent ile veriler çekilir. Bu repository'de database driver'ı (Eloquent mysql'den değil de elasticsearch den gelsin mesela ?) tek tıkla değişir, controller verinin hangi driver'dan (fluent, eloquent, mysql vs.) geldiğini bilmez ve de sadece repository ile konuşur, veriyi alır ve ilgili yere aktarır. Bu repositoryler farklı lojikjlerde de kullanılabilir. Bu yüzden farklı lojiklerde (sitedeki farklı bölümler) Tekrarlanacak "Controller metodları için" repository açmaktansa ayrı bir namespace'de bu işlemleri gruplamanın şahsen daha mantıklı olacağını düşünüyorum şahsen.

Burada tek event ile sitedeki farklı lojiklerde çağrılan farklı metodlu kadar kompleks bir yapı yok ama. İleride multi dil eklerim o zaman tabi.

Eventlerde haklısınız, sluggable da eventlerle çalıştığından evente taşımayı düşündüğüm attach/sync işlemleri 2 kere çalışır mı onu test ediyorum, sanırım sorun olmayacak.

Fikirlerin için yeniden teşekkürler smile

Son düzenleyen Arda (03.06.2015 11:01:39)


PacktPub'dan çıkan kitaplarım: Laravel Application Development Blueprints, Laravel Design Patterns & Best Practices.
Türkçe çıkan kitabım: Raspberry Pi

Çevrimdışı

#7 03.06.2015 13:20:17

MURATSPLAT
Yönetici
Yer: Antalya
Kayıtlı: 06.05.2014
Mesajlar: 642
Website

Yanıt: Örnek Laravel Projesi: WhatTheTag

Şahsen kendi açımdan düşündüğümde yazılımdaki tekniklerin hangisi iyi sorusunun tek bir doğrusu yok. Var diye biri çıkarsa  da çok ciddiye almıyorum. Kodladıkça olası problemleri fark edebiliyor olabildiğince esnek ve farklı senoryolara da cevap verecek şekilde düşünmeyle başlıyoruz. Bu iş biraz da tecrübeyle doğru orantılı.

Genellikle iki defa kod tekrarı yaparsam ya da karmaşıklıktan dolayı hatalar çıkmaya başlayınca "bir yerlerde hata yapıyorum!"  duygusuna kapılıyorum. Sonra sorunu tanımlayıp yeni bir çözüm getirmeye çalışıyorum. Zaten yazılım desenleri gibi teorik konular karşılaşılan sık sorunları çözümüne yönelik ortaya çıkıyor. Benzer sorunların çözümü de benzer oluyor.

Çevrimdışı

#8 03.06.2015 15:42:17

Aristona
Üye
Yer: Kastamonu
Kayıtlı: 08.02.2013
Mesajlar: 173
Website

Yanıt: Örnek Laravel Projesi: WhatTheTag

Arda yazdı:

Eğer ayrı modele gitmek istenmiyorsa validation'un exists metodu ile exists:users,id gibi de yazılabilir sanki. Bu sayede modele erişmeden doğrudan tablodan kontrol edilebilir.

Tam anlayamadım. exists:users,id, User modelinin "update" için kullanılacak yerlerde çağırılacak bir validationu. Yani şöyle birşey atıyorum:

UserValidator.php
$create = [
    'user_id => 'required|max:20|alpha_num...';
];

$update = [
    'user_id => 'exists:users,id'
];

Mesela Photo eklerken, user_id ile relation yapackken, user_id nin validation kurallarını PhotoValidator içine yazmaya gerek yok. Bu veri UserValidatorden gelmeli. Şöyle birşey oluyor yani:

'photo_title' => 'required|alpha_num|max:50',
'user_id'      => new \UserValidator->getAttr('user_id', 'update');

Benim yazdığım şey bunu yapan aracı bir sınıftı.

Eğer şu örneğinde: Photo::find(1)->user()->update(['username'=> 'Değer']); username değerinin validation kuralları biryerden çekilip otomatik çalıştırılıyorsa, ve geriye de bir Validation sonuçları dönüyorsa bu özelliği bilmiyorum. Yani ben oraya 'username' => null yazarsam ne oluyor. Veritabanına gidip hata mı alıyor, yoksa önceden engelleniyormu validation kurallarıyla?

Aynı noktadanmı bahsediyoruz emin olamadım. Senin verdiğin örnekte Photo::find(1)->user(), photo modelindeki user() relationdan gelen user instancesini döndürüyor. Yani orası aslında User modeline dönüyor, ve sen {user}::update(...); 'yi çalıştırmış oluyorsun.

Dediğim gibi, yeni başlayanlara yönelik örnek uygulamada bu kadar detaya girmeye gerek olmayabilir.

MURATSPLAT yazdı:

Şahsen kendi açımdan düşündüğümde yazılımdaki tekniklerin hangisi iyi sorusunun tek bir doğrusu yok. Var diye biri çıkarsa  da çok ciddiye almıyorum. Kodladıkça olası problemleri fark edebiliyor olabildiğince esnek ve farklı senoryolara da cevap verecek şekilde düşünmeyle başlıyoruz. Bu iş biraz da tecrübeyle doğru orantılı.

Genellikle iki defa kod tekrarı yaparsam ya da karmaşıklıktan dolayı hatalar çıkmaya başlayınca "bir yerlerde hata yapıyorum!"  duygusuna kapılıyorum. Sonra sorunu tanımlayıp yeni bir çözüm getirmeye çalışıyorum. Zaten yazılım desenleri gibi teorik konular karşılaşılan sık sorunları çözümüne yönelik ortaya çıkıyor. Benzer sorunların çözümü de benzer oluyor.

Katılıyorum.


"Eğer 6 ay önce yazdığın kodları gördüğünde utanmıyorsan, kendini yeterince hızlı geliştiremiyorsun demektir."

Site: http://anilunal.com/
Blog: http://aristona.github.io/

Çevrimdışı

#9 05.06.2015 14:16:07

sineld
Yönetici
Yer: Bursa
Kayıtlı: 26.12.2012
Mesajlar: 1,087
Website

Çevrimdışı

#10 26.12.2016 23:04:05

Arda
Üye
Yer: İstanbul
Kayıtlı: 08.03.2013
Mesajlar: 178
Website

Yanıt: Örnek Laravel Projesi: WhatTheTag

Bugün yeni bir sürüm geçtim. Biraz can sıkıntısından biraz da hevesle.

0.4.0 sürümünde en başı çeken özellik Algolia araması. Bu arama sayesinde artık neredeyse anlık ve gerçek zamanlı arama yapabilirsiniz.
Bir diğer özellik de AWS s3 desteği.


PacktPub'dan çıkan kitaplarım: Laravel Application Development Blueprints, Laravel Design Patterns & Best Practices.
Türkçe çıkan kitabım: Raspberry Pi

Çevrimdışı

#11 27.12.2016 19:15:45

Çevrimdışı

Forum alt kısmı