Author Archives: TrayhopeR

Ninni

6 ay geçmiş. Bir post daha atayım. “bkz. herkes postasını atsın da sigaramızı yakalım.”

Son yazılarıma baktım da neredeyse hepsi uzun aralardan sonra yazılmış yazılar. Bunun nedenini düşündüğümde ise artık eskisi kadar yazmak istemediğimi fark ettim. Eskiden bir content üretmek bana olumlu şeyler katardı. Sanırım artık bu içeriklerden bana dönen şeylerden pek de memnun değilim. Bilmiyorum kafalar karışık.

Yine yaz geldi falan derken yağmurlar başlıyor. Havanın da kafası karışık ve günler geçtikçe her şey daha da karmaşıklaşıyor. Bu duruma büyüdükçe hayatın getirdiği saçma salak şeyler mi sebep oluyor yoksa sıcağım diyip yağdıran hava mı sebep bilmiyorum. Öğrenmek de istemiyorum çünkü benim düzeltebileceğim bir şey gibi görünmüyor.

Neyse güzel darladığıma göre sizi artık anlamlı şeyler yazabilirim. Amerika macerası ile ilgili bi yazı yazmıştım. Uzunca bir yazı olacağından bölümlere ayırmak istedim ama bu yukarıda bahsettiğim içerik üretmemecilik yüzünden onun da devamı gelmedi. Bir aralar Windows Phone dersleri serisine başlayıp ara verdiğim gibi. Ama onda benim pek de suçum yok yani adamlar desteği kesti ne yapalım…

Bayram dolayısıyla Istanbul boş. Ama Ümraniye değil. Sanki diğer ilçelerden de Ümraniye’ye gelmişler gibi bir durum var. Çok kötü çoook. En yakın zamanda bu salak yerden uzaklaşmam lazım. Kafamın uyuşmadığı, haklarıma ve özgürlüğüme saygısızca hakaret eden, kafalarını kaldırıp günyüzünü göremeyecek kadar önlerindeki anlamadıkları arapça kitaba yumulan insanlar artık psikolojimi bozmaya başladı. Büyük çerçeveye bakarsak zaten benim gibi bir adamın akıl sağlığını koruyabilmesi için Türkiye’den uzaklaşması gerekiyor. O da olacak elbet. Her gün cinayet, vahşet, savaş, adam kayırma ve adaletsizlik. Taş olsa çatlar be bilader.

Yazasım geldi yazdım. Gerçekten çok sıkıldım.

0
Shares

[UWP] Async Storyboard çağırmak.

Windows uygulamaları geliştirirken sayfadaki elementler üzerinde animasyon kullanmak istiyorsak Storyboardları kullanıyoruz. Genellikle geliştiriciler bu animasyonları hazırlamak için Blend kullanırlar. (Düzenlemek istediğiniz elementin bulunduğu sayfanın üzerine Solution Explorer’dan sağ tıklayarak ‘Design in Blend’ seçeneğine basarak erişebilirsiniz.)

Animasyonu oluşturup Storyboardumuzu XAML tarafında tanımladıktan sonra kod tarafında bu animasyonu belirlenen obje üzerinde oynatmak için Begin methodunu kullanıyoruz. Begin methodu senkron çalışan bir method ve Storyboard sınıfının içerisinde bu methodu asenkron hale getirecek başka bir oynatmak methodu bulunmuyor. Fakat Completed eventini ve TaskCompletionSource sınıfını kullanarak bütün Storyboardları asenkron çalıştıran bir extension method yazabiliriz.

sampleAnimation isimli bir Storyboard düşünelim. Bu animasyon başlamadan önce ekrana animasyonun çıkan diyalog kapatıldıktan sonra başlayacağını belirten bir mesaj verdirtelim. Daha sonra animasyonu oynatalım ve animasyonun bittiğine dair bir mesaj daha verdirelim.

private async void MainPage_Loaded(object sender, RoutedEventArgs e)
{
    await (new MessageDialog("Animasyon bu diyalog kapatıldığında başlayacak.").ShowAsync());
    sampleAnimation.Begin();
    await (new MessageDialog("Animasyon bitti!").ShowAsync());
}

Peki ya bu animasyon bitmeden kodun devamına geçmesini istemiyorsak? Şu anki haliyle ilk diyalogu kapattığımız gibi animasyon başlayacak fakat Begin methodu senkron çalıştığı için kod çalıştırması devam edecek ve animasyonun bittiğini belirten ikinci bir diyalog gelecek. Animasyon 3,5 milisaniyede bitmiyorsa bu durumda çok yanlış yapıyoruz demektir 🙂 İşte o zaman bu oynatma methodunun asenkron haline ihtiyacımız oluyor. Aşağıdaki şekilde bir StoryboardHelper içerisinde BeginAsync extension methodunu yazarak bu işten kurtulabiliriz.

public static class StoryboardHelper
{
    public static Task BeginAsync(this Storyboard storyboard)
    {
        var completionSource = new TaskCompletionSource<object>();

        storyboard.Completed += (c, r) =>
        {
            completionSource.SetResult(null);
        };

        storyboard.Begin();

        return completionSource.Task;
    }
}

Daha sonra animasyonu oynattığımız yeri de aşağıdaki gibi düzenlersek amacımıza ulaşmış oluyoruz.

private async void MainPage_Loaded(object sender, RoutedEventArgs e)
{
    await (new MessageDialog("Animasyon bu diyalog kapatıldığında başlayacak.").ShowAsync());
    await sampleAnimation.BeginAsync();
    await (new MessageDialog("Animasyon bitti!").ShowAsync());
}

Asenkron Storyboard kullanımına ihtiyacınız varsa TaskCompletionSource kullanımına ait de çok güzel bir örnek olan yukarıdaki BeginAsync methodunu kullanabilirsiniz.

0
Shares

UWP için MVVM destekli Modal Dialog Helper.

UWP uygulamaları geliştirirken çok sorunla karşılaştığım ve uzunca bir süredir canımı sıkan bir konu var. ContentDialog. Oldukça hoş bir görüntüsü olduğunu söyleyebilirim. Kullanıcıdan cevap almak için birebir. FAKAT AŞIRI SINIRLI!

Evet çok sınırlı bir kontrol. Sınırlı kontrolden kastım özelleştirmesi oldukça zahmetli ve hatta bazı şeyleri yapabilmek için imkansız bir kontrol. Ben dahil bir çok geliştiricinin tam ekran kaplayan bir ContentDialog tasarlarken kafayı yediğini öngörebiliyorum. Hayır bahsettiğim FullSizeDesired değil…

Microsoft’un bu konudaki tutuculuğunu anlayabiliyorum. Bir amaç uğruna tasarlanmış bir kontrolün amacı dışında kullanılmasını engellemek oldukça mantıklı bir davranış. Bir modal dialog olarak ContentDialog altyapısını kullanmak ilk başta oldukça mantıklı gelse de biraz haşır neşir olunduktan sonra imkansız olduğunu anlayabiliyoruz. WinRT zamanlarında kullandığımız modal dialog açmamıza yarayan helper classların çoğunun yeni UWP altyapısında çalışmadığını görmek beni ilk başta üzmüş olsa da kendiminkini yazmak için cesaretlendirdi.

Tıpkı bir ContentDialog gibi çalışan, kolayca özelleştirilebilir ve MVVM altyapısına uygun bir ModalDialogHelper sınıfı hazırladım. Bu generic sınıfın özelliği parametre olarak verdiğiniz herhangi bir Control objesini ContentDialog gibi bir container elementinin içine basması ve async bir şekilde kapatılmasını beklemesi. Eğer ViewModel tarafından aktarmak istediğiniz bir sonuç varsa bu bekleme işlemi sırasında onu da yakalayabilmenize imkan sağlıyor. Yani:

var result = await (new ModalDialogHelper<bool>()).ShowDialogAsync(typeof(TestUserControl),new TestUserControlViewModel());

tarzındaki bir kullanım DataContext’i TestUserControlViewModel olan bir TestUserControl kontrolünü ekrana basıp ViewModel içerisinden diyaloğu kapatmak istediğiniz bir methoddaki cevabı bekler.

Kendi amacım için olan kısmında bu datacontext mevzusu tamamen yoktu çünkü projemde Unity container olduğu için viewmodel bağlantıları otomatik olarak oluşturuluyordu. Fakat paylaşmak adına bu şekilde bir kullanım da ekledim.

Diyaloğu ViewModel içerisinden kapatmak için :

DialogDismissRequested.Invoke(null, null);

DialogDismissRequested eventini çağırmanız yeterli. Bu eventin ikinci parametresi T generic alıyor ve geriye döndürmek istediğiniz cevabın türünden olmak zorunda. Yukarıdaki örnekte ModalDialogHelper<bool> kullanimindaki bool aslında döndürmek istediğim tür olduğu için bu şekilde örnekledim.

Yukarıda yazıya başlarken bir containerdan bahsetmiştim. Unity olmayan ModalDialogContainer. Bu container da aslında bir Control ve kendine ait bir ContentTemplate içeren bir XAML resource’u içeriyor :

<Style TargetType="local:ModalDialogContainer">
            <Setter Property="Template">
                <Setter.Value>
                    <ControlTemplate TargetType="local:ModalDialogContainer">
                        <Grid>
                            <Grid Background="Black" Opacity="0.8"/>
                            <ContentPresenter x:Name="ContentPresenter" Margin="16">
                                <ContentPresenter.Transitions>
                                    <TransitionCollection>
                                        <EntranceThemeTransition />
                                    </TransitionCollection>
                                </ContentPresenter.Transitions>
                            </ContentPresenter>
                        </Grid>
                    </ControlTemplate>
                </Setter.Value>
            </Setter>
        </Style>

Ben ContentDialog görünümü verebilmek için arkaya %80 opacity kullandım. Aşağıdaki resimde gördüğünüz kontrol TestUserControl ve yukarıdaki satırları kullanarak ekrana bastığınız Modal şu şekilde görülüyor :

testusercontrolpreview

Arkaplanda beyazdan kırmızıya giden bir grandient Grid mevcut.

ModalDialogHelper’ın işi UI ile olduğu için sanırım yapılan bütün çağrıların UI Thread üzerinden yapılması gerektiğinden bahsetmeme gerek yok 🙂

Bu helper özelleştirilebilir. Normal ContentDialogda aşina olduğumuz geri tuşuna basıldığında diyaloğu kapatma gibi özellikler eklenebilir. Fakat şimdilik başlangıç için yeterli diye düşünüyorum.

ModalDialogHelper’ı kullanırken hatırlamanız gereken şeyler :

  • ViewModel her zaman IModalDialog interface’inden türemeli.
  • ShowDialogAsync methodu her zaman UI thread üzerinden çağırılmalı.
  • ViewModel içerisinde açılışta bir yükleme yapmak istiyorsanız OnInitializedAsync Task’ını kullanabilirsiniz.
  • Diyaloğu kapatmak veya beklediğiniz yanıtı göndermek için ViewModel içerisinden DialogDismissRequested eventini kullanabilirsiniz.

Helper’a ve örnek projeye buraya tıklayarak ulaşabileceğiniz GitHub reposu üzerinden ulaşabilirsiniz.

Cheers.

0
Shares

Okunabilir XAML Yazmak

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

Bahsettiğimiz konu kod yazmaya gelince bütün geliştiricilerin kendi standartları olabilir. Fakat yazdığımız kod ne olursa olsun biz bırakıp gittiğimizde kodumuzu okuyacak bir diğer insan bunu işkence görmeden başarabilmeli 🙂

Hangi dilde yazıyor olursak olalım eğer bir tasarım dili yazıyorsak visualization (görselleştirme) her zaman daha zor olacaktır. Çünkü yazdığımız şey aslında hayali bir çerçeve içerisinde hayali şeylerin nasıl görüneceğini belirlemek. Yazdığımız kodların bu hayali çerçeve içerisinde nasıl görüneceğini zaman içerisinde biz de kestirebiliyoruz. Fakat bu büyük bir uğraş ve zaman gerektiriyor. Yeni XAML yazmaya başlamış birinin Designer kullanmadan tasarım yapması beklenemez. Gün geçtikçe Designerdan uzaklaşıp XAML’ı kod tarafında yazmak hem geliştiricinin yazdığı kodu görselleştirmesinde hem de daha hızlı geliştirme yapmasına yardımcı olacaktır.

Daha önce de söylediğim gibi bütün geliştiricilerin kendilerine has standartları olabilir. En basitinden Camel & Pascal Case diye ayırdığımız naming conventionları örnek verebiliriz. Peki iş tamamen görsele dayalı bir dil olduğunda okunabilirliği nasıl sağlayabiliriz?

Bu yazıda kendi günlük geliştirmelerimde yaptığım XAML sayfalarında dikkat etmeye çalıştığım ve kod okunabilirliğini arttırmaya yardımcı olacak maddeleri sıraladım. Bunlar benim standartlarım olduğu için herhangi bir geçerliliği elbet yok. Fakat yazının amacı eğer okunabilirliği arttırmaksa aşağıdaki maddeler hem size hem de sizden sonraki geliştiricilere hayatı büyük bir oranda kolaylaştıracağından eminim.

Ortak özelliklere sahip elementler için Style kullanın.

Copy – paste programming günümüzde bu kadar yaygınlaşmışken sayfa veya proje içerisinde aynı özelliklere sahip elementler için kullanmanız gereken Style kodlarının da bu kadar az olması haliyle kaçınılmaz. Çoğu geliştirici için bir tane elementi tam haliyle yazıp onu kopyalayıp yapıştırarak çoğaltmak, bu elementlerin kullanabileceği ortak bir Style kodu yazmakdan daha kolay geliyor. Şimdi bunu yapmanın işinizi ne kadar kolaylaştırdığı tartışılabilir. Fakat kopyala – yapıştır yaparak çoğalttığınız elementlerin büyük çaplı projelerde başınıza dert olacağı bir kaçınılmazdır.

Style kodları kullanmak yönetmesi kolay bir tasarım kodu oluşturmaya yardımcı olur. Ayrıca her maddede olduğu gibi kod anlaşılabilirliğini had safhada tutmanızı sağlar. Resimlerle örneklemek gerekirse:

Birbirlerinden bağımsız fakat aynı özelliklere sahip TextBlocklar.

Birbirlerinden bağımsız fakat aynı özelliklere sahip TextBlocklar.

Page Resource içerisine tanımlanmış bir Style koduyla tanımlanmış TextBlocklar.

Page Resource içerisine tanımlanmış bir Style koduyla tanımlanmış TextBlocklar.

 

 

Birbirine benzer fakat çok az propertyler ile birbirinden ayrılan stil parçaları için BasedOn kullanarak ana stilden farklı stil parçaları oluşturabilirsiniz.

Sayfa içerisindeki bütün TextBlocklar aynı stile sahip olacaksa bir x:Key tanımlaması yapmanıza gerek yok. Ayrıca her zaman olduğu gibi gerektiği yerlerde comment tagleri içerisine açıklama yazmayı öncelik sıranıza almayı unutmayın.

UI Elementleri yazarken belirlediğiniz kurallara uyun.

Şimdi bu da aslında yazıda yazdığım bütün maddeler gibi size kalmış bir şey. Fakat code-readability (kod okunabilirliği) açısından en önemli unsurlardan biri. Geliştirdiğiniz projelerin her aşamasında olduğu gibi yazdığınız kodun başkası tarafından rahatça okunabilinip anlaşılabiliyor olması beklenir. İş tasarım dili olunca da backend kodu gibi şöyle bir göz gezdirilip devam edilemeyebiliyor çoğu zaman. Çünkü bir componentin tanımlanmış 10’dan fazla propertysi olabilir. Bunların hepsini bir XAML koduna bakıp akılda tutmak ya da yeri geldiğinde dönüp bulmak vakit kaybına yol açabilir. İşte bu tarz ufak gibi görünen ama aslında geliştirme zamanınızı çok daha hızlandırabilecek küçük unsurları düzeltmek için şunları yapabilirsiniz:

Inline yerine Newline kullanın

Aşağıya iki farklı resim ile çok propertyli bir UI element kodu ekliyorum, sanırım bahsettiğim şeyi anlayacaksınız.

Inline

Inline

Newline

Newline

 

 

 

 

 

 

Sonuç olarak iki resimdeki kod da aynı işi yapıyor ve aynı elementi ekrana basıyor. Fakat alt resimeki koda baktığımızda okunabilirlik diğerine göre daha çok daha fazla.

Kendi rulesetinizi oluşturun

Şimdi Ruleset dediğimiz olay aslında kod kalitesini arttırmak ve kod okunabilirliğini yüksek seviyelerde tutmak için geliştirilmiş bir dosyadan başka bir şey değil. Visual Studio içerisinde belirli rulelara (kurallara) göre kod yazmak da aslında bu bahsettiğim iki unsuru destekleyen bir unsur. Daha detaylı bilgi için şu MSDN sayfasını inceleyebilirsiniz.

Benim bahsettiğim ruleset ise tamamen sizin kendi kod standartınıza uygun bir hayali ruleset. Emin olmamakla beraber bildiğim kadarıyla şu an Rule dosyaları XAML içerisinde kullanılamıyor. Bu durumda da bize düşen kendi hayali rulesetimizi oluşturup kodu ona göre yazmak. Nasıl mı?

Örneğin XAML dosyası içerisine tanımladığımız her bir componente erişmek için bir x:Name tanımlar ve onu kullanırız. Ben şahsen bunu her zaman componentin ilk propertysi olarak hemen altına tanımlamaya özen gösteririm. Bu gerekli bir şey değil, isterseniz ortalarda bir yere ya da en görünmeyen yere yazın hiç fark etmez, sonuçta compilerdan geçtiğinde pek bir önemi kalmıyor, değil mi? 🙂 Değil abi. Özellikle designer çok exceptional caseler dışında designer kullanmayan biri olarak bu benim için önemli. Benim için aslında uymaya çalıştığım ruleset öncelik sırasına göre şöyle:

  1. x:Name her zaman en başta olmalı ki ben neyle uğraştığımı anlamak için gözümü ordan oraya çevirmeyeyim.
  2. Eğer kontrol bir Grid içerisinde ise attached propertyleri olan Row ve Column propertyleri her zaman ikinci sırada, x:Name’den sonra gelir. Bunun nedeni de Grid yapısını kullanırken elementin tam olarak nerede render edileceğini kafamda daha rahat canlandırabilmem aslında.
  3. Width ve Height propertyleri olabildiği en üst sıralara yazılır. Bunun sebebi de yine Row ve Column ile aynı aslında. Tamamen yazılan tasarım kodunu kafamda rahat canlandırabilmek.
  4. Bunlardan sonra gelen propertyler öncelik sırasına göre yazılır.

Bunlar benim uymaya çalıştığım kurallar. Siz de yukarıdakiler gibi kendi kurallarınızı oluşturup bunları projenin uygun bir yerine açıklayıcı bir şekilde yazabilirsiniz. Böylece bir dahaki sefere neyi nerde bulabileceğinizi daha kolay bir şekilde halledebilirsiniz. Aşağıda yine kıyaslama adına iki farklı resim paylaşıyorum.

Yapılması gereken.

Yapılması gereken.

Koşarak uzaklaşılması gereken.

Koşarak uzaklaşılması gereken.

 

 

 

 

 

 

 

Yukarıdaki Grid içerisinde Row setter indexi 0 olan Textblock için atama yapılması tercih sebebidir.

Bütün Resourceları tek bir yere yazmayın.

Hepimizin nimetlerini sonuna kadar kullandığı bir dosya var. App.xaml 🙂 İş resource yönetimine gelince çoğu zaman her şeyi en kolay yöntem olan App.xaml üzerine yüklüyoruz. Bu da geniş çaplı projelerde gereksiz resourceların tek bir dosyada toplanmasını beraberinde getiriyor. Bu durum her ne kadar günümüz bilgisayarlarının halledemeyeceği kadar yoğun bir iş yükü oluşturmuyor olsa da amacımız her şeyi nizami bir şekilde geliştirmek. Peki nedir bunun yolu / yordamı?

ResourceDictionary kullanın

ResourceDictionary ile farklı amaçlar için saklamak istediğiniz farklı türdeki resourceları (örneğin Converter’lar, DataTemplate’ler, Style’lar) farklı xaml dosyaları içerisine yazarak tek bir yerde toplayabilirsiniz.

Ayrıştırılmış Resource dosyaları.

Ayrıştırılmış Resource dosyaları.

 

 

 

 

 

Tek bir dosya için kullanacağınız resourceları ortak alanlara yazmaktan kaçının

Yalnızca tek bir sayfa için kullanacağınız bir DataTemplate’i App.xaml veya farklı bir Resource xaml’ı içerisinde yazmanın hiç bir anlamı yok. Eğer yazdığınız bu template yalnızca o sayfa içerisinde kullanılacaksa Page.Resources altına yazabilirsiniz. Bu ayrıca IntelliSense’in gerektiği durumlarda kod bölüğünü bulmasını da hızlandıracaktır.

Yüksek Margin ve Padding değerleri kullanmayın.

WinRT, UWP, WPF vs. konusunda yeni yeni geliştirme yapmaya başlamış bir geliştiricinin en çok düştüğü hatalardan biri Designer üzerinden ekrana sürükleyip bıraktığı kontrolün, uygulamanın çalıştığı ekran çözünürlüğü ne olursa olsun hep aynı yerde gözükeceğidir. Bu tabiki de yanlıştır, çünkü siz drag & drop yöntemiyle ekranın herhangi bir yerine bir element sürüklediğiniz zaman Designer bu elemente sizin koyduğunuz yere uygun olması için gerekli Margin değerlerini otomatik olarak atar. Görünürde bir saçmalık yoktur, çünkü zaten XAML Designer bunu sizin görmek istediğiniz şekilde ayarladı bile. Sorun bu uygulamayı farklı çözünürlüklerde çalıştırdığınız zaman ortaya çıkar.

Margin ve Padding propertyleri için okunabilirliği ele almamız yine bize visualization (canlandırma) konusunda yardımcı olabilir. Küçük değerlerle çalışmak hem bu canlandırmayı kolaylaştırdığı gibi hem de farklı çözünürlüklerde uçuk kaçık elementler görmemizi engeller. Yani aslında küçük değerlerle çalışıp istediğimiz ekran görüntüsünü yakalayabilmek bizim veya çalışma arkadaşlarımızın işini okunabilirlik konusunda kolaylaştırdığı gibi farklı ekran çözünürlüklerinde test ettiğimiz elementlerin çok farklı yerlerde konumlanmasını engeller.

 

0
Shares

UWPToolkit Yayınlandı!

UWPToolkit Nedir?

Evet yukarıda alıntı yaptığım tweetten de anlaşılacağı gibi 18 Ağustos tarihinde UWP Toolkit adı altında Windows 10 geliştiricilerinin işini kolaylaştıracak bir sürü user control, converer, service provider vs. barından bir toolkit yayınlandı. Bunu daha önce Windows Phone için yayınlanan WPToolkit’in UWP hali diyebiliriz. UWP olduğu için Windows 10 içeren bütün cihazlarda bu toolkiti kullanabiliriz demek oluyor bu elbette! Toolkitin içerisinde neler var şöyle bir göz atalım:

UWPToolkit'in GitHub sayfasından...

İçinde Neler Var?

Aslında yukarıdaki resimde tam olarak içerisinde neler olduğu anlatılmış. Fakat ben biraz da Githubdaki projeden bahsetmek istiyorum. Github’da projenin bütün source code’uyla beraber bir de sample app yani örnek proje yayınlanmış. Projeye ait bütün componentlerin detaylı bir şekilde kullanıldığı bu örnek uygulamayı Windows 10 cihazınıza yükleyerek projenin bütün içeriğini test edebilirsiniz.

Bilmeniz Gerekenler

  • UWP Toolkit minimum version olarak SDK 10586 gerektiriyor. Eğer projeniz 10586 öncesini hedef göstererek oluşturulmuşsa bu toolkiti malesef kullanamıyorsunuz. Çünkü içerisinde Composition API’dan estanteneler bulunduruyor ki bu API’da zaten minimum olarak bu sürümü destekliyor. Proje içerisindeki animasyonlar eğer destekleniyorsa Composition API aracılığı ile yapılıyor. Örneğin Blur efektini normalde XAML aracılığı ile veremezsiniz. (Araya DirectX falan sokmak gerekiyo, hiç araştırmayın :P)
  • Bir alt başlıkta da değindiğim gibi proje açık kaynak kodlu olarak Github üzerinden geliştirilmeye devam ediyor.
  • Visual Studio 2015 Update 3 kurmadan geliştirme yapamazsınız. Gereksinimler için buraya tıklayarak Getting Started sayfasını ziyaret edebilirsiniz.

Açık Kaynak

Yayınlandığı günden itibaren buraya tıklayarak ulaşabileceğiniz Github profili üzerinden açık kaynak olarak yayınlanan bu toolkit için henüz yayınlanmasının üzerinden 5 gün geçmesine rağmen bir çok pull request geldi bile… Hatta ben de birkaç tane gönderdim. 🙂 Eğer siz de projenin gelişmesine katkı sağlamak istiyorsanız Github sayfası üzerinden Issue’lar kapatabilir, eksik gördüğünüz yerleri tartışıp ortak karar alındığında pull request göndererek geliştirebilir ya da kendi projelerinizde kullanarak eksiklikleri dile getirebilirsiniz.

 

0
Shares

“Burak Amerika’ya gitmişsin hiç söylemiyosun bro ?” – 1

Ya ben size söylemeyi unuttum ama ben Build 2016’ya gittim ta Amerigalara ya. Cidden oldu yani öyle bişey. Her seferinde desteğinden bahsettiğim Microsoft’un güzel bir jestiyle MSP’ler arasından beni seçip Build 2016’ya gönderdiler. Şaka gibi, hehe. Hadi biraz ondan bahsedeyim:

Efenim 13,14 Mart gibi bir tarihte Microsoft Türkiye’den sevindirici bir telefon aldım. Beni 30 Mart – 2 Nisan tarihleri arasında San Francisco’da yapılacak olan ve Microsoft’un her sene düzenleyip yeni teknolojilerini & ürünlerini tanıttığı ve katılımcılara deneme fırsatı verdiği bir etkinlik olan Build’a göndermeyi düşündüklerini söylediler. Önce sakince telefonu yere koyup bi ajandama baktım (:P) Sonra bu bir hata diyerekten telefonu kaptım ve “Oluuur” dedim. Ardından bir pasaport macerası başladı…

2 hafta gibi bir sürede hem pasaportumu yenilemem hem de Amerika vizesi için başvuru yapıp onay almam gerekiyordu. Vize başvurusu yapabilmem için pasaport numaramı DS 160 formuna yazıp göndermem lazımmış. O yüzden randevuyu erken tarihe alamadım. Bir an önce pasaportumu yenilemem gerekiyordu…

Yeni yeni gelişmekte olan bu e-pasaport sistemini biraz araştırdım. Istanbul’daki bütün ilçe emniyetlerdeki pasaport şubelerindeki randevular çok geç tarihe veriyordu. Ben de işimi Yalova’da halletmeye karar verdim. Sabahın köründe IDO ile Yalova’ya gidip pasaport işlemlerimi yaptım. Pazaresi günü yapmıştım, Cuma pasaport elimdeydi. Asıl sıkıntılı kısım şimdi başlıyordu: AMERIKA VIZESI!

Pasaport numaram artık olduğuna göre kısa Amerika vizesine başvurmam ve onay almam gerekiyordu. 28 Mart günü sabah 6 gibi uçağım var ve benim randevu ve onay almama sadece 10 gün kalmıştı 🙂 Istanbul’daki Amerikan Konsolosluğuna randevu almak istediğimde en yakın tarih 29’unu gösteriyordu, o nedenle Ankara konsolosluğunu denemek istedim. Ordaki tarih de 27’sini gösteriyordu. Bir mutsuzluk, bir çaresizlik ki aldı başını gidiyor o saatler…

Biraz araştırdım, yaklaşık bi 10 dakika vakit öldürdüm internette. Sonra dedim ki arkadaş başka çare yok, mission abort. Iptal yane gidemiyoruz… Sayfayı bi refresh ettim ki bir de ne göreyim, Ankara için biri sanırım iptal etmiş en yakın randevu tarihi 25 Mart! Onay alıp vizenin gelmesi falan çok kısa bir süreye tekabül edecek ama denemeye değerdi. Bu sırada bir yandan da Microsoft ile görüşmeleri sürdürüyor, “Gelicem, relax, her şey under control, sıkıntı yook” falan diyorum tabi…

Neyse efenim 24 Martı 25’e bağlayan gece Ankara’ya uçtum. Sabah konsoloslukta işlerimi hallettim. Onayı aldım. Her şey mikemmel ilerliyor derkeen pasaportumu alıp geri göndermeleri gerektiğini fark ettim. Konsolosluktaki mülakatı geçerseniz ve onay alırsanız pasaportunuzu alıp vize işlemleri için sıraya koyuyorlar. Ardından belirttiğiniz adrese postalıyorlar. O postanın gelmesi gerekiyordu ben uçana kadar…

Konsolosluğa girdiğiniz zaman size mülakatı Ingilizce mi yoksa Türkiye mi yapmak istersiniz diye soruyorlar. Ben farketmez dediğim için bana Ingilizce fiş verdiler. Şimdi orası öyle bi ortam ki insan ister istemez geriliyor. Ben Ingilizceme güveniyorum ama etrafta ‘Ben yüksek ıııh, I study master in bla bla önivörsiti’ diye konuşanları gördükçe insan geriliyor tabi haliyle. Pamuk ipliğine bağlı zaten her şey… Neyse. Yaptık tontiş bi abiyle mülakatımızı. Ayaküstü bi sohbet, bi mappet, sorma… Gülüştük, geçiştik, konuşma biterken onayı verdi dayı sağolsun. Onayı alınca dedim battı balık yan gider: “Benim 28’inde uçmam gerekiyor, ne yapman gerekiyorsa yap dayı da şu pasaport bana erken gelsin ya” diye bi acındırdım kendimi. O da “Sıkıntı olmaz kardeşim merak etme” dedi, Ingilizce ama… 😛

25’inde pasaportu verdim, 27’sinde telefonuma PTT’den bir SMS geldi ve dedi ki ” Al bu kafayı sepete ekle binbir türlü..” Yok öyle demedi. Dedi ki beyefendi postanız geldi, gidin alın şubeden. Sabahın köründe koşarak gittiğim şubeden Amerikan vizeli pasaportumu teslim aldım. Artık her şey hazırdı, sonunda 🙂

28’inin sabahı Frankfurt aktarmalı olarak San Francisco’ta gidiyordum. Sabahın köründe bindik uçağımıza paşalar gibi Frankfurt’a indik. 2 saat bekleme süresi vardı. Biraz Frankfurt Airport’ta takıldıktan sonra asıl baba uçağa binme vakti geldi. İki katlı böyle değişik bi makine koymuşlar, binin dediler bindik. Bir uçuş ki sorma. Tam 12 saat uçtum neredeyse. Dilekolay. 12 saat yav!

Iyi ki yanımdaki 2 koltuk boştu şansıma, sülalem raad bi şekilde takıldım koltuklarda 😛 Ikramlar başlayınca da bira ve şarabın dibine vurdum ayıptır söylemesi 🙂 Bütün bu macera zaten efsane bir deneyim fakat çok büyük bir makinanın içerisinde ve yerden kilometrelerce yükseklikte okyanusun üzerinden geçip camdan dışarıyı izlemek oldukça keyif vericiydi benim için. Normalde pek umrumda olmaz, “Aaa bu da başka bi dağ işte” diyip geçerdim. Bu sefer öyle olmadı.

Uçakta U.S sınırından geçerken vermeniz gereken “ben sizin ülkenize şu ürünleri sokuyorum, şu kadar litre & kiloda sokuyorum, hayır son 10 yılda adını bilmediğim bu 10. dünya ülkesine girip çıkmadım zart zurt” olarak doldurmanız gereken bir form veriyorlar size. Verdiler, doldurdum. Ama salak ben o formu kurşun kalemle doldurdum 🙂 Evet, salak.

Uçak sonunda indi. Indi ama ben saatlerdir uçarken saatin sadece 3,4 saat oynaması (bkz. nam-ı diğer jetlag) haliyle bünye tarafından pek hoş karşılanmadı. Sınırdan geçmek için sıraya girdim. Yaklaşık 1.5 saat sırada bekledim ve sıra bana geldiğinde vezneye doğru ilerledim. Cool bi dayı benden o border formunu istedi, uzattım. “Ama sen bunu kurşunla doldurmuşsun, git tükenmezle doldur geri gel” demez mi… Bakın 1.5 saat yorgun argın ayakta beklemişken konuştuğunuz ve sizi sınırdan geçirebilecek tek insanın böyle bir şey demesi insana koyar. Koydu da. Ekşimiş ve üzülmüş (yalancıktan) bir surat ifadesiyle “Ama ben sıranın en başına dönemem, çok bekledim memedali bey nolur yardımcı olun” dedim. Cool dayı da küçük bi masa gösterdi ve “Orda tükenmez kalem ve yeni form var. Git ordan doldur ve senden sonraki kişi gittiğinde tekrar gel” dedi. Ay bir sevinç, bir mutluluk…

Gittim aldım yeni bir form doldurdum ve cool dayıya verdim. Cool dayı da coolluğunu konuşturarak beni sınırdan geçirdi. Artık resmi olaraktan Amerika’daydım. San Francisco International Airport (SFO) da yorgun argın B.A.R.T diye bir şeyden haberim oldu. Otele gitmek için şehir merkezine gitmem gerekiyordu. Bunu mesela daha Amerikan-vari söylemek gerekirse “Otele gitmem için biraz kuzeye doğru yol almam gerekiyordu” diyebilirim 😛 Yok lan şaka şaka, öyle bişey yok. Daha o kadar Amerikan olmadım.

Bay Area Rapid Transit (kısacası BART) dedikleri bir metro sistemi var. Bazen yeraltından bazense yerüstünden yol alarak şehrin büyük bir kısmını dolaşıyor bu sistem. Zaten  Amerika ile ilgili biraz araştırma yaptıysanız şehiriçi ulaşımın arabanız olmadan çok zor olduğunu biliyorsunuzdur. Gerçekten de öyle, araba şart abi.

Bu metroya binip bir şekilde otelime yakın durakta indim. Internetim yok. Haritayı da indirmediğim için kullanamıyorum. Insanlara sora sora oteli buldum, yerleştim, uyuyakaldım….

Etkinlikten 1 gün önce saat 16:00 civarı oteldeydim. Yarın sabah Build 2016 başlayacaktı ve şu an hepimizin bildiği ama benim gittiğim zamanlarda kimsenin tahmin bile edemeyeceği yeniliklerden bahsedilecekti.

Ah be yine olsa da yine gitsek… Şimdi öncelikle bu macera çok büyük olduğu için parça parça paylaşmaya karar verdiğimi size üzülerek (!) söylemek istiyorum. Bütün maceramı GoPro ve telefonumun kamerasına kaydettim. Videoları birleştirip tam bir video yapma hayalım var (hala) ama video editing falan pek işim olmadığı için hiçbir zaman uğraşmadım. Artık son! 😛

Yakında tekrar görüşürüz.

 

0
Shares

YeZeFe – aR25

Başlığı neden böyle apaçi sıtayla yazdım ben de bilmiyorum.Neyse.

Yaklaşık 3 gün önce benimle beraber binlerce kilometre boyunca Istanbul trafiğini göğüslemiş Yamaha YBR 125’ime veda ettim. Son zamanlarda aramız pek iyi değildi. Kış dolayısıyla fazla konuşup görüşemiyorduk. Bir şeyler artık eskisi gibi tat vermiyordu. O da farkındaydı bunun da belli etmiyordu sanırım. Artık başka motosikletler gözüme daha güzel görünmeye başlamıştı ve bundan ona bahsetmeliydim. Bu ilişkide hatalarımı hep alttan alan o olmuştu, onun hakkını hiçbir zaman ödeyemeyeceğim sanırım. Herşeye rağmen Ağustos ayından Şubat ayına kadar seviyeli bir ilişkimiz oldu kendisiyle. Geçen hafta da çalışmıyorken motor bloğunun kalbine aşağıdaki veda mektubumu bıraktım …

YBR … Nerden başlasam bilemiyorum. İlk başlarda her şey ne de güzeldi. Çok iyi hatırlıyorum, seni ilk gördüğüm anda “İşte başlamam gereken motosiklet bu !” demiştim. Haklıymışım. Sen tam bir başlangıç motosikletisin. Sana ‘motor’ dendiğinde ne kadar kızdığını biliyorum, o nedenle kaçınıyorum o ahlaksız kelimeden… Sen yeni başlayan bir motosikletçinin sahip olmak istediği herşeye sahipsin: Motor bloğu, sele, gidon ve o elciklerin…

Yazın her şey ne kadar da güzeldi seninle. Koskoca Istanbul trafiğini beraber alaşağı etmiştik. Hala da ediyoruz ya, neyse…

Beraber çok güzel yatışlarımız oldu seninle. Hep yollarda yattık belki pek konforlu değildi ama, olsun. Seni daha iyi asfaltlarda yatırmak isterdim, olmadı.

Artık bilmeni istiyorum ki bazı şeylerin aramızda yürümediğinin ben de farkındayım. Belki sen teknik olarak hiç değişmedin, ama ben değiştim YBR. Benim için daha yüksek bir motosiklet sürmenin vakti geldi artık. Şu “Sen daha tecrübesiz sürücülere layıksın” klişesi vardır ya, malesef öyle. Ben artık seni haketmiyorum YBR.

Grenajların çiziksiz, ciğerin hep sağlam kalsın YBR, hoşçakal …

Başta biraz laga luga etti, bakımı gelmiş numarası yaptı ama yemezler 😛 (Kaşla göz arasında motosiklete şiir yazdım ya la …)

Sözün özüne gelecek olursak artık hayatımda yeni bir motosiklet var.

r25bk_004

(Yamaha YZF – R25)

Yukarıdaki bebek 250cc ve gerçekten tam bir ca – na – var. YBR’den sonra böyle bir motora binince eşekten inip ata değil resmen unicorna falan binmiş oluyorsunuz. Motora alışma sürecim hala devam ediyor, fakat şu 3 günde oldukça ilerlettim kendimi. Artık şehiriçi her virajda dizimle kafamı yere değdirebiliyorum. (yersen)

Hep inceleme videolarında bahsedilidiği üzere alet 5,6 bin devirden sonra çıldırıyor ve toplam 14bin devir çeviriyor. Yani siz coştuğunu zannederken devir göstergesinde aslında bi 7bin devir daha sizi bekliyor. Rodajda olduğu için makina tabiki daha 7’binin üstünü nadiren görüyorum henüz, fakat bitmesine 300km falan kaldı 🙂 (hihihihihi)

Teknik özellikleriyle sizi bu yazıda boğmak istemiyorum, zaten favori arama motorunuza R25 yazdığınızda bütün specler önünüze dökülecektir. Ben bu yazıda aslında o speclerden çıkartılamayacak tecrübeleri sizlere aktarmak istiyorum.

Nasıl yaptılar bilmiyorum, fakat söylemem gerekiyor ki Yamaha mühendisleri resmen imkansızı başarmış olabilirler. Motor kaçıncı viteste ya da kaç bin devirde olduğunuza bakmaksızın her zaman harika bir ivmelenme veriyor. Kısacası motor hiçbir zaman boğulmuyor diyebilirim. Siz hissetmiyorsunuz, 4. viteste 10 ile giderken gazı açtığınız zaman alet size ayak uydurup ivmelenmeye başlıyor. Nası oluyo la o?

Dışarıdan oldukça kalıplı duruyor (ki zaten kalıplı bir motor). Ben 172 boyuma rağmen almadan önce “Nası sürcem la ben onu” ya da “O motor çok büyük bana abi yeaa” triplerine girerken aslında yanıldığımı fark ettim.

İster racing tarzında, isterseniz de yarı-racing sürüş pozisyonuyla sürebiliyorsunuz motoru. Gidon turu öyle ahım şahım geniş değil, fakat U dönüşü yapmayacaksanız dar alandan gayet yeterli. Göstergede vites göstergesi dahil neredeyse her şey var ve Ninja 250R gibi öyle sanayi işi bir görünüme sahip değil.

Vitesler şıkır şıkır, fakat ayak pegleri biraz dandik sanırım. Benden kaynaklı da olabilir (zaten 3 gündür sürüyorum hayvanı) ama ara sıra ayaklarım takılmıyor değil.

Ben her zaman kuralcı bir adam olduğumdan dolayı 125,250cc kullanmadan direk 600cc ve racing bir motorla başlayan motorcuları sevmiyorum. Onlar allaemanet gidiyolar yollarda. Bir sevmediğim tip de 125cc,250cc gibi düşük cc (kimilerine göre) motosikletleri %100 olarak kavramadan hacim yükselten motorcular. Motorla içli dışlı olmadan, onla beraber her şeyi yenibaştan keşfetmeden “Gitmiyo abi bu, ehe ehe…” triplerine giren aptallardan bahsediyorum. Her hacimde motorun kendi zevki ve sana katacakları var. Bir kitap gibi. Sen kitabı yarısında bırakırsan sonunu hiçbir zaman öğrenemezsin. Ha eğer kitap seni sarmadıysa belki kitap okumaman, ne bileyim, çimleri falan biçmen gerekiyordur. Malesef, ama bu işin kuralı böyle dostlar.

Hadi eyvallah.

0
Shares

Scorp Macerası

Herkese selam 🙂

Malum maceranın hikayesine geçmeden önce Scorp hakkındaki görüşlerimi belirtmek istiyorum. Scorp, Türkiye’den çıkmış nadir başarılı platformlardan bir tanesi.Bunu kabul etmek lazım. Sikko sikko startuplara milyon liralık yatırımların yapıldığı güzel Türkiyemde communityyi sağlam temellere oturtmayı başarmış başarılı bir startup görmek güzel. Bugün 1 yaşını kutlamış hatta, tekrar kutlayalım 🙂

1 yıllık bir girişimin altyapısında teknik hataların bulunması son derece normal bir durum. Zaten “Biz sistemi kurduk haydaaa hobareee 10 yıl gider” kafasıyla işler yürümüyor bu sektörde. O nedenle açıklardan vs. bahsetmek yerine ben bu platformda yanlış giden bazı şeylere değinmek istiyorum.

Moderasyon. Üzülerek söylüyorum ki moderasyon her ne kadar işini tam anlamıyla yapsa da bazı şeylere göz yumulması kabul edilebilir değil. “Dünyanın en samimi sosyal medyası” başlığıyla bu sistem yürüyorsa bana göre orospuluğu bir şöhret basamağı olarak gösteren insanlar samimi değil. Scorp herkesin kolayca erişebildiği ve yaş sınırının olmadığı bir platform. Bu durum göz önüne alındığında günümüz sosyal medyasında küçük yaştaki gençlerimizin bu tarz kişilere özenebilmesi çok ihtimalli bir durum.

Geçen hafta küçük bir kız kardeşimiz bu kişilerden birine özenip onun gibi bir post atmış. Ben videoyu görmedim fakat bir headline altında konuşulurken duydum. Bu benim Scorp’ta yapılamayacakları yapmamdaki birinci sebebimdi.

Asıl hikaye aslında ikinci sebebimde başlıyor 🙂

Bundan yaklaşık 3 ay öne MasterCard’ın düzenlediği Masters of Code Hackathonuna katılmıştık “Nane” ekibi olarak. Koç Kuluçka Merkezi’nde gerçekleştirilen bu etkinlikte biz de Scorp’un ofisinde çalıştık. O sırada Scorp’un kurucu ortaklarından Sercan yanımıza geldi (aslında adam kendi ofisine geldi … :D) Scorp’un web sitesi o zamanlar henüz beta aşamasındaydı. Biz de meraklı yazılımcılar olarak daha önce kurcalayıp bazı açıkların olduğunu öğrenmiştik, fakat bununla ilgili bir aksiyon almamıştık. Kendisiyle bu açıklar hakkında konuştuk ve “Hackleyebiliyorsanız hackleyin” yanıtını aldık 🙂 Ben şahsen bunu bir challange a dönüştürmek istemedim kendi içimde. Fakat “hackleyebiliyorsanız” dedikten sonra test sunucusu falan sohbeti geçmediği için dönüştürmüş bulundum.

Ben kendimi hacker olarak görmedim, görmüyorum da. Hacker kavramı çok daha farklı bir olay benim için. Fakat bir sistemi çalışabilir en stabil haline getirebilmek için bir tarafın saldırıp diğer tarafın bu saldırıları karşılayabilmesi gerekli. Büyümek istiyorsunuz, anlayabiliyorum. Almanyalara açılmalar falan başlamış, bunlar çok güzel hareketler. Bana göre şu an yaptığınız hareketin yürümeyi bile bilmeyen bir bebeği yüzsün diye havuza atmaktan hiçbir farkı yok. Herşey alelacele yürüyormuş gibi bir his var içimde. Bunun nedeni yatırımcıların gereksinimlerini karşılamak da olabilir, açgözlülük de olabilir, ya da yetersiz kaynaklar da olabilir. Şu an benim aklıma en çok yatan kaynak yetersizliği oldu çünkü en son kendileri Python – Django ile uğraşıp 5 yıllık iOS tecrübesi olan bir full-stack developer arıyorlardı.  Good luck with that.

Android var, Türkçe tabiriyle bas-çek yok. Servisler allaha emanet. Tasarımlardaki uyuşmazlık diz boyu. Windows Phone clientı yok. (olmasa da olur dediğinizi duyar gibiyim). Feature-set için çok konuya girmeye gerek yok eminim Faz 2 – Faz 3 seviyesinde güzel özellikler eklenecektir, bu tarz şeyler için henüz erken. Fakat implementasyonu çok basit bir “Profil Yaş Sınırlaması” özelliği eklemek bütün bu NSFW olaylarını çözecekmiş gibi geliyor bana.

Scorp’un bu saatten sonra “meme görmek isteyen kullanıcı” kitlesini kullanarak kendini büyütmeye ihtiyacı yok. Aksine, artık oluşturduğu bu topluluğa yanıt verebilen hareketlere ihtiyacı var. Fenomenlere sinema – konser bileti vs. dağıtmaktan bahsetmiyorum. Zaten fenomen – fenomen değil diye ayrım yapılması da ayrı bi olay da , neyse. Burada olay herkes. Herkes bu oluşturulan topluluğun bir parçası. Buna bağlı aksiyon alınması uzun vadede her türlü kazanç sağlar.

Şu trolleme işine gelecek olursak. Sanırım üç kez ban yedim 🙂 Zaten Scorper olma gibi bir niyetim olmadığı için bu bana zarar veren bir şey değil. Hesabımı geçen hafta sistemi daha yakından tanıyabilmek için açmıştım.

Unutmadan eklemek istiyorum, adıma açılan “Scorpu Hackleyen Adam”  headline’ına atılan bütün postları tekrar tekrar izledim. Hepsine çok güldüm, hepiniz harikasınız 🙂 Güzel dilekleriniz için çok teşekkür ederim. Bana göre bu benim başarım olarak değerlendirilmemeli asla. Bu tam olarak benim o videoda savunduğum şeye katılan insanların samimiyetiyle ortaya çıkmış bir baş kaldırış. Scorp bu insanlara kulak vermeli.

İş hayatımdan vakit bulduğum her zamanda Scorp’a her konuda destek vermeye hazırım, benim Scorp ile bir zıtlaşmam vs. hiçbir şekilde yok, yanlış anlaşılmasın 🙂 Bu konuyla ilgili gerekli prooflarla bkaankose@outlook.com adresinden bana ulaşılabilirler.

Hadi eyvallah…

0
Shares

Yazılımcının Kendini Yazılımcı Olarak Hissettiği Anlar

Zamanında ekşisözlük’te bir entry okumuştum.Bir devlet işi için bir yazılımın paketlenmesi gerekiyormuş, yazılımın devredildiği alet gümrüğe mi takılmış vs. artık tam hikayeyi şu an hatırlayamadım. Daha sonra yazılımın ölçeklendirilmesi gerekmiş. O zamanki zaat-ı alimler de bu işi duyduğunuzda ‘hadi len öyle şey mi olur’ tepkisi verdirecek bir cinsten çözmüşler. Eminim çoğunuz o yazıyı görmüş ya da okumuşsunuzdur.

Bir yazılıma fiyat biçilmesi her zaman sorun olmuştur. Bu bir inşaat işi değil ki şu kadar kilo çimento şu kadar lira, vinç gelecek günlük kirası şu kadar lira vs. diye ölçeklendiresiniz. Yani elle tutulur tek şey aslında yazılımcının bastığı tuşlar. Komik 🙂 Sektörü ve şirketini tanıyan insanlar bu fiyatları az-çok kestirip bir şeyler sunabiliyorlar.Amaaa , benim bahsedeceğim yer tabiki de burası değil ^^

Lafı uzatıyorum çünkü hislerimi nokta atışı anlamanız gerek bu konuda. O zaman haydi başlayalım.

Yazılım sektöründe çalışan bir yazılımcı olarak söyleyebilirim ki yaptığım işten çok çok keyif alıyorum. Bir şeyler üretmek, bastığım her tuşun aslında neye hizmet edeceğini benim belirlemem, iş sonunda ortaya çıkan şeyin verdiği mutluluk beni oldukça sevindiriyor.İşimi seviyorum diyelim kısaca.Fakat işimi sevmemin de dereceleri var.Bunun için aşağıdaki maddeler arasında biraz kıyas yapmamız gerekiyor :

  1. Az kod yazarak major bir bug düzeltmek.
  2. Çok kod yazarak minor bir bug düzeltmek.
  3. Az kod yazarak minor bir bug düzeltmek.
  4. Çok kod yazarak major bir bug düzeltmek.

En akıl işi olan tabiki de 1. seçenek. Fakat benim için değil. Benim için önemli olan az veya çok yazdığım ya da minor veya major bugları düzelttiğm değil.Neden diye soracak olursanız cevabı çok basit : Mükemmelliyetçilik.

Atatürk İlke ve İnkılaplarını benimseyen biri olarak o listeye ekleyebileceğim bir madde olsaydı eğer kesinlikle bunu eklerdim. Evet evet, aynen bunu. Mükemmelliyetçilik benim için bir şeyin mükemmel olması değil, mükemmel olmasına giden yolda benim ona verdiğim katkı payıdır.Leylasını arayan Mecnun misali sonsuz bir çölde olmayan birini aramak gibi.Hiçbir şey mükemmel olamayacağı için bu iş de tam olarak buna benziyor.

Kimseyi üzmek ya da kırmak değil amacım, ama basit bir uygulamayı ingilizcesi kuvveetli bir insan 1 hafta çalışmayla kavraya kavraya ortaya koyabilir. Tıpkı benim ilk başlarda yaptığım gibi. Ara sıra eskiden yazdığım kodlara bakıyorum da, bu kendini geliştirme işini çok iyi ilerlettiğimi düşünüyorum.

Bugün çalışırken üzerinde çalıştığım uygulamanın Suspend modundayken App-List’ten tekrar çalıştırıldığında sapıttığını fark ettik. Uygulama alt yapısında Prism kullandığımız için SessionStateService ile ilgili bir şeylerin yanlış gittiğini düşündüm ilk başta. Bunun için yaklaşık 2 saatimi harcayarak SessionStateService’i Prism kütüphanesinin Github reposundan proje içerisine override ederek debug yaptım.Sorun burada değildi, anladığım kadarıyla da olamazdı da.Sorun tam olarak App-List’ten tekrar çalıştırılan uygulamaların Suspended modundan Resumed moduna geçmesi yerine tekrardan launch edilmesiydi.Launch edilen yerde de bizim yaptığımız bazı konfigurasyonlar Frame’in tamamen kararmasına ve AppBarların kapanmasına neden oluyordu.Küçük birkaç dokunuşla bu işi de halletmiş oldum.

Bu olay esnasında zevk aldığım tek şeyin aslında bu mükemmelliyetçilik olduğunu anladım. Sorunun nereden kaynaklandığını bilmiyordum, sadece tahminlerim vardı. Kesin sonuca ulaşamayacağımı bile bile open source bir library üzerinden bir classı kendi projemize implemente ettim. O classın içini düzenledim, methodlarını işimize daha yarayacak şekilde düzenledim vs… En sonunda, yani yaptığım şeyin tamamen boşa olduğunu anladığımda aslında küfürler etmem gerekirken benim yaptığım hareket sadece rahatlamak oldu. Çünkü deep-level işlerle uğraştığımı biliyordum. Yaptığım işler ekrana buton at, butona tıkla mesaj verden çok çok daha öte bir şeydi. Elbette onlar da gerekli, fakat bana asıl yaptığım şeyi sevdiren işler bu tarz şeyler. Beni zorlayan, beni geliştiren, sonu kesin olmayan ve sonucunda da ortaya çıkaracağı şeyin boyutunun küçük ya da büyük olduğunun önemsiz olduğu şeyler.

Yorulmak söz konusu değil. Olamaz.

 

0
Shares

Güncel Televizyon geri dönüyor !

Hızlanan kalp atışlarınızı duyar gibiyim … Çok pardon o odamın camına çarpan kar tanelerinden geliyormuş 😛

Yaklaşık 10 gün önce Güncel Televizyon’un Windows 10 sürümünü yazmaya başladım.Azar azar buraya tıklayarak ulaşabileceğiniz GitHub reposunu güncelliyorum.Şu an için sadece tamamlanmamış ana sayfası , hakkında sayfası , kanal listeleme ve yayın akışı sayfası var.Henüz izleme kısmıyla ilgili bir çalışma göndermedim repoya.Yoğunluktan sıyrıldığım zaman elbet o da gelecek.

Projeyi Prism kullanarak MVVM altyapısıyla geliştiriyorum.Aslında bir Universal Windows Project (UWP) projesi.Yani çıktı alabildiğimiz zaman hem Windows 10 , hem Windows Phone 10 hem de Xbox üzerinde çalışacak.Xbox kısmı şu an için mümkün değil gerçi fakat ben projeyi tamamlayana kadar o SDK’i de sanırım yayına almış olur sayın Microsoft 🙂

Güncel Televizyon her zaman benim üzerinde çalışmaktan zevk aldığım bir proje olmuştur.Aslına bakarsanız kendimi ve diğerlerini geliştirmenin bir yolu olarak düşünebiliriz.Açık kaynaklı geliştiriyorum çünkü ‘Bunu ben yaptım, sadece benimdir‘ demeyi sevmiyorum.Ben yazdıkça, insanlar okudukça bu döngü mutual bir ilişkiye doğru gider.Ben yazarken kendimi geliştiriyorum, siz de öğrenmek istediğiniz yerler için bir referans bulabiliyorsunuz.Bundan güzel daha ne olabilir ki?

Uygulamanın Windows 10 sürümünde yepisyeni birkaç özellik daha eklemeyi düşünüyorum.Tamamen freestyle bir şekilde geliştirildiği için aslında yazarken “Aaa bu da olsa efsane olur” dediğim birçok özellik gelecektir aklıma.O nedenle main feature set henüz hazır değil.Fakat elbette bir önceki sürümde olan kanal bulma, canlı yayın akışı, bozuk kanal raporlama gibi ana özellikler bu sürümde de yerini koruyacak.Bunlara ek olarak yeni bir kanal eklendiğinde push notification gönderme gibi şekil şukul işlere de girişmek istiyorum aslında.Bakalım daha neler göreceğiz 🙂

Projeye her zaman destek olabilirsiniz.Bu projeye benim başlamış olmam sadece benim geliştiriyor olmam anlamına gelmiyor.Tıpkı çoğu açık kaynaklı geliştirilen proje gibi.Naming conventionlara ve proje altyapısına uygun her türlü kod desteği kabulümüzdür 🙂

Yakın zamanda bu proje üzerinde çok detaylı bir yazı hazırlamayı da düşünüyorum.Şimdilik bu kadar yeter, hayat toz pembe olmasa da hep gülücük saçın 🙂

0
Shares