Kategori arşivi: Yazılım & İnternet

Yazılımla ilgili bilgiler falanlar filanlar

PHP7 ve pear paketi

PHP7 kullanmaya karar verdiğinizde pear kurulumunda sıkıntı yaşabilirsiniz. Normalde kurulumu dotdeb repolarındaki php-pear paketiyle yapıyordum ama php7 kullandığımda bazı sorunlarla karşılaştım.

Örneğin şöyle bir hatayla karşılaşmanız mümkün:

[email protected]:~$ pear
PHP Parse error:  syntax error, unexpected ‘new’ (T_NEW) in /usr/share/php/PEAR/Frontend.php on line 91

Bunun sebebi, yüklenen php-pear paketinin PHP4-5 için olması ve deprecated özellik içermesi. Satır 91 e baktığımızda

$obj = &new $uiclass;

Bir objenin referans olarak türetildiğini görüyoruz ki bunun ne için kullanıldığını pek anlamadım. Kısa bir araştırmayla 5.3 sürümünde deprecated özellikler arasına girdiğini gördüm: http://php.net/manual/tr/migration53.deprecated.php

Çözüm:

Pear paketini phar ile yüklemek. Güncel paket adresi işe şu şekilde: http://pear.php.net/go-pear.phar

İndirdiğiniz dosyayı “php go-pear.phar” komutuyla çalıştırın. Kurulum için bir iki soru soracak ve sisteminizde pear komutunu artık kullanabileceksiniz.

Ansible için görev komutu da yazdım, sizlerle paylaşayım.

tasks:
– name: “Download latest php-pear installer to /tmp”
get_url: url=http://pear.php.net/go-pear.phar dest=/tmp/go-pear.phar mode=0740

 

– name: “Copy go-pear installer script”
template: src=install-pear.expect
dest=/tmp/install-pear.expect
force=yes

 

– name: “eecute install-pear.expect script”
command: /tmp/install-pear.expect

 

install-pear.expect

#!/usr/bin/expect

spawn php /tmp/go-pear.phar

expect “1-11, ‘all’ or Enter to continue:”
send “r”
expect eof

spawn rm /tmp/go-pear.phar

LetsEncrypt ile sitelerinize ssl yükleyin

SSL YÜKLEYİN! Ssl önemlidir arkadaşlar. Sizinle sunucu arasındaki trafiği şifreler. Ki bu da çok önemli birşeydir. Baya önemli ama.

Yıllar öncesinde ssl oldukça pahalı bir üründü. Ve anlaması güçtü. Belki de sadece benim için böyleydi bilmiyorum :) Fakat bugün günümüzde ssl kurulumu 2-3 tıklamaya kadar düştü. Bu yüzden ssl yüklemeyi ihmal etmeyin. Kişisel bloga da ssl mi yüklenirmiş demeyin, yükleyin.

Ve artık bunun için LetsEncrypt kullanabilirsiniz. Tamamen ücretsiz.

Nasıl?

Ssh bağlantımızı yapalım ve ilk önce LetsEncrypt dosyalarını sistemimize yükleyip letsencrypt klasörüne geçelim.

git clone https://github.com/letsencrypt/letsencrypt && cd letsencrypt

Aşağıdaki komutu çalıştırarak LetsEncrypt için gerekli dosyaların sisteme yüklenmesini sağlayalım.

./letsencrypt-auto –help

Eğer LetsEncrypt komut listesini görüyorsanız kurulum başarıyla tamamlanmış demektir. Eğer göremiyorsanız bir sorun var demektir. Ki ne olduğunu bilmiyorum.

Sertifika Oluşturma

Sertifika oluşturma için birden fazla yöntem mevcut. Hatta sertifikanın oluşturulup apache ve nginx için konfigürasyonların otomatik yapıldığını söyleyen bazı komutlar da var. Ancak ben otomatik konfigürasyon yapanı henüz beceremedim. Bu yüzden size kendi kullandığım komutu göstereceğim:

./letsencrypt-auto certonly –webroot –webroot-path /var/www/site.tld/web/public –email [email protected] –agree-tos –renew-by-default –text -d site.tld

Bu komut webroot yöntemiyle yalnızca sertifika dosyalarını oluşturuyor. Webroot yönteminde site doğrulaması letsencrypt’in otomatik oluşturup doğrulama yaptığı bir yöntemdir. –webroot-path ile tanımladığınız klasöre bir doğrulama dosyası oluşturur. Daha sonra bu dosyanın http://site.tld/olusturulandosya şeklinde kontrolü yapılır LetsEncrypt tarafından. Eğer dosyaya erişim sağlanamazsa sertifika dosyaları oluşmaz. (Zaten LetsEncrypt Domain Validation Ssl oluşturur. Yani domain doğrulama sertifikası)

–agree-tos komutu, kullanım şartlarını otomatik kabul etmenizi sağlar. –renew-by-default ise 1 yıl sonra otomatik yenilenmesini sağlar. Ya da öyle olmasını umut ediyoruz.

Eğer herşey yolunda giderse “Congratulations! Your certificate and chain have been saved at /etc/letsencrypt/live/site.tld/fullchain.pem.” şeklinde bir mesajla karşılaşırsınız. Yani artık sertifika dosyalarınız kullanıma hazırdır. Peki nasıl kullanacaksınız?

Nginx

Ssl anahtarlarınızı vhost dosyanızda tanımlamanız gerekiyor. /etc/nginx/sites-available/site.tld dosyanızı favori editörünüz ile açın. Eğer dosyanız bu değilse, vhost dosyanızı bulun!

Şu 3 satırı uygun olduğunu düşündüğünüz bir yere ekleyin.

listen 443 ssl;
ssl_certificate    /etc/letsencrypt/live/site.tld/cert.pem;
ssl_certificate_key    /etc/letsencrypt/live/site.tld/privkey.pem;

Son olarak nginx servisini reload etmeyi unutmayın. Eğer reload ederken bir hata almazsanız, sitenizi https:// ile kullanabilirsiniz demektir. İnternetteki örneklerle vhosts dosyanızı oluşturduğunuz varsayarsak, vhost dosyanız en son eklemeden sonra şunun gibi görünecektir: https://gist.github.com/shibby/450e32d7a5a2ef86904d

Apache2

Hiç bir fikrim yok nasıl ekleneceğine dair. LetsEncrypt’in apache için default gelen modülünü kullanmayı deneyin. Başarırsanız bana da öğretin.

  • LetsEncrypt Resmi Web Sitesi: https://letsencrypt.org/
  • LetsEncrypt Github Sayfası: https://github.com/letsencrypt/letsencrypt
  • EFF’ye bağış yapın! https://supporters.eff.org/donate

 

Karşılaştığım sorunlar:

Kurulum esnasında hata alıyorsak ve bu hata içerisinde “Cannot allocate memory” gibi bir şey geçiyorsa (python paketleri yüklerken), sunucunun ram’i yetmiyor demektir. Ama ram arttırmadan önce swap var mı bir kontrol edin. Eğer swap yoksa çok kolay bir biçimde dosya-swap eklemesi yapabilirsiniz: http://www.cyberciti.biz/faq/linux-add-a-swap-file-howto/

Ali’ye cevaben: Neden Laravel kullanıyorum?

Ali Gündoğdu, Neden Laravel Kullanmıyorum başlıklı bir yazı yayınlamış. Çok fazla yazacak şey bulamıyorum, fırsat bulmuşken bir yazayım dedim. Hem Laravel kullandığım için söz hakkı düştüğünü düşündün hem de polemik olsun dedim. Gerçi burada Laravel’i düşündüğünüz kadar savunmayacağım.

PHP’de aşağı yukarı herkesin hikayesi aynıdır. Önce fonksiyonlar.php dosyası vardır, sonra sınıf kavramıyla tanışılır. Bir klasör içerisinde resim yükleme, form doğrulama, veritabanı, email gönderme, belki smarty gibi bir template motoru vardır ve artık bunları kullanmaya başlarız. Tebrikler, kendi frameworkümüzü yapmayı başardık :)

Zaman geçtikçe bu bize yetmez. Gerek yapmaya başladığımız projeler büyür, gerek bizim ufkumuz genişler. Adım adım, büyürüz ve gerçek bir framework ile tanışırız. (Bu arada direkt büyük projenin içine düşen ya da araştırmacı ruhuyla programlamaya düzgün başlayan bazı şanslı veletler vardır, onlara dicek söz yok. Döngüyü bozdunuz ulan!)

Mesela ben bu frameworklerden ilk olarak Yii ile tanıştım (ismen tanıştık). Bir yazılımcı abimiz; böyle böyle bişey var, süper, şunu yapıyo, bunu yapıyo gibi şeyler söyleyince neymiş la bu bir bakayım dedim. Baktım ve hiç bir şey anlamadım. Bana bir kaç gömlek üstün geldi. Çünkü framework nedir bilmiyorken direkt Yii ile başlamak, ağır bir model kavramı ile tanışmak zordu. Gel zaman git zaman, rahmetli Codeigniter abimiz ile tanıştım. CI’yi öğrenmem yaklaşık 1 günümü aldı. Çünkü gerçekten çok basit bir dökümantasyonu vardı. “+Ne yapmak istiyorsun? -Resim yükleyeceğim. +Buyur, bu şekilde yapabilirsin” gibi net cevaplar içeren bir dökümantasyon. Düşünmene gerek yok, fazla araştırmana gerek yok. Copy-paste yeterli :) Neyse, CI beni uzun bir süre götürdü. Ben bunu baya baya kullandım.

Gün geldi, ihtiyaçlar büyüdü. CI’nin geliştirmesi durduruldu, zaten sürekli $this-> yazmaktan kollarım yoruldu. Daha sonra Ali’yle bir projeye başladık. Çok şükür, CI’nin adı bile geçmedi projede. En azından o bilinç varmış. Ali’nin yazısında bahsettiği, Symfony/Silex, ZF1, Doctrine içeren yapıyı kullanmaya başladık. Ne de iyi yapmışız!

Peki Laravel bu yazının neresinde? Başlayalım Laravel kısmına. Kendi yönettiğin projelerde belki kendine has bir yapı kullanmak güzel, fakat ileride projeyi devretmen gerekirse ya da projeye birilerini dahil etmen gerekirse sıkıntı yaşayabilirsin. Bunun temel sebebi dökümantasyondur. Ne nasıl yapılırın cevabını iyi vermen gerekiyor. Bunun için eğer kendi yapını kullanacaksan, en başından itibaren sürekli dökümantasyon yazman gerekiyor. Kod yorumlarından bahsetmiyorum, bildiğin framework dökümantasyonu gibi yazman gerekiyor. Burada bir parantez açıyorum. Kullandığınız her parçanın bir dökümantasyonu var. Her biri süper dökümantasyon olsa da sizin yapınızda bir bütün oluşturmayacak. Sizin yazdığınız dökümantasyonda bu parçaları birleştirmeniz gerekiyor.

Laravel’in dökümantasyonu, öğrenme açısından oldukça iyi hazırlanmış durumda. Tam benim gibi üşengeç, dummy(bu tam olarak ne demek bilmiyorum, havalı durur diye düşündüm) tiplere hitap ediyor. Öğrenmesi kolay, geliştirme yapması hızlı. Ama burada, Ali’nin bahsettiği, geriye dönük dökümantasyon sorunu ortaya çıkıyor. Bugün 5 sürümü hazırlanan Laravel için 1 yıl sonra 4 sürümüne ait dökümantasyona erişebilecek miyiz ve tüm talepleri karşılayabilecek mi? Evet, versiyonlama sistemi başlı başına sıkıntılı. Ben belki de bu geriye dönük dökümantasyonu ve versiyonlamayı göz ardı ederek bir hata yapıyorum ama burada tercih ettiğim şey hızlı öğrenme süreci. Hızlı öğrenme süreci sayesinde hem projeyi daha hızlı gerçekleştirebilir hem de gelecekte birisinin projeye dahil olması durumunda adaptasyon kolay olur ki zaten bugün elini sallasan Laravel bilen birine çarpıyor. (Eskiden CI öyleydi :))

Bu konudaki sorulması gereken soru şu: Kullandığın frameworkün geriye dönük desteğinin kısıtlı olmasına ne kadar tölerans gösterebilirsin?

Diğer bir noktadan, “kendi yapını oluşturmak” bir takım sıkıntıları daha doğuruyor. Bunlardan ilki dökümantasyondu. İkinci problem ise, her ne kadar güçlü frameworkleri arkana alsan da, sen gerek mimari açıdan gerekse pratik açıdan doğru bir yapı kurabiliyor musun? Örneğin ben bunu kesinlikle göze alamıyorum. Tek başıma girdiğim bir projede artık kendi yapımı kullanamam. Çünkü bunu oluşturabilecek kadar yeterli teknik bilgiye sahip değilim. Hatta şöyle diyelim, eskisi kadar cahil değilim, bu yüzden kendi yapımı oluşturamam :) Ama 2-3 kişi olursun, herkes belli bir bilgi birikimine sahiptir, o zaman kendi yapını kurma girişimlerine başlayabilirsin. Gerek doğru/en iyi mimariyi kurabilmek, gerek hataların takibini yapabilmek ve sorunları çözebilmek, gerek ne bileyim başka şeyler için bir ekip olmak bu konuda çok işe yarayacaktır. Ki biz Ali ile kendi yapımızı kullanalım dediğimizde sadece ikimiz oluşturmadık bunu. Dışarıdan arkadaşlar da buna gerek fikir gerek kod anlamında katkıda bulundu ve hala daha geliştirmeye devam ediyoruz. (Geliştirmeden kasıt, örneğin composer ile yeni araçlar ekliyoruz, değiştiriyoruz. Ya da klasör yapımızda değişiklikler yapıyoruz. Kendimiz için en mükemmel yapıyı oluşturmaya çalışıyoruz)

Peki ya Laravel’de Taylor’un tek adamcılığı? Biz bu tabloya ülkemizden alışığız, o yüzden beni çok rahatsız etmedi, desem yanlış olur. Ama Laravel üzerindeki tartışılması gereken en büyük konu bu değil. Zira, Laravel bir özgür yazılım. İsteyen aynı kodlardan Paraver adında bir framework yapar. (Gerçi MIT lisans bu kadar özgür mü bilmiyorum, birisi aydınlatırsa çok sevinirim.) Neyse, aslında demek istediğim bu değildi ama demiş bulundum. Şunu diyecektim; Laravel üzerindeki tüm kararları tek bir kişi versin. Belki bu kullanmamak için bir sebep olabilir. Ama bunun kilit bir şey olduğunu düşünmüyorum. Bununla birlikte Ali’nin yazısında Ubuntu’nun pencere kapatma butonlarını topluluk ısrarlarına rağmen solda tutmasına atıfta bulunularak bir kıyaslama yapılmış. Ben bir Ubuntu kullanıcısıyım. Bazı dayatmalarından, hatta spyware’a varan uygulamalarından rahatsızım. Ubuntu’dan daha iyisi var. Arch linux. Ama sırf kurulumu bile ömrümden ömür çalıyor. Ki daha hiç kuramadım (çok uğraşmadım). Ubuntu(Canonical) her ne kadar saçma sapan kararlar verse de, bu onu kullanmayacağım anlamına gelmiyor. Bir gün çizmeyi aşar, o zaman bırakır ve ona en yakın dağıtıma geçerim. (Gerçi spyware a doğru yol alması çizmeyi aştığını göstermez mi?) Örneğin Mint. Ubuntu’nun tüm paketlerini destekliyor. Demek istediğim de bu, Laravel konusunda tek adamcılık en büyük sorun değil. Bugün böyle bir sıkıntı varsa, yarın başka birisi Laravel ile %100 uyumlu başka bir framework çıkartır, oradan yürünür. Bu konudaki özet ise şu; Laravel’i seven Taylor Otwell ile sevsin. Sevmeyen de sevmesin.

Ali’nin yazısına büyük çoğunlukla yanıt vermekle birlikte neden Laravel kullandığımı özetlemeye çalıştım. Belki söyleyecek daha çok şey var ama uzadıkça uzayacak gibi duruyor. En iyisi burada bırakmak. Son olarak şunu söylemek istiyorum; Laravel’i “mükemmel” olduğu için kullanmıyorum. Zaten mükemmel de değil. Kullanma sebebim, kurması, geliştirme yapması, öğrenmesi hızlı olması. Bazen kararlılığa bakarsınız, bazen hıza bakarsınız. (Mesela telefonumda stabil olan Samsung firmwarelerini kullanmak yerine Cyanogen modun, telefonum için unofficial modunu kullanıyorum. Cyanogen mod bile unofficial iken ben onun unofficial sürümünü kullanıyorum düşünün :))

Dipnotlar:

* Kendi yapın dediğimiz kavramı biraz açmak gerekli. Burada kastedilen şey “kendi framework”ün değil. Belli başlı frameworkleri arkana alıyorsun, belki sadece beğendiğin kısımlarını alıyorsun ve kendine göre onları kullanıyorsun. Ama burada yine kafana göre bir kullanma geliştirmiyorsun. Bu konuda dahi belli başlı standartlar, teknik konular var. Belki dizin yapın farklı olur, belki config dosyaların ve kullanımın farklı olur. Ama en nihayetinde temelde hepsi aynıdır.

* Kendi yapınızı oluşturma konusunda şu kaynak oldukça fayda sağlayacaktır: https://github.com/fabpot/Create-Your-Framework

Owncloud ve Youtube-dl

Uzunca bir zamandır (8-9 ay gibi bir süre) Google Drive, Dropbox vb. gibi hizmetler yerine kendi sunucumda kurduğum OwnCloud‘u kullanıyorum. Eksileri/artıları nelerdir, neden kullanıyorsun gibi sorulara kısaca, gerek gizlilik gerekse geliştirilebilirlik açısından bu yazılımı tercih etmeye karar aldım diyebilirim. Elbette daha bir çok nokta var.

Owncloud’u kurduğumda kendim için bir Youtube Downloader eklentisi yapmıştım. Belki bu tarz birşey yapmak isteyen olur diye fikir vermesi açısından Github‘a kodları yüklemiştim. Eklenti verilen Youtube linkini downloader ediyor, eğer istersem ogg formatına çeviriyordu. Şimdi eklentiyi geliştirdim ve tüm OwnCloud kullanıcılarının basitçe yükleyebileceği bir forma soktum. Çok ahım şahım bir kod yok üzerinde. Github adresinden kodları inceleyebilir, Owncloud sunucunuza kurup geribildirimde bulunabilirsiniz.

https://github.com/shibby/owncloud-youtubedl

Kafa patlatmak isteyenlere: Mesajlaşma/Sohbet sistemi yapısı

Yazılımını geliştirdiğim bir web sitesinde üyeler arası mesajlaşma sistemine ihtiyaç duyuldu. Bunun üzerine ben de biraz araştırma yaparak biraz da kendim birşeyler katarak bir yapı oluşturdum. Yapı “conversation” modeli üzerinde çalışıyor. Yani iki kullanıcı arasında bir mesajlaşma olduğu anda bu iki kullanıcının üyesi olduğu bir konuşma(conversation) kaydı yapılıyor. Gönderilen mesaj ise doğrudan üyeye değil bu konuşma kaydına gönderiliyor. Teknik olarak baktığımızda, her ne kadar ihtiyaç olmasa da, bir konuşmaya birden fazla kişi katılabilir. Yani Facebook mantığıyla bir mesajlaşma sistemi olmuş oluyor.

Bu yazıyı yazma sebebim, sizlerden de fikir alarak sistemi iyileştirmek ve problemli kısımlarını gidermek. Sql şeması ve use-case gibi şeyleri oluşturmada çok iyi değilim. O yüzden düz metin olarak bilgileri paylaşacağım.

1- Veritabanı tablo kayıtları ve kullanım amaçları
Veritabanı olarak Mysql, programlama dili olarak Php kullanılmaktadır.

Tablo1: konusmalar
Kullanım amacı:
Mesajlaşma aksiyonunu gerçekleştiren 2 üye için bir kayıt oluşturulur.
Sütunlar:

  • id: auto increment, primary alan.
  • uniq: Konuşmanın benzersiz anahtarıdır. Bir kişi ile olan geçmiş sohbeti görüntülerken mesajlar bu uniq değerine göre getirilir.
  • lastupdate: datetime formatında, konuşmanın son güncellenme tarihi-saatidir.
  • lastmsg: son mesajı gönderen kullanının id değeridir.

Tablo2: konusmalar_uyeler
Kullanım amacı:
Konusmalar tablosunda oluşturulan bir kayda hangi üyelerin dahil olduğunu belirten tablodur.
Sütunlar:

  • id: auto increment, primary alan.
  • user: Dahil olan üyenin id değeri.
  • konusmaid: Konuşmalar tablosundaki ilgili id değeri. (konusmalar.id)
    (Burayı neden id yaptım bilmiyorum. uniq değerine göre de eşleştirme yapılabilirmiş halbuki.

Tablo3: konusmalar_mesajlar
Kullanım amacı:
Bir konuşmaya aitmesajların kaydedildiği tablodur.
Sütunlar:

  • user: Mesajı gönderen kullanınıcın id değeri.
  • mesaj: Kullanıcının yazdığı text mesaj.
  • konusmaid: Bu mesajın hangi konuşmaya ait olduğu ile ilgili alan. (konusmalar.id)
  • deleted: Bu mesajı hangi kullanıcıların sildiği bilgisi. (Bu sütun Problemler başlığında irdelenecek)

2-) Kısaca mesaj gönderme işlemi

  • Kullanıcı mesajını ilgili kişinin profiline girerek ya da konuşma penceresinden gönderebilir.
  • Mesajını gönderdiği anda arkaplanda şu işlemler gerçekleştirilir
    1. İki kullanıcı arasında daha önce bir konuşma gerçekleşmiş mi konusmalar_uyeler tablosu ile kontrol edilir. Eğer gerçekleşmemişse, konusmalar tablosuna yeni bir kayıt eklenir. Eğer gerçekleştirilmişse, konusmalar tablosundaki ilgili kayıt alınır.
    2. Gönderilen mesaj konusmalar_mesajlar tablosuna, ilgili konusmaid ile kayıt edilir.
    3. konusmalar tablosundaki ilgili satırın lastupdate ve lastmsg alanları güncellenir.
    4. Mesaj gönderilen kişiye bildirim yapılır. (Eğer kişi konuşmayı görüntüledikten sonra mesaj alırsa kendisini bir bildirim yapılır. Bunun kontrolü konusmalar_notify ile yapılıyor fakat asıl konu bu olmadığı için dahil etmedim)

3-) Konuşma görüntüleme işlemi

  • Üye kişisi, şu şekilde bir link açar: site.com/mesaj/oku/konusmauniqdegeri
  • Arkaplanda, ilgili konuşma uniq değerine ait bütün mesajlar listelenir. (Aslında bütün mesajlar görüntülenmez. “Daha fazlasını yükle” şeklinde pagination mevcut. Bununla birlikte sildiği mesajlar da görüntülenmez.)

4-) Mesajlar sayfası

Bu sayfada kişinin daha önce kimlerle mesajlaştığı listelenir. Teknik olarak konusmalar tablosundaki üyesi olduğu konuşmalar listelenir. Bu sql sorgusundan, her bir kayıt için konuşmanın kiminle olduğu(user details) ve son gönderilen mesaj döner.

5-) Problem: Mesaj silme

Bir kullanıcı, bir mesajı sildiğinde, ilkel bir içimde ilgili mesajın konusmalar_mesajlar.deleted sütununa silen üyenin id değeri eklenir. Silme kaydı json_encode ile eklenir. Yani geri dönüştürdüğümüzde silen üyelerin id değerlerini içeren bir array elde ederiz.

Ancak konuşmanın içeriğini listelerken, sql sorgusuna şu şekilde bir where değeri ekliyoruz:
konusmalar_mesajlar.delete NOT LIKE ‘%uyeniniddegeri%’
(Burada olası id değeri çakışması basit bir iki trick ile halledilmiş durumda. Sonuçta standart bir array şu şekilde kaydediliyor:[1,3])

Bir veritabanı uzmanı değilim ama NOT LIKE gibi bir sorgunun üstelik wildcard kullanılmış halinin ne kadar performans açısından sıkıntılı olabileceğini tahmin ediyorum. Belki de çok sıkıntılı değildir bilmiyorum ama içime sinmedi bir türlü.

Keza, mesaj silmek için değil, tüm konuşmayı silmek için, konuşmaya tüm mesajların deleted sütununu güncelliyorum. Bu da tüm konuşmaları listelerken problem yaratıyor. Çünkü bir kişiyle konuşma var fakat içi boş şeklinde dönüşü oluyor. Bu yüzden tüm mesajları görüntülerken içinin dolu olup olmadığı kontrolünü ekstradan yapıyorum.

Çözüm üfürmesi: Her bir mesaj için tek satır kaydediyorum. Peki o satırı üye olan herkes için kayıt etsem nasıl olur? Yani aynı mesajı hem a hem b kullanıcısı için kaydetsem. Böylece biri mesajı sildiğinde sadece kendine ait kaydı siler (Fiziken veya bir işaret ile). Eğer fiziken silmezsem konuşmaya ait mesajlar listelenirken mesajın silinip silinmediğini NOT LIKE ile değil != ile kontrol ederim. Ayrıca bir konuşmanın içinin dolu olup olmadığı daha basit bir şekilde kontrol edilmiş olunur.

Belki iki kişilik konuşmalarda bu çözüm kullanılabilir. Her ne kadar grup konuşma olmayacak olsa da bu çözümün %100 doğru olduğunu düşünmüyorum. Ki, veritabanı konusunda uzman olmadığım için, hangi koşullarda satır sayısı çokluğu kabul edilebilir olur bilemeyeceğim. Belki binlerce satır yerine NOT LIKE daha avantajlı bir çözümdür.

6-) Sizden beklediğim

Ufak tefek başka problemleri olsa da şimdilik aklıma gelen kilit olaylar bunlar.Yapacağınız yorumlar için şimdiden teşekkür ediyorum. (Ya kimse yorum yapmazsa :/)

  • Sistemi varolan yapı ile inceleyip yorumlamanız öncelikli ricam. Dezavantajları neler olabilir? Geliştirmek için neler yapılabilir?
  • İkinci olarak mysql bu iş için ideal mi? Mysql ideal değil diyorsanız, aynı fonksiyonalitede yerine ne kullanabiliriz?
  • Mesajlaşma sistemini başka bir servisten satın alsam ne dersiniz? Daha önce böyle bir tecrübe yaşadınız mı? (www.cometchat.com/ facebook tarzı mesajlaşma stiliyle şu biraz kafama yatıyor. Ama %100 kontrol edemeyeceğim bir sistem. Örneğin offline mesaj göndermede notifikasyon işini nasıl çözeceğiz?)

İstihdam olmadan proje nasıl olur?

Günümüzde çeşitli bilişim firmaları “startup” kültürüyle yırtık dondan çıkar gibi piyasaya atılıyor. Bu firmaların yaptığı işlere baktığımızda sistem yöneticiliğinden, proje yöneticiliğine; neredeyse bsd dahil bilimum işletim sistemlerini kapsayan yazılım geliştiriciliğinden, tasarım hizmetlerine kadar bir çok alanda hizmet verdiklerini görüyoruz.

Bu da birşey mi? Kendi firmasında istihdam yaratmadan her biri ayrı uzmanlıklar gerektiren bu tarz alanlarda iş yapıp, piyasaya yazılımcı/tasarımcı ihracat eden firmalar bile mevcut.

Bir eleştiri yazısı gibi olcaktı fakat pek eleştirecek birşey bulamadım. Çünkü konu hakkında bilgi sahibi değilim. Küçük ölçekli (1-5 personel istihdam eden) bir firma nasıl oluyor da bilişim sektöründeki tüm konular ile ilgili hizmet verebiliyor? Nasıl oluyor da bünyesinde personel çalıştırmazken, başka firmalara İK danışmanlığı yapabiliyor? Ki bu firma sahipleri “Türkiye’de işin ehli personel yok yeaa” diyip bugüne kadar neden proje gerçekleştirmediklerini açıklıyorlar.

Biri bana açıklasın lütfen.

Php Java tabanlı bir dil mi?

İki kere bu tartışmaya denk geldim. İki kişi de “Php zaten Java tabanlı” cümlesini kurdu. Ben de ısrarla C tabanlı olduğunu söyledim. Tartışmalar esnasında internet yoktu, kaynak gösteremedim. Zaten daha önce C tabanlı olduğuna dair birşey okuduğumu hatırlamıyorum ama nedense böyle kalmış aklımda. Bunun başlıca nedeni, C ile PHP’nin fonksiyon benzerlikleri olabilir.

Herneyse, şimdi buna kaynak gösterebilmek açısından araştırma yaptım ancak tam olarak istediğime ulaşamadım. PHP’nin kaynak kodları arasında dahi gezindim :)

Wiki sayfasında ise (https://en.wikipedia.org/wiki/PHP) etkilendiği diller olarak; Perl, C, C++, Java, Tcl(Bu neyse artık) gösteriliyor. Yine aynı sayfada Türkçe karşılığını tam olarak bilmediğim ama sınıf yapılarında “implements” şeklinde kullandığım “Implementation language” olarak C gösteriliyor. Türkçe dökümanda Uygulama dili olarak çevrilmiş. Eğer Wikipedia’yı baz alırsak (ki alabiliriz), PHP’nin C tabanlı bir dil olduğunu söyleyebiliriz.

Hello everybody out there using minix -I’m doing a (free) operating system (just a hobby, won’t be big and
professional like gnu) for 386(486) AT clones.

Herhalde birisi bizim LKD listesine böyle bir mail atsa, maili gönderen kişi kimlik değiştirmek zorunda kalırdı. Gerçi dönemin şartlarında -egolarını bir kenara bıraktıktan sonra- çokta haksız sayılmaz LKD listesi üyeleri.

Aşağıdaki linkte Linux’un yaratıcısı Linus Torvalds’ın minix listesine gönderdiği Linux ile ilgili ilk maili görebilirsiniz. Mailde, hobi amaçlı ve gnu kadar profesyonel ve büyük bir şey olmayacak bir işletim sistemi yazıyorum diyor. Nereden bilebilirdi ki :)

https://groups.google.com/forum/#!msg/comp.os.minix/dlNtH7RRrGA/SwRavCzVE7gJ