Kodlamak Yazılımcı olmak için Yeterli mi ?

Mezun olmamın üzerinden beş sene geçmişken daha geçen gün diplomamı almak için lisans okulum olan İstanbul Üniversitesi Bilgisayar Mühendisliğinin Avcılar Kampüsüne gittim. Gencecik dimağlar  kampüste oturmuş sabahın dokuzunda patsolarını yerken arkadaşımla gittiğim kampüsü gezip bir de bölümümüz hocalarının yanına gidip konuşunca o günler gözümde daha iyi canlandı ve bu konuyla ilgili bir blog yazısı yazmaya karar verdim. (Bu satırları yazmamın üzerinden uzun bir süre geçti 🙂 ) Filmlerdeki geriye dönüş sahneleri gibi şu ana kadar yaşadıklarımdan edindiğim tecrübelerle o senelere gitsem neyi daha farklı yapmaya çalışırım sorusuna cevap niteliğinde bir yazı haline getirmeye niyetlendim. Yazı taslağı ve değineceğim konuları belirleyince bunun çokça anlatılan genel iletişim, sosyallik, proje yapma gibi klişeleşmiş konuların olacağı bir yazı olacağı için yazıyı yazmaktan vazgeçmiştim. Blog okurken şu yazıya denk gelince yazmaktan vazgeçtiğim konu ve bu yazıyı toparlayarak bir yazı hazırlamaya karar verdim.  Bu uzun girizgahtan sonra hazırsanız yazıya geçiyoruz.

Kendimize yazılım geliştirici, yazılım uzmanı, geliştirici ya da  yazılımcı her ne dersek diyelim günün sonunda yaptığımız iş bir yazılım üretmek oluyor. Kimi zaman var olan bir yazılıma küçük eklemeler yapıp; kimi zaman sıfırdan başlayarak bir yazılım ortaya çıkarabiliyoruz. Kimi zaman da doğrudan kod yazmasak da sistem, altyapı, donanımsal ya da teknik konularda çalışarak yazılımımızın daha iyi bir noktaya taşınması için çalışıyoruz. Eğer freelance bir çalışan değilseniz bu aşamaların çoğunda da bir takımın parçası, bir hiyerarşinin basamağı olarak çalışıyoruz. Bu yüzden yaptığımız tek işi kodlama olarak nitelemek eksik bir tanımlama olacaktır. Bu yazıda, yazılımcı eşittir kodlama şeklindeki eksik gördüğüm tanımlamayı başka hangi yetkinliklerle besleyebiliriz sorusuna kendimce cevaplar vermeye çalışacağım. Bu konuda yazılımcılar başta olmak üzere yazılım ile bir şekilde ilişkisi olan herkesin söyleyecekleri vardır mutlaka. Fikrini paylaşmak isteyenler yorumlar yazının daha iyi bir noktaya gelmesini sağlayabilirler. İyi bir yazılımcı olmak için teknik donanımın iyi olması gerektiğini ön kabul olarak bu yazıya devam edeceğim 🙂

Haydi maddelendirmeye başlayalım 🙂

Algoritmik Düşünme

Yazılım geliştiren bireyler olarak çoğu zaman en hızlı çözümü düşünerek sonuç odaklı çalışmalar yapmamız gerekebiliyor. Kısa vadede istenen çözüm bu olabilir ancak hızlı çözümlerin ya da kısa yolların başımıza iş açma ve sürprizleri sever bir yanı olduğunu da unutmayalım. Murphy’e selamlarımızı iletelim bu noktada. Ancak büyük sistemlerde ya da etki analizi büyük, kullanıcısı çok olan yani yazılım ekosistemindeki bir çok ürün için istenen şey ürünün stabil, oluşabilecek problemlerin ön görülerek önlemlerin alınması istenir. Bu sebeple yazılım geliştirirken yaptığımız değişikliklerin neleri etkileyeceği performanstan, sistemsel etkisine kadar her adımını tek tek düşünerek işlemlerimizi yapmalıyız. Algoritmik düşünme bir yazılım geliştirici için yazılım geliştirmeyi sadece kodlamanın ötesine taşıyan önemli özelliklerden birisi. Çok basit olacak ama  indexleme ya da ilişkilendirme yapılmadan, zamanla tablonun tutacağı data düşünülmeden, veri tabanı mimarisine kafa yorulmadan hazırlanmış bir tablolar bütünü er geç sizi zorlayacak belki de başta kurgulamış olmaktan daha fazla vaktinizi alacaktır.

Kod okuma becerisi

Zamanla gelişecek olan bu beceri problem çözümü, önceden yazılmış olan kodların nasıl çalıştığını kavrama açısından oldukça önemlidir. Kimi zaman devraldığınız bir projenin önceki yazılımcısı gitmiş olabilir ya da tam aktarım almadan siz projeye dahil olmuş olabilirsiniz. Bu noktada kodun çalışma sürecini uçtan uca anlayabilmek için debug, Find All Reference vs. desteği ile beraber kodun nasıl bir süreç izlediğini anlayabilmek hayatımızı oldukça kolaylaştıracaktır. Önceki yazılımcının temiz kod yazmış olması sonraki yazılımcılara güzel bir miras olacaktır. Sektör içi dayanışma için temiz kod yazmaya çalışalım 🙂

Image result for code review funny

Problem Çözme

Yazılım geliştiriciler olarak işimiz her zaman yeni bir yazılım üretmek olmuyor elbette. Yazıp üretim ortamına aldığımız projelerde problemler ortaya çıkabilir ya da var olan projelerde çıkan problemlere bakmamız gerekebilir. Problem çözme süreci başlı başına anlatılacak, üzerine çalışılacak bir konu bence. Süreci yönetme, problemin tespiti, problemin kritiklik ve aciliyeti, problemin düzeltilmesi ve üretim ortamına alınması.

Süreç Yönetimi

Aslında süreç yönetimine problem çözme alt başlığı altında değinmiştim. Ancak ayrı bir başlık olarak da eklemem gerektiğini düşünüyorum. Çoğunlukla yaşayan bir yazılım ürünü ya da yeni yeni yeşeren, yeni başlanmış projelerde çalışıyoruz. Bu projelerle ilgili yöneticilerinizin hedefleri, müşterilerin beklentileri, -büyük ölçekli bir proje ise – şirket planları, proje yönetimi ekiplerinin planlamaya uygun ilerlemesi ve kendinizin yazılımcı olarak tatmin olma beklentileriniz oluyor. Tüm ürün oluşturma sürecindeki yazılımcı dışındaki analist, testi yapan, Önyüz geliştirici, kabul testlerini yapan müşteri tarafını da düşündüğümüzde yazılım geliştirme sürecinin çok fazla paydaşı oluyor. İyi günlerde zaten bir problem olmuyor ama kötü günde bu paydaşların büyük bir kısmı ile olan iletişimi iyi yönetmeniz gerekiyor. Bu biraz da zamanla ve tecrübe edinmeyle gelişen bir beceri olsa da bu yetkinliğin farkında olmak ve kendimizi bu konuda geliştirmenin önemli olduğunu düşünüyorum. Önceki cümlelerde kötü zamanlarda süreç yönetimi ve iletişim oldukça önemli olduğundan bahsetmiştim. Bir ekleme daha yapayım: İyi yaptığınız işleri de bu profesyonellikte ifade edip, farkındalık yaratmanız da oldukça önemli.

Empati

Yazılımını gerçekleştirdiğimiz ürünleri kimi zaman biz de kullanıyor olabiliriz ama çoğunlukla müşteri/kullanıcı diye isimlendirdiğimiz başka insanlar geliştirdiğimiz ürünleri kullanıyor. Bunun dışında geliştirme sürecinde beraber çalıştığımız başka insanlar da olabiliyor. Onlarla empati yapabilme, ihtiyaç ve varmak istedikleri noktayı anlamak açısından empati önemli. Bu başlık eleştirilmeye müsait; daha fazla uzatmadan bir sonraki başlığa geçeyim 🙂

Image result for empathy 6

İşbirlikçilik

Yazıyı yazarken farkediyorum ki aslında başlıkların bir çoğu birbiriyle ilişkili. İletişimi sağlıklı kurmanız ve süreç yönetimi iyi yönetmeniz doğal olarak sizi işbirlikçi bir çalışan yapacaktır. Bununla beraber kimi  zaman başka ekiplerle, başka firmalarla çalışmak zorunda kalabilirsiniz; ya da agile çalışıyor ve sprinte başlamışken sizden bir iş talebinde bulunan başka bir ekip olabilir. Bu durumlarda planlamanızı yapıp işbirliği içerisinde çalışmak da hem o gün için takdir edilmeyi hem de imajınızın iyi olarak anılmasını sağlar.

Çok Yönlülük

Bu başlık daha iyi programcı olmak için gerek olmayabilir. Ancak vizyon sahibi olma, farklı düşünme, farklı yönleri görebilme gibi önemli becerilere sahip olmanın önemli ve insanı bir adım öne çıkarabilecek özellikler olduğunu gözlemliyorum. (Öne çıkma derdi olmasa da güzel yetkinlikler bence 😀 ) Bu açıdan kendisini her açıdan geliştirmeye çalışmanın önemli olduğunu düşünüyorum. Buradaki maksadım her alanda iyi olun; her şeyi bilin demek değil elbette. Her konuda iyi olamazsınız ama mesleğiniz, hobileriniz ile ilişkili alanlarda biraz bilgi sahibi olup, bu bilgi neticesinde konuşabiliyor olmanın da bir yazılımcı açısından önemli bir özellik olabileceğiniz düşünüyorum. Başta dediğim gibi bu biraz daha genel bir özellik.

Başta söylediğim gibi bu konu, oldukça geniş ve saydığım özelliklerin dışında bir çok özelliği belirtebileceğimiz bir konu. Tabi kimisi de “ben yazılımcıyım; kodumu yazar gerisine karışmam diyebilir ” ki bunu küçük ve orta ölçekli firmalar da düşünmek bile mümkün değil ama büyük, iş tanımları net olan kurumsal firmalarda bile söylemek bana pek mümkün gelmiyor. Bu yazıyı yazmama sebep olan daha geniş yazının linkini tekrar buraya bırakıyorum.  Bu yazıyı o yazının tercümesi olarak değil; tecrübelerim neticesinde yazmaya çalıştım. Umarım faydalı olur 🙂

Dependency Injection

Debug ve Temiz Kod yazılarından sonra ismini sıkça duyduğumuz, adını bilmeden uyguladığımız ya da tam da uygulanması gereken noktalarda özen göstermediğimiz Dependency Injection konusunda yazmak istedim. Şu ana kadar yazmaya çalıştığım konular zemini sağlam yapmaya yarayacak konular oldu. Temiz kod yazımı, SOLID prensipleri, birim testlerin önemi ve Debug yapabilmek doğrudan kod yazmayı değil yazılmakta olan ya da var olan kodlar bütününü daha doğru şekilde yazmayı amaçlamanın neticesinde oluşmuş yazılardı. Bir önceki yazımızı SOLID Prensipleri ile bitirmiştik. Bu yazıya önceki yazıda bırakmış olduğumuz noktadan başlayalım.

SOLID diye kısaltılan prensiplerin en sonundaki harf tarafından temsil edilen Dependency Inversion Principle ile tümüyle aynı şeyleri ifade etmese de benzer amaçları olan Dependency Injection kavramına değinmek istiyorum.

dependencyinjectioncaps

Yazının başında ifade ettiğim gibi Dependency Injection kavramı bilerek ya da bilemeyerek de olsa bir çok yazılım geliştiricinin uyguladığı bir desendir. Kodun okunabilirliği ve mimarinin kurgulanması açısından yazılım geliştiricilere fazlasıyla yardımcı olan bir desendir. Dependency Injection, kodun aritmetiğini işin kitabına uygun ve verimli şekilde yapmayı amaçlayan bir konu. Dependency Injection’ı kısaca açıklayacak olursak projemizin dışarıya bağımlı olmasıdır. Fazlasıyla kısa bir ifade oldu sanırım 🙂 Bu bağımlılık bir fremawork, dll, obje, konfigürasyonlar, statik tanımlamalar, new keywordü ile yaratılan nesneler, email servisi, log servisi, sistem kaynakları (sunucudaki tarih,saat vs.) veya third party bir ürün olabilir.

Uygulamalar geliştirilirken ihtiyaçlar kapsamında yukarıda bahsettiğim dışa bağımlı kısımlar olabilir. Dependency Injection bu bağımlılıkları aza indirgeyip yönetilebilir hale getirilmesini amaçlar. Dependency Injection ile uygulamanın bağımlı olduğu alanları uygulamaya enjekte ederken enjekte edilen alanların dinamik olarak değiştirilmesine olanak sağlanması hedeflenir. Yapılan bir işin ihtiyaç duyulan başka çalışmalara mümkünse hiç değişiklik olmadan uyarlanabilecek şekilde tasarlanmış olmasıdır. Loosely coupled (gevşek bağlı) tasarım prensibi dikkate alınarak yazılım içerisinde kullanılan obje, sınıf ya da komponentler değişiklik taleplerine cevap verebilecek şekilde tasarlanmalıdır. Dependency Injection bakımı daha kolay yapılabilir, test edilebilir, loosely coupled (gevşek bağlılık) kod yazmayı amaçlayan bir desendir. Solid prensiplerine uygun kod yazılmasını sağlar. Dependency Injection deseni dikkate alınmadığında uygulama büyüdükçe yapılacak küçük değişiklikler bile uygulamanın bir çok yerini etkileyebilir ve etki analizi büyük olabilir. Dependency Injection desenine uyulmadığında her yeni veya değişiklik ihtiyacı için geniş geliştirme yapmak gerekecektir. Bu durumda bir süre sonra var olan yerlerde değişiklik yapmaktansa yeni classlar oluşturmak gibi yollara gidilebilir ki bu da uygulamada gereksiz kodlama veya karmaşıklığa sebep olur. Bir süre sonra Lemi Orhan’dan alıntıyla ifade edecek olursak “Kod’dan kötü kokular gelmeye başlar.”

Bir genelleme yapmak istemem ama galiba toplumumuzun genel bir özelliği kervan yolda düzelir düşüncesi bir çok yazılım projesinde de kendisini gösteriyor. Uzun süren toplantılar, hazırlanan analiz dökümanları, net olarak belirtilmeyen use case’ler ve oluşturulmayan mimari sebebiyle bir çok proje yapım aşamasında olgunlaşıyor.  Oysa ki başta use case’lerin belirlenmesi, mimarinin tasarlanması ve bağımlılıkların ortaya konulması projenin daha net iterasyonlarla devam etmesine katkı sunar. Aksi takdirde süreç içerisinde yeni isteklerle, öngörülmeyen ihtiyaçlarla proje sürekli yeniden düzenlenmek zorunda kalır. Dependency Injection deseni biraz da sonrada gelecek ihtiyaçlara hızlı entegrasyonun sağlanmasına katkıda bulunur.

DI tasarım deseni sayesinde aşağıdaki sorular cevaplanmış olur.

  • Bir uygulamanın nesnelerinin nasıl oluşturulduğundan bağımsız olarak nasıl olabilir?
  • Bir sınıf, ihtiyaç duyduğu nesnelerin nasıl oluşturulduğundan bağımsız nasıl çalışabilir?
  • Nesnelerin oluşturulma şekli, ayrı yapılandırma dosyalarında nasıl belirtilebilir?
  • Uygulama farklı konfigürasyonları nasıl destekleyebilir?

Avantajları :

  • Kod bağımlılığını azaltır
  • Kodun tekrar kullanılabilirliğini artırır.
  • Kodun sürdürülebilirliğini artıtrır
  • Uygulama testinin yapılabilmesini kolaylaştırır.
  • Sınıf birleştirmeyi azaltır
  • Merkezi yapılandırma

Dezavantajları

  • Karmaşıklık katabilir. Çünkü her şey metod ya da sınıfın içerisinde yazılmamıştır.
  • Öğrenmek, kodu anlamak biraz vakit alabilir.

Dependency Injection için yazmış olduğum kod projesine github adresimden inceleyebilirsiniz.

Temiz Kod

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.

Martin Fowler

Debug yazısından sonra bu yazıda kodun okunurluğu açısından son derece önemli olan temiz kod konusuna  değinmeye çalışacağım. Temiz Kod’dan kastın ne olduğu, Temiz Kod’un avantajları, temiz kodun nasıl yazılacağı gibi sorulara deneyim ve araştırmalarım neticesinde oluşan bilgilerimi aktarmaya çalışacağım. Çoğu kulağımızın aşina olduğu, bilip de bazen dikkat etmediğimiz pratikleri bu yazıyla not etmiş olacağım. Bu yazıyı yeni öğrendiğim ya da deneyimlediğim tecrübelerim neticesinde sürekli güncellemeye çalışacağım. Bu yazıyı okumaya devam ediyorsanız, muhtemelen bir yazılımcı ya da yazılımcı olmaya niyetli birisiniz. Bu yazının amacı işte daha temiz bir yazılım yapmak, temiz yazılım yapmanın neticesinde daha iyi bir yazılımcı olmak.

Öncelikle temiz kod yazımı bugünden daha fazla geleceğe yatırımdır. Yarın daha fazla zaman harcamamak için kodu yazarken temiz kod için vakit ayrılmalıdır. Temiz kod, prensipleri basit ama biraz vakit alıcı, üzerinde düşünülmesi gereken bir konudur. Temiz kod yazmada temel amaç kodun basit ama verimli, okunulabilir, test edilebilir ve yeni ihtiyaçlara uyarlanabilir olmasıdır. Temiz kod yazmak sizden sonra gelecek yazılımcının kodu anlayabilmesi ya da ileride çıkabilecek herhangi bir problemde kodu anlamada oldukça yardımcı olacaktır. Buradan hareketle sadece çalışan kod yazmak hedef olmamalıdır. Kodu yazmak kadar geliştiricilerin kodu okuyup, anlayıp, yeni ihtiyaçları ve bakımını kolay yapabilecekleri şekilde yazılmasıdır. Kurumsal firmalar, büyük modül ve projelerde bu daha da önemlidir. Bu amaçla bazı firmalar KGG’si yapılmamış, standartlara uygun olmayan kodların üretimine izin vermeyen toollar kullanmaktadırlar.

Kod yazma sürecinde uzmanlaştıkça programın çalışması işin tamamlanması açısından yeterli olmaktan çıkıyor.  Yeni kodlamaya başlayan ,Junior bir geliştirmeci için kodun çalışması yeterliyken; yıllar geçtikçe  kodun doğru bir şekilde çalışmasının yanında performans, kodun okunabilirliği, unit test gibi kavramlar önem kazanmaya başlıyor. Bu iki farklılığı kavramlaştıracak olursak; birisi Programlama iken diğeri İyi Programlama olarak ifade edilebilir. Kodun çalışmasını referans almak günü kurtarabilir ama daha sonra gelen bir hatayı anlama ve çözme ya da yeni bir geliştirmecinin orada çalışma ihtiyacı doğduğunda oldukça problemli bir hal alacaktır.

Yukarıda saydığımız tüm gerekçeler neticesinde temiz kod yazmak bir ek katkı değil zorunluluk haline geliyor. Programlamanın sanat olduğuna inanan birisi olarak Donald Knuth’ın alıntısıyla söylemek istediğimizi daha net ifade edelim.

Programming is the art of telling another human what one wants the computer to do.

Donald Knuth

Kodun da bir eser olduğunu düşünüyorum. Ve bu eserin başkalarına bir şeyler ifade etmesi eseri daha da kıymetli hale getirir.

Bu kadar  Temiz Kod Dedikten sonra temiz kodun özellikleri nelerdir onları sıralayalım :

  1. Okunması kolay olmalı. Okurken kod parçaları arasında kaybolmayıp, bir parçanın bütünün keşfeder gibi okunmalı
  2. Net olmalı. Her bir sınıf, entity, business katmanı ya da metod sadece bir amaca hizmet etmeli.
  3. Bakımı yapılabilir olmalıdır. Bakımı yazımından daha zor olacak kodlardan kaçınmalıyız 🙂
  4. Tüm testlerin başarılı bir şekilde tamamlaması
  5. Tekrar (duplicate ) olmaması
  6. Kullanılmayan kodların olmaması.

Kodumuzu bu maddelere uygun yazıp sonuçlandırdık. Peki bu şekilde  Temiz Kod yazmanın bize avantajları ne olacak diyecek olursak;

Temiz kod’un avantajları

  1. Kod parçalarının amacının ne olduğunu anlamayı kolaylaştırır.
  2. Uygulamanın akışını kolaylaştırır
  3. Farklı objelerin birbiriyle nasıl çalıştığını anlamayı kolaylaştırır
  4. Her class, entity ya da metodun rolünü ve sorumluluğunu anlamayı kolaylaştırır.
  5. Refactor, bugları bulma ve kodu düzenlemede hızlı aksiyon almaya yardımcı olur. Bakımı kolaylaştırır. Zaman kurtarır.
  6. Kodun değiştirilmesini, yeni ihtiyaçları hızlı entegre etmeyi sağlar.
  7. Kodun testini kolaylaştırır. Unit testleri anlama ve yazmada kolaylık sağlar.
  8. Yeni geliştirmeler için efor tahmin etmeyi kolaylaştırır. Beklenmeyen durumlarla karşılaşma olasılığını azaltır.
  9. Kodda sıkılmadan geliştirme yapmanızı sağlar. Temiz olmayan bir kodda geliştirme eziyete dönüşebilir çünkü. Eziyettir. Lemi Orhan’ın ifadesiyle o kod kokmaktadır. Ve kötü kokan bir kodda yazmak istemezsiniz.

Temiz Kod yazmada en önemli hususlardan birisi isimlendirmedir. Doğru yapılmış bir isimlendirme metodu incelemeye gerek bırakmayabilir. Ve bu da vaktinizi size bırakır. İsimlendirme oldukça zaman alan bir uğraş. Ancak doğru verilmiş bir isim daha sonra ayıracağınız zamanı size bırakır. Değişken, sınıf ya da fonksiyon ismi onunla ilgili sorulara cevap vermelidir. Neden olduğu, ne olduğu, nasıl kullanıldığını anlatmalıdır. Eğer bu soruların cevaplarını yorum ile yazıyorsanız isimlendirmeniz eksik kalmış demektir.  List gibi genel ifadeler yerine customerCardList gibi daha net ifadeler kullanılmalı. Önek ya da altçizgi gibi ifadeler kullanılmamalıdır. Şimdi sırayla değişken, sınıf, metod isimlendirmelerini ele alacağız.

Değişken İsimleri :  Anlamlı, aranabiliyor olmaları kolay bulunması açısından  önemlidir. (startDt yazmak yerine startDate). Açık, anlaşılır olması teknik bir ifade olmasından iyidir. Değişkeni tanımladığınız sınıf ya da obje isminde kullanılan bir ifadeyi değişken adında tekrarlamaktan kaçınılmalıdır. GetCustomer metodunda müşteri bilgisi atanan bir değişkeni Customer öneki eklemek fazlalık olacaktır.  Bazı metod değişkenlerinin default atamaları vardır. Değişken default atamaları  parantez içerisinde değişken yazılırken atamasını yapılmalıdır.

Sınıf İsimleri: Sınıf isimleri isim veya isim türevli ifadeler olmalıdır. Genel ifadelerden kullanmak yerine sınıfı ifade eden isimlendirmeler yapılmalıdır. Sınıf ismi sıınf içerisindeki metodların üst başlığı gibi görülmelidir.

Metod isimleri : Metod isimlerinin bir fiil ile başlaması daha doğru olacaktır. GetCustomer,DeleteCustomer,SaveCustomer, CreateCustomer gibi. Metod ismi metodun işlevini net olarak ifade etmelidir. İsimlendirme son derece kibar veya sert olmalıdır. (Üniversite birinci sınıf BMG dersi kodlama sınavında nasıl nazik bir sonuç yazdırdığımı hatırlayan arkadaşlar bunu daha iyi anlayacaklardır. Zira halen gülme konusu olur bu nazik uyarım :))

Metodlar : Fonksiyonlar öncelikle tek bir amaca hizmet etmelidir. İkinci olarak metodlar kısa olmalıdır.  Max sınır olarak tüm metodun ekranda tek seferde görüntülenmesi gibi bir varsayım konulsa da mümkün olduğu kadar kısa, okunabilir ve amaca hizmet etmelidir.  Metodlar ile ilgili yorum yazmaktan kaçınılmalıdır. Gerçekten yazılması zorunluysa yorum yazılmalı.  Eskiden metod üzerine vs’nin default verdiği syntax ile yorum yazmanın faydalı olduğunu düşünürdüm ve uygulardım. Ancak zamanla kodun kendisini anlatması gerektiğini düşünmeye başladım. Metodlar ile ilgili yorumlar sadece business bilgisi ya da bilinmeyecek bir yazılım kullanımı yapılmışsa yazılmalı.  Aksi takdirde KOD KENDİSİNİ ANLATABİLMELİ.

Metod içerisinde koşul ifadeleri ile de birkaç cümle yazarak metod kısmını da tamamlayalım. Bazen if, switch koşullarında oldukça uzun kontroller yapılıyor. Satırlar süren, or ve and keyleri ile zincire dönen koşulları bir if() parantezine sığdırmak kodu okunur olmaktan çıkarıyor. Bu durumlarda koşulları yeni bir metod yapıp buradan çağırmak hem okuma hem anlama açısından daha sağlıklı olacaktır.

Metod değişkenlerinin sayısı : Bunun için 2 diyeni de duydum, üç diyeni de, dört diyeni de duydum. Dörtten fazla alabilir diyeni duymadım ama gözlerim üç dört satır değişken alan fonksiyon gördü J  Bir fonksiyon üçten fazla değişken almamalı. Bu sayı mümkün olan minimum sayıda tutulmalı. Eğer üçten fazla değişken bekleniyorsa da değişkenleri barındıran bir obje tanımlanıp oluşturulan obje tipinde bir değişken gönderilmelidir.

Temiz kod açısından yazılım bileşenlerinin isimlendirmelerine tek tek değindik. Şimdi de OOP açısından da önemli olan SOLID’ten kısaca bahsedelim.  SOLID,  OOP projelerinin standartları olarak bilinir. Kendisini oluşturan maddelerin baş hraflerinden oluşur:

S – Single Responsibility Principle (SRP): Her nesnenin sadece bir sorumluluğu olmalı, tek bir amacı olmalıdır. Herhangi bir değişiklik yapıldığında bu nesnenin amaç ya da sorumluluğunun değişmesinden dolayı olmalıdır.

O – Open/Closed Principle (OCP): Yukarıda belirtmiştik.; Metod düzenlemelere, yeni şart ve güncellemelere açıktır. Ancak metod ya da nesnesin varlık sebebini etkileyecek değişiklikler yapılmamalıdır.

L – Liskov ‘s Substitution Principle (LSP): Türetilen bir nesnenin türetildiği sınıfın metodlarını kullanmasıdır.

I – Interface Segregation Principle (ISP): Nesnelerin ihtiyaç duymadıkları Interface’ten ayrılması ilkesidir.

D – Dependency Inversion Principle (DIP): Yüksek seviyeli sınıfların daha düşük seviyeli metodlara bağımlılığının olmamasıdır. Alt sınıflardaki değişiklikler üst sınıfları etkilememilidir.

Toparlayacak olursak ; Temiz kod kodun kaliteli olması açısından önemli ve vakit ayrılması gereken bir aşamadır. Tabi bunu söylerken çok temiz kod yazacağım diye aşırı titiz davranmak da gerekmez. Temiz kod yazımı dikkat edilmesi durumunda zamanla gelişecek bir çalışma. İlk denemede olmayabilir, dolayısıyla üzerinde çalıştığımız kodu geliştirmek için her zaman çaba göstereceğimiz bir zihniyet benimsememiz gerekiyor. Yazılan kodun temiz kod açısından yeterince iyi olduğunda karar verdiğimizde yeni koda devam etmeliyiz.

Kaynaklar:

https://medium.com/mindorks/how-to-write-clean-code-lessons-learnt-from-the-clean-code-robert-c-martin-9ffc7aef870c

https://github.com/ryanmcdermott/clean-code-javascript

https://cvuorinen.net/2014/04/what-is-clean-code-and-why-should-you-care/

Debug yapmak derde deva mı yoksa cefa mı ?

Uzun süredir ara verdiğim blog yazılarına bu yazıyla yeniden başlama niyetindeyim. İlk konu olarak da sevdiğim bir konu olan Debug ile başlamak istedim. Umarım arkası da gelir 🙂  İşe Debug kavramını tanımlayarak başlayalım: Debug, bir yazılımda beklenilenin dışında çalışan, kodun çalışmasına engel olan veya olması muhtemel hataların saptanması ve kaldırılması sürecidir. Debug bir yazılım veya sistemin hatalı çalışmasını önlemek için hata veya kusurların bulunup çözülmesi için yapılır. Küçük boyutlu yazılımlarda debug ile hata ayıklama nispeten kolayken; alt sistem veya modüllerden oluşan bir yazılımın debug edilmesi daha zor ve vakit alıcı olacaktır. Bu durumda bir modülden yapılan herhangi bir değişikliğin diğer modüllerde hataya sebep olabileceğinden, debug ve etki analizi daha da önemli bir hale gelmektedir. Etki analizi demişken unit testlerin yazılmazı ve ölçeklenebilirlik konularının ayrı bir yazı konusu olduğunu ekleyerek yazımıza devam edelim.

Birkaç ay önce twitter’da sektördeki bir çok insanın görüş bildirdiği bir Debug yapılmalı mı ? yapılmamalı mı ? minvalinde bir tartışma başladı.

Her şey bu tweetle başladı 🙂 Ve twitterda bizim sektörde gördüğüm en çok görüş bildirilen tartışmalaradan biri böylece start aldı 😀

Gerçekten de debug yapıyorsak; kodu anlamamış mı oluyorduk. Debug yaparken kodu anladığımızı düşünüyorsak, aslında debuga ihtiyacımız yok mudur ? şeklinde soruları soran bir tweetti. Oldukça iddialı bir fikir olsa da oluşturduğu tartışma ortamı açısından faydalı bir tweet oldu. Bu fikre destekleyen kullanıcılar olduğu kadar çoğu kullanıcı da kendi argümanlarıyla bu fikirlere karşı çıktı.

Debug yapmayla ilgili bu faydalı tartışmayı geride bıraktığımıza göre şimdi yazımızın esas konusu olan Debug ve debug pratiklerine gelebiliriz.

Debug yapmanın faydalı olduğunu düşünen biri olarak yazının bu kısmından sonrası bunun gerekçelerini anlatmaya çalışacağım. Debug (hata ayıklama), kodun satır satır nasıl işlediğini gösterir. Bir nevi kodun sonuca hangi adımlardan geçerek gittiğini bize gösterir. Sonuca giden yolu bulmanın daha kolay yolları da olabilir.

Eğer kodumuz standartlara uygun yazılmış, okunabilir bir kod ise debug yapmaya gereksinim duymadan da kodun nasıl çalıştığını görebiliriz. Küçük sistemler ya da kod blokları için bu mümkündür. Ancak büyük sistemlerde kod okunur olsa bile kodun çalışma mantığını kavramak daha zor olabilir. Üstelik debug yapmadan birbirini çağıran kod bloklarını okuyarak ne yaptığını anlamaya çalışmak vaktimizin boşa geçmesine neden olabilir. Çünkü kodu gözle okurken kodun çalışmasını engelleyen bir durumu göremeyebiliriz. Kodu okurken yeterli gördüğümüz kontrollerden birini kod hata veriyor olabilir. O yüzden debug yapmayı son başvurulacak çözümlerden biri olarak görmüyor; aksine bir çok zamanlar ilk başvurduğum inceleme şekli oluyor. İki durumda debugger’ı kullanıyorum.

  1. Mevcut, çalışmakta olan bir kodu devraldığımda
  2. Hata ayıklamada

Bir projeye sonradan dahil olduğunuzda ya da know-how bilgisine sahip birisi olmadığında kodun nasıl çalıştığını, hangi aşamalardan geçtiğini görmek için debug etmeyi tercih ediyorum.

Hata ayıklamada ise öncelikle exception veya log bilgisinden hatanın sebebini anlamaya, kodun hata verdiği kısmı incelemeye çalışıyorum. İlk aşamada problemi tespit edemeyince case’i oluşturarak debug yapıyorum.  Daha önceden bilmediğim bir sistemde debug yapıp sonuç elde edince keşif yapmış gibi mutlu oluyorum 🙂 Tabii bir de mutsuz eden sonuç vermeyecek debug süreçleri oluyor. Özellikle karmaşık sistemlerde debug yapmak bazen o ihtiyaç için gerekli yazılımı yapmaktan daha uzun süre alabiliyor.

Verimli ve etkili debug yapabilmek için bazı adımlar var: Kimisi altı kimisi yedi adım diyor. Yazmaya başlayalım bakalım kaç olacak 🙂

  1. Problemi gerçekleştirebiliyor, yeniden oluşturabiliyor olmak. (Benim localde çalışıyor diyenler; haklısınız bende de çalışıyor ama hep çalışması gereken kişilerde çalışmıyor )              
  2. Hatayı kullanıcısından  tanımla : Hatayla karşılaşılan kullanıcıdan hatayı hangi aşamalarda, hangi işlemi yaparken aldığını anlamak. Hatanın kesin nedenini tam anlamak için kullanıcıdan mümkün olduğu kadar detay almaya çalışın.
  3. Hata alındığındaki durumda olan durumu not et. Programında tüm değişken değerlerini ve durumlarını o anda almaya çalışın
  4. Hatayı oluştur.
  5. Bir üst maddedeki duruma göre analizi yaparak hatayı bulmaya çalışın.
  6. Mevcut hatayı fixleyin             
  7. Testlerinizle hatanın fixlendiğine emin olun.
  8. Çalışmanızın yeni bir hataya sebep olmadığını kontrol edin.
  9. Son olarak bu çalışmanızı bir yere not alarak dökümante edin. Daha sonra benzer problemlerle karşılaşıldığında hızlı aksiyon alınmasını sağlar.

Debugdan bahsettiğimiz bu yazıda doğru hata mesajları fırlatmanın önemine değinmemek olmaz. Öncelikle mümkün mertebe hataya sebep olabilecek caselerin kontrol yapılarıyla kontrol edilmesi sağlanmalıdır. Öngörülemeyen durumlarda ise  exception döndürmemiz gerekiyor. Exceptionları doğru şekilde fırlatmak üst katman, log ve son kullanıcıda anlaşılır olacak şekilde handle edilmesi problemin sebebini hızlıca saptama noktasında oldukça fayda sağlayabilir. En basitinden ex’ı döndürmek yerine ex. Message şeklinde dönüş yapılması küçük, basit görünse de mesajın daha çabuk anlaşılmasını sağlayacaktır. Ayrıca hata ayıklama da try catch ile kontrollerin yapılmasındansa kontrol yapılarıyla kontrollerin yapılması performansa da olumlu yönde katkı sunacaktır.

O sebeple öngörülen tüm hata case’lerinin kontrol yapılarıyla kontrol edilmesi, öngörülemeyen caseler için exception fırlatılması tercih edilmelidir. Burada da direkt Exception yerine belli amaçlara hizmet eden exception class’larının fırlatılması daha doğru olacaktır.

Yazının son bölümünde ise  debug yapanların aşikar olduğu Visual Studio’nun bir kaç özelliğinden bashetmek istiyorum.

Breakpoint: Breakpoint, Debug’un temel taşı diyebiliriz. Kodun execute zamanında durmasını istediğimiz kısımda durmasını sağlar. Uygulamanızın çalışması esnasında süreç bu kod satırına geldiğinde durur. Debug adımlarıyla bundan sonraki sürecin işleyişi kontrol edilir.

Condition :  Breakpoint konulan satırda belli şartlar sağlandığında durmasını sağlar.
Watch window: Değişkenlerin değerlerinin görüntülenebileceği kısımdır.
Locals window: Lokal değişkenlerin değerlerini gösteren kısımdır.

Immediate Window: Değişkenleri görüntüleme, kod yazabileceğimiz penceredir.
CallStack : Stack içerisinde kullanılan fonksiyonları görüntülemimizi sağlar. Bu sayede sürecin nasıl olduğumuz noktaya geldiğini görebiliriz.

Kaynak :

https://www.codementor.io/mattgoldspink/how-to-debug-code-efficiently-and-effectively-du107u9jh

https://economictimes.indiatimes.com/definition/debugging

Balkan Turu

Balkanlar kocaman bir coğrafyanın adı. 12 ülkeden oluşan bu büyük coğrafyanın bir kısmında bizim de topraklarımız var. Balkanlar denilince aklımda yeşillik ve tarih beliriyordu. Gidip geldikten sonra bu ikisine bir de Sakinlik eklendi. Beş gün süren gezi boyunca küçük-büyük yedi sekiz şehir gezdik. Karadağ oldukça sakin ve yaz dönemi yeri gibiyken; Bosna Hersek bir bahar ülkesi gibi. Balkanlardan gelen soğuk hava dalgasının aksine içim sıcacık dolmuş bir şekilde döndüm bu geziden.  Giderken böyle bir yazı yazmak gibi bir niyetim yoktu. Aklımda kalanları paylaşacağım bu yazı hem güzel bir anı hem de gitmek isteyen olursa küçük bir rehber olur.

Gezi boyunca dikkatimi çeken bir kaç şeyi belirterek yazıya geçeceğim. Neredeyse her yerde çekik gözlü (farklı ülkelerden de olsalar bu sevimli ortak özelliğe sahipler) turistler ile karşılaşmak mümkün. Tur rehberlerini canı gönülden dinliyor ve sıkça fotoğraf çekiyorlar. Karadağ’da bu turistlere Avrupa ve dünyanın başka yerlerinden de turistler katıldı. Çoğunlukları yaşlıydı. Gençken çalışıp yaşlanınca geziyor insanlık 🙂 Bir diğer gözlemim ise insanlar çok sakin abi hele ki İstanbul’un koşturmaca, kargaşasına, insanların yüzündeki ifadesizliğe alışınca oradaki insanlar oldukça sakin göründü gözüme. Bir gezi yazısının girişi iki paragraf oldu bile hemen yazıya geçiyorum.

9:30 saatinde kalkan uçak ile yerel saatle 10:20 gibi Saraybosna’ya indik. Saraybosna ile Türkiye arasında bir saatlik zaman farkı var. Beklediğimden daha az sayıda olsa da pasaport sırasında Türkiye’den ziyaretçiler görmek mümkün. Niçin geldiniz ?, dönüş biletleriniz hazır mı ? şeklindeki bir kaç sorudan sonra pasaport kontrol noktasını geçerek Bosna Hersek toprağına giriş yapmış olduk. İlk iş olarak araç kiralamak için havaalanında bulunan rent a car firmalarından araç baktık. Yan yana dizilmiş firmaların kiralama ücretleri fazla gelince merkezden kiralamaya karar verdik. Havaalanından merkeze gitmek için iki seçenek var: 3€ ücretli otobüs ya da 15€ civarı bir ücretle taksi. Havaalanının önünden kalkan otobüsle Saraybosna merkeze gittik. Yaklaşık yirmi dakika süren bu yolculukta şehrin 1992-1995 yıllarında 3 yıl süren, savaş zamanından kalma çok sayıda hasarlı bina görmek mümkün. Şehir merkezinde de bu binalardan çok sayıda görebilirsiniz. Şehir savaşı unutturmamaya çalışır gibi. Gölgesi bitmemiş bir savaşın izleri dolaşıyor şehirde.

DSC_0002

Delik deşik olmuş bir binanın tek bir penceresine yerleşmiş çiçekler nasıl da canlı kılıyor binayı. Pencereleri tek açık olan kat olmasına da dikkatinizi çekiyorum. Fotoğrafın adı “Çiçekten Yara Bandı” olsun.

DSC_0003

Şehrin merkezine yakın mesafede olan ulusal kütüphanenin önünde indik. Şehrin görkemli binalarından biri olan bu kütüphanedeki yazma eserler 92 savaşı sırasında atılan bombalar sonucu imha olmuş. Daha sonrasında başçarşı denilen kısıma geçtik.

 

DSC_0316

Başçarşı Anadolu’da herhangi bir yerde görebileceğiniz naiflikte yabancılık hissettirmeyen bir alan. Gezi listemizde olan Mrkva ‘da meşhur Cevabi köftesi yedik. Lezzetli olmasına rağmen yanında soğan yerine daha farklı bir şeyler aradı gözüm 🙂  Araç kiralama için merkezde yer alan rent a car bürolarına geçip aracımızı güler yüzlü, yardımsever bir amcadan kiraladık. Bir miktar depozito isteyeceğini düşünüyorduk ama teslim ederken tüm parayı verirsiniz demesi de ayrı bir güzellik oldu. Tatil boyunca gerek Bosna gerek Karadağ’da tanıştığımız insanlar oldukça yardımseverdi. Saraybosna gezisini son güne bırakacağımız için başçarşıda biraz dolaştıktan sonra aracımızı alarak savaşta yüz binlerce kişiye umut olan Yaşam Tüneline geçtik.

DSC_0014

Yaşam Tüneli, Saraybosna’nın Sırp kuvvetler tarafından kuşatılması sırasında sivillerin kurtarılması ve silahların taşınması için bulunmuş çözümlerden biri. Kuşatmanın en yoğun olduğu 1993’de 4 ay 4 günde bitirilen tündel 1 metre genişliğinde ve ortalama 1.5 metre yüksekliğinde ve 800 metre uzunluğundadır.

DSC_0022

Savaş sırasında günde ortalama bin kişinin geçtiği tünel Saraybosna’nın kuşatmadan en önemli çıkış yolu oluyor. Hemen havaalanının yanında yer alan tünel yüz binlerce kişinin hayatta kalmasını sağladığı için Yaşam Tüneli olarak adlandırılmış. Tünelin yirmi metrelik kısmını yürümek bile bende bir an önce çıkma isteğini uyandırmışken insanların ne zor şartlarda hayatta kalmaya çalıştığını anlamayı sağlıyor. Yaşam Tüneli evinin hemen önünde Saraybosna’nın farklı yerlerinde bulunan kanlı Saraybosna güllerinden bir tanesi yer alıyor.

Yaşam tünelinden sonra Konjiç’ e geçtik. Yol üzerinde bal, ayva armut satan seyyar satıcılar bulunmakta. Meyveleri oldukça lezzetli 🙂

Konjic ise Mostar’a geçmeden önce uğranması gereken güzel bir yer. Kısa süre burada kalmamıza rağmen güzel kafeleri ve mekanlar gördük. Türkiye – Tika – etkisini en çok gördüğüm yer burası oldu. İkinci dünya savaşı sırasında yıkılan tarihi köprü Türkiye’nin de yardımlarıyla yeniden yapılmış.

IMG_6627

Yakınlarında TIKA levhası ve biraz ötesinde Boğaziçi köprülü İstanbul resmi ile Konjic köprüsünü bir arada bulunduran büyük bir duvar resmi bulunuyor.  Burada dikkatimi çeken bir şeyde cami avlusunda yer alan mezarların üzerinde güzel, zanlı çiçekler olması. Rengarenk ve capcanlı görünen çiçeklerdi. Köprünün üstünde fotoğraflar çektirirken yolun ortasında bir adam gelinlik giymiş kıza yeniden evlilik teklifi yapıyor gibi dizlerinin üzerine çöktü ve kız da kabul ediyorum tarzı bir şeyler söyledi. Ve düğün konvoyu geldi sokağın başından. Garip şeyler 🙂 Gelin konvoyu tıpkı eski düğünlerimiz gibiydi. Araçlardan atılan şekerlerden alamasam da tatlı bir anı bıraktı hafızamda.

IMG_6603

Sonrasında bloglarda çokça anlatılan kuzu çevirmesi ile meşhur Jablenika’da ki Kovacevic Restaurant’a  geçtik. Uygun fiyatlara güzel bir mekanda kuzu çevirme yiyebilirsiniz. 1 kg kuzu etini nasıl yedik bilemiyorum 🙂

kovacevic

Kuzu çevirmeleri izlemeyi de ihmal etmeyin.

20171014_203846Aslında Jablanica’da gezilecek güzel yerler varmış ama biz akşam vardığımız için kuzu çevirmemizi yiyip Mostar’a doğru yolumuza devam ettik.

Mostar’a geç ulaştığımız için sadece akşam açık olan mekanları gezebildik. Sezon sonrası geldiğimiz için mekanların çoğu 11’den sonra kapalıydı. Aynı problemi sonrasında budva ve kotorda da yaşadık. Mostar’a girişte şehri çevreleyen tepelerden birinde aydınlatılmış bir haç görüyoruz. Mostar da Saraybosna farklı inançlardan insanların bir arada yaşadığı bir şehir.

Sabah Mostar köprüsünden geçerek hemen hamam müzesinin önünde yer alan Moon Star Cafe & Pizzeria isimli kafede kahvaltı yaptık. Aşağıdaki resimde göreceğiniz gibi şirin bir yer. Mekan güzel olsa da çayı ve kahvaltı menüsü daha iyi olabilirdi. Kahvaltı seçenekleri daha iyi olan bir yer seçilebilir. Hemen yanında da kahve içmek için otantik tarzda bir başka kafe mevcut.

IMG_6634

Kafe han benzeri bir yapının ön tarafında yer alıyor. Her iki yanında ise turistlerin ilgisini çeken bir cami ve karşısında hamam müzesi var. Müzede görevli Türk çalışandan bu üç yapının eski zamanlarda dericiler için inşa edilmiş bir kompleks olduğunu öğrendik. Handa deri işe ile uğraşan çalışanlar o koku ve kirle cemaati rahatsız edebilirler düşüncesiyle onlar için bu cami ve hemen karşısında da hamam yapılmış. Türkiye’de de benzer örnekleri olduğu söylense de ilk defa duymuştum.

Sonrasında Mostar’ın diğer tarafında kalan yerleri gezerek henüz çarşıda hayat başlamadığı için kaldığımız otele döndük. Otel çıkışını yaptıktan sonra gezi haritasında ilk sırada olan camiye geçerek caminin minaresinden Mostar’ı izledik. Burada garip olan şey camiyi ziyaret için de para isteniyor.

DSC_0039

Birden fazla camide minareye çıkabildiğiniz için bence Mostar’a yakın olan camiyi seçin. Biz merkezdeki gezi haritamızda Karagöz Bey Camii olduğu için o camiyi seçtik manzara da güzeldi ama Mostar’a yakın minarelerden nehir ve tarihi yerlerin manzarası daha güzel olacaktır.

IMG_6714

Sonrasında Biscevica Köşkü ve Çarşı’yı gezerek Mostar köprüsüne gittik.

DSC_0046

DSC_0070

Mostar köprüsünden parayla atlamaya hazır bir insan görebilirsiniz. Köprüde mayosuyla bekleyen adam ücreti karşılığında nehre atlıyor. Girişimciliğin bu kadarı 🙂

DSC_0164

Hemen ilerisinde dondurmacılar var. Oradan dondurmanızı alarak Mostar’ı aşağıdan gören alana inebilirsiniz. Sonrasında biraz ileride yer alan Küçük Mostar’ı ziyaret edebilirsiniz.

Karadağ’a geçmeden önce Bosna’da gezmek istediğimiz bir kaç yer olduğu için Mostar gezisini burada sonlandırıp Blagay’a doğru yola koyulduk. Blagay’da ki tekkeyi, Poçitelde ki tarihi mekanları ve şelaleyi gezdikten sonra Karadağ’a geçmeyi planlıyorduk. İlk olarak Balagaydaki dağın dibine kurulu Erenler tekkesini ziyaret ettik.

550 yıllık Buna Nehri’nin kıyısına dağın dibine kurulan tekke tam bir tevekkül yeri.

IMG_6744

Blagay’dan çıkana kadar akşam olduğu için şelale ve Poçitel’i dönüşe bırakmaya karar verdik. Akşam yemeği için yer ararken bir yerde durduk. Harika bir yerde. Sokak araları kaldırımlar, evler muhteşemdi. Bu yeri mutlaka öğreneceğim derken buranın Poçitel olduğunu sonradan öğrendik. Gündüz gözüyle görülmeli. Akşam olmasına rağmen sokak ve evlerin yapısı oldukça güzeldi.

IMG_6758

Şans eseri de olsa Poçitel ziyaretiyle Bosna’da ki ilk iki günü bitirerek Karadağ’a doğru yola koyulduk.

Bir yerde çevirmede durduran polis pasaportlarımıza bakıp arkadaşın üzerindeki takım formasını görünce takımlarımızdan bahsetti. Sonrasında sınırda sınır çizgisini farkında olmadan geçtiğimiz söylenerek az biraz ceza yazdı. Dikkatli olmakta yarar var 🙂 Karadağ sınırındaki görevli ise son derece güleryüzlüydü. Gece ulaştığımız Budva’da dışarı çıktığımızda açık bulabildiğimiz tek yer old town’da ki açık coffee bardı. Erkeklerin gecenin bu saatinde takım elbiseler, şık giysilerle takıldığı bu ortamdan başka şehirde gece erkenden sonlanmıştı. Her yerin kapalı olduğu o saatlerde de old town’u gezmek keyifli olabiliyor. İyi ışıklandırma ve düzen old townu bir film sahnesi kadar güzelleştiriyor. La la Land filmini anımsatabilir. 😊

Budva Old Towndan kısa bir görüntü için tıklayınız

Sezon döneminde sabaha kadar açıkken mekanlar sezon dışında en geç 1’de kapanıyormuş. Kotorda ise bu süre daha erken. 11’de polis tarafından oturduğumuz mekanın kapatılması için uyarı yapıldı. Tek açık yer orası olmalı ki son müşteri çıkana kadar ayrılmadılar 😊

DSC_0199

Üçüncü gün gündüz gözüyle yeniden old town’u gezdik. Old town canlanmış, her yerde karşımıza çıkan çekik gözlü turist kafilelerine avrupalı turistler de eklenmişti.

20171016_134527

Ekseriyeti yaşlı olan avrupalı ve çekik gözlü turist kafileleri arasında gözüme ilişen bir fark çekik gözlülerin daha bir meraklı, heyecanlı gözlerle etrafı incelerken Avrupalılar daha sakin rehberden dinlemeyi tercih ediyor. Tespit yapamadan duramıyorum 😀  Eski şehir kale duvarlarının arasında yer almış. Tıpkı  Budva’da olduğu gibi dar Ortaçağ sokaklarında dolaşmak, küçük restoran ve kafelerde zaman geçirmek çok keyifli. Eski şehrin içinden yukarıya doğru tırmanarak 45 dakikalık bir yürüyüşle surların bitiminde tepedeki kiliseye ulaşmak mümkün. Kotor’da eğlence ve gece hayatı istiyorum diyorsanız tekrar Budva’ya dönmeniz gerekecek.Old town’un göbeğinde yer alan büyük ve küçük kiliselerin yanında bir de şehri üstten görebileceğiniz bir kale var.20171016_134620Kalenin bitişiğinde ise denizle karayı ayıran küçük güzel bir kıyı var. Orada fotoğraf çektirelim, mümkünse orada çalan gitaristin dinletisi eşliğinde.

20171016_140236

Sonrasında yüzmek için kıyı boyunca uzanan sahillerden herhangi bir sahili gezebilirsiniz. Yürüyüş yolu ile yürüyüş yapmanız mümkün. Budva ile özdeşlemiş Dans Eden Kız Heykeli de bu yürüyüş yolu üzerinde. Bir fotoğraf da burada çekerek ayrılabilirsiniz Budva’dan.

20171016_143314

Heykel hemen yanımda ama karenin dışında kalmış 🙂

IMG_6786

En azından biz öyle yaptık. Kotor’a geçtik. Kotor da bir liman şehri. Yaklaşık yarım saat süren yolculuk sonrasında tarihi bir döneme adım atar gibi içeri giriyorsunuz şehrin kale kapısından. Sizi ilk karşılayan saat kulesi ve hemen yanında masaları mumlarla süslenmiş,bir yerlerden gelen hafif müzik ile insanı yumuşatan romantik havasıyla bambaşka bir yer olduğunu ilk adımda hissettiryor bu şehir.

Akşama doğru geldiğimiz için karanlık çökmeden kaleye çıkmaya karar verdik.

IMG_6800

3 euroluk ücreti verdikten sonra 1000 adımdan fazla bir buçuk saati aşkın süreden sonra tepeye vardık. Bir cümleyle kısa gibi oldu ama yukarı çıkana kadar bir kilise, yıkılmaya yüz tutmuş seyir tepeleriyle bol manzara ve maceralı bir yolculuk oluyor. Burada ki şansımız yolu yarılamak üzereyken kıyıya yanaşan shipping tur gemisi oldu. Hem çok sayıda turist geldi, hem de güzel olan manzara harika olmaya başladı.

IMG_6842

 

IMG_6807

Kaleye çıkarken karşılaştığımız türk gençler, delivery heroda çalışan Alman turist ve Hong Kong’lu çılgın çiftler.

IMG_6934

Selfie çubuğuyla bol bol fotoğraf çekmeye başlayınca harika bir yürüyüş olmaya başladı benim için 🙂 Uzun yoldan korkmadan, ne gerek var demeden Kotor’a yolunuz düşerse mutlaka çıkmanızı tavsiye ederim. Karanlık çöktükten sonra aşağı indiğimizde yemek için bir çok seçeneğiniz oluyor. Çoğunlukla deniz ürünleri olsa da farklı tarz yemekler bulmak mümkün.

Özetle son derece romantik bir şehir. Şimdiden iki arkadaşa önerdim. Bu yazıyı buraya kadar okuyanlara bonusumuz olsun. Tüm özel günleriniz için gidip dönmesi son derece güzel anlar yaşayabilirsiniz 😊

20171016_172705

IMG_6811

Dördüncü günün sabahında ilk olarak Budva’ya yakın mesafede olan  Stevi Stefan adasına gittik. Yemyeşil denizin içeriside bir tuval resmi kadar güzel görünüyor. Adaya girişlere izin verilmiyor.

DSC_0264

Sonrasında şehrin dışında bir kiliseye uğradık. Şu ana kadar gördüğüm en iginç kiliseydi. Hemen arkasında yer alan mezarlık, ön kısmındaki bahçe ve bölünmüş alanlarıyla oldukça farklıydı.

DSC_0270

Tatil planına başladığımız günden beri en çok istediğim şeylerden biri olan yüzme aktivitesine dördüncü gün vakit ayırabildik. Ekim ortası saatlerce denizde olmak unutamayacağım anılardan biri olarak kaldı geriye. O gün akşama doğru otelden çıkışı yaparak Karadağ macerasını Kotor’da biraz duraksayıp son kez şehirde biraz gezerek sonlandırdık.

20171017_190248

Yaklaşık dört saat süren yolculuk sonrası sınırı, Mostarı ve yol üzerindeki her yeri es geçerek Jablanica’da ki Markovic’e yetiştik. Son müşteriler olarak dönmeden bir kuzu çevirme daha yedik. Yukarıda yeterince methini yaptın diye es geçiyorum. 🙂

Sonrasında son gece kalacağımız Saraybosna’ya geçtik. Yeşilliği, sakinliği ve kıvamında canlılığıyla insanı hemen içine alan bir şehir Sarajevo. Başçarşı’da iyi bir mekan olduğunu okuduğumuz Buregdzinica Sac’da meşhur boşnak böreği yedik. Ancak ben beğenmedim, çay olmamasını ise esefle karşıladım. Gitmeyin diyemiyorum ama gidin demek de gelmiyor içimden 🙂  Sonrasında Aliye İzzetbegoviç müzesi ve Sebil’in olduğu Saraybosna meydanında gezdik.

20171018_101828

Sonrasında Brusa Bezistan ve civarında ki lokasyonları gezdik.

DSC_0290 DSC_0310 DSC_0317

Burada daha çok görüp de girdiğimiz için mekan ismi veremeyeceğim. Sonrasında bizim eski İstiklal Caddesine benzeyen güzel sakin bir cadde var. Hafta içi olmasına rağmen oldukça canlıydı. Ve en son durağımız ilk gün gördüğümüz o güzel, yeşil ve sonbahar renklerine bürünmüş parka gittik.

DSC_0335 DSC_0337 DSC_0365

Park yaprağın her rengini barındırmanın yanında yere batmakta olan mezar taşlarıyla birşeyle anlatır gibi.

DSC_0348

Bu şekilde severek, eğlenip dinlendiğimiz bir gezinin sonuna gelmiş olduk. Çok gezen mi bilir çok okuyan mı bilmem ama gezmenin dünyayı bilmekle ilgisi olduğunu daha da iyi anladım bu geziyle.

Yorulmadan buraya kadar okuyan ziyaretçilere ayrıca teşekkürler. Esen kalın 🙂

 

Agile Yönteme Geçiyoruz. Hayat Daha Güzel Olacak !

Teknoloji çağında neredeyse her gün yeni bir kavram, yeni bir teknoloji ya da yazılımdan haberdar oluyoruz. Hızla gelişen ve her geçen gün hızına ivme katan teknoloji dünyasını takip etmek ve yeniliklere adapte olmak da zorlaşıyor.  Fazla geriye gitmeden son beş on senede sıkça duymaya başladığımız bir çok kavram hayatımıza girdi. Akıllı sistemler, NFC vb teknolojiler,  Big Data, Drone, Devops gibi kavramlar hızlı bir şekilde popülerleşti. Bu teknolojilerden bazıları üstüne katarak gelişirken bir kısmı da  popülerliğini kaybedebiliyor. Birkaç sene önce sıkça duyduğumuz Big Data kavramı artık eskisi kadar dillendirilmemektedir. Big data’dan vazgeçilmiş değil, şahsi fikrim ileri de duymaya devam edeceğiz. Büyük şirketler bu alana yönelip sadece bu alanda çalışacak ekipler oluşturuyor ancak aktif ve başarı olarak –en azından takip etmeye çalıştığım büyük firmalar arasında- duyduğumuz bir çalışma yok. Eğer big data ilginizi çekiyorsa big data ile ilgili verilerin de yer aldığı “2017’de Big Data Projelerinin %60’ı Başarısız Olacak” isimli çalışmayı okuyabilirsiniz. Bu kısa girişten sonra yukarıdaki kavramlar gibi son zamanlarda daha çok duymaya başladığımız bu yazının konusuna gelebilirim :Agile. Türkçeye çevik yöntem olarak çevirilen Agile projenin varolmaya başlamasından bitirildiği son ana kadar ki süreci belirleyen bir yöntemdir.

On altı senelik bir geçmişi olan Agile proje yönetim süreçlerinin belirlenmesi amacıyla 2001’de guru sayılan 17 kişi  tarafından 12 maddeden oluşan manifesto hazırlanmıştır. Manifesto paydaşlar arası iletişim ve işbirliği, güncellenebilen yazılımlar, ekibin kendisini organize edebilmesi, ve değişimlere adapte olabilmesine vurgu yapar. Agile çerçevesi kesin hatlarla belirlenip  ve yalın üretim(lean manufacturing) prensipleriyle netleştirilmiş waterfall gibi süreçlere karşı yeni bir çözüm olarak ortaya çıkmıştır.

Agile yöntem, zamanı yönetmeyi, müşteriyi sürece dahil etmeyi, yüksek işbirliğini, esnekliği, ürünlerin düzenli production’a alımını, sürecin ve üretimin beraber devam edecek şekilde gelişimini önemser. Waterfall gibi süreçlerde iş hatları daha belirgin ve değişkenken agile ile daha çok söz sahibi ve daha esnek bir iş yapış süreci mevcuttur. Daha az çalışma değil işin değişme imkanı da dikkate alındığı için daha esnektir 🙂  Bir proje ile ilgili ihtiyaç ve hedefler proje sürecinde güncellenebiliyor; değişebiliyor. Bu da sürecin değişime açık ve esnek olmasını zorunlu hale getiriyor. Esnek olması ürün sahibi ve ürünü ortaya çıkaracak ekip için de bu yöntemi cazip hale getiren etkenlerden bir tanesi. Scrum da ilk zamanlarda geleneksel, ardışık yaklaşımlara karşı daha esnek bir yapıda olunmasıyla tanıtılan bir yaklaşımdı. Ancak günümüz yazılım projelerinde dökümantasyon ve sprintler gibi sıkı denebilecek bir metodoloji olarak görülmektedir.   Proje yönetimi, proje üretimi ve yazılım geliştirme takımlarının sayısının artması da geleneksel waterfall metodolojisinden agile metodolijlerine yöneltiyor.  Aslında agile, scrum metodolojlerinden biridir. Scrum, agile hareketinin bir parçasıdır. Agile ve Scrum birbirilyle ilişkilidir ancak farklı yönleri de vardır.

Agile, agile menifestosunda belirtilen prensiplerin iterasyonlar halinde yazılımın geliştirilmesidir. allmethodologies

Scrum ise yazılım geliştirme sürecinde takip edilecek özel kurallar bütünüdür. Agile de iş ve teknik taraf diye iki taraf yerine o işin sorumlusundan geliştiricisine kadar bir takım vardır.

Waterfall eşyayı her katta görevlendirilen birisine aktararak eşyayı taşımaya benzerken agile’da asansörle eşyanın parça parça daha hızlı bir şekilde yukarıya çıkması gibidir.

Agile elbet her derde deva olmayabilir ama yazılım projelerini tüm paydaşlar açısından daha balşarılı ve kaliteli bir şekilde sonuçlandırma adına faydaları vardır. Müşteri açısından bakacak olursak  daha kısa sürelerde ürünün belli kısımlarını üretim ortamında kullanmaya başlayabilir. Inception fazında projenin tüm paydaşları ve özellikle de yazılım ekibiyle beraber ihtiyaçlar belirlendiği için istekleri net bir şekilde anlaşılmış olur. Scrum’da yazılım ekibi analiz safhasında yer almadığı için yazılım açısından uygulanabilirlikten dolayı bazı ihtiyaçlar proje ortasında yapılacak işler arasından çıkarılıyordu. İki ya da üç haftalık periyotlarda öncesinde müşteriye demo yapılarak ürünün belli kısımları üretim ortamına alınır. Bu sayede ürünü kullanmak için projenin sonlandırılması beklenmez.

Geliştirme Ekibi de bu yöntemin mutlu olacak taraflarından biridir. Inception fazında ihtiyacın ne amaçla istendiğini bildiği için yaptığı geliştirmenin business tarafına da hakim olacaktır. Yazdığı yazılımın kullanımı ve değerini daha aktif görebilirler. Analiz süreci ve –kullanılmayacak olan- dökümanların hazırlanması süreci ortadan kalkmış olur. Müşterinin kullanacağını bildiği ve değerini inception fazında gördüğü için daha keyifli çalışmaya başlarlar.Projenin diğer paydaşları için de faydaları sıralamak zaten uzun olacak bu yazıyı daha da uzatacağı için o konuya girmiyorum 🙂

Yukarıda saydığımız agile yöntemin avantajlarının yanında bazı zorlukları da vardır : Raporlanması, finansal yönetimi, zaman ve kaynak yönetimi, müşterinin artık sürece dahil olması, değişikliğin her zaman yapılabilmesi, net bir planın olmaması. Bu zorlukların hepsini tek tek açıklayabiliriz ancak zorluk olmalarının ortak özelliği sürecin esnekliği ve güncellenebiliyor olmasıdır. Agile yöntemde belirlenmiş, kesin çizgiler yoktur.

Agile ile ilgili özellikle üzerinde durulması gereken iki kavram var: User Stories (Kullanıcı Hikayeleri) ve Iterations. Iterasyondan kısaca bahsettiğim için burada kullanıcı hikayelerinden bahsedeceğim. Zira bu kısım önemli. Ürün backlog’unu oluşturmak için en popüler yöntemlerden biri müşteri ya da kullanıcının gereksinimlerinin küçük açıklamalar  ile yazıldığı user storyler şeklinde hazırlanmasıdır. Kullanıcı hikayeleri ürünün müşterileri ya da kullanıcının perspektifinden gereksinimin kısa ve basit olarak ifade edilmesidir. Kullanıcı hikayeleri yazılım dilinden öte müşterinin diliyle oluşturulur. Kullanıcı neyi neden istiyor sorusunun cevabı bulunmaya çalışılır. Yazılım ekibi ve projenin tüm paydaşlarının hem fikir olacağı kullanıcı hikayeleri neticesinde yapılacak projenin kapsamı tahmin edilir. Bu kullanıcı hikayelerinin eforu belirlenerek iki haftalık iterasyonlarla üretim ortamına alınır.

Waterfall, Kanban, Scrum ve Agile Hakkında Kısa Karşılaştırmalar

Waterfall metodolojisinde geliştirme başlamadan tüm gereksinimlerin analiz edilip dökümante edilmesi gerekir. Agile’da ise gereksinimler kısa iterasyonlar halinde geliştirilir ve değiştirilebilir. Geliştirme öncesi bir handshake durumu yoktur. Agile development öncesi geçirilen uzun zaman periyotlarını ortadan kaldırır. Ayrıca uzun geliştirme süreçlerinde ortaya çıkabilecek –analizde olmayan, kaçınılmaz- değişiklerin bir problem olarak ortaya çıkmasını engeller.  Waterfall’de analizde yazılan herşeyi birebir ürün haline getirmiş olabilirsiniz. Bu geliştiren takım için başarılı bir sonuçtur. Ancak müşteri tarafında ihtiyaç değişmiş olabilir ve ortaya konan ürün kullanılmayacak bir ürün olabilir.  Bu şekilde üretici ihtiyacını karşılamadığı , geliştirici efor sarfettiği, proje yönetimi ise kaynak ayrılan bir ürünün kullanılmayacak olmasından mutsuz olur.

Kanban ise Scrumdan biraz daha esnektir. Kanbanda yürütülen bir süreç kolayca Agile a dönüştürülebilir. Kanbanda bir tahta üzerinden süreç yönetilir : progresstestingready for release ve released aşamaları vardır. Eğer etkili ve uzun bir proje süreci olacaksa Scrum ama zaten süregelen bir proje ise kanban kullanılabilir. Scrum ve Agile buz ile su gibi benzerdir. Scrum ve kanban da agile yazılım metodolojilerinin özelleştirilmiş halidir. Scrum ve kanbanı karşılaştırmak ise iki ayrı agile metodolojisini karşılaştırmak gibidir.

methodologies

Sonuç olarak bu metodoloji ve toolların temelde bir amacı var : Projeleri daha verimli, kaliteli ve mutlu bir şekilde sonuçlandırmak. Bu sebeple küçük bir proje için use story’ler için biraraya gelip işin tüm bireylerini biraraya getirmek yerine Kanban belki waterfall bile daha etkili olabilir. Eğer başka birimlere bağımlığınız fazla ve beraber yürüyemeyecek bir süreçse –bence yine de tercih etmeyin waterfall tercih edilebilir.

Son olarak üç tip yöntemde de çalışmış biri olarak Agile yöntemin diğerlerinden çok daha iyi olduğunu düşünüyorum. Tabii burada Agile yöntemlerin tamamiyle uygulanmaya çalışılmasıyla iyi bir şekilde proje yönetilebilir. Esnek diye sürekli geliştiriciye müşteri yeni istek istedi agile yapıyoruz bunu da hemen çıkmamız gerekiyor denilen bir ortamda geliştirici nasıl mutlu olamazsa, her işe uzun eforlar verip esnekliği rahata dönüştüren bir ortam da müşteri için memnun edici bir süreç olmayacaktır.

Çevik süreçler dileğiyle..

Bir kaç link :

http://canertosuner.com/post/kisaca-agile-nedir-neler-gerektirir

https://www.mountaingoatsoftware.com/agile

https://www.smartsheet.com/agile-vs-scrum-vs-waterfall-vs-kanban

Eğitim’in Big Data’sı : Öğrenme Analitiği

Blog yazmaya verdiğim uzunca araya son vermek ve tez konum olan öğrenme analitiği ile ilgili birikmiş bilgileri bir yazıyla paylaşmak isteği sonucunda öğrenme analitiği hakkındaki bu uzunca yazıyı yazmaya karar verdim. Öğrenme Analitiği, fen bilimleri ile sosyal bilimlerinin alt dalları olan bilgisayar bilimleri ve eğitim teknolojilerini bir arada harmanlayan bir alan. Teknolojinin günden güne hayatımızın her noktasına biraz daha temas etmesi sonucu yaklaşık beş altı senelik bir geçmişi olan bir kavram. Son yıllarda bilgisayar bilimlerinde sıkça duymaya başladığımız big data, IoT ve smart solutions –akıllı çözümler diyince tam karşılamıyor hafızamda 🙂 – gibi yeni ve gelişerek kullanılan bir kavram.

Geleneksel okul değerlendirme ölçütleri bir kaç açıdan sınırlı ve öğretmenler açısından fazlasıyla zaman alıcıdır. Teknolojinin hayatımıza girmesi ve okuryazarlık becerisine sahip bilgi toplumu olmaya başlamamızla beraber teknolojinin öğretime katkıları üzerinde çalışmalar da artmaya başladı. Öğrenci, öğrencinin internet ortamındaki verileri ve okul bağlantılı tüm verilerden oluşan Büyük Eğitimsel Veri’nin analizi ile yeni çalışma ortamlarının oluşmasına olanak sağlandı. Verilerin analiz edilmesi sonucunda ortaya konan analitik uygulamalarla kurum ve öğrenciler için ileride görülebilecek tahmini problemler karşısında çözümler üretilebilir. Bu veriler, hem ekonomik hem de pedagojik kaynakların optimal kullanımının desteklenmesi için veri odaklı kararlar alınmasında kullanılabilir.

Öğrenme analitiği, eğitim sisteminin her katmanında verilen kararlara delil sağlamak, öğrenciye kişiselleştirilmiş öğrenme etkinlikleri sunmak, öğrencinin öğrenme tarzına uyum sağlayan öğretim yöntemlerini ve uygulamaları etkin biçimde kullanmak ve öğrenme sorunlarını zamanında çözmek için tanı koymak gibi amaçlarla öğrenci verilerini analiz etmeye dayanır.

Öğrenme analitikleri kavramı ilk kez Siemens tarafından “öğrenme üzerinde tahmin ve tavsiye yapabilmek için akıllı veri, öğrenenin ürettiği veri, bilgi ve sosyal bağlantıları keşfetmek için analizlerin kullanılması” olarak tanımlanmıştır. Bu tanım zaman içerisinde güncellemeler geçirse de son haliyle şu şekilde bir tanımlama yapılabilir : Öğrenme Analitiği öğrenci ve öğrencinin ilişkili olduğu ortamlardan elde edilen tüm verilerin öğrenme süreçlerinin iyileştirilerek desteklenmesi ve zengin geri bildirimler sağlamak için toplanması, analiz edilmesi, ölçülmesi ve raporlanmasıdır.

Öğrenme Analitiği bir çok etkenin göz önünde bulunması sonucunda gerçekleştirilir. Bu bileşenler şunlardır :

  • Paydaşlar (Öğrenciler, Öğretmenler, Veliler, Kurumlar)
  • Amaçlar (Hedefler, Tahminler)
  • Eğitim Veri Analizi ( Açık Kaynak Veri, Korunmalı Veri)
  • Kısıtlamalar ( Özel Verilerin Kullanımı, Etik İlkeler )
  • Teknolojiler ( Eğitim Veri Analizi, Öneri Sistemleri, İstatiksel Teknolojiler)
  • Yeterlilikler  (Yorumlama, Titiz Düşünme, Analizler)

Öğrenme Analitiği Bileşenleri

Öğrenme Analitiği ile elde ettiğimiz analizin eğitsel sonucundan eğitsel davranışlara yön verilir.

Öğrenme Analitiğinin Pedagojik Etkileri

Öğrenme Analitikleri  sonucunda öğrenim sürecine katkı sunulabilmesi için başka alanlarla da ilişkilidir. Bunlar:

learninganalytics3

  • Akademik Analizler
  • Web Analizleri
  • Veri Madenciliği
  • İş Zekası

 

 

 

 

Veri Analizi

Eğitim Verisinin Analizini eğitsel sistemlerden elde edilen ham verinin eğitim yazılımlarının, geliştiricilerin, öğretmenlerin ve araştırmacıların kullanabileceği bilgiye çevirme süreci olarak tanımlamak mümkün.

Eğitim Verisinin Analizi sürecinde eğitsel ortamlardan veri toplanır, işlenir ve elde edilen bilgi eğitsel ortamlara uygulanır.

Eğitim Verisinin Analiz Aşamaları

Öğrenme Analitiği ilkeleri kapsamında geliştirilen öğrenme ortamları Amerika’da bir çok eğitim kurumunda kullanılmakta. Uzak doğu ülkelerinde de bu alanda yapılmış çalışmalar var. Ülkemizde bu konuda yazılan tez çalışmaları bulunmaktadır. Öğrenme analitiği kapsamında yapılan proje ve çalışmaların öğrenci, öğretmen ve kurumlar tarafından daha çok tercih edileceği ve popülerleşeceği görüşündeyim. Öğrenme Analitiği ile ilgili olarak Yıldız Teknik Üniversitesi Böte Bölümü Kariyer Günleri kapsamında yapmış olduğum sunumdan bir kare ile bu yazıyı noktalamış olayım.

ogrenmeanalitigisunum

 

 

Bilgisayar Mühendisliği Eğitimi ve Yazılım Sektörüne Dair Röportaj

 

Uzun süredir blogda yazı yayınlamıyordum. İlk fırsatta yazmak için konular belirlesem de bir türlü yazıya döküp paylaşamadım. Geçen ay Gebze Teknik Üniversitesi Bilgisayar Mühendisliği 3. Sınıf öğrencileri Merve, Alper ve Zehra yazılım sektörüne ve bilgisayar müdendisliğine dair bir mülakat yaptık. Dönem ödevi olarak bir akademisyen ve yazılım sektöründe çalışan bir mühendisle gerçekleştirdikleri röportajları arkadaşlarına da  sunacaklarını ifade ettiler. Benim için keyifli ve verimli geçen mülakattan sonra mülakattaki fikirlerimi düzenleyerek burada da paylaşmaya karar verdim. 🙂  Keyifli okumalar.

  1. Türkiyede bilişim sektöründeki ilerleme hakkında ne düşünüyorsunuz ?

Bilişim sektörü özellikle son senelerde daha hızlı bir ilerleme kattediyor olsada ilki aslında bilişim sektöründeki ilerlemeler devletin de bu konuya eğilmesiyle başlıyor. 2003’te bilgi toplumu olmak için hükümet ve devlet destekli bir proje başlatılıyor. Bunun içerisinde  e-devlet üst başlığı altında e-fatura, e-sağlık, e-imza gibi hizmet sektörüne önemli katkılar sunan çalışmalar gerçekleştirildi. Eskiden bir randevu alacağınız  zaman hastaneye gitmeniz ve ordaki görevli memurdan almanız gerekiyordu ama şimdi telefon ettiğinizde bile randevu almanız zor, internette kendiniz randevu alın şeklinde internete yönlendirilebiliyorsunuz. Tabi sadece devlet bilişim sektöründe çalışmalar yapmadı. Özel sektörde de yapılan çalışmalar vardı, mesela ekşi-sözlük daha öncesinde oluşmuş birşeydi zaten. Kriz sonrası bankaların hızlı büyümesi ve telekom firmalarının da bilişim sektörüne dahil olmasıyla bu alandaki çalışma ve rekabet arttı. Teknolojinin hızlı gelişimi aslında bilişim sektörünün de ilerleme hızını artırdı. Teknolojinin yenilikçiliği, sektörü de yenilikçi olmaya, son teknolojileri takip etmeye zorladı diyebiliriz. Ve teknoloji tek bir koldan ilerlemiyor. Her gün yeni bir kavram, yeni bir alan açılıyor. Örnek vermek gerekirse, son yıllarda büyük veri (big data) diye  bir kavram ortaya çıktı. Bu alan ilgimi  çektiği için biraz bunun üzerinden konuşmak istiyorum. Veri(data) artık ticaret, devlet ,banka, Telekom gibi sektörler  için  çok kıymetli olmaya başladı. Bu dediğimiz sektörlerde çok fazla veri toplanıyor ve bu verilerin değerlendirilmesi gerekiyor. Bu ham haliyle kıymetsiz veriler işlenerek çok değerli bir veri haline dönüştürülebiliyor. Verinin değerlendirebilmesi için de teknolojilerden geride kalmayıp , adapte olup ve hatta daha iyi bir konumda olmak için hızlı bir şekilde öncü konumda çalışmalar yapmanız gerekiyor. Bu da en özet haliyle rekabeti getiriyor. Özetle toparlayacak olursak; teknolojideki ilerlemeden dolayı bilişim sektöründeki ilerleme Türkiye’de de gelişmekte olan ülkelerde de daha hızlı bir şekilde devam ediyor. Türkiye de buna uyuyor aslında , adapte oluyor , önce olmasa da ilerleyen teknoloji ile beraber yoluna devam etmeye çalışıyor diye görüyorum.

  1. İlk profesyonel iş deneyiminizi ne zaman yaşadınız? İlk işinizden bahseder misiniz? İlk iş gününüz nasıldı ?

Daha önce part-time yerlerde çalışmıştım ama ilk profesyonel iş deneyimim mezun olduktan bir ay sonra kurumsal bir bankada başladı. Kurumsal bir bankanın iştirakçısı olan teknoloji şirketinde ATM biriminde işe başladım. Burada genel olarak C#, MySql ve MsSql yazılımları ile transaction, raporlama ekranları geliştirdikten sonra ATM yazılımları geliştirme alanında çalıştım. Bu çalışmaların dışında ve farklı teknolojilerle yaptığımız çalışmalar olsa da genel olarak ilk iş tecrübemi bu şekilde özetleyebilirim.

Heyecan olarak ta ; stajlarınızı  özellikle  yazılım evlerinde yapmışsanız , yazılım evleri nispeten daha az sayıda kişinin çalıştığı herkesin herkesi tanıdığı, bildiği ortamlardır. Ama ilk defa büyük ölçekli, kurumsal bir firmada çalışıyorsanız ortama adapte olmanız daha uzun sürebilir. Beraber bir arkadaşla aynı gün işe başlamamdan ötürü ilk günüm kolay geçmişti diyebilirim. En azından vakit hızlıca geçip erkenden akşam olmuştu.

  1. Mezun olduktan sonra iş hayatına ilk adım attığımız adaptasyon süreci nasıl olacaktır? Sizin bu döneminiz nasıldı ?

Final dönemini aratmayacak bir süreç oluyor açıkçası, yine stres oluyor, yine çabalıyorsunuz ama sonucun ne olcağını tam kestiremiyorsunuz. Birçok yere başvuruyorsunuz , birçok yerle görüşüyorsunuz ve klasik bir şekilde biz sizi ararız diyorlar arayanlar olduğu gibi, aramayanlar da oluyor. Mezun olduktan sonra iş aramaya başladıysanız bu süreç sıkıntılı oluyor ama daha öncesinde yaptığınız projeler varsa veya çalıştığınız staj yerleri ile ilişki bağınızı koparmadıysanız bu süreç daha rahat oluyor; çünkü çalışabileceğiniz bir işiniz olmuş oluyor. İş bulur muyum bulamaz mıyım telaşından öte istediğim sektörde bir iş bulur muyum diye düşünüyorsunuz. Bu süreçte kısa sürede iş arayışınız sonuçlanmaza moraliniz bozulacak, artık olabilecek kötü  iş seçeneklerini bile değerlendirmeyi düşünmeye başlayabilirsiniz. Hangi sektörde çalışmayı düşünüyorsanız, o sektör dışında bir sektörde çalışmam diyorsanız onun temelerini 4. sınıfta aldığınız bitirme projesiden itibaren çalışmalarınızı o sektörde yapmanız faydalı olacaktır. Özellikle tavsiye ediyorum eğer IBM ya da Microsoft un yarışmaları gibi onların  üzerinden bitirme projelerinizi yaparsanız hem bitirme projesini yapmış oluyorsunuz hem de sektörde birileri ile tanışma fırsatı yakalıyorsunuz ve CV’inizde fark yaratacak bir yarışmaya dahil olmuş oluyorsunuz. İş görüşmelerinde iş tecrübeniz yoksa işverenin size sorabileceği tek şey bitirme projesidir stajlarda etkili olabilir ama özellikle sizin bitirme projenize bakarak sizinle ilgili bir fikirde bulunuyorlar. O yüzden bence şimdiden bitirme projelerini araştırın ve Tübitak ‘ın ,IBM’in yarışmalarına katılın.

  1. Sektöre ilk adımımızı attığımızda bize en büyük katkıyı sağlaması açısından hangi alana yönelmeliyiz ?

Bilgisayar mühendisleri mezunları için çok fazla alan var. Üniversitedeyken temelde 4 alan vardı diyebilirim : Yazılım, veritabanı ,sistem ve proje yönetimi şeklinde alanlarda çalışabiliriz diye düşünüyoruz ama daha sonra sektöre girince özellikle de son senelerde birçok yeni alan ortaya çıkıyor. Örneğin büyük veri(big data) , veri analitiği gibi her gün varolan  alanlara yeni bir alan ekleniyor.O yüzden Bilgisayar Mühendisliği seçeneği çok olan bir alandır. Burada kişinin kendisinin hangi alanda daha iyi olabileceğine karar vermesi gerekir diye düşünüyorum. Örneğin; döküman hazırlamaktan sıkılıyorsanız analist olamazsınız ya da iyi bir analist olursunuz belki  ama mutlu olmazsınız veya kod yazmayı çok seviyorsanız yazılımcı olmanız lazım veritabanında çalışmak beklentilerinizi karşılayamayabilir. Ya da güvenlik ilginizi çekiyordur güvenlikçi olunca o alanda daha çok mutlu olursunuz gibi. O yüzden üniversitedeyken sektörle çok ilişkili değilseniz tüm alanları bilemeyebilirsiniz ama hangi alanda daha mutlu olabileceiğinizi araştırabilirsiniz. Şu aşamada hangi alanlara yönelmeniz gerektiğini söylememiz gerekiyorsa; mobil uygulamaları , veri analitiği(bu alanla ilgilendiğim için bu alanı takip ettiğim içinde olabilir J ama şu bir gerçek ki veri(data) gerçekten çok önemli bir hale geldi), güvenlik gibi alanlar şu an  revaçta görünüyor ama teknoloji çok hızlı geliştiği için alanların revaçta olma durumları her an değişebiliyor.

rop

  1. Yeni mezun olan arkadaşların şirket kurup risk alması ne derece önemli sizce , Bu konuda onlara ne tür önerileriniz olabilir?

Eğer gerçekten fikrinize inanıyorsanız ben bunu yaptım (veya yaparım) ve satarım diyorsanız çok mantıklı bir karar vermiş olursunuz. Neden? Çünkü başka bir firmaya girdiğinizde  8.00-17.00 arası o firmanın  işini yapmak zorunda olucaksınız ve hiç mesai yapmasanız bile  8.00-17.00 arasında o işle uğraşacak haliyle yorulacaksınız eve geldiğinizde kendi fikirleriniz üzerinde  düşünmeniz gerekecek buda son derece yorucu olacaktır. Sonuçta akan bir hayat ve sosyal bir hayatınız var. Yani  başka firmada çalışıp bir yandan  kendi firmamı kurayım, kendi fikrim üzerinde çalışayım dediğinizde bu zor olacaktır. Mezun olur olmaz bir firma açayım dediğinizde de sonuçta bu firmanın vergisi olacak, çalışanı olacak yani bir sermaye elinizde olması gerekiyor ve günümüz şartlarında az bir sermaye ile firma kuramıyorsunuz ama bedavaya firma kurabiliyorsunuz. Bu nasıl oluyor? Şu an birçok girişimciliğinizi(proje) verdiğinizde sadece bakanlığın bile verdiği destekler var ve  buna Teknoparkların,Tübitak desteklerini de ekleyebiliriz. Bu şekilde girişimleriniz varsa birçok yerden destek alabiliyorsunuz bu yerde(mekan) olabilir parasal da olabiliyor  yoksa diğer şekilde firma kurma süreci sıkıntılı bir süreç olucaktır. Eğer mezun olur olmaz  firma kurma gibi düşünceleriniz varsa bu tür girişimcilik desteklerini araştırmanızı tavsiye ederim ve eğer mezun olur olmaz  sektörde tanıdığınız veya  çevreniz de yoksa bu durumda tabi baya bi deli yürek(cesaretli) olmanız lazım J.Bu tür girişimlerde bulunmak gerektiğine inananlardanım yani kendini garantiye almak biraz da standart bir hayat yaşamak demektir her ayın 1’in de maaşınızı alırsınız , standart bir hayatınız olur ama sürekli aklınızın bir kenarında  firma açsa mıydım sorusunu atmak için girişilebilir  fakat dediğim gibi üzerinde iyi düşünülmesi gerekir.

  1. Mezun olduktan sonra akademik anlamda eğitim görevlisi olmak ya da özel sektöre atılım konusunda bize ne gibi önerileriniz olucaktır? Akademisyen olmayı hiç düşünmüş müydünüz ?

Lisans’tan mezun olduktan sonra daha da üniversiteye adımımı atmam diyenlerdenim. Belki hiçbir öğrenci çalışmayı sevmez ama ben hiç sevmem J J Çalışmayı severim ama ders çalışmak veya sınavı geçmek için çalışmayı hiç sevmezdim. Eğer kendim okuyacaksam bu  belki hoşuma gider veya ilgimi çeken bir konuda çalışmak hoşuma gider ama sınavlar ve stresi  deyince  ben bunları yapamam tekrar bu stresi kaldıramam diye düşünüyordum(yordumJ)  ama şuan Yüksek Lisanstayım ve teze başladım. İnsan, kendisini planladığının çok tezatını yaşarken bulabiliyor. Bazıları gerçekten ders çalışmayı çok sever işte o insanların akademiye yönelmesi gerektiğini düşünüyorum. Eğer gerçekten ders çalışmak, araştırmalar yapmak, makale yazmak , tez yazmak , birilerine birşeyler öğretmek sizi mutlu edecekse gördüğüm ve gözlemlediğim kadarıyla akademik dünya sizin için çok güzel bir seçenek olacaktır diye düşünüyorum. Eskiden maaşları düşüktü o yüzden pek seçenek haline gelmiyordu düşünüldüğünde tamam gider mühendis olurum belki biraz daha stresli olurum , belki daha çok çaba sarfetmem gerekiyor  ama iyi bir karşılığını alırım düşüncesi vardı ; ama  gördüğümüz gibi son senelerde de  akademik dünyasının maaşlarında da bir iyileştirme yapıldı onun dışında kendilerine vakit ayırabiliyorlar sektördeki gibi 8.00-17.00 gibi bir çalışma durumları yok. Akademisyenler de  biz çok çalışıyoruz diyorlar ve haklılarda ama en azında 8.00-17.00 arasında sürekli çalışmaları  gereken bir iş değil , yani o stresi yaşamamazlar akademide çalışmanın böyle avantajlı yanları var. Bu yüzden eğer  araştırmayı seviyorsanız,bir şeyleri öğretmeyi gaye edindiyseniz iki kişinin daha hayatını kurtarayım bir yerlere gelsinler diye düşünüyorsanız akademisyen olun. Çünkü mühendisin en güzel  ürünü yazılım olurken , akademisyenin en güzel ürünü yetiştirdiği öğrencisi oluyor ve insanlar yetiştiriyorlar. Herşeyden önce çok  kıymetli bir şeydir bu. Ve gerçekten hakkını verebiliyorsanız , öğrenci yetiştireceğim mantığıyla yaklaşıyorsanız  akademik dünyada kariyer yapın yoksa rahat diye akademiye geçip te öğrenciye PowerPoint Sunumundan  ders anlatıyorsanız bu hiç hoş olmaz o zaman akademiye geçmeyin derim. Bu tür sebeplerden dolayı akademisyen olmayı hiç düşünmedim ve halen de düşünmüyorum açıkçası bana hiçbir zaman cazip gelmedi.

  1. Yüksek lisans yapan ve lisans eğitimi alan mühendis arasında ne gibi farklılıklar var? Bize Yüksek lisans eğitimini almayı tavsiye eder misiniz?

Evet fark var ve kesinlikle yüksek lisans yapın derim. (Ben profesör’de olun derim J ama söylemek kadar kolay değil tabi J). Kariyer adımlarında yüksek lisans destekleyici bir basamak olabiliyor. Özellikle yönetici pozisyonlarında buna çok dikkat ediliyor diye biliyorum. Eğer iki aday ve bir koltuk varsa tüm parametrelere bakılıyor ve bu parametreler arasında yüksek lisans ve doktora olması da önemli bir kriter. Bunun dışında Bilgisayar Mühendislerinin çoğu İşletme, MBA, Ekonometri gibi branşlarda yüksek lisans yapıyorlar. Açıkçası, Bilgisayar Mühendisi olupta Bilgisayar Mühendisliğinde yüksek lisans , doktora yapmayı pek anlamlı bulmuyorum. Yazılımcı ya da  mühendis olarak başladığınız iş hayatınızın  ilerleyen senelerinde yöneticilik gibi pozisyonlarda çalışacaksınız. Burada teknik bir eğitim almış olan eğitimin sosyal alandaki yeterlilikleri de devreye girecektir. Yüksek lisans’ın kişisel gelişim ve kariyer açısından faydalı, avantajlı olduğunu düşünüyorum.

  1. İş hayatına ilk adımımızı attığımızda küçük bir şirket ile büyük bir şirketin bünyesinde yer almanın bize ne gibi avantaj ve dezavantajları olacaktır ?

Bu soru kendime en çok sorduğum sorulardan biriydi. Yazılım evleri diye tanımladığımız küçük işletmelerde başlarsanız az çalışan olmasından dolayı çok iş olacaktır. Her işi aynı teknoloji ile yapmazsınız yani daha çok çalışmanız ve daha çok farklı farklı teknolojileri bilmek zorundasınız. Örneğin; Ben C# biliyorum yazılım evlerinde sürekli bunu yazarım derseniz işveren açısından bu pek kabul görülen bir seçenek değildir. Kurumsal firmalara gelince bu tür firmalara girdiğinizde zaten sizi bir ekibe alırlar ve bu ekibin standartları , kullandığı teknolojiler vardır siz sadece bu teknolojileri kullanırsınız. Bunun dışında   araştırmacı bir kimliğiniz varsa  teknolojiler nasıl ilerliyor , ne çalışmalar yapılıyor  diye araştırırsınız, takip edersiniz ancak işinizde kullanmanız pek mümkün olmayabilir. Ama yazılım evlerinde teknoloji kullanımı açısından daha esnektir. Bir gün bir iş gelir C# la yapmanız gerekebilir başka bir gün işte Matlab’la  ya da Delphi ile  yapmak isteyebilirsiniz. Şu bir gerçek ki yazılım evlerinde çalışmak farklı teknolojilerden haberdar olma ve bunları öğrenebilme-kullanabilme durumunuz olabiliyor fakat kurumsal bir firmada evet yine bütün teknolojilerden haberdar oluyorsunuz ama bunların hepsini öğrenebilme-kullanabilme durumunuz olmuyor. Kurumsal bir firmada çalışıyorsanız yapacağınız iş, o işin yapılma şekli, kullanacağınız teknoloji , kullanacağınız bilgiler belli  olduğu için bütün teknolojileri kullanabilme durumunuz(şansınız) olmuyor. Yani farklı  teknolojileri öğrenerek  gerçek anlamda mühendislik yapmak  istiyorum diyorsanız  bu sefer maaş konusunda  bir engel çıkıyor ;çünkü yazılım evleri ile kurumsal firma arasında maaş olarak çok fark oluyor. rakam vermek gerekirse örneğin; yazılım evlerinde iki binle (2.000) başlıyorsanız kurumsal firmada üç binle (3.000) başlayabiliyorsunuz. Bu maaş farkındaki uçurum  bazen düşebiliyor bazen daha da açılabiliyor. Sonuç olarak bu iki tür şirketin bünyesinde çalışmak hakkında  karar verirken iş hayatından beklentiniz nedir ? sorusuna net bir cevap vermeniz gerekiyor.

  1. Dünya piyasalarında yazılım sektörü çok büyük bir paya sahip olasına rağmen ülkemizde sahip olduğu pay çok düşük bir rakamda. Ülkemizin yazılım sektöründeki geleceğini nasıl görüyorsunuz?

Aslında bir çok sektör gibi yazılım sektörünün geleceği de ülkenin geleceğiyle doğrudan ilişkilidir. Ülkenin ekonomisi ,gelişmekte olan ülkeler arasında mı yoksa teknolojiye öncü olan ülkeler arasında mı gibi soruların cevapları tüm sektörlerin geleceğini de gösteriyor. Maalesef teknoloji , dolayısıyla yazılım sektöründe öncü olmaktansa daha çok gelişmeleri takip eden bir konumdayız. Yazılım sektörüne bilgisayarın tarihçesinden itibaren baktığımızda bi 50-60 senelik ABD’de doğan bir güneş var , teknolojiyi sürekli onlar ilerlettiği için ilk memba(kaynak) orası olduğu için onlar öncü oluyor buna Japonya ,Rusya ve Almanya’yı da ekleyebiliriz ama son senelerde bizde de gelişmeler görülmektedir. Örneğin; Geçenlerde Amerika’daki bir sağlık girişiminde girişimi desteklenmiş ilk kişi bir Türk girişimci şeklinde bir haber okumuştum. Bu firmanın hiyerarşisine , çalışanlarına baktığınızda birçok Türk var ; bunun gibi Silikon Vadisinde de  Türk çalışanlar var. Artık Türkler de bu alana yönelmeye başlıyor  mesela  şuan ilköğretimde  kodlama dersleri verilmeye  başlanacak. Bu öğrencilere bir bilinç düzeyi  getirecektir. Teknoloji okuryazarlığı artmakta olan gençliğin bu alana yönelmesi de bu sektörde daha fazla çalışma yapılacağına inandırıyor.  Baktığımızda teknolojinin geleceği zaten parlak ve teknoloji artık çok hızlı ilerlediği için istemeseniz bile, dünyadan soyutlanmış bir ülke olsanız bile eğer birşeyler  üretecekseniz her türlü teknolojiye ihtiyaç duyarsınız. O yüzden bizim ülkemizde de yazılım sektörünün geleceği parlak olacaktır; çünkü insanlar işlerini teknoloji üzerinden yapacaklardır dolayısıyla teknolojide  yazılım sektörünü besleyecektir. Evet yazılım sektörünün geleceği parlak olacaktır ama ne kadar hızlı olacağını önümüzdeki yıllar gösterecektir.

  • Türkiye’de Bilgisayar Mühendisliği eğitimi ile ilgili sektörün beklentileri nelerdir? Eğitimin yeterli düzeyde olduğunu düşünüyor musunuz?

Hayır! Eğitimin yeterli düzeyde olduğunu düşünmüyorum ,aslında sadece düzey değil içerik ve planlamala ilgili de sorunlar olduğunu düşünüyorum. Örneğin yazılımcı olmak isteyen bir öğrenci lisans eğitiminde Mikroişlemciler veya Lojik dersinin temelini öğrensin ama bu dersler ile sık boğaz edip Java’yı aşağıda tutmak veya C# ‘ı göstermemek  veya bir veritabanı düşünen öğrenciye  Oracle SQL’i gösteriyorsanız bunu sadece Select Query’si ile  sabit tutmak bu alanları düşünen öğrenciler açısından son derece sıkıntılı bir durum. Gerçi bunun yapılması zor veya  şu an  üniversitelerde olan bir şey değil ama üniversitelerin sektörün ihtiyaç duyacağı alanlara göre öğrenci  yetiştirmesi  gerektiğini düşünüyorum. Örneğin; veritabanı alanında öğrenci yetişriyorsa bu alanda yetiştiripte öylece piyasaya sürmesi lazım  ve bu öğrenci piyasaya çıktığında işte ben bu alanda eğitim aldım , şu şu projeler yaptım bu konuda bilgi sahibiyim diyebilmesi lazım ama şu aşamada gördüğüm kadarıyla proje yönetimi, network , sistem güvenliği , yazılım , donanım ,… alanların hepsi aynı anda verilince öğrenci adeta overload (aşırı yükleme) oluyor. Sanırım üniversiteler  öğrenci mezun olmadan ne kadar çok alan verirsek  o kadar iyi düşüncesinde oysa mühendislikte algıyı düşünmek lazım yani normal bir ders gibi değil , yani en iyi çözüme yaklaşabilmek için  beynin biraz daha kullanılması(motorun yanması) gerekir. Çünkü mühendislikte bir problemi çok farklı yollardan çözebilirsiniz ama en iyi ,en performanslı ,en doğru  çözümü bulmak için biraz daha farklı düşünmek gerekir. Yani üniversite öğrencilere üstünkörü bütün alanları vermektense sektörden , sektör bilgisi iyi olan öğrencilere sektöre dair bigiler veren bir hocayı getirtip öğrencileri sektöre hazırlaması  gerekir. Zaten siz üniversiteyi okurken sektörden biriyle görüşmediğiniz için üniversite  de sizi sektöre hazırlamadığı için  sadece eğitim almış oluyorsunuz ,öğreniyorsunuz. Aslında bu kopukluğu kırmak için de Teknoparklar var. Teknoparkların çıkış amacı da budur yani teknoparklar hem küçük ölçekli firmalara yardımcı oluyor hem de üniversite ile sektör(piyasa) arasında bir köprü oluyor. Daha doğrusu amaçlardan bir tanesi de bahsettiğimiz köprü göreviydi ama bu amaç gerçekleşiyor mu noktasında açıkçası emin değilim.

  • Sektörde çalışmayı düşünüp iyi bir kariyere sahip olmayı hedefleyen bilgisayar mühendisi adaylarına ne tür nasihatlerde bulunurdunuz iş hayatına dair önerileriniz nelerdir ?

Derslerde kapsamlı olmasa bile teknolojileri görüyorsunuz bu teknolojileri tam öğrenmeye çalışın. Dersi geçeyim hoca şuralardan sorar şeklindeki yaklaşımdan ziyade ürün geliştirmeye  çalışın , çünkü ürün somut bir şey oluyor. Siz bir firmaya gittiğinizde yağtığınız bir web uygulamasını gösterip şurda şu var burda bu var demek işte şöyle bir çalışma yaptık şu teknolojileri kullandık demekten çok daha öte bir şeydir. Sonuçta bir projede çalışmış ve ürün çıkartarak sonuca getirmişsiniz. O yüzden ürün yapabiliyorsanız ki şu aşamada web’te , mobil’de , veri madenciliği’inde ürün geliştirmek çok kolay ;ürün geliştirmeye çalışın ve kendinizi geliştirin örneğin; daha çok araştırın , alanınızla ilgili seminer ve konferanslara katılın ,İngilizcenizi olabildiğince çok geliştirin çünkü farkedildiği üzere bilgisayar mühendisliği ile alakalı  Türkçe kaynak bulmak oldukça zor hatta neredeyse yok(Bi Türkçe kaynak diyebileceğimiz Yrd. Doç. Dr. Şadi Evren ŞEKER bilgisayarkavramlari.com var J). Girişimleri takip etmeye çalışın  kim ne yapıyor , sektör nereye gidiyor, hangi teknolojiler revaçta, işe girerken hangi teknolojiler işime yarar gibi soruları cevaplandırın. Bunun dışında yatırım alabiliyorsanız yatırımlık projeler yapmaya çalışın, yaptığınız her bir ürünü bir yere dayandırmaya çalışın. Örneğin bitirme projesi yapıyorsunuz zaten yapacaksınız neden bunu bir yarışmaya sunmayasınız ,sektörden kişiler ile network’unuzu artımaya çalışın; çünkü bazı büyük firmalar genelde kendi içerisinden CV’ler alıyor. Sektördeki ağınızın geniş olması demek CV’inizi gönderebileceğiniz daha fazla kişi demektir. Bunu menfaatçi duygular ile söylemiyorum. O insanlar size ilham da olabilirler bu açıdan network’unuzu geliştirin.

Sorunun ikinci kısmında ise iş hayatında farklı kişilerle çalışacaksınız. Üniversitede kendi arkadaş grubunuzu seçebiliyorsunuz o insanlarla takılabiliyorsunuz ama iş hayatında böyle bir seçeneğiniz yok. Türkiye büyük bir ülke ve bu ülkenin farklı farklı yerlerinden gelmiş farklı kültürdeki insanlar ile çalışabilme ihtimaliniz var. Bu yüzden sıkıntı yaşamamak adına  sosyal ilişkilerinizin iyi olması gerekiyor yok işte ben istemesem bunlarla takılmam gibi bir lüksünüz yok, çünkü o insanlarla iş yapmak zorundasınız. Birde teknolojileri takip etmek sizin açınızdan faydalı olucaktır. Kısaca iş hayatına dair size verebileceğim tavsiyeler bunlar.

 

 

Bu yazıda üniversite ve bir sonraki adımı olan sektör hakkında fikirler içerdi. Bu ilişki açısından bu yazı bana daha önce lise ve üniversite arasındaki farklı yazdığım bir yazıyı hatırlattı. Okumak isterseniz bonus olarak o yazı : Fark Var

Nesnelerin İnterneti -Internet Of Things (IoT)

Nesnelerin İnternet’I (Bilinen adıyla IoT – Internet of Things) birbirleri ile veya daha büyük sistemlerle iletişim halinde olan nesnelerin oluşturduğu ağdır. Amerikan Federal Ticaret Komisyonu Nesnelerin İnterneti için “ Günlük kullanımımızda olan nesnelerin İnternet’e bağlanıp veri gönderip alması kabiliyeti” şeklinde bir tanımlama yapmıştır. Nesne kavramı Nesnelerin İnternet’i açısından geniş kapsamlı bir ifadedir. Sensörler, izleme cihazları, tekil tanımlayıcılarla(unique identifier) veri transferi gerçekleştirebilen insan ve hayvanları da kapsar. IoT açısından nesne kavramı bu kadar geniş olduğu için kimileri Internet of Things ifadesini Türkçe’ye Şeylerin İnternet’i olarak çevirir. Şeylerin İnternet’i ifadesi net bir ifade gibi görünmediğinden Nesnelerin İnternet’i ifadesinin daha doğru olduğu düşüncesindeyim.

internetofthingNesneler üzerindeki sensörler aracılığıyla wireless teknolojileri, mikroelektromekanik sistemler ve internet aracılığıyla oluşan bilgi Nesnelerin İnternet’ini oluşturur. Nesnelerin İnternet’inde esas önemli kısım nesnelerdir. Önemli aşama etkileşim halinde olduğumuz nesnelerin sensörlerle akıllı (smart) hale getirilmesi sonucu birbirleri ile iletişimi, veri alışverişi ve bu işlemler sonucunda işlemler yapabilecek hale gelmesidir.  Cihazlardan elde edilen veriler değerlendirilerek bilgi haline gelir ve bu bilgi işlenerek kullanılır. İlk zamanlarda Nesnelerin İnterneti M2M(Machine-to-Machine) haberleşme ile ifade edilmeye başlamıştır. M2M haberleşme ile birbiriyle veri alış-verişinde bulunabilen sistemlere akıllı sistemler denildi. Bu çerçevede akıllı ev, akıllı ofis, akıllı şehir gibi ifadeleri duymaya başladık. Akıllı sistemler konusu da bir yazıyı hakedecek kadar önemli bir konu. O da başka yazıya kalsın 🙂  Tekil tanımlayıcılarla (unique identifier) tanımlanmış nesneler İnternet aracılığıyla entegre bir şekilde beraber çalışır. Nesnelerin beraber çalışmasından doğan verilerin değerlendirilmesi sonucunda bir çözüm üretilir. Çözüm bulma hedefi Internet of Things kavramının tarihçesine baktığımızda ilk olarak bir kahve makinesinin kamera ile gözetlenmesi karşımıza çıkıyor. 1991 yılında Cambridge Üniversitesi’ndeki yaklaşık 15 akademisyenin kahve makinesini görebilmek için kurduğu sistem sayesinde kahve makinesinin görüntüsünü dakikada üç kez bilgisayar ekranlarına gönderiyordu. Bu şekilde gerektiğinde kahve makinesine müdahele ediliyordu. Bu sistem 2001 yılına kadar kullanılmıştır. Internet of Things ifadesinin ilk kullanımı ise 1999 yılında İngiliz Girişimci Kevin Ashton tarafından kullanılmıştır.  RFID(Radyo Frekans Tanımlama) teknolojilerin şirketine getireceği faydaları anlattığı sunumda “Internet of Things ” ifadesini kullanmıştır. RFID teknolojisinin IoT’nin vazgeçilmesi olacağı ifade ediliyordu aynı sene.

Birbiriyle ilişkili cihazların  sayısının yıllar geçtikçe daha da artması başka sorunları da beraberinde getirdi. Şu an 10 Milyar olan Internet bağlantılı cihazların sayısının 2020 yılında 21 milyar cihaz seviyesine çıkacağı tahmin ediliyor. Bu cihazların ortaya çıkaracağı büyük verinin yönetilmesi bir problem olarak karşımıza çıkıyor. Yakın zamanda İnternet’in yaygınlaşması ve bu şekilde cihazların hayatımıza girmesi sebebiyle hızlı şekilde ortaya çıkan ve sürekli artagelen verinin kaydedilmesi, yönetilmesi önem kazanıyor. Bunların sonucunda da big data (büyük veri), veri analizi gibi kavramlar ortaya çıkıyor. Bu sebeple Nesnelerin İnterneti ve Büyük Veri kavramları ve uygulamaları birbirleri iç içedir. Büyük veri ile ilgili blogtaki yazıyı bu linkten okuyabilirsiniz : Veri Dünyasının Geleceği : Büyük Veri (Big Data)

Ipv6 protokolüne geçiş de cihaz IP çakışmalarının önüne geçmesi bakımından önemli bir adım olmuştur.

Nesnelerin İnterneti Projelerine Dair Dikkat Edilmesi Gereken Konular

Verinin Güvenliği ve Gizliliği : İnternetin Nesneleri etkileşim halinde olduğumuz cihazlardan veriyi temin ettiği için bu verinin herkesten tarafından kullanılabilir mi yoksa kişisel veri olarak mı kullanılacağı konusu gizlilik bakımından önemlidir. Verilerin gizliliği için güvenlik algoritmaları ile şifrelenme işlemi gerçekleştirilmelidir.

Cihaz (Sensörler) : Nesnelerin İnternet’inde esas olan datayı sağlayan cihazlardır. Nesnelerin İnterneti kavramının ortaya atıldığı toplantıda RFID teknolojisinin Nesnelerin İnterneti’nin vazgeçilmezi olduğu ifade edilmiştir. Daha sonra NFC, QR kodlar, barkod teknolojileri de Nesnelerin İnterneti projelerinde kullanılmaya başlandı.

Verinin Toplanması ve Analizi : Nesnelerin İnternet’i projelerinde hangi sensörlerden hangi verilerin alınacağı, alınan verinin nasıl değerli bir bilgi haline getirilebileceği belirlenmelidir. Cihazdan gelen çok miktarda verinin analizi sonucunda elde edilen değerli verinin nasıl kullanılacağı sistemler ile belirtilmelidir.

Bu yazıda sadece Nesnelerin İnterneti’nin ne olduğundan bahsedebildim. Bir sonraki yazıda Nesnelerin İnterneti hayatımızda neyi değiştirecek, hayatımıza yansımalarını nasıl olacak bunlara değinmeye çalışacağım.

Veri Dünyasının Geleceği : Büyük Veri (Big Data)

Büyük veri; sosyal medya paylaşımları, ağ günlükleri ,bloglar, fotoğraf, video, log dosyaları vb. gibi değişik kaynaklardan toparlanan tüm verinin, anlamlı ve işlenebilir biçime dönüştürülmüş biçimine denir. Özetlemek gerekirse herhangi İlişkisel veritabanları ile yönetilemeyecek büyüklükte olup  büyümeye devamlı devam eden verilerdir. İlişkisel veritabanları yapılandırılmış verilerle ilgilendiğindiği için günümüzdeki kısıtlı veriyi işleyebilir. Ancak buz dağının görünmeyen yüzü olan yapılandırılmamış data ise big data’nın alanına girer.  İlişkisel veritabanları terabyte seviyesinde veri tutabilirken, büyük data ile petabyte seviyelerinde veriler saklayabiliriz.  Büyük veri veriyi bir defa yazıp sonrasında defalarca ve paralel şekilde okuyup işleyebilir. Dünya çapında yıllık veri hacmindeki büyüme %59 ve büyümenin artarak devam etmesi bekleniyor. Bu büyümenin merkezinde hem geleneksel hem de yeni veri kaynakları yatıyor. IDC önümüzdeki on sene içinde de şu anki verinin 44 katına çıkacağını tahmin ediyor. Twitterda her gün 7 TB, Facebook ise 10 TB’dan fazla data saklıyor.  Ve bu datanın büyük bir kısmı yapısal olmayan veriden oluşuyor. Big data bu datanın çöplük olmasını engeller. İlişkisle veri tabanlarında yapısal olmayan data işlenemediği için faydalı olamıyordu. Ancak yapısal olmayan datanın sürekli artışı bu tablonun değerlendirilmesini zorunlu hale getirdi.  Çöplük kelimesinden çağrışımla bir nevi çöplükten enerji elde edilmeye başlandı. Ve bu enerji çok kıymetli.

Big data bu yapısal olmayan veri ile yapısal verinin işlenmesiyle çok değerli bir hal almasını sağlıyor. Buradan bu verinin neden bu kadar değerli olduğuna –CRM deki kullanımına-   geçmek istiyorum.   Bu veriler işlenip analiz edilerek geleceğe dair stratejiler, yapılacak kampanyalardan çıkarılacak ürünlere kadar bir çok konuda kullanılıyor. Eskiden ürün çıkartılır ve bu müşteriye sunulurdu. Ancak artık e-ticaret sitelerindeki alışverişler sosyal medyadaki paylaşımlar ile artık müşterinin taleplerine göre ürün çıkartılıyor.  Hükümetler bu işlenmiş verilere göre yönetim stratejilerine yön veriyor. Büyük veriye en çok önem veren ülkeler: ABD, Hindistan ve Birleşik Krallık

Big Data’yı üç formda sınıflandırabiliriz. Yapılandırılmış(Structured), Yarı Yapılandırılmış (Semi Structureed) ve Yapılandırılmamış(Un-structured)

Yapılandırılmış (Structured)  : Belli bir yapıda(formatta) depolanabilen, işlenebilirliği ve erişilebilirliği olan veridir.  İlişkisel veri tabanlarındaki datalar buna örnektir. Belirli yapıdaki veriler tablolar aracılığıyla ilişkilendirilerek sistemli bir şekilde işlenir.

Yarı Yapılandırılmış (Semi- Structured) : Tablolar ile kesin bir sistemle düzenlenmemiş verilerdir. Veriler arasında bir ilişkilendirme yapısı yoktur. XML dataları buna örnektir. Özellikle internet kullanımının da artmasıyla 2000’lerden sonra yapılandırılmamış veriler log ya da history tablolarıyla yapılandırılmış dataya çevriliyor.

Yapılandırılmamış(Un-Structured) :  Bilinmeyen bir formda –standart olmayan- yazılmış verilerdir. Standart olmamamasının bir sebebi de bu dataların büyük hacimli ve karmaşık olması.  Dosyalar, videolar, resimler, metin dosyaları gibi farklı yapıları içinde barındırır. Bunun en bilinen örneği google’dır.

Big Data Nitelikleri (5 V)

  • Hacim (Volume): Big data ‘ya adını veren big (büyük) sıfatı çok büyük boyutları barındırabilmesidir. Big dataya olan ihtiyaç datanın hacmi ile doğru orantılıdır. Bir işte big dataya gereksinim olup olmadığı o projedeki data hacmine bağlıdır.
  • Çeşitlilik (Variety): Hacimden sonra big datayı öne çıkaran bir başka niteliği ise farklı türde heterojen datayı birlikte işleyebilmesi. Eskiden veri tabanları benzer kaynaklardan beslendiği için çeşitlilik büyük bir sorun değildi. Ancak gün geçtikçe veri tipi daha çok çeşitleniyor. Email, ses, resim,fotoğraf ve akıllı sistemler ile sağlanan çeşitli yapılardaki dataları işleyebilir.
  • Hız (Velocity) : Veriyi tanımlama, bağımlılıklarına göre hızlıca genelleştirip kullanılabilir potensiyel bir data haline gelir.
  • Değişkenlik (Variability) : Bu sayede tutarsız verileri etkili yönetebilir.  Farklı sistemlerin farklı yerlerdeki datalarını kombine eder. Bir çok kaynaktan gelen veriler birbirinden farklı türlerde olacağı karmaşık bir veri büyüklüğüne sebep olur. Big data bu karmaşık  verinin yönetimini hızlı bir şekilde sağlar.
  • Değer (Value ): Verilerimiz yukarıdaki veri bileşenlerinden filtrelendikten sonra büyük verinin üretimi ve işlenmesi katmanlarında elde edilen verilerin geleceğe yönelik stratejilerde belirleyici oluyor.

Big Data Avantajları

Büyük verinin avantajlarını dört başlıkta toplayabiliriz : Doğruluk, zaman yönetimi , müşteri talep yönetimi, gerçek zamanlı etkileşim.

 

Daha önce konuyla ilgili olarak blogtaki bir yazım : Big Data

1 2 3 9