[PHP] DOMDocument Sınıfının Desteklenmeyen Etiketlerde Hata Vermesinin Engellenmesi

Başlık pek bi' uzun oldu. Sorun ve çözümü pek kolay hâlbu ki.

DOMDocument sınıfını kullanırken veya kullanan bir dependency ile çalışırken uygun olmayan etiket hatası almanız gayet mümkün. Hele de şu vakitlerde Facebook gibi sosyal ağların semantik algılama için web sitelerine eklenmesini istediği W3 standartları dışında olan etiketlerden dolayı.

QueryPath kullanırken ben de aşağıdaki hatayı aldım. Ufak bir araştırma ile DOMDocument'in hata yakalama özelliğini pasif ederek uyarı vermemesni sağladım. Hatalardan kaçtığımdan değil; ancak bu sorunu aşmanın hatayı gözardı etmekten başka çaresi yok.

Warning: DOMDocument::loadHTML() [domdocument.loadhtml]: Tag fb:like invalid in Entity, line: 135 in /.../querypath/src/QueryPath/DOMQuery.php on line 3643

Çözümü şu şekilde yapabilirsiniz:

[Laravel] Denetim (Validation) Sınıfını AJAX ile Kullanmak

Server-side denetim işlemlerinin geçmişte kaldığını (kalması gerektiğini!) düşünüyorum. Daha iyi bir kullanıcı etkileşimi için de client-side yani sayfanın yenilenmeden onaylanması gerektiğini de...

Yanlız bu durumda bir sorun oluşmakta. Eğer sadece client-side denetim yaparsak yeterli bilgiye sahip kullanıcı bu denetimleri aşarak karşılaşmak istemediğimiz durumlar altına bizi sokabilir. Öyleyse klasik yoldan denetim yapıp bunu etkili bir biçimde kullanıcıya göstereceğiz, yani AJAX ile...

Vereceğim örneği hazırlığında bulunduğum basit bir destek sistemi üzerinden vereceğim. Böylelikle daha gerçek hayattan bir uygulama yapmış olacağız.

Laravel Artisan CLI'de php artisan controller:make TicketsController komutunu çalıştırarak bir resource controller oluşturuyoruz. işlerimiz bunun üzerinden yürüyecek.

Şimdi de Ticket ve TicketMessage adlarında iki adet birbirlerine one to many ilişkisiyle bağlı model oluşturacağız. Bunlar ./app/models klasöründe bulunmalı. Bu arada tablo yapılarını vermiyorum. Zaten gerekli yapıyı siz tahmin ediyorsunuz. ;P



Modellerimiz de hazır olduğuna göre artık podyuma çıkılabilir! (Pek yersiz bir mizah oldu bu, kabul.) ./controllers/TicketController.php'yi açıyoruz. Oradaki store metodu dışındakiler şimdilik bizi ilgilendirmiyor. store metodunda create metodunda verileri denetleyip, duruma göre AJAX ile cevap vereceğiz duruma göre veri kaydedip index metoduna göndereceğiz sayfayı. store metodununun içeriği şöyle:


Şimdi de AJAX iletişimini sağlayan JavaScript kodlarımızı verelim:

Bunun haricinde view'ları vermiyorum. Verilmek istenen mesaj ile alakalı olmadığından dolayı. view'lar tasarrımınıza göre özel olarak hazırlanmalıdır.

Kaynaklar

http://stackoverflow.com/questions/17097797/validation-errors-in-ajax-mode

[Laravel] Validatörde reCAPTCHA Doğrulaması

Biraz uzun bir başlık oldu. Umarım bu uzun başlığın hakkını verebiliriz:

Öncelikle doğrulaması yapacağımız API'yle iletişim için ben cURL-Easy adında bir wrapper kullandım. --Tavsiye ederim.-- Laravel'e eklemek için aşağıdaki packeti composer.json dosyanızda tanımlayıp "composer update" komutunu CLI'dan çalıştırın:

./app/filters.php dosyasında uygulamanın başlatıldığı zamanı temsil eden App:before filtresinde Validator'ü genişleterek "recaptcha" adında bir rulea sahip oluyoruz.

Bu işlemden sonra ./app/en/validation.php'de uygun bir yerde hata mesajının tanımlanması gerekli:
Artık reCAPTCHA doğrulamalarını "recaptcha" adındaki ruleınızla kolayca yapabilirsiniz.

Blogger/Blogspot Dinamik Gösterim Sayfalarında GitHub Gist Embed Kullanımı

Blogger "dynamic view" tasarımları gerçekten çok albenili. Ancak kod paylaşımları için kullanılan GitHub Gistleri desteklemyor. Bunun için de bir bir proje geliştirilmiş. Projeye ait repositorye gitmek için tıklayın. Kullanım Bu kodu Gist eklemek istediğiniz yazıların en sonuna editörü HTML moduna geçirerek ekleyin:

Loading ....

Sonrasında da aşağıdaki kodu Gisti göstermek istediğiniz noktada yine editörünüz HTML modundayken kendi Gistinizin ID'sini yazarak yazıyı kayıt edin:

Loading ....

Tabii unutmadan şuan burada da kullandığım gibi eğer Gist içerisindeki sadece bir tane dosyayı göstermek isiyorsanız data-file "attribute"ini kullanmalısınız:

Loading ....

Continuous Integration (Sürekli Entegrasyon) Nedir? Travis-CI Nedir?

Continuous Integration (Sürekli Entegrasyon) yaklaşımı birlikte kullanılan VCS ile yapılan her commit-push işleminden sonra kaynak kodu derleyipi testlerini çalıştırıp yapılan son değişikliklerin projenin sağlık durumuna etkisini görmemizi sağlar. Buradaki ilk akla gelen soru şüphesiz "Projeyi biz derleyemiyormuyuz? / Testlerini çalıştıramıyor muyuz?" Sorunun cevabı, evet. Fakat bir projenin derlenişinin (alışık olmayarak masaüstü yazılımdan bahsediyoruz) ve test edilişinin onu beklerken bize ne kadar vakit kaybettireceğini biliyor muyuz? Continuous Integration'a ihtiyacımız işte tam bu noktada oluyor.

Kullanılan Continuous Integration servisi, asenkron (bizden bağımsız) olarak son commit-push ile beraber projeyi derliyor ve testleri gerçekleştirip bize sonucu belirtiyor, biz de hatrı sayılır bir zamanı ilerleme çubuğunun karşısında geçirmiyoruz.

---

Gel gelelim, Travis-CI.org servisine. Travis-CI servisi açık kaynak uygulamalar için Continuous Integration hizmeti vermektedir. GitHub'la eşsiz etkileşmiyle; GitHub'da bulunan repositorylerimizi otomatik algılayıp kurulum aşamasını da kısaltmaktadır. Birçok dili desteklemesi de birçok community tarafından kullanılmasının sebei olmuştur. An itibariyle şu dilleri desteklemekte: Clojure, PHP, Java, Node.js (JavaScript), Ruby, Python, Objective-C, Scala, Go, Perl.

Şimdilik kullanım hakkında detaylar veremeyeceğim. İlerleyen zamanlar için ayrı bir blog konusu olarak akılda kalmalı.

Kaynaklar
http://www.serdardemir.net/continuous-integration-nedir.html
http://net.tutsplus.com/tutorials/tools-and-tips/travis-ci-what-why-how/

Singleton (Tekil Nesne) Tasarım Deseni

Merhabalar,

Bugün en bilinen ve ihtiyaç duyulan 'Tasarım Desenleri'nden biri olan Singleton'u inceleyeceğiz/öğreneceğiz.

Öncelikle, Singleton için Türkçye'ye iyi bir karşılık arayışdaydım. Biraz Googling'ten sonra bu desene kendi çapımda 'Issız Nesne' olarak adlandırmayı uygun gördüm. Fark ettiğiniz üzere bu karşılık Çağan Irmak imzalı 'Issız Adam' filminden gelmekte. Belki de Singleton için daha fazla açıklamaya gerek kalmamıştır, bu benzetmeden sonra. ;P

Olay: Singleton 'Tasarım Deseni' ile hazırladığımız sınıftan sadece bir tane 'örnek' (instance) oluşturmamızı, ve buna her yerden erişebilmemizi sağlar.
Neden: Tamamiyle OOP tabanlı bir proje üzerinde çalıştığınızı düşünün. Bu projeyi elbetteki bazı yönetici sınıflarınız da olacaktır. Örnek vermek gerekirse, uygulamanızda tek bir Database sınıfının varlığı kaçınılmazdır. İşte bu noktada bir uygulamada Database sınıfından kaç tane 'örnek'e (instance) ihtiyacımız olacaktır? Cevap sırıtmakta, sadece bir!

PHP ile Singleton çalışması:

Loading ....

PHP5.4 ile birlikte "traits" denen bir özellik eklendi. Bu traitler dediğimiz özellik, belirteceğimiz property (özellik) ve methodlarının (metot) traiti kullanacağımız sınafa göre şekillenmesi amacıyla eklendi. Aslında bu ayrı bir yazı konusu olurdu. Ancak basit anlamda anlatmak için yeterli cümleleri kurduğuma inanıyorum. Şimdi yapacağımız şey ise traitleri kullanarak Singleton tasarım desenini tüm sınıflarımızda kullanabilmek. Bu sayede DRY (Don't Repeat Yourself) ilkesini de gerçekleştirmiş olacağız. Kalıtım'ın (Inheritance) da dibine vurduğumuz söylenebilir.

Loading ....

JavaScript ile Singleton çalışması:

Loading ....

Java ile Singleton çalışması:

Loading ....

Ruby ile Singleton çalışması:

Loading ....

Git "Signed-off" Nedir?

Büyük çaplı açık kaynak projelerde ana repoya pushlanan o kadar commit bulunmasından dolayı, commitin kime ait olduğunun bilinemesi için bir ihtiyaç olarak çıkmış, commit mesajınızın sonuna "Signed-off-by: xxx <xxx@xxx.xxx>" satırına Signed-off (satırı) denir.

Günümüzde Git "incelemelerini" GitHub, BitBucket gibi web servislerinden karşıladığımızdan dolayı (CLI'ya saygımız sonsuz!), açıkçası Signed-off satırını gerekli bulmuyorum. Ancak geleneklere sağdık kalmakta ısrarcı projelerde Signed-off (satırı) eklenmesi isteniyor. Bu son derece basit. Commit komutuna --signoff parametresi eklenmesi yeterli oluyor. Tabii isim ve mail adresinizin "global" olarak ayarlanmış olması gerekli.

Paragraf Soruları Nasıl Çözülür?

FEM'in bu yaklaşımı gayet mantıklı geldi.

Post by FEM.

Git 'Fork'umuzu Ana Repo ile Güncel Tutmak

Merhaba,

Git'in "dağıtık" yapısı her ne kadar güzel işlere yarasa da bir problem de oluşturmuyor değil.

Çok büyük bir komüniteye sahip bir projede çalıştığınızı (örneğin ben SMF için kod yazıyorum) düşünün. Siz kendi forkunuzda bir şeyler yaparken ana repoda dönen taklalardan bir haber olak istemezsiniz. Kendi forkunuzu ana repoyla arada eşleştirmek gerekir. Bu yazının ana fikri de budur.

CLI'dan $ git remote -v komutunu çalıştırdğımızda bize aşağıdaki gibi, projemizin uzak kaynakları (remotes) verilecektir:

origin https://github.com/user/repo.git (fetch)
origin https://github.com/user/repo.git (push)

Bizim buraya ana repoyu eklememiz da gerekli -ki oradan güncel verileri alabilelim. Bunu aşağıdaki git komutu ile yapıyoruz:

$ git remote add upstream https://github.com/anaUser/anaRepo.git

Şimdi $ git remote -v komutunu çalıştırdığımızda 'upstream' isminde ana repoya ait uzak kaynak (remote) eklenmiş olarak görünmeli:

origin    https://github.com/user/repo.git (fetch)
origin    https://github.com/user/repo.git (push)
upstream  https://github.com/anaUser/anaRepo.git (fetch)
upstream  https://github.com/anaUser/anaRepo.git (push)

Harika! Şimdi yapılacak işlem, 'upstream'den değişiklikleri öğrenip kendi forkumuza uygulamak:

# 'upstream'den değişiklikleri çektik:
$ git fetch upstream 

# Kendi forkumuza uyguladık:
$ git merge upstream/master

Bu kadar.

---

Bunu sadece ana repo için uygulamak zorunda değilsiniz. Diğer kullanıcıların forklarından da bu adımlarla değişiklikleri kendi forkunuza alabilirsiniz.

Kaynaklar
https://help.github.com/articles/syncing-a-fork
http://bradlyfeeley.com/2008/09/03/update-a-github-fork-from-the-original-repo/

Tasarım Desenleri Serüvenleri

Merhabalar,

'Tasarım Desenleri' konulu uzun süreli bir serüven yaşayacağız. Bu serüvende bizi yanlız bırakmayacak değerli dostlarımız PHP, Java, JavaScript ve Ruby dilleri olacaktır. 4 dili birden kullanmamızın tabii ki bir sebebi var: Dil yeteneklerimizi geliştirebilmek.

 'Tasarım Desenleri'ni tam anlamıyla kavrayabilmek amaçlı bir serüven olacak bu. Serüvenlerimizde olabildiğinde güncel yaşamda karşımıza çıkabilecek örnekler kullanıp öğrenme eğirimizi minimuma düşürmeye çalışacağız.

Öğreneceğimiz 'Tasarım Desenleri'ni kavramamıza yardımcı olacak UML diagramlarından da yararlanacağız tabii. Bu nedenle UML'ler hakkında en azından başlangıç seviyesinde bir bilgi edinmeniz önerilir.

Eğer 'Tasarım Desenleri' konusunda 'Nedir?' sorusu ile başlayayacaksanız sizi buradan Wikipedia sayfasına alalım.

Serüvenler:

Kurucu Tasarım Desenleri (Creational Design Patterns)

• Abstract Factory
• Builder
• Factory
• Prototype
• Singleton

Yapısal Tasarım Desenleri (Structural Design Patterns)

• Adapter
• Bridge
• Composite
• Decorator
• Facade
• Flyweight
• Proxy

Davranışsal Tasarım Desenleri (Behavioral Design Patterns)

• Chain of responsibility
• Command
• Interpreter
• Iterator
• Mediator
• Memento
• Observer
• State
• Strategy
• Template
• Visitor

Merhaba Dünya!

Merhaba! Ben, Berat Doğan. PHP ağırlıklı olmakla birlikte "Yazılım Geliştiricliği" ile uğraşıyorum.

Bu blog ise mesleki tecrübeleri ve kişisel düşünceleri Dünya'ya sunmak sebebiyle açıldı. Yakında tekrar görüşmek üzere!