Soner Gönül

Platon? un, tüm yazılım geliştiricilerin bilmesi gereken ve her zaman yanlarında taşımaları gereken bir sözü var;

Uyum, zarafet ve iyi bir ritim basitliğe bağlıdır.

Bu söz, bir cümle ile yazım geliştiricilerin neyi arzuladıklarını özetler niteliğinde.

 

Kodumuzun içinde dikkat etmemiz gereken birkaç konu var;

1. Okunabilirlik
2. Sürdürülebilirlik
3. Geliştirme Hızı
4. Güzelliğin nadide kalitesi

Platon, bütün bu nitelikleri sağlayanın basitlik olduğunu bize bildiriyor. Peki güzel kod ne demek? Bu aslında potansiyel olarak çok subjektif bir soru. Güzellik algısı çoğunlukla arka plan özelliklerine bağlıdır tıpkı algılarımızın çoğunun oluştuğu yer gibi. Sanat eğitimi alan kişilerin fizik eğitimi alan kişilere göre güzellik algısı her zaman daha farklı olmuştur. Bir sanatçı yazılıma baktığında bu çalışmanın içindeki sanat kavramına yakın olan şeyleri karşılaştırır, bir fizikçi ise baktığında simetri, altın oran gibi kavramları formüle ederek karşılaştırır. Sonuçta, basitlik her iki tarafın argümanlarının temelini oluşturur.

Üzerinde çalıştığınız kaynak kodu bir düşünün. Eğer başka birinin kodu üzerinde hiç çalışmadıysanız, bunu okumayı bırakın ve açık kaynak bir kod üzeirinde çalışmaya başlayın. Gerçekten! İnternette Türkçe birinin yazdığı kodu bulun, tabi iyi bir yazılımcının yani alanında uzman birinin yazdığı kod olsun.

Sonra bu yazıya geri dönün. Bulduğunuz kodların, aynı zamanda güzel olduğunu düşündüğünüz, birkaç ortak özellikleri vardır. Bunların başında sadelik gelir. Bütün sistem ne kadar karmaşık olursa olsun, parçalar basit olmalıdır, basit sorumluluğu olan basit nesneler benzer basitlik içerirler. Bir de yanlarında açıklayıcı method ve tanımlayıcı isimleri varsa tadından yenmez bu nesneler. Bazı insanlar 5-10 satır kod içeren methodları aşırı bulurlar ve bazı dillerde bunları uygulamanın zor olduğunu söylerler. Ben böyle bir kısalığın istenilen bir amaç olduğunu düşünüyorum.

Sonuç olarak güzel kodun basit kod olduğunu düşünüyorum. Her özgün kısım, basit sorumlukları ve basit diğer kısımlarla basit ilişkileriyle tüm sistemi basit kılar. Bu zaman içerisinde, temiz, basit, test edilebilir kod ile sisteminizin ömrü boyunca yüksek bir geliştirme hızı sağlayacaktır.

Güzellik, basitlikle birlikte doğar.

Sizlerde bu yollardan geçmişsinizdir. Bir projenin başlangıcında, herkesin birçok iyi amacı vardır ki buna ?Yeni proje kararları? adı verilir. Oldukça sık, bu kararların birçoğu dökümanlara yazılır. Bunlardan bir tanesi de proje içinde kullanacağınız kod standartlarıdır. Bir başlangıç toplantısında, takım lideri bunları dökümana yazar ve en iyi ihtimalle herkesin bu standartları takip edeceği üzerine karar verilir. Ardından proje başlar ve bu iyi niyet kısa zamanda terkedilmiş bir hal alır. Sonunda proje teslim edildiğinde, kodlar karmakarışık görünür ve işin komik tarafı kimse bunun nasıl bu hale geldiğini biliyor görünmez.

Neler yanlış gitti? Muhtemelen başlangıç toplantısında. Bazı proje çalışanları dikkatlerini bu konuya yoğunlaştırmadı. Diğerleri bunu anlamadı bile. Daha da kötüsü, bazı karşı olanlar çoktan kafalarında kendi kod standartlarını kullanmayı seçmişlerdir bile. Sonunda bazı noktalar üzerinde karar alınır, fakat proje üzerindeki basınç arttıkça, saldım çayıra mevlam kayıra deyip işlerin gitmesi gibi gittiğine inanılmaya başlanır. Güzel formatlanmış bir kod size müşterinin daha fazla fonksiyonlar istemesi konusunda birşey kazandırmaz. Ayrıca, otomatik değilse bir kod standartı uygulamak çok sıkıcı bir iş haline dönüşebilir.

Fakat bu bir problemse, neden en baştan itibaren bir kod standartını uymayı istiyoruz? Bir nedeni, projedeki kimsenin kendi koduna kendi gizli ?kod standartı? çerçevesinde uygulasını önlemek. Yazılımcıların başına çok sıklıkla gelen hataları farkı antipattern?ler ile gidermelerini engellemek isteyebiliriz. Hepsinden öte, kod standartı bir proje içinde daha kolay çalışmayı sağlamalı ve başından sonuna kadar development hızını korumak olmalıdır. Ve eğer gerçekten bir kod standartı tutturduysanız projenizde ve buna herkes katıldıysa, bir developerın kod içerisinde 3 boşluk, diğeri 4 boşluk kullanması hiç farketmez.

İnternette kod kalitesi raporu oluşturabileceğiniz, dökümanlayabileceğiniz ve bir kod standartı yaratabileceğiniz birçok tool mevcut ama tam çözüm bu değil. Kod standartı mümkünse zorunlu ve otomatik olmalıdır. Birkaç örnek:

• Kod standartının bir işlemi gerçekleştirmenin bir kısmı olduğuna emin olun, böylece herkes her zaman kodu compile ederken otomatik çalıştırabilsin.
• Sabit bir kod analiz tool?u kullanın ve kodu istenmeyen antipattern?ler için taratın. Eğer bulunursa, build işlemini bırakın.
• Bu şekilde çalışan tool’ların konfigürasyonunu öğrenin ve kendi kodunuzu bununla kontrol edin.
• Sadece test kapsamında ölçmeyin, ama otomatik olarak sonuçları kontrol edin.

Bu konuda önemli gördüğünüz herşeyi herkes için uygulamaya çalışın. Önemsediğiniz herşeyi otomatik hale getirmek mümkün olmayacaktır. Otomatik olarak işaretleyemediğiniz ya da düzeltemediğiniz şeyleri otomatik bir kod standarı için ek bir madde olarak göz önünde bulundurun fakat siz veya üniversitedeki arkadaşlarınızın bunu özenle takip edemeyeceğinizi de kabul edin.

Sonuç olarak, kod standartı statik yerine dinamik olmalıdır. Proje geliştikçe, projenin ihtiyaçları değişir ve başlangıçta zekice gözüken şeyler birkaç ay sonra zekice gözükmeyebilir.

Nerdeyse herkesin bir facebook hesabı mevcut. Hatta internet ile alakalı olmayan insanlar bile (Doğduğum köyün korucusu mesela) girip bir hesap açıyor. Milyonlarca insan aktif olarak kullanırken, iletilerini güncelliyorlar, mesajları reply ediyorlar, fotoğraf ve video yüklüyorlar ve daha bir sürü bilgi girişi yapıyorlar. Peki nasıl oluyor da facebook hala bu kadar hızlı yüklenebiliyor?

 

Aslında temel olarak bir neden olmamasına rağmen birçok nedeni var;

1. İleri derecede caching kullanımı. (APC ve memcached) ki bu ikisi büyük ölçüde işlem zamanını kısaltıyor. Slaytta APC ile  130ms süren bir işlem APC?siz olarak 4050ms sürdüğü görülmüş. Bu 30 kat daha hızlı olduğu anlamına geliyor. Facebook sayfasında gördüğünüz şeylerin %98?i güçlü memcache server?larında tutuluyor.
2. HipHop kullanımı, ki bu PHP kodunu C++ koduna dönüştürüyor. (ki derlendikten sonra, PHP koduna göre daha verimli bir makina kodu elde ediliyor.)
3. Facebook PHP ve MySQL kullanıyor fakat sadece bunlar değil. Örneğin Chat kısmı için Erlang, depolama birimi için Hadoop Clusters framework kullanıyorlar. Eğer facebook?un kariyer sayfasına giderseniz C++, Java ve Python ile uzmanlaşmış birçok kişiyi işe almak istediklerini görürsünüz.
4. Facebook?un dağıtılmış veriyi tutmak için birçok server?ı var. Haziran 2010?da, Facebook?un 60.000 server?ı vardı. Çok olduğunu mu düşünüyorsunuz? Google?ın yarım milyon server?ı vardı.. 5 sene önce.
5. BigPipe adında bir teknolojiyi, network?e tüm sayfayı değil de değişen veriyi göndermek için kullanıyorlar. Datayı sıkıştırmak için Gzip, cookie, Javascript, HTML..
6. Daha hızlı yapabilmek için birçok zeki insanı işe alıyorlar.

Buradaki Memcache olayı benim de yeni öğrendiğim bir konu. Kısaca şöyle özetleyebilirim;

Web uygulamalarının database?e erişimi minimize etmek temel amaç. Belirli key?leri belirli süre cache?te tutar ve harddisk input / output işlemi yapmadığı için daha hızlı bir şekilde işlemciye gönderir. Select, Delete, Insert, Update için MySQL tablosunu depolama motoru seçeneğinden memcache?yi seçince o table?ı disk yerine ram?de tutmaya başlıyor. Sık sık değişen, sık sık sildiğiniz veriler için ideal. Server?a restart attığınızda bütün hafızasını kaybettiği için kalıcı dataları burada tutmak sağlıklı olmaz.

Hepimiz diğer insanların bizim gibi güşündükleriniz varsayarız. Fakat düşünmezler. Psikologlar buna ?yanlış önyargılı görüş? derler. İnsanlar bizden farklı düşünür ya da davranırlarsa, bilinçaltımızda onları negatif bir şekilde etiketleriz.

Yandaki resimde de söylediği gibi; Önemli olan yazılımınızın ne yaptığı değil, kullanıcının ne yaptığıdır.

Bu önyargı programcıların neden kendilerini kullanıcıların yerine koydukları zaman çok zorlandıklarını açıklar. Kullanıcılar programcılar gibi düşünmezler. Başlangıç olarak bilgisayar başında daha az zaman geçirirler. Bilgisayarların nasıl çalıştıklarını ne bilirler, ne de umursarlar. Bunun anlamı, onlar programcılar gibi kafalarında problem çözme tekniklerini çizemezler. Tasarım desenlerini tanımazlar, arayüz etrafında, içinde çalışmanın ipuçlarını bilmezler.

Kullanıcıların nasıl düşündüklerini bulmak için en iyi yol, bir kullanıcıyı izlemektir. Geliştirme yaparken, yazılımınızın bir parçasını oluşturmak için kullanıcıya sorun. Gerçek bir görev olduğundan emin olun: ?Sayısal bir sütun ekle? gibi bir görev iyidir. ?Geçen ayki giderleri hesaplayın? daha iyidir. Çok özel görevlerden kaçının; örneğin, ?Bu tablodaki hücreleri seçin ve SUM ile en alta toplamını getirin? gibi. Tabi bu sorunda büyük bir ipucu var. Kullanıcıyla konuşun. Sözünü kesmeyin. Yardım etmeye çalışmayın. Kendinize şunları sorun;

• Neden bunu yapıyor?
• Neden bunu yapmıyor?

Farkedeceğiniz ilk şey, çekirdekte kullanıcıların aynı şeyi yaptığıdır. Görevleri aynı sırayla tamamlamaya çalışırlar ve aynı yerlerde aynı hataları yaparlar. İşte bu çekirdek görevlere göre dizayn yapmalısınız.

• Peki ya kullanıcı şunu yapmak isterse.. ?

Bu ayrıntılara yol açar ve kullanıcıların ne istedikleri üzerine kafası karışır. Yukarıdaki söylediğimi tekrar ediyorum. Yardım etmeye çalışmayın. Kullanıcıların seçtiği yolu izlemek bu tür karışıklıkları ortadan kaldıracaktır.

Kullanıcıları tıkanmış olarak görebilirsiniz. Siz tıkanıyorsanız, şöyle bir etrafınıza bakın. Kullanıcılar tıkandığında kendi odaklanmalarını daraltırlar. Bu onlar için ekranda başka çözümler görmeyi zorlaştırır. Yardım metni gibi çözümlerin, eksik arayüz tasarımlarında neden zayıf çözüm olduğunun bir nedeni vardır. Eğer bir talimat ya da yardım metnine ihtiyacınız varsa, onu problem yaşadığınız yerin hemen sağına koyduğunuza emin olun. Kullanıcılar dar bir görüşe odaklandıklarından daima, Tooltip kullanmak yardım menüsü kullanmaktan daha kullanışlıdır.

Kullanıcılar bir verinin üzeirnden geçip giderler. Onlar çalışan bir yol bulacaklardır ne kadar dolambaçlı olursa olsun. Her zaman apaçık kestirme yol, iki ya da daha fazla kısayoldan daha iyidir.

Ayrıca kullanıcıların ne istedikleri ile ne yaptıkları arasında bir boşluk olduğunu da görebilirsiniz. Endişe verici bulunur bu, bu yüzden kullanıcı gereksinimlerini almanın normal yolu onlara sormaktır. Bu yüzden bir kullanıcının gereksinimlerini elde etmenin en iyi yolu onları izlemektir.

 

Kullanıcıları izlerken geçirdiğiniz bir saat, bir gün boyunca ne istediklerini tahmin etmekten daha bilgilendiricidir.

Fonksiyonel programlama, son zamanlarda programlama toplulukları tarafından aşırı derecede ilgi görmeye başlandı. Fonksyionel programlama yazılım endüstrisinin çok çekirdekli yapıya doğru kaymasından sonra çıkardığı zorlukların üstesinden gelmek için konumlandırılmış bir özellik te denebilir. Ancak bu yapı, sizin için çok önemliyse fonksiyonel programlama uygulamak zorunda değilsiniz.

Fonksiyonel programlama paradigması yazmış olduğunuz kodun kalitesini büyük ölçüde arttırabilir. Eğer fonksiyonel programlama uygulamayı derin olarak anlarsanız, tasarımınız çok yüksek bir derecede bütünsel bir şeffaflık gösterecektir.

Bütünsel şeffaflık denilen olgu çok beğenilen bir özeliktir. Bu şekilde input?umuz ne şekilde girilirse girilsin, nerede ve ne zaman çağırılırsa çağırılsın, verimli olarak sürekli aynı sonuç verecektir.

Fonksiyonel programlama asıl olarak nasıl elde edebileceğinizden ziyade ne istediğinizi tanımlamak amacı yansıtır.

Fonksiyonel programlama derleyici içerisinde temel programlama fikirleri olarak hareket eder.  Listeye alma işlemleri ve önbellek gibi fikirler bunlara örnektir. Fonksiyonlar sadece kendi işlerini yaparlar. Bu fonksiyonlar atama değerleri içermediği için değişkenlere verilen değerler bir daha değiştirilemez.

En büyük yararı ise özlük, kısalıktır. Çünkü her zaman kodunuz daha kısa ve öz yapılabilir.

Fonksiyonel programlama yineleyici değişken yaratmaz bir döngünün merkezinde. Böylece kodunuzun yükünü ortadan kalkar.

Başka bir yararı ise eş zamanlılık yaratmaktır, ki bunu FP ile yapmak gayet kolaydır. Çünkü derleyici durum değişkenlerini manuel olarak yapmaya özen gösterir. (Bir loop içinde yineleyici gibi..)

Basit tekli işlemlerin oluşturduğu bazı performans faydalarında (programın yazılış yoluna da bağlı olarak) birçok fonksiyonel dil ve eklenti ağır şekilde ölçülür. Fonksiyonal programlama kullanılarak kodun niyeti açıkça ilan edilmesi sağlanır.

Bu konu ile ilgili John Hughes ?ün Why Functional Programming Matters konulu araştırmanızı kesinlikle okumanızı tavsiye ederim.

1. Gerçek gülüşünüzü gösterin.

İnsanlar gülmeyi sever, güldürmeyi sever. Bazen gülmek için para bile verdiğimiz zamanlar olur. Peki gerçek gülüş nasıl olmalıdır? Bu konuyla ilgili fransız fizikçi Guillaume Duchenne ?Duchenne Smile? adından bir kavram oluşturmuş. Bu kavrama göre, gerçekten zevk ya da mutluluk gösteren bir gülümseme göz çevresindeki kaslarla yanak kaslarının aynı anda çalıştığı gülümsemedir. Bunun dışındakiler sahte gülümsemelerdir der Duchenne. Bu yüzden vesikalık çektirirken sadece yanak kaslarımızı hareket ettirdiğimiz için daha resmi ve sahte bir gülümseme çıkar. Örneğin;

 

 

 

 

 

 

 

 

 

 

• Gülümsemenizin maliyeti nedir? Hiçbirşey.
• Gülümsememenizin maliyeti nedir? Herşey, özellikle insanlarla aranızda bir bağ kurmaya çalışıyorsanız.

2. Doğru kelimeleri kullanmak

• Basit kelimeleri kullanın.
• Aktif sesinizi kullanın. Doğru kelimelere doğru vurgular yapın.
• Kısa kesin aydın havası olsun. (İnsanlar ilgilenirlerse, daha fazla bilgi için size sorarlar. İlgilenmezlerse bu bilgler yeterlidir onlar için.)
• Yaygın kullanılan kesikn analizlerden örnekler verin.

3. Mükemmel el sıkışma

• 1. maddedeki Duchence gülümsemesi
• Göz teması
• Sözlü selamlama
• Sıkı tokalaşmanın tamamlanması
• Elinizin kuruluğu
• Elinizin sıcaklığı
• Uygulanan kuvvet
• Dinç olmak
• Ellerin yapısı
• Kontrol

 

Bütün bunlar ne demek?

1. İyi bir göz teması kurun.
2. Uygun bir söz ile selam verin.
3. Duchence gülümsemesi yapın.
4. Orta düzeyde bir gayret edin el sıkışmak için.
5. Diğer kişiler ile orta bir mesafede durun.
6. Elinizin serin, kuru ve pürüzsüz olmasına özen gösterin.
7. Elini 2 ya da 3 saniyeden fazla tutmayın.

4. Giyinme Sanatı

Kazanan veya kaybeden gibi giyinmeyin !

Özellikle iş yerinizde;

• Birinden daha iyi giyinirseniz bu ?Senden daha zengin, daha güçlü yada daha önemli birisiyim lanet olası? anlamına gelir.
• Birinden daha kötü giyinirseniz bu ?Sana saygım yok. Kendimin istediği gibi giyineceğim her zaman? anlamına gelir.
• Biriyle aynı şekilde giyinirseniz bu ?Bizler bir bütünün parçalarıyız? gibi anlaşılır.

5. Yakınlaşmak

Birini tanımak için geçirilen zamanda en önemli faktör yakınlık kurmaktır. Fakat büyük şirketler, dijital iletişimde fiziksel yakınlık kurmanıza karşıdır. Öyleyse ayağa kalkın ve çevrenizdeki kişilerle yüzyüze görüşün.

6. Değerlerinizi zorlamayın

İnsanları kendinize çekmek için onları kendi değerlerinizle veya özelliklerinizle sıkmayın. Bu genellikle ters tepki ile geri döner.

7. Diğerlerini kabul edin.

• İnsanlar binary değildir. Herkesin güçlü ya da zayıf özelikleri vardır.
• Herkes bir konuda sizden daha iyidir. Bunu bilin.
• İnsanların farklılıklarından çok benzerlikleri vardır.

8. Paylaşılabilecek tutkuları bulun.

• Herkesin bir tutkusunun olduğunu varsayın.
• Herkes ile ortak bir özelliğinizin olduğunu varsayın.
• Araştırmanızı yapın.

9. Varsayılan olarak ?Evet?

Hayatınızı 2 fikirden biri ile yaşayabilirsiniz;

• İnsanların iyi olduklarını ispatlayana kadar kötü oldukların düşünmek
• İnsanların kötü olduklarını ispatlayana kadar iyi oldukların düşünmek

–Eğer insanların kötü olduklarını ispatlayana kadar iyi olduğuna inanırsanız, çoğu insan sizi daha çok sevecektir.

Ne üstlenirseniz üstlenin, sağduyu ile hareket edin ve sonuçlarını dikkate alın.

Bir işi tekrar tekrar yapmak ne kadar rahat edici gözükse de, bazı zamanlar baskı altında kalmayı engelleyemezsiniz. Eğer kendinizi ?doğru yapmak? ve ?hızlı yapmak? seçenekleri arasında bulursanız, sık sık size çekici gelen seçenek ?hızlı yapmak? olur çünkü daha sonra gelir düzeltirim diye düşünürsünüz. Kendinize, takımınıza veya müdürünüze bu sözü verdiyseniz bunu yaparsınız. Ama çoğu zaman, bir sonraki tekrarlamalar yeni problemler getirir ve onlar üzerine odaklanmaya başlarsınız. Bu şekilde ertelenen işlerin sıralanması teknik borçlanma (technical debt) olarak bilinir ve kesinlikle sizin düşmanınızdır. Özellikle, Martin Fowler (ki kendisi pattern ve refactoring alanında uzman bir developer?dır.) bu durumu deliberate technical debt (tedbirli teknik borçlanma) olarak tanımlar ki bunu inadvertent technical debt (dikkatsizlik teknik borçlanma) ile karıştırmamak gerektiğini söyler. (Bu terimler size yabancı gelebilir, Google amca?yı kullanarak bu terimler hakkında geniş bilgiler elde edebilirsiniz.)

Teknik borçlanma kredi?ye benzer; kısa vadede size kazanç getirir, ancak tamamen ödeyinceye kadar faiz ödemek zorunda olursunuz. Kodunuzdaki kısa yollar veya kısaltmalar, kodunuza yeni özelikler eklemenize veya kodunuza refactoring uygulamanıza engel oluşturur. Kusurlu ve kırılgan test durumları oluşturmanıza neden olur. Artık bunu bırakın, kötü durumlar oluşur. Orjinal düzeltmeler ile, refactoring ve doğru kodu yaratmak için, orijinal sorunun üzerine doğru-katmanlı tasarım seçenekleri ile bir bütün oluşturulabilir. Aslında, bu durum da  sıklıkla, sadece işler kötü gittiğinde orijinal problemi düzeltmek zorundasınız. Ve bunu asıl problemi çözmek isteyip geri döndüğünüzde yapın. Ve o zaman, çoğunlukla çok fazla efor harcayamadığınızda bunu çözmek çok zor olur. Risk almanız gerekir.

Deadline durumlar ile karşılaşacağınız zamanlar da olur. Böyle durumla karşılaşmamaya çalışın. Ama başınıza geldiyse, üzerine gidin bu durumun. Ama teknik borçlanmayı takip etmek zorundasınız ve hızlıca geri ödemek zorundasınız yoksa herşey hızla yokuş aşağı sürüklenir. Kararda uzlaşır uzlaşmaz, bir görev kardı (task card) yazın veya unutmamak için kullandığınız issue-tracking uygulamanıza ekleyin.

Eğer bir sonraki yenilemede bunu gerçekleştirirseniz, size olan maliyeti en az olur. Ödenmemiş borç bırakmak faiz işletir, ve buradan oluşacak faiz, maliyeti görünür kılmak için takip edilmelidir. Bu, projenin ?teknik borçlanma??nın ?iş değeri? üzerindeki etkisini vurgulamak ve uygun önceliklendirme geri ödeme sağlar. Burada borçlanmayı nasıl hesaplayacağınız ve nasıl takip edeceğiniz uyguladığınız projeye göre değişir fakat bunu kesinlikle takip etmelisiniz.

Teknik borçlanmayı en kısa zamanda ödeyin. Aksi takdirde diğer işleri yapmak tedbirsizlik olur.

Geçenlerde forumların birinde şu şekilde bir soru gördüm.

SQL?im şu şekilde;

SELECT userid FROM tbluser WHERE year!=2001 OR year!=2003

Neden tüm yılların kayıtlarını getiriyor?

Aslında cevap olarak düşündüğümüzde çok basit. Bu iki yılın dışındaki tüm yıllar birbirini kapsadığı için tüm yılların kayıtlarını getirir. Yani, 2001 yılın dışındakiler ile 2003 yılın dışındakilerin (ki burada 2001 yılı da var.) birleşimi tüm yılları getirir.

Bu soruna şöyle de yaklaşmak mümkün;

year! = 2001 OR year! = 2003

kısmına De Morgan kuralını uygulayıp eşleniğini bulalım.

(year! = 2001 OR year! = 2003) == !(year = 2001 AND year = 2003)

Yukarıda da belirttiğim gibi, bu iki yılı and ile bağlayıp NOT halini aldığımızda tüm tarihleri getirecektir. Burada bu kişinin yapmak istediği şu şekilde;

SELECT userid FROM tbluser WHERE year!=2005 AND year!=2010

Bu iki yılın dışındaki tüm tarihlerdeki kayıtları getirmek için bu iki tarihi AND?leyip daha sonra NOT halini almamız gerekir.

Herşeyden önce müzik dinlemenin yaptığınız işi, iyi ya da kötü anlamda etkilemesi kişiden kişiye göre değişdir. Burada kendi açımdan müzik dinlemenin işim üzerinde nasıl bir etkisi olduğunu ve genel olarak doğru sayılabilecek (subjectif) konuları sıralayacağım.

 

 

 

devamını oku…

Microsoft SQL Server?ı bilgisayarınızda bulununa Windows?a yüklediğinizde sunucuya birçok hizmet yüklenir. Bu yazı da bu servislerin görevlerinden kısaca bahsedeceğim..

devamını oku…