Ahmet Oğuz Koca

Sosyal olaylar.

Esnek çalışma saatleri ile ilgili bir infografik

Esnek çalışma saati "çalışanların kişisel ihtiyaç ve tercihlerine göre günlük çalışma süresinin başlangıç ve bitiş saatlerini değiştirmelerine olanak tanıyan çalışma süresi düzenlemeleri" anlamına gelmekte ancak ülkemizdeki yapısal aksaklıklar sebebiyle iş verenler tarafından çoğu zaman işe giriş saatinin sabit işten çıkış saatinin belirsiz olması anlamında kullanılıyor. Malesef bu ekstra çalışma saatlerinin de karşılığı olmadığı için işverenler tarafından ciddi derecede suistimal ediliyor. Vodafone gerçek anlamında kullanıldığında esnek çalışma saatlerinin iş yerlerine ne kazandırabileceği ve mevcut durum hakkında bir çalışma hazırlamış, ben de elimden geldiği kadar tercüme ettim. Esnek çalışma saatleri hakkındaki görüşlerinizi yorum olarak bırakabilirseniz sevinirim.

 Patronların

%56'sı verimliliğin düşeceğinden korkuyor

%40'ı çalışma saatinin doğru hesaplanamamasından kaygılı

%50'si takım çalışmasın sekteye uğrayacağından korkuyor

Çalışanların

%75'i iş tatiminlerinin artacağını düşünüyor

%72 iş hayatı normal yaşam dengesinin sağlanacağını düşünüyor

%54'ü daha verimli çalışacağını düşünüyor

 

Patronların esnek çalışma saatlerinden gelecekteki beklentileri

%54'ü daha küçük ofis alanından dolayı maliyetlerin düşeceğini bekliyor

%57'si organizasyonların daha verimli olacağını düşünüyor.

%70', çalışanların tatmin düzeyinin artacağını tahmin ediyor.

 

Infografiğin devamında şirketinizi nasıl esnek çalışma saatlerine taşıyabileceğinizden bahsediyor. 

Bu kısım daha çok patronları ilgilendirdiğinden burada bırakıyorum.

Fazlası...

Networking kitabından notlar

Ertuğrul Belen tarafından yazılmış olan "Networking Tanışma, Tanıştırma ve Tanınma Sanatı" adlı kitaptan aldığım notları paylaşıyorum.

Kitap Detay

Daha iyi bir kariyer ve daha iyi bir iş ağı için bu kitabı okumanızı tavsiye ederim.

* Firmalarda oluşan pozisyonların neredeyse %80'i için hiç ilan verilmiyor
* Tanıdığınız birinin referansıyla gittiğiniz bir görüşmede başarılı olma şansınız %63 daha yüksek.
* İşe alımların %59'u networking ile bağlantılı gerçekleştiriliyor.
* Dünyadaki tüm ticari hacmin %65'inin referanslarla gerçekleştiği tahmin ediliyor.
* Yeni kurulan şirketlerin %70'i kendi network gücüyle ayakta kalıyor.
* Networking daha fazla insan tanımak değildir. Pareto prensibinin geçerli olduğu alanlardan biridir yani tanıdıklarınızın %20'si hayatınızda %80 etki yaratır.
* Networking çok daha fazla kişiyi tanımak değil çevrenizdeki insanlara daha fazla yararlı olmaktır.
* İlk tanışmanızda insanların hemen size güvenmesini beklemeyin. Bunun için en az 5 kez görüşmeniz gerekir.
* Tanışma, tanınma, itibar ve sonunda güven gelir.


bu kitabı okuduktan sonra kendime bir kart bastırdım, onu da paylaşayım :)


Sil baştan kitabından notlar 1

Sil Baştan (Rework) kitabından aldığım notları parçalar halinde yayınlama karar verdim. Bir yılın ardından blog'uma yazdığım ilk içerik olacak. 

Not kitap hakkında detalı bilgiyiye buradan ulaşabilirsiniz. 

 

Bir diğer yanılgı da şu: "İnsan hatalarından ders çıkarmalıdır." Hatalarımızdan ne gibi dersler çıkarabiliriz ki? Belki neyi bir daha yapmamamız gerektiğini öğrenebiliriz, ama bu çok mu değerli bir derstir. Bundan sonra ne yapmamız gerektiğini bilmiyorsak hele. Bunun yerine başarılardan ders çıkarmak daha doğru olmaz mı? Başarı sizi donatır. Bir şey başarılı olduysa neyin işe yaradığını görebilirsiniz ve bunu tekrarlayabilirsiniz. Hatta bir dahaVki sefere muhtemelen daha iyi yapabilirsiniz.

 

Yapılan bir araştırmada başarılı girişimcilerin bir sonraki girişimlerinde başarıyı yakalama oranının başarısızlara göre %50 daha fazla olduğunu ortaya koydu.

 

Tahminlerinizi planlara çevirirseniz tehlikeli bölgeye adım atarsınız. Planlar geçmişin geleceğe yön vermesine neden olur. Başınıza at (at mı ne atı) gözlükleri takarlar. "Bu yönde ilerleyeceğiz çünkü bu yönde ilerleyeceğiz demiştik. Sorun da bu zaten planlar doğaçlamaya aykırıdır.

 

İşkolikler çözdüklerinden daha fazla sorun yaratırlar. Her şeyden önce, böyle bir çalışma sıklığı sürdürülebilir bir şey değildir. Psikolojik yorgunluk başladığını zaman ki başlayacaktır, bireyi orantısal bir şekilde çarpacaktır. İşkolikler meselenin özünü de kavrayamamışlardır. Sorunların üzerinde aşırı zaman harcayarak onların üstesinden gelebileceklerini düşünürler. Entelektüel tembelliği kaba kuvvetle ikame etmeye çalışırlar. Bu da zarafetsiz sonuçlar doğurur.

 

Evrende insanlara anlam ifade eden küçük bir çentik oluşturmalısınız. Bir şeyler yapmak istiyorsanız önemli bir şeyler yapın. 

 

Bir ürün veya hizmet geliştirdiğiniz her gün yüzlerce küçük meseleyi karar bağlarsınız. Başkasının sorununu çözmeye çalışıyorsanız karanlıkta hareket ediyorsunuzdur ama kendi sorununuzla ilgilendiğiniz zaman ışıklar açıktır.

 

Kendi sorununu kendin çöz yaklaşımı insanı yaptığı işe aşık eder. Sorunu da bulunan çözümün kıymetini de yakından biliyorsunuzdur. Buna ikame edilebilecek bir şey yoktur. Yaptığınız iş sizin için önemli bir şey olsa iyi olur.

 

Çıktığınız yolda ilerlerken yaptığınız şeyi neden yaptığınızı hep aklınızda tutun. Büyük şirketlerin belli bir bakış açısı vardır, sadece bir ürün ya da hizmetten ibaret değillerdir. Bir inancınız olmalı. Sizi ayakta tutan bir belkemiği olmalı. Ne için savaşmayı göze aldığınızı bilmelisiniz. Sonra da bunu dünyaya göstermelisiniz.

 

Yaptığın iş iyi değilse yapmanın anlamı yok.

Aslında inanmak ve inandığınız şeyi yaşamaktır.

Sadece parayla mutlu olabilecek misiniz? Gerçekten keyif aldığınız ve inançla bağlandığınız bir şirketi yönetmekten daha büyük bir keyif verecek mi size bu?

 

 

Entity Framework'te Jenerik Repository kullanımı

Bilindiği üzere büyük ölçekli (multi tier/layer) uygulamalarda DRY (don’t repeat yourself/kendini tekrar etmeme) prensibini etkin şekilde kullanarak proje içindeki kod tekrarlarının önüne geçmek çoğu zaman mümkün olamayabiliyor. Özellikle de veri tabanı merkezli (database centric) uygulamalarda farklı entityler (tablo/class) üzerinde işlemler yaparken sık sık kod tekrarları (çoğu zaman where ve orderby sorguları) yapmak durumunda kalabiliyoruz. Bu durumda da proje sonunda elimizde onlarca benzer fonksiyon ve class’tan oluşan yapılar kalabiliyor. Bu da projelerde hem kodlama (harcanan zaman ve emek) hem de bakım (maintenance) maliyetini arttıran bir faktör olarak karşımıza çıkıyor.

Aslında C# dilinin gelişimi sürecinde dile eklenen yeni yöntem ve isim uzaylarını (namespace) etkin şekilde kullanarak bu tekrarların önüne geçmek mümkün. İlk bakışta dilin temel söz diziminin (syntax) ötesine geçmesinden dolayı okunabilirlik konusunda zorlukları olsa da bir kaç alıştırmadan sonra siz de bu yöntemleri öğrenip projelerinize kolaylıkla entegre edebilirsiniz.

Ben de bu yazıda linq ve jenerikler yardımıyla bir repository sınıf oluşturucak ve modelimizdeki tüm entitylerimiz üzerinde başka bir sınıfa ihtiyaç duymadan istediğimiz işlemleri nasıl yapabileceğimizi anlatıyor olacağım. Konuyu oldukça basit tutmak amacıyla iki farklı sınıf (entity) üzerinde duracağız ancak jenerik repository kullanmanın faydalarının farkına projemizdeki entity sayısı arttıkça daha fazla varabiliriz.


Basitleştirilmiş iki entitymiz şu şekilde olsun

Fazlası...

Linq aracılılığıyla basit bir DRY (don't repeat yourself) yöntemi

Programlama dünyasında aynı veya benzer amacı taşıyan kod bloklarının uygulamanızın farklı yerlerinde defalarca yer alması istenen bir durum değildir (don't repeat yourself). Özellikle çok katmanlı uygulamalarda bu problemden kaçınmak malesef oldukça zor olabilmekte. Bugün bir projenin kaynak kodları üzerinde araştırma yaparken programcının bu sorunun üstünden gelmek için güzel bir yöntem izlediğini gördüm ve sizlerle de paylaşmak istedim. Ben burada konuyu mümkün olduğu kadar basit tutmak amacıyla çok küçük bir örnek ile konuyu anlatmaya çalışacağım. 

Şekildeki gibi bir Member Class'imiz olsun

 

Öncelikle DB üzerinde işlem yaptığımız bir Reposiyory class'imiz olsun (örnekte MemberRepository) Class'imiz ile site üyelerimiz arasında isim ve email adreslerini kullanarak arama yapıyoruz.

İlk iki fonksiyonumuzda klasik yöntemle iki ayrı fonksiyon oluşturuyoruz. Bunlardan birincisi ile Nick üzerinden ikincisinde ise email adresi üzerinden ilgili kullanıcının veritabanımızda yer alıp yer almadığını kontrol ediyoruz. Üçüncü fonksiyonumuzda ise Linq expression'lar arayıcılığıyla daha esnek bir GetMember fonksiyonu oluşturuyoruz ve hangi parametre üzerinden arama yapılacağını sınıf örneğini oluşturan client kodumuza bırakıyoruz. Bu sınıf üzerinden işlem yapan istemci kodlarımız ise şöyle

Görüldüğü üzere linq expression ile oluşturduğumuz GetMember fonksiyonumuz sayesinde kod tekrarından kurtulmuş olduk ve uygulamamıza müthiş bir esneklik kattık. Nick ve EMail Adresinin yanında aynı fonksiyon sayesinde Member Class'imizin bir çok fieldi üzerinde arama işlemi yapabileceğimizi de unutmayalım. Ben burda sadece where fonksiyonu üzerinden örnek yaptım ancak tahmin edebileceğiniz üzere order sorgularından group'lama işlemelerine kadar bir çok yerde bu esnekliği siz de kullanabilirsiniz. Görüş ve önerilerinizi yorum olarak bırakabilirsiniz. Kolay kodlamalar...

Asp.Net MVC3'te Recaptcha (güvenlik kodu) kullanımı

Asp.net MVC3 projelerinizde form alanlarınız için güvenlik kodu uygulamasına ihtiyaç duyarsanız, NuGet üzerinden Microsoft-Web-Helpers dağıtımıyla dağıtılan google'ın recaptcha uygulamasını kullanabilirsiniz.

Projenize Recaptcha eklemek için öncelikle Nuget'ten "microsoft-web" araması yapıp resimdeki paketi projemize dahil ediyoruz.

Daha sonra captcha uygulamamıza sayfalarımızdan direkt olarak ulaşabilmek için web.config dosyamıza Microsoft.Web.Helpers namespace'imizi ekliyoruz.


Sadece bir tek formda ihtiyaç duyorsanız ilgili sayfada using ile de referans da verebilirsiniz.

Daha sonra kendimize http://www.google.com/recaptcha üzerinden bir hesap açıyor ve Domain alanına ilgili alanadını girdikten sonra bize sağlanan private ve public key değerlerini projemizde kullanmak üzere saklıyoruz. Formumuzda captcha alanını göstermek için form taglarımızda istediğimiz alana bu kodları giriyoruz.

Form verilerimizi aldığımız Controller'imizde bu kodlarla girilen değeri kontrol ediyoruz

Asp.net MVC ile GooglePlus Api kullanımı

Google bu hafta içinde Google+ (google plus) için API desteğini kısıtlı özelliklerle de olsa açınca bende .net developerlar için basit bir client yazma gereği duydum.  Google'ın API'ye ek özellikler eklemesiyle birlikte paylaştığım kodları geliştirmeyi planlıyorum. Görüş ve önerilerinizi benimle paylaşırsanız kodların geliştirilmesine katkıda bulunabilirsiniz.

Şu an paylaştığım kodlarda Oauth2 ile yetki alıp bu yetkiyi kullanarak basit bir get sorgusu yapıyoruz. Bir çok arkadaşın konuya yabancı olduğunu düşünerek adım adım ilerleyeceğimiz bir yazı hazırladım.

Adım 1. API Başvurusu

Öncelikle Google'ın kendi uygulamaları için sağladığı API'lere erişim için Google Console aracılığıyla bir API projesi başlatıyoruz Link => https://code.google.com/apis/console

 Fazlası...

BlogEngine 2.5 kurulumunda .cshtml hatası.

Bugün dotnetblogengine blog'umu 1.6 'dan 2.5'e taşıdıktan sonra yeni versiyondaki .cshtml uzantılı dosyalara erişmeye çalıştığımda IIS,  "HTTP Error 404.7 - Not Found" hatası veriyordu. Hatanın detayını iyi okumayıp bir çok mime ve isapi numarası denedikten sonra sorunun IIS 7.5'te varsayılan olarak .cshtml uzantılı dosyalara erişimin kapalı olduğunun aklıma gelmesi ve IIS'te gerekli ayarı yapmamın ardından problemim çözüldü. Benzer durumda olan arkadaşlar için yapılması gerekenleri paylaşayım istedim.

 

 

IIS'te ilgili sitenin detay bölümünden Request Filtering'i seçiyioruz

 

.cshtml dosyalarına getirilen kısıtlamayı "Remove ile kaldırıyoruz"

 

 

Not: MVC projelerinizde cshtml dosyalarını direkt erişime açmanız güvenlik sorunlarına sebep olabilir bundan dolayı bunu sunucu bazında değil sadece blogengine kurduğunuz websitesi için yapmalısınız.

Asp.net MVC projelerinde ViewModel kullanımı.

 

Asp.net MVC'de Controller sınıflarınızdan view sayfalarınıza istediğiniz nesneleri geçebilmeniz için bir çok yöntem olsada (viewbag, viewdata, entity classları v.s.) kanımca bu imkanların efektif olarak kullanımı neredeyse mümkün değil. Özellikle çalışma zamanı sırasında tip dönüşümü hatalarından ve controller'da bu bilgileri doldurma sırasından oluşan problemlerden (null değer v.s.) dolayı dynamic viewbag yapısı zamanla sadece çile kaynağı haline gelebiliyor. Özellikle unit testing kullanmıyorsanız view tarafında oluşan hataları gidermek proje geliştirme sürecinizin büyük bir bölümünü oluşturabiliyor.

Bütün bu problemlerin üzerinden gelebilmek amacıyla çeşitli tasarım desenlerinden kotarımlar yaparak bir yapı geliştirdim ve bu yapı sayesinde proje geliştirme sürecimi hayli kısaltabildim. Aslen bu yapı endüstri standartlarına çok uygun olmasada özellikle hızlı projeler geliştirmek adına size de bir çok avantaj sağlayabileceğinden sizlerle paylaşmak istedim. Açıklamamı fazla uzatmadan direkt ilgili kodları paylaşıyorum.

 

Öncelikle bütün ViewModel'lerimizi türeteceğimiz bir ViewModel classi oluşturuyoruz. 

http://pastebin.com/ehdsFwtT

 

Bir eticaret sitesi anasayfası yaptığımızı varsayaraktan basit bir AnasayfaViewModel Class'i oluşturuyoruz. 

Class'in içinde view tarafınfa ihtiyaç duyacağımız çeşitli classların liste tipinde örnekleri bulunuyor

http://pastebin.com/vPNFpv1M

 

Controller da ViewModel içinde tanımladığımız listelerimizi dolduruyoruz. 

http://pastebin.com/wD8QXxBT

 

View'imize geçtiğimiz ViewModel class'imiz üzerinden ihtiyaç duyduğumuz işlemleri gerçekleştiriyoruz.

http://pastebin.com/zrp8Jdkk

 

Pastebin üzerinden verdiğim kodlara gerekli açıklama satırlarını ekledim ancak sorularınız olursa bana sosyal medya kanalıyla ulaşabilirsiniz.

twitter.com/aokocax ,friendfeed.com/aokocax