Category Archives: Genel

Adres Değişikliği

Selam arkadaşlar,
Blog adresimi ilk açtığım günden sonra gidip domain almama rağmen oturup da adam akıllı bir aktarı gerçekleştirememiştim. Zaten kim uğraşacaktı bu kadar işle, wordpress.com zaten herşeye yetiyordu falan da yetmiyormuş sonra fark ettim olayı. Google Analytics eklemek istediğinizde sistem paralı olmanızı istiyor, font değiştirmek istiyorsunuz sizden para istiyor. Az buz da para istemiyor yani haliyle ben de bununla uğraşmak yerine direk elimde olan adresi de taşıma kararıyla blogumu yeni adresi olan (http://bosisleryazilimcisi.com)‘a taşımış bulunmaktayım.

Bundan sonra daha geniş içerikli yazılar yazacak olup, hali hazırda başladığım güzel bir Mobile App projesi ile de sizinle daha fazla detay paylaşacağım.

Falanlar filanlar hayatınızdan eksik olmasın…

“Request entity is too large.” konusu

Eğer siz de “The page was not displayed because the request entity is too large.” hatası alıyorsanız, öyle internette her bulduğunuz şeyi denemeyin bazen bulduğunuz çözüm, çözüm olmayabilir. Bu konuyu çok uzatmayacağım ki kısaca çözüme geçelim.

Olay

SSL kullandığınız projelerinizin requestlerinin boyutları IIS’in applicationhost.config ayarı ile çatışması. Bu boyutun arttırılması, dosya yüklerken ya da büyük resultlar dönerken tip tip hatalar görmeniz tamamen buna delalettir.

Çözüm

Önce C:WindowsSystem32inetsrv adresine girip applicationhost.config dosyasının bir yedeğini aldın ki diliniz yanmasın. Sonra nette bulduğunuz klasik örneği kullanarak arttırım yapmayın, önce bir bakın adamlar ne yapmış örneklerinde;

appcmd set config "https://mysite" /section:system.webserver/serverruntime /uploadreadaheadsize:1048576 /commit:apphost demişler. Bi bakalım sırayla;

  • https://mysite buraya kendi sitenizin adını yazın, bu ad nedir diyorsanız hiç sitenin urlsini yazmayın, IIS’i açıp Sites kısmındaki ismini yazın arkadaşın…
  • 1048576 hep buradan yanıyor başımız. 1048576 = 1024 * 1024 = 1mb yani adam 1mb için örnek yazmış, sen de git kopyala hemen mal gibi, yapmayın tabii böyle. Max: 2147483647 verin ki bu da 1.99GB’a denktir.

Sonuç

Yükleme kısmınız varsa bu sorunu çözüyor bir de limiti 2gb’a kadar çıkartıyorsunuz da, 2GB’dan daha fazla yükleme yapmak için ayarlar .Net’de gelmiş olsa da IIS’de henüz gelmediğinden, 2GB’dan fazla doküman yükleyecekseniz, beklemeniz gerekmektedir.

Doğru bil(me)diklerimiz neler?

Dediğim gibi bir sürü boş vaktim olmasa da bir sürü boş işe harcadığım vaktim olduğu için bir çok gereksiz konuda yazı yazabiliyorum. Aynen bir sürü gereksiz yazılım yazmak gibi ama biraz daha farklı. Bus efer ki konu, esasta doğru bildiğimiz yanlışlar ile alakalı. Bildiğiniz gibi, yazılım üzerine çalışınca, yazılım hakkında bir çok diyaloğun da içerisinde oluyorsunuz. Bu yazının ortaya çıkmasında sebep aynı böyle bir tartışmaydı; **“Object Oriented Programming kullanmıyorsunuz!” lafından çıktı hepsi, beni suçlamayın onu suçlayın.

Ne Bil(mi)iyoruz?

Pek tabii ki yazılımcılar olarak biz her şeyi biliyoruz! Aksi ispat edilemez, edilecekse gelsin çıksın karşıma. Biz bu meslekte dirsek çürüttük, her şeyini biliyoruz tabii ki. Ne biliyoruz peki? OOP biliyoruz, Pattern biliyoruz, Nesne biliyoruz, Polimorfizm biliyoruz, her bir şeyi biliyoruz. Açıkcası bir kaç güne kadar ben de böyle diyordum ki, piyasadan bir üstadımız beni yerin yedi kat dibine sokuncaya kadar. Sonrasında kendime geldim, nefes aldım bir oh çektim falan.

Peki gerçekten bu terimlere hakim miyiz?

Konuşmanın biraz daha heyecanlandığı noktada, benim otomatikman muhalefete geçme gibi bir özelliğim olduğundan, konu genelde farklı boyutlara taşınır. Konuşmada arkadaşın yukarıda belirttiği OOP kullanmıyorsunuz, bir nefi bilmiyorsunuz lafı sonrasında, sinirler arttı benim. “OOP Nedir?” dedim arkadaşa, basitçe bana OOP tasarım kalıplarıdır dedi o da. Bir kere öyle değil bu işler. OOP dediğimiz, nesne tabanlı programlamadır. Yani nedir? Nesne olması gerekir, yani senin nesneler yaratman, basitçe bu nesneleri yönetecek katmanları yazman ve buna bağlı programlama yapmanı anlatır. Peki ben hiç tasarım kalıbı ya da güzel adıyla Design Pattern kullanmamışsam? O zaman ben hiç OOP kullanmamış mı olurum? Ekmeğe, şeklini verirken franzile şekil vermediysem ortaya çıkan ürün ekmek değil midir? Aynı mantıkta yanıtlanabilecek bir cümle.

Eğer sen nesnelerini oluşturup, katmanlarını koyduysan, SOLID mantığını biraz da olsun yakaladıysan o zaman zaten OOP yapmışsın ne mutlu sana. Pattern kullanmadıysan OOP yapmadın diye bir algı yok, olmamalıdırda. Pattern kullanmadım diyorsunuz da peki o konuda da emin misiniz?

Pattern olayı

Ya şimdi bir gerçek var, Design Patterns popüler olduğundan beri, herkes bu terimi kullanır oldu hayatında. Adı üzerinde, tasarım kalıbı bu, yani kalıplaşmış kod yapısı. Hiç kullanamadan adam akıllı kod yazmanız için çömez olmanız lazım, kullanıp adını bilmezseniz normal developersınızdır. Fakat insanlar sizden ismini ve cismini bilmenizi bekler. Yeni dünya diye bir meyva var, ismini tam olarak bilmem. Alırım, yerim. Tutup da sen bana bunu yerken, “hiç yeni dünya yememişsin, çok süper meyva” dersen, yemiş olsam bile yemedim psikolojisi oluşur üzerimde.

Kod açısından örnek verirsek, yıllarca data fonksiyonlarını yazdıktan sonra, datayı ele alan DAL yani Data Access Layer’ı yazarken nesnelere uygun tekil sınıflar yazdım. Yani bir tablo varsa, o tabloya data girişini sağlayan. DataTablosuBase.Save() ya da DataTablosuBase.Insert(DataTablosu _dataTablosu) kodlarını içeren sınıfı yazdım ve datalarımı öyle kaydettim. Şimdi yıllar sonra öğreniyorum ki bu yöntem Repository Pattern olarak ele alınıyormuş. Şimdi aynı konuşmada, arkadaş bana onu da dedi “Hiç pattern kullanmadan OOP yazılmaz”. Bu arkadaşı ilk arayan 20 kişiye postayla göndermeye karar verdim. Bildiğin bas baya kullanmışım işte.

Bu pattern’in üç temel prensibi var; Data erişiminde tek noktanın olması, Tablolarınızla alakalı tek bir sorumlu yer olması, Olası altyapı değişimlerinde sistemin minimum değişimle işlemesi. E ben bunu gayet yerine getirmişim, sadece “DataTablosuBase” yerine “DataTablosuRepository” dememişim. Ha bir de EF kullanmamışım ama o kontaya girersem çok olaylar çıkar.

Sonuç

Demem odur ki, asla bir insanla beraber adam akıllı kod yazmadan ona şunu yapmamışsın, bunu yapmamışsın demeyin. Yapmıştır, illa yapmıştır da bilmiyordur. Yapmıştırsın da bilmiyorsundur diyin. Bu sayede siz de o insandan biraz kod öğrenebilir, o insanla aranızı bozmazsınız. Dünya daha güzel bir yere gelir. Fakat konunun başında da dediğim gibi biz yazılımcılar her şeyi bildiğimiz için bu konuda burnu havada insanlarız. Arada bir kendinizden daha iyi olan insanlar tarafından alaşağı edilin de, kendinize gelin vallaha.

Composite Application Architecture ve Service Oriented Architecture

Bu sefer de biraz servis tabanlı mimariler üzerine bir yazı yazayım istedim. Belki bildiğiniz üzere, son zamanlarda her insan SOA demeye başladı yazılım firmalarında, fakat bu terime aşina mıyız? SOA diye bahsettiğiniz şey CAA Composite Application Architecure olmasın ya da SaaS Software as a service de olabilir. Bu terimler üzerine biraz düşmek ve aklımızda bazı şeyleri netleştimek istiyorum.

Bu yazının sonrasında detaylı olarak açıklancak şeyleri burada listeleyeyim ki sonradan açıklanmamış şeyler kalmasın;

  • CAA – Composite Application Architecture (Bileşik Yazılım Mimarisi) Nedir?
  • SOA – Service Oriented Architecture (Servis Tabanlı Mimari) Nedir?
  • SaaS – Software as a Service (Bir Servis Olarak Yazılım) Nedir?

Yukarıda belirtiğim konulara özgü detaylı makaleleri sonradan anlatacağım pek tabii ki. Şimdilik ben SOA ve CAA üzerinde durmak ve aklınızda oluşan sorulardan kurtulmak istiyorum.

CAA Nedir?

CAA dediğimiz olay bileşik yazılım mimarisini temsil etmektedir. Adından da anlaşılacağı gibi bazı temel faktörlerin, yazılım mimarisini oluştururken birleştirilmesi temeline yatar. Oluşturulan sistemin bel kemiğine Composite Solution Platform (Bileşik Çözüm Altyapısı) diyebiliriz, diğer programlar ya da programcıklar buraya bağlanır ve yönetilirler. Şöyle detaylıca anlatmaya çalışayım. Programlama temelleri üzerinden gidersek, bir programın illa birleşim yapması için service olmasına gerek yok. Her hangi bir dille yazılmış, dışarıya data verirken belirli limitasyonlar ve standartlar altında alınmış programlara Composite Application diyebiliriz. Bu programlar ister servis olsun – SOA üzerinden – ister dll olsun – CBD component based development üzerinden – bir şekilde projeye entegre olabilmelidirler.

Belirtilen entegrasyonu sağlayan bir Governance (Yönetim) altyapısı çıkar. Bu yönetim altyapısı, bileşik altyapıların entegrasyonu ve yönetimini sağlamakta ayrıca diğer programlar ile data alışverişi, mesaj alışverişi gibi kontrolleri sağlamalıdır. İstenilen dilde ve istenilen altyapıda buna uygun bir yöntem bulabilirsiniz.

Bu programlama modeli, yazılım mimarisinde üç temel noktayı ele almaktadır;

  • İşin ya da çalışmanın dizaynından tam yarar alabilmek,
  • İşin ya da çalışmanın, olabildiğince efektif evrim geçirmesine destek olmak,
  • Var olan sistemlerin yerine yenilerini yapmak yerine, onlara destek vererek tekrar kullanmak (reusability).

Kısaca bu programlama modelinde amaç; esnek, adapte edilebilir ve iş ile IT arasında yüksek oranda verim sağlayacak şekilde mimariler oluşturmak.

SOA Nedir?

Bu geyiği burada yapmazsam tabii ki kafayı yerim; One person successfully described SOA completely, and immediately died. Tabii ki böyle bir olay yok, SOA aslında anlatılabilir ve anlaşılabilir bir yapıda. SOA’nın açılımı Service Oriented Architecture, yani servis tabanlı mimari. Buradan da anlayabileceğimiz gibi, program altyapımız servisler (.net için WCF, Web Service, Web API).

Bu mimariyi kısaca özetlersek; Bir Enterprise Application geliştirdiğimizi düşünelim, CMS olur, ERP olur, HRP olur. Bu tip sistemler için daha önceden yazılmış, başka sistemlerde de kullandığınız küçük programlar olsun, SMS gönderimi, Mail SMTP sunucusu, acil durumlarda gerekli kişilere haber verecek Code Red altyapısı ya da bir Report programı. Bu programların büyük seviye programlar ile iletişime geçmesi için önce hepsini servis olarak yani entegre edilebilir, bağımsız programcıklar olarak kodlayıp, gerekli kısımlara entegre etmemiz işleminin planlanmasına SOA denir.

Daha detaylı örnek olarak ele alalım; Report servisi, düzenli olarak her hafta sonunda ilgili haftanın ilgili datalarını almak için ERP’ye HRP’e gidebilir. ERP’de HRP’de bu programın çalışması ya da çalışmaması bağımsız olacak şekilde datalarını ona verirler. Bu Report servisine bir de önemli bir rapor çıktığı için Code Red servisi bağlayabilirsiniz ki bu datanın gelmemesi durumlarını kontrol eder, eğer data gelmiyorsa Code Red sistemine bağlı SMS gönderim servisi – ki bu servis daha önceden ERP ve HRP sistemlerine bağlanmıştır – acil durum çağrısını ilgili birimlere gönderir.

Tekrar tekrar kod yazmadan ne kadar çok işlemi yapabildiğimizi görebildiniz mi? ERP ve HRP genel arayüzü oluştururken, SMS gönderim gerekli bildirimi, Reporting ise gerekli raporlamaları sağlamaktadır. Code Red ise datanın bütünlüğünü ve acil durumların kontrolünü sağlamaktadır. Bu arada yaptığımız Seperation of Concerns olayına da dikkatinizi çekmek isterim.

Lafı uzatmadan, SOA’nın dört ana maddesini de ele alalım istiyorum;

  • Sınırlarınız kesin olmalıdır.
  • Servisler özerk yapılarda, kendini idare edebilir olmalıdır.
  • Servisler schema ve contract paylaşır, class paylaşmaz.
  • Servis uyumluluğu belirli politikalarla belirlenir.

Bu dört kurala bağlı şekilde yazdığınız servisleri, birbirleri ile entegre hale getirebilir, projelerinizi genişletebilirsiniz. Daha detaylı olarak SOA kısmından daha sonra bahsedeceğim.

SaaS Nedir?

Aslında SaaS’ın konu ile hiç bir alakası yok, fakat tartışmalar sırasında insanların aklına alakalıymış gibi gelmesin diye burada bahsediyorum. SaaS yani Software as a Service olayı, bir yazılımın servis olarak sunulmasıdır. Yukarıda bahsettiğimiz SOA olayı değil, bildiğiniz ücretli ya da ücretsiz bir işlem yapan kapalı kutulardan bahsediyoruz. Online Task Yönetimi ya da Online Project Management araçları bunlara örnek verilebilir. Kendi API’leri ile diğer programlarla konuşabilirler ama bu demek değildir ki bizim SOA altyapımıza uygun olacaklar. SaaS olayını kendi içinizde geliştirirseniz bir servis olur, parayla satılan servis olmaz. Burada Türkçe karmaşası yaşıyoruz, ilk servis dediğim nokta bir iş yapan programı analtırken, diğer servis kelimesi hizmet veren programı kast etmektedir.

Sonuç

Bu yazıda biraz tanımları size aşina olması için ele almak istedim. Halen aklınızda sorular olabilir ki bu soruları Yorum kısmında yazarsanız, elimden geldiğince yanıt vermek isterim. CAA ile SOA aslında bağlantılı sistemler olmasına rağmen SOA daha kalıplaşmış bir tanıma sahiptir, CAA ise daha genel ve daha eski bir teridir. Neticesinde günümüz programlama mantığı SOA’yı bile eskitmiş olmasına rağmen, geleneksel yazılım mimarilerinden yeni kurtulan Türk Yazılım Piyasası anca SOA terimini yeni kabul etmeye başladı. Belki yıllardır kullanıyorsunuz fakat emin olabilirsiniz ki çoğu firma daha terimi ilk defa duyuyor.

SOA ve CAA konusunda daha detaylı analiz makalelerini daha sonra yazacağım, şimdilik iyi kodlamalar…

Facilitation / Kolaylaştırma

Geçen gün takip ettiğim Project Management bloglarından bir tanesinde bir yazıyı yıldıza aldığımı fark ettim. Bu yazıyı burada çevirip sizinle de paylaşmam lazım, bugün yarın ihtiyacınız olabilir. Benim gibi boş vakti bol olanların bir görevi de bu tabii ki.1

Zayıf PM’ler2 takımlarını ve kullandıkları yöntemleri kontrol etmeye çalışır. Fakat bunu yaparken işleyişin doğal düzenine müdahale edip daha kaotik bir ortamın ortaya çıkmasını sağlarla. Ekibin işleyişi kendi kendine evrimleşip olgunlık kazanmalıdır. Eğer PM sürece müdahale eder ya da onu kontrol etmeye çalışırlarsa, proje genelde başarısız olacaktır.

Erdemli PM, proje takımı içinde ne olduğuna güvenmeyi öğrenir. Eğer bir suskunlık var ise onun büyümesini ve ortaya çıkmasını sağlar. Eğer bir fırtına var ise, onun köpürmesini ve böylece kendi kendine sönmesini sağlar. Eğer takım bir şeylerden mutsuzluk duyuyorsa bunun çözümünü bulur. Erdemli PM, dağılan iş sürecini rahatlatır, kolaylaştırır. O, olaylar derinlemesine etki bırakmadan nasıl işlerin düzeltileceğini bilir.

Maalesef erdemli PM, Türkiye şartları içerisinde pırlanta değerinde ve bir o kadar da bulunması zor bir nesne. Yetişmesi için bulunması gereken ortam da maalesef burada yok. Belki öncesinde bir kaç defa fail olması lazım ki öyle Erdemli PM olabilsinler.


  1. Kaynak (http://thetaoofpm.blogspot.com.tr/2014/03/58-facilitation.html) 
  2. Project Manager (Proje Yöneticisi) 

Yazılım’ın Boş Bir İş Olması

Şimdi aynı meslek grubundaki arkadaşlar bana kızabilirler, hatta başlığı okuyup eksiyi de basabilirler, fakat yazının sonuna kadar dayananlar anlayacak ki biz de biliyoruz da konuşuyoruz. Sonuçta bu meslekte az denemeyecek kadar çalışan birisiyim ben de1. Önce madde madde bu mesleği ele alalım, korkmayın gayet mantıklı şeylerden bahsedeceğim – şu an için bana mantıklı geliyor da olabilir. Öncelikle belirtmem gerek ki burada bahsettiğim tüm bilgiler kendi kişisel görüşlerimin yansımasıdır, başka bir amaca hitap etmemektedir.

Yazılım’ın Diğer Tanımı

Yazılım dediğimiz şey, şu an bu yazıyı okumanızı sağlayan teknolojinin ihtiyaç uyduğu mantığı, bilinci, yöntemi belirleyen sistemlerdir. Basitçe ele alırsak yazılımcı dediğimiz de bu sistemin oluşmasını sağlayan insanlara verilen genel ad, aslında bu meslek grubundaki insanların hepsinin başka adları da var, örneğin veritabanı uzmanı ya da yazılım mimarı gibi isimleri. Fakat bu blog içerisinde kimseye ayrımcılık göstermeyeceğimiz için, hepsine yazılımcı diyeceğim.

Basit tanımları geçtiğimize göre esas tanımlara geçebiliriz – sizi burada Boş işler yazılımcısının harikalar diyarına alıyoruz. Yazılım dediğimiz şey, esasında soyut bir şeydir ve soyut kavramlar kendi içlerinde ikiye ayrılırlar;

  • Boş soyutluk durumu: Sevgi, Aşk, Nefret gibi tanımlayabileceğimiz şeyler boş soyut kavramına girer.
  • Dolu soyutluk durumu: Bilgi, Felsefe, Din gibi tanımlayabileceğimiz şeyler de dolu soyut kavramına girer.

Yazılım da “dolu soyutluk durumu” içerisinde ele alabileceğimiz bir yaratımdır. Bu soyutluk durumunda, madde açısından bir şey yoktur. Sadece bilgi ve onun yansıması vardır. Bilgi ile diğer insanlara bir şeyler anlatabilir, onlara bir şeyler katabilirsiniz. Yazılım ile de hem kişiye, hem de teknolojiye bir şeyler anlatabilir, istediğiniz şeyi yapmasını sağlayabilirsiniz. Fakat yazılım da bilgi gibi somut bir duruma geçmeden önce tamamen soyut olarak ele alınan temellere dayanmaktadır.

Yazılım’ı Babaya Anlatmak

Başlığı okuyunca yüzünüzde oluşan ifadeyi gözlerimde görür gibiyim, genelde bu ifade küçük çocukların ebeveynlerine çok sevdikleri bir çizgifilmi alnatırken ortaya çıkmakta. Konudan şaşmadan devam edeceğim, soyut olayların en büyük sorunu başka insanlara anlatılmasıdır. Zira somut bir şey her daim paylaşılması en kolay şeydir, bir odunu başkasına göstererek, dokundurarak, koklatarak, hatta ve hatta ısırtarak anlatabilirsiniz ama bir yazılımda bunu yapamazsınız. “Gösterebilirsiniz, dinletebilirsiniz, robot kollarla dokundurabilirsiniz” demeyeceğim zira bunlar maalesef yazılımın sonrasında çıkan şeyler sayesinde olur. Yazılım geliştirdiğiniz IDE’de bulunan kodları gösterin bakalım karşı taraf ne anlayacak ondan. Bu maalesef soyut kavram içerisinde çalışan insanların kaderinde var.

Yazılım vs …

Bu meslek ile uğraşıyorsanız, siz de çok iyi biliyorsunuz ki toplumun gözünde asla bir marangoz kadar değerli olmayacaksınız. Sadece toplum olsa, aileniz öncelikli gelecek, sonra kız arkadaşınız, belki de çocuklarınız. Hiç bir zaman bir marangoz olamayacaksınız, çünkü o bir odunu alıp, ondan kereste almaktadır – burada marangozlardan saygıyla bahsedilmiştir, hayalimdeki meslek oydu – fakat siz bir avuç kelimeyi, çok az kişinin bildiği bir dile sökerek bir sonuç, bir sayfa, bir uyarı ekranı çıkartmak zorundasınız. Ayrıca sadece elektronik eşyalara bağlısınız, bir marangoz meyva bıçağı ile bilişer yapabilirken siz elinizde bir akıllı telefon olmadan ne yapabilirsiniz ki?

Görsel somut algılar maalesef içinde bulunduğumuz toplumun temelinde yatmaktadır. Yazılım maalesef bu mantığa uygun bir meslek ya da iş değişdir. İlerleyen zamanlarda belki teknolojinin gelişmesi ile bu konuda daha somut adımlar elde edebiliriz, ne bileyim maatbaa makinası gibi bir alete kodları yerleştirip tuşuna basınca yazılım falan çıkar aletin diğer ucundan, olur bir şeyler.

Felaket Senaryoları

Bu geyiği yapmadan bu blog girdisini bitiremezdim, yapamazdım, anlayın beni. Olası “Dünyanın Sonu” senaryolarını kafanızdan geçirin, çok dalmayın hızlıca geçirin. Sunucuların çalışmadığı, elektriğin olmadığı, teknolojinin 16.yy’a gerilediği bir dünyada siz ne iş yapabilirsiniz? O dünyada bir Felilozofa ne kadar ihtiyaç varsa bir Yazılımcıya da aynı ölçüde ihtiyaç vardır. Fakat bir marangoz öyle mi, alır eline aletlerini, barikatını kurar, mobilyalarını inşa eder. Somut adımlar atar ve prensesi kurtarır, siz anca ona bağımlı yaşayan sidekick’den öteye geçemezsiniz.

Hayatta kalmak için bile yeterli olmayan bir mesleğe mendup kişiler olarak bana Yazılım‘ın boş bir iş olmadığını maalesef kanıtlayamazsınız. Diğer insanlara kanıtlayabilirsiniz, hem de çok basit bir şekilde; Onlara sadece ne kadar maaş aldığınızı söyleyin.


  1. Sen mi büyüksün, hayır ben büyüğüm ben Yaşar Usta! 

Yıllar sonra yeniden blog açmak

Bugün blog açacağım diye o kadar çok kastım, o kadar çok servisi araştırdım ki ne kadar boş bir insan olduğu tekrar anladım. Neyse uzun lafın kısası WordPress’de kaldık yine. Fakat bu blog açma serüveninde eskilere gitmedim diyemem.

Ah o eskiler

İlk blog sayfamı 08.2007 yılında açmışım. O zamanlar WordPress’de var ama bu kadar parlak bir geleceği belli değildi – ya da ben yanlış yorumlamıştım – ve ben Blogger üzerinde açmışım. Aslında ondan da önce bir blog açmışım gibi bir his var, böyle web 2.0 zamanlarının olduğu vakit açmış olmam lazım ama pek emin olamadım. Şimdi tutup da kendi adımı Google’da aramak da istemiyorum, çok sıkılıyorum sonra bulduklarımdan.

Eski Blogda bir sürü boş şeyden bahsetmişim, kedim varmış o zamanlar. Düşünün, kedim varmış!!! lan kaç yıl önceki olay kedi beslediğim günleri bile unuttum sayılır. Zaman ne kadar da hızlı geçiyor. 2008 zamanında çok entry girmişim oraya ama sonra pek uğramamışım, en son 2010 yılında Blogger API için bir entry girmişim. Sonrasonda tekrar blog açmak istedimsede olmamış, “ne yapalım allah baba da beni böyle yaratmış” diyerek kaderimi kabul etsem de, son zamanlarda aklıma gelen fikirleri paylaşmak için geçen sene ya da ondan önceki sene bir hikaye blog’u açmıştım; Yazdım, Oku! adında. Gayet de güzel başlasa da, sonrasında elimde draft halde bulunan hikayeleri oraya paylaşamayacak kadar boş işim oldu elimde.

Yeni Başlangıç

İşte bu yüzden, sonra zamanlarda aklımda olan Yazılım Blog‘u açma fikrini bugün hayata geçirdim. Fakat burada bir sürü teknik – şeyden – detaydan bahsetmek yerine, bu işin felsefik yanlarına da değinmeyi planlıyorum. Tabii yazılımla ilgili takıldığım noktalarla ilgili yazılarım olmayacak değil. İlerleyen zamanlarda, burayı terk ettikten sonra en azından anı olur bana, eğlenirim falan.