Singapur

Singapur

648 kilometrekare yuzolcumlu, nufusunun %78’i cinli, %12’si malezyali, %7’si hindu, %3’u ise bilumum milletlerden olusan minicik bir ada ulkesi. bu ulkede sokaklar, non smoking olmayan otel odalari ve bir kaç bar disinda sigara icmenin 1000 singapur dolari’na maloldugu ve gece sokaklar bombosken dahi insanlarinin kirmizi isikta bekledigi inanilmaz duzenli ve temiz ulke.

İnsanlarinin refah seviyesinin ne kadar yuksek oldugunu herhangi bir bilimsel arastirmaya ihtiyac duymadan sokaklarda dolasan araclardan rahatlikla anlayabileceginiz ulke.

Fotoğrafçılık Meslek mi? Yoksa Sanat mı?

Fotoğrafçılık Meslek mi? Yoksa Sanat mı?

Işığın açısı, diyafram açıklığı, örtücü hızı,iso falan gibi pek çok değişkeni bir kimsenin tamamen subjektif yorumlaması ile ortaya bütünüyle bir kişisel yorum çıkar.

aynı kareyi 10 fotoğrafçı çeksin 10 farklı yorum görebiliriz.
yani fotoğrafçılığın içinde yorum vardır.
yorum var ise yaratıcılık vardır.
yaratıcılık var ise sanat vardır gibime geliyor..

ara güler mütevazılığın gereği olarak sanat değil demiş olabilir.

fotoğrafçılık sanat değilse şarkı söyleyenler de sanatçı değil diyebiliriz.
kendilerine ait olmayan bir eseri seslendiriyorlar.

DevOps Nedir?

DevOps Nedir?

devops bir title değil, bir kültürdür’ olayına katılmadığımı söyleyim öncelikle. yönetim de sadece yöneticiyle değil takımla da ilgili bir olay mesela, ama ‘yöneticilik bir title değildir’ demek ne kadar saçma olacaksa, bence bu da öyle. devops herşeyden önce bir kültür evet, bir teknikler bütünü – bir sistematik, ve hatta bir sorun çözme biçimi. bir disiplin yani. ve her disiplin gibi, onu iyi anlamış, doğru uygulayan ve çevresindekilere doğru şekilde öğreten insanlara ihtiyaç duyuyor. bu da gayet önemli bir ‘title’ demek.

ha evet, tabii ki kapısında ‘devops’ yazan bir ekip olmadan da çok güzel işlere imza atabilirsiniz, ama bu demek değildir ki ‘devops’ pratiklerine ihtiyacınız yok veya onları uygulamıyorsunuz.

devops, benim için, otomasyon sanatı olsa gerek. her programcı bir şeyleri otomatize etmiyor mu diyebiliriz, ama bu çok daha geniş bir otomasyon. altyapının, networkün, makinelerin, işlerin, insanların ve süreçlerin otomasyonundan bahsediyoruz. hepsinin kendi içinde de değil, birbirleriyle etkileşimin otomasyonu.

‘geliştiricinin yaptığı commit, yayındaki web sitesine nasıl gidecek?’

* committen önce, bu commitin yapılmasına sebep olan iş nereden ve nasıl geldi? nasıl tanımlandı? ekip, ihtiyacı olan şeyi geliştiriciye doğru şekilde aktarabildi mi?
* geliştirici commiti nerede ve nasıl yaptı? önünde hazır bir development ortamı var mıydı? bu ortamı nasıl kurdu? bu ortamın hatasız ve istendiği gibi olduğundan emin miyiz? her geliştiricinin önünde aynı ortam olduğuna emin miyiz? bu ortamın, canlı yayın ortamını yeterli şekilde yansıttığından emin miyiz?
* geliştirici bu commiti nereye gönderdi? bir git hosting mi satın aldık yoksa kendimiz mi kurduk? bu git alanı üzerinde yetkiler doğru tanımlanmış mı? aynı anda çeşitli geliştiricilerden çok sayıda commit geldiğinde, birbirlerine karışmadan ve sağlıklı şekilde süreç devam edebiliyor mu?
* commit geldi, kalitesinden emin miyiz? otomatik testlere giriyor mu – giriyorsa nasıl giriyor? test patlarsa noluyor? ekipteki diğer kişiler tarafından kalite kontrolünden geçirildi mi?
* herşey tamam, commitin kalitesinden eminiz, işi açan kişi, iş tanımının karşılandığını ve gerekli geliştirmenin hakkıyla yapıldığını düşünüyor mu?
* bu özellik sitedeki başka herhangi bir şeye zarar veriyor mu? (bu tek cümle, kocaman bir qa sürecinin özeti aslında.) bunun cevabını alabilmek için tabi, commitle gelen değişikliği nasıl bir test ortamında ve ne şekilde yayına aldığınız şeklinde bambaşka dinamikler içeren bir süreci incelemek gerekiyor.
* commit depoya kabul edildi;
** bu commit, geliştiricilerin günlük düzeninde önemli bir değişiklik yaratıyor mu? yaratıyorsa, nasıl bir bilgilendirme yapmalı?
** bu commit, daha önce stackte olmayan yeni bir araç gerektiriyor mu? bu araç nedir, nasıl kurulur, nasıl ayarlanır? yayındaki siteye zarar vermeden nasıl yayına dahil edilir?
** bu commit, veritabanında bir değişiklik gerektiriyor mu? bu değişiklikler, yayındaki web sitesine zarar vermeden nasıl uygulanır? bu değişiklikler, geliştiricilerin önündeki ortama nasıl uygulanır?
* tüm gerekli değişiklikler tespit edildi ve bilgilendirmeler yapıldı, bu değişiklikler yayındaki websitesine nasıl yansıtılacak? (hey gidi koca ‘deployment’)

hepsini bitirdik, geliştiricinin yazdığı kod yayına girdi. bir de o yayındaki sitelerin nasıl bir performansla çalıştığı, ayakta kalıp kalamadığı, farklı yükler altında nasıl davrandığı vs. konular var ki içinden çıkılmaz, kısa kesiyorum.

bunların hepsini yapabilmek için de bazen geliştirici, bazen sistemci, bazen sre, arada dba, kimi zaman networkçü olmanız gerekiyor. öyle puppet ya da chef implemente etmekle olan bir iş değil yani. hatta en uyuz olduğum şey, devops’un araçlardan ibaret bir iş sanılması. otomasyondan konuşuyorsak, otomasyonu sağlayacak aracın hayati önemi olduğu doğru, ancak buradaki en önemli ‘araç’ insanın ta kendisi.

ha bir de herkesin her konuda fikri olması durumu var. biri gelir ‘olm siz docker kullanmazsanız olmaz o iş’ der, biri gelir ‘abi muhteşem ya nasıl kullanmazsın manyak mısın’ der. bir ara herşeyin mikroservise dönüşmesi gerektiğini savunan bir dünya insan vardı, neyse şükür ki zamanla azaldılar. ya bu teknoloji/yöntemlerin hepsi, kendi içlerinde gayet güzel şeyler olabilir ama hali hazırda çalışan bir altyapı söz konusu ise, onun nasıl çalıştığını anlamadan, araştırmadan, bilmeden üstüne ‘x kullanmalıyız çünkü bu ara çok hype’ kafasıyla etrafa tavsiyeler yağdırmak, ne bileyim işte üzülüyorum… ucu sistem yönetimine dokunan bir alanda nasıl hype-driven iş yapılabildiğini de aklım almıyor, javascript kütüphanesi mi yahu bu?

özet olarak, stres altında çalıştığınızda insanı hayatından soğutabilecek, ama doğru şartlarda bi o kadar da keyif vermesi mümkün ve çılgın miktarda yeni bilgi edinmeyi sağlayan/gerektiren bir alan. yalnız, ekosisteme hakim değilseniz çok can yakan bir learning curve’i var. etrafınız, naptığını biliyormuş gibi davranan insanlarla doluyken sizin hiçbir şey anlamıyor olmanız insanı salak gibi hissettiriyor ama inanın onlar da çok anlamıyor, detaylara pek takılmıyorlar sadece.

PEGA nedir? Ne işe yarar?

PEGA nedir?

Pegasystems satış, pazarlama, servis ve operasyonlar için stratejik uygulamalar geliştirir. Pega’ nın uygulamaları, kritik iş süreçlerini en verimli hale getirir, kurumlar ile müşterilerini gerçek zamanda, tüm kanallardan, kesintisiz bir şekilde birbirine bağlar ve hızla değişen ihtiyaçlara uyum sağlar. Pega’nın müşterileri arasında dünyanın en önde gelen yetkin ve başarılı kurumlarının bir çoğu yer almaktadır. Tamamı yerinde ya da Bulut ortamında kurgulanabilen Pega’ nın bu uygulamaları, görsel araçları ile stratejik iş ihtiyaçlarını karşılamak için uygulamaları kolaylıkla genişletme ve geliştirme imkanı sağlayan Pega 7 platformunda oluşturulmuşlardır.