Çarşamba, Ocak 16, 2013

Programcı Tıkanması

İki satır kod bile yazamayan durumdaki programcıyı ifade etmektedir. Beyin durması, mala bağlamak ya da AGD* durumu gibi varyasyonları olsa da benim içlerinde en çok sevdiğim "Programcı Tıkanması".
(* Ağzı Gözü Dağılmak)

Tıkanmış bir programcı mayın tarlası oyununda harikalar yaratabilir ya da saatlerce sıkılmadan youtube videosu izleyebilir ama kodun başına oturduğu zaman IQ iki yaş düzeyine iner. Normalde şakır şakır yapılan işler gözde büyür. İki saatte 10 satır kod yazarsın onu da üç gün önce farkettiğin bir problem yüzünden yazmaman gerektiğini hatırlayıp rollback yaparsın.

Bu tıkanma durumu birkaç saat sürebileceği gibi günler hatta aylar bile sürebilir. Tıkanmanın nedenine göre hayata bile küstürebilir :) Bu durumu çözebilmenin yolu önce sebebi keşfetmektir. Bunu türlü nedenleri olabilir.

  • Genel can Sıkıntısı: Bu sık sık başa gelebilecek bir durum. Çalışılan ortam genelde en büyük etken.
  • Sevilmeyen / Monoton bir işle uğraşıyor olmak: Sevmesek de hep bizi bulur bu işler ama bir taraftan bu tür işlerle uğraşıyor olmak mimari bir probleme de işaret ediyor olabilir. Dikkat etmek lazım.
  • Sebebi belli olmayan bir Bug: İşte benim en sevmediğim tür. Bir hata var belli ama reproduce edebilen yok. Bir nedenle hata raporu da yeterince fikir vermiyor. Bu hata çözülmeden iki satır kod daha yazabilmek mümkün değil. 
  • Birşeylerin Yanlış Gittiği Hissi: Sanırım bu en sevimsizi. Yaptığınız iş belli ve güzel ilerliyor gibi görünüyor ama içten içe biryerlerde hata yapıldığını hissediyorsunuz. Görünürde bir problem yok ama iş production'a çıktığında bayağı bir sorun açacak gibi duruyor.
  • Aşırı kompleks bir yapı tasarlayıp ipin ucunu kaçırmak: Burada olan şey genellikle aşırı soyutlama nedeniyle düşünce zincirini bir noktada koparmak. Tasarladığınız case'i bir şekilde kapatamamak. Sanırım tıkanıklık içinden çıkması en zor olan. Aylarca sürme potansiyeli olan şey.
Programcı Tıkanması probleminin en iyi çözümü bu noktaya yaklaşıldığını erkenden sezip işi hiç bu noktaya getirmemektir ama eğer başınıza gelirse yapılabilecek şeyler şunlar.
  • Biraz uzak kalmak, geri düşünceye atmak. Aslında bambaşka işlerle uğraşıyor olsanız da beyin background'da problemi çözmekle uğraşıyor olacak. İşe geri döndüğünüzde şakır şakır kod yazmaya başlayabilirsiniz.
  • Sıkıcı işleri otomatize etmek / Refactoring: Bu da aslında sıkıcı bir iştir ama asıl sıkıcı işle uğraşmak yerine daha etkin bir çözüm üretmek gelecekte bu işlerle bir daha uğraşmamak anlamına gelir. Bir de eğer sorun tasarımsal bir problemse bunu da acilen refactor etmek iyi bir fikir olabilir.
  • Sebepsiz Buglar: Eğer bir bug reproduce edilemiyorsa genellikle sorun ya multi thread ya da multi user kullanımında ortaya çıkar. En güzeli ne yapıp edip bu sorunu çözmek. Bu acayip bir rahatlama hissi verir. 
  • Kötü hisler: Muhtemelen TDD yapmıyorsunuz. Bu işin ilacı emin olmadığınız noktalar için birim testleri yazmak.  Bu iki şekilde işi kolaylaştırır. Hem kodu test edilebilir hale getirmek kodu kontrolümüz altına almamıza neden olur hem de programın mevcut çalışmasını bozacak bir hata yaparsak anında farkederiz. 
  • Geri adım atmak: Bazen kodu geliştireceğimizi düşünerek başlarız ama sonu olmayan bir yola gireriz. Zamanında geri adım atmayı bilmek işi büyük sorun haline getirmeyi önler. Etkin bir şekilde versiyon kontol sistemi (VCS) kullanmak gerekiyor ki gerektiğinde belli bir zaman diliminde yapılmış işleri inceleyebilin ya da istediğiniz bir noktaya geri dönebilin. Ayrıca DVCS sistemleri bize bu tür işlere başlamadan önce projeyi ayrı bir dala ayırıp tatmin olana kadar ayrı bir yerde geliştirmeye devam etme şansı verir. GIT, Mercurial gibi sistemleri iyi incelemek gerek. 
Bazen de hiçbir sebep yokken kod yazmak istemeyeceğiniz bir döneme girebilirsiniz. Kod yazmaya her oturduğunuzda uyku basması, çay istemek, maiileri kontrol etmek gibi şeyler oluyorsa bunun nedeni genelde aşırı çalışmadır ve biraz dinlenmek gerekiyor olabilir. Burada kendinizi kodu devam ettirmeye zorlamak yerine biraz gevşek davranmak iyi bir çözüm olabilir. Biraz düşünürseniz kod yazma dışında yapmanız gereken işler muhakkak bulursunuz. Mesela blog'unuza yazı yazabilirsiniz ;)

Cuma, Ocak 11, 2013

Yeni başlayanlar için Açık Kaynak projelere katkıda bulunmanın yolları

SambaPOS projesini geliştirmeye başladığımdan beri bana en çok sorulan soru "Nasıl para kazanıyorsunuz?" olmuştur. Bu soru hiç bitmeyecek zannediyordum. Artık ne kadar çok anlattıysam giderek daha çok kişi açık kaynak projelerde yer almak istediğini söylüyor. Gerçekten de bu projeleri ilgiyle takip ediyor ve bir şekilde içlerinde yer almak istiyoruz ama malesef yine çok fazla sayıda kişi bu tür projeler içinde yer alamayacağını da söylüyor. Genelde sebepler şunlar.
  • Programlama bilgim yeterli olur mu bilmiyorum.
  • Hiç vaktim yok.
  • İyi bir proje bulamıyorum. 
Öncelikle Programlama bilgisinin yeterli olmaması konusundaki düşüncelerin açık kaynak projelerin katılımcı bulmaktaki en büyük problemi olduğunu söylemeliyim. Genellikle açık kaynak projeler yürüten kişilerin deha programcılar olduğu gibi bir izlenim var. Bu kimi projeler için çok doğru ancak hemen her projede yapılması gereken işlerin büyük çoğunluğu herkesin yapabileceği türde işlerdir. Evet ilk başta yaptığınız işler dünyayı yerinden oynatacak işler olmayacaktır ama topluluğun arasına karışmak bu yolda atılması gereken ilk adımdır.

Belli bir teknolojiyi ya da herhangi bir işin nasıl yapıldığını öğrenmek için bir açık kaynak projeye katılmak müthiş güzel bir fikir. Ancak çoğunlukla açık kaynak projelerde kodun kendisi dışında pek fazla öğretici dökümantasyon bulunmaz. Yani okuyarak öğrenmek değil yaparak (bozarak) öğrenmek isteyenler için güzel ortamlardır. Örneğin WPF öğrenmek istiyorsanız hiç kimse oturup size WPF anlatmaz ama bir iş parçasını üstlenip takıldığınız noktaları danışırsanız birsürü şey öğrenirsiniz.

Bu nedenle bir şekilde bu projelerin içine sızmak gerek. Bunun için neler yapılabilir.

Öncelikle projeyi takibe almak gerek. Her projenin muhakkak bir blogu, bir forumu, bir mail grubu ya da topluluğun temek olarak iletişim kurduğu bir yeri vardır. Buraları bir süre takibe alın. Öncelikle neler olup bittiğini bir anlamak lazım.

Her projede kullanıcı kesim programcı kesime yaşadıkları hataları ya da istedikleri özellikleri iletirler. Projenin bu işler için nasıl bir yöntem kullandığını anladıktan sonra bir süre için ilginizi çeken istekleri ya da hataları takibe alın.

Bu noktada şunu belirtmem gerek. Her projenin en önemli altyapısı kullanılan versiyon kontrol sistemidir. İdeal bir projede gönderilen her bir kod parçası bir işle ilişkilendirilirler. Yani x işinin yapılması konusundaki bir "issue" o işi yapan kod parçası ile "commit" ilişkilidir. Eğer ilgilendiğiniz işle ilgili Commit'i incelerseniz satır satır o işi yapmak için ne kodlar yazılmış olduğunu görebilirsiniz.

Bu konularla ilgili projenin nasıl yürüdüğünü anlamadığınız noktalarda gönül rahatlığı ile topluluk ile iletişim kurabilirsiniz. DVCS nedir? diye sorarsanız muhtemelen bir vikipedia linki dışında bir cevap gelmez ama spesifik konularla ilgili güzel cevaplar muhakkak gelir.

Projeye girişin en güzel yollarından birisi gelen hataların nedeninin tespit edilmesine yardımcı olmaktır. Kullanıcılar genellikle yaşadıkları hataları düzgün ifade edemezler. Kullanıcı ile iletişim kurarak ve kaynak kodlardan neyin yanlış olabileceğini takip etmek ve problemin nedenini ortaya çıkarmak en saygın işlerden biridir.

Eğer hatayı düzeltebiliyorsanız düzeltin. Her projede programlamaya dün başlamış kişilerin bile düzeltebileceği tarzda problemler vardır. Bunu yapmak için projenin mimarisinin ne olduğunu bilmek gerekmez. Ancak bu noktada mesela yaptığınız değişikliği nasıl gönderebileceğinizi bilmiyorsanız yine gönül rahatlığı ile topluluk ile iletişimde bulunabilirsiniz. Normal şartlarda kimse size nasıl commit yapılacağını öğretmez ama böyle bir durumda otomatikman işin nasıl yapıldığını öğrenirsiniz.

Yani genel anlamda topluluktan birşeyler öğrenmek için değil de başladığınız bir işi tamamlamak için yardım isterseniz beklediğinizden çok daha fazlasınız alırsınız. Neyin nasıl yapılacağını öğrenmenin en güzel yolu bu.

Projenin beta testleri üzerinde kullanım testleri yapmak ve programcı gözüyle karşılaştığınız problemleri bildirmek yine iyi başlangıç işlerinden biridir.

Proje üzerinde performans testleri ya da memory leak testleri yapabilir ve karşılaştığınız problemleri bildirebilirsiniz. Bunlar da neyin ne iş yaptığına dair güzel fikirler verirler.

Birim testleri projelerin hatalarını gidermek için kullanılan güzel araçlardan biridir. Çoğu açık kaynak projenin kaynak sıkıntıları nedeniyle Pure TDD yapmak gibi bir şansı yok ama kritik noktaları kontrol altına almak için çeşitli testler yazarak projeye katkıda bulunabilirsiniz.

Kod yazmak dışında da kullanıcıların sorularına cevap vermek, küçük dökümanlar yazmak, websitesinin geliştirilmesine katkıda bulunmak ya da sadece proje ile ilgili düşüncelerinizi paylaşmak bile yine güzel katkılar olabilir. Ancak düşünce paylaşmadan önce en azından konuyla ilgili yeterli fikriniz olduğundan emin olun.

Her açık kaynak projenin temel öğesi proje etrafında gelişen insan topluluğudur. Genel anlamda bu topluluğun büyümesine ve gelişmesine faydası olabilecek her tür katkı sizi topluluğun vazgeçilmez bir parçası yapacaktır. Hiç bir açık kaynak proje ağır sorumluluklar almayı ya da günler harcamayı gerektirmez. 10dk. bile ayırabilecek olsanız muhakkak çorbaya ekebileceğiniz bir tuz taneniz vardır.

Tabii bunları genel anlamda yazıyorum. Söylediklerimin birçoğu SambaPOS projesi için de geçerli ancak bizim bir taraftan da Türkiye'de açık kaynağı tanıtmak ve sevdirmek gibi bir amacımız da olduğu için bize her konuda ulaşabilirsiniz.

Salı, Ocak 01, 2013

Plans for 2013

We are in the first few minutes of 2013 and I wish a happy new year to everyone.

As lots of you know we are developing a Restaurant POS application called SambaPOS. We release it as Open Source Software and Restaurants can download & install it for free.

2012 was a great year for SambaPOS project. Thanks to everyone who helped us on creating SambaPOS and who shared their SambaPOS installation photos on our Facebook Page.

We stared SambaPOS development in 2011. In the beginning of 2012 it was stable enough for production use and we released latest stable release in August 2012. In 5 months stable release downloaded more than 7200 times. It supports 16 languages and have installations in more than 50 countries. Our first users are using SambaPOS for more than a year and they created about 50.000 ~ 100.000 tickets. We proud of it because setting up a POS system for a Restaurant is not an easy task like installing any other free application. We worked hard to be able to create a simple installation & configuration procedure.

During V2 development a lot of people suggested great ideas for future releases. We listened them carefully and to be able to create a better business infrastructure for restaurants we stared V3 version development.

Our future objective can be defined with a single word. Integration.

Today I've read a great article from Dave McClure about the incoming tech revaluation in Food industry. http://500hats.com/why-menus-suck-food-tech-revolution. The abstract asks a good question. "what the hell we waiting for?"

During last year lots of great solutions and online services released for food businesses but all of them have the same problem. They work individually. For the real benefit these services should integrate seamlessly in the business process. Restaurant managers should be able to integrate & automate these services as their business needs. Additionally the system should generate meaningful reports from the analysis of data generated by all of these services. A solution for this infrastructure problem will trigger the tech revolution for the food business.

Sambapos is flexible, programmable and Open Source. For this reason we believe SambaPOS is the missing piece and during 2013 we'll work hard to make this dream come true.