Google Code, Mayıs 2009 tarihinden beridir barındırdığı projelerde sürüm kontrol sistemi olarak SubVersion veya Mercurial kullanabilmemize olanak sağlıyor. Fakat daha önceden oluşturulmuş Subversion ambarlarının Mercurial’a dönüştürülmesinin ise elle yapılması lazım.

Dönüşüm için benim uyguladığım adımlar şöyle:

• Cygwin‘i svn-pyhton ve mercurial paketleri ile birlikte kurun.
• C:\cygwin altına kurulumu gerçekleştirdiğinizi varsayarsak, c:\cygwin\bin\ash.exe aracını çalıştırın.
• /bin/rebaseall komutunu çalıştırın. (Bu işlem cygwin altında pyhton’un düzgün çalışması için gerekli)

• c:\cygwin\home\<kullanıcıadı>\ klasörü altına .hgrc adında bir dosya oluşturun. Ve içeriğini şu şekilde belirleyin:

  [extensions]
  hgext.convert=
  

• Cygwin’i çalıştırın.

• Sırası ile aşağıdaki komutları çalıştırın:

  svn co http://<projeadı>.googlecode.com/svn svn-repo
  hg convert svn-repo hg-repo
  

• Google code projenizin sürümleme kontrol sistemini Mercurial olarak değiştirin.

• Yerel mercurial ambarınızı google code ambarına gönderin (push)

  cd hg-repo
  hg push https://<projeadı>.googlecode.com/hg/
  

Mercurial istemcisi olarak TortoiseHG kullanabilirsiniz. Ayrıca Visual Studio entegrasyonu için de hgscc eklentisini deneyebilirsiniz.

Düşününki C++ için bir IDE hazırlamışsınız ve bu IDE de oldukça popüler olmuş. 20,000 geliştirici tarafından kullanılıyor ve yıllardır da bunu satıyorsunuz. IDE’nin performansı fena değil ne de olsa C++ derleyiciler yavaşlıkları ile ünlüdürler.

Fakat bu IDE’nin kullanıcılarından birisi (Andread Hausladen) öyle bir yama yapıyorki derleme zamanı %75 azalıyor. Görünen o ki; derleme işlemi başlatıldığında derleyiciye IDE tarafından bazı callback fonksiyonları kaydediliyormuş ve bunlardan birisi de OpenFile fonksiyonuymuş. Sorun ise OpenFile fonksiyonunun aynı zamanda dosya var mı yok mu kontrol etmek için de kullanılıyor olmasıymış ki bu da oldukça zaman kaybına neden oluyormuş. Andreas ise yamasında OpenFile çağırılmadan önce GetFileAttributes fonksiyonu ile dosyanın var olup olmadığının kontrol edilmesini, dosya varsa OpenFile çağırılmasını sağlamış ki bu da 30 saniyelik derleme süresini 4.5 saniyeye düşürmüş!

İşin ironik tarafı ise enerji tasarruflu uygulama geliştirme için yapılabileceklerle ilgili StackOverflow’da sorulan bu soruda karşıma çıktı. İlk cevap şu an C++ Builder’ı geliştiren CodeGear’ın ürün sorumlusu Nick Hodges‘dan gelmiş, ikinci cevap ise tam bir ayar niteliğinde.

C++ Builder’ın yılda 200 gün çalışıp, günde 15 dakikasını derleme işleminin bitmesini bekleyerek harcayan 20000 geliştirici tarafından 5 yıldır kullanıldığını düşünürsek saatte 50$ masraf ile toplam maliyet 187.5 milyon doları buluyor. Borland’ın neden bu hale geldiğine şaşmamak lazım.

Delphi’nin hızlı yazılım geliştirmeye getirdiği kolaylıklar anlatmakla bitmez. 90′ların sonu ve 2000′lerin başında; saniyeler içinde derleme, tüm uygulamanın tek exe olarak çıkarılabilmesi, veritabanından arayüze data bağlamadaki kolaylıkları ve arkasındaki çok büyük bir komünite ile zirvedeydi diyebiliriz.

Öncesinde Java, sonrasında .Net’in gelmesi ve Borland-Inprise-Borland-CodeGear-Embarcadero arasında sekmesi sürecinde oldukça kötü delphi sürümleri (Delphi 8, Delphi 2005, Delphi 2006) arkası arkasına geldi ve Delphi popüleritesini kaybetti. Devam…

DelphiPI‘nin 0.33 sürümünü hazırladım. Bu sürümdeki bazı yenilikler:

Yerelleştirme: Şimdilik sadece Türkçe ve İngilizce dilleri destekleniyor. Yeni diller eklenebilir. Yerelleştirme işlemi için dxgettext kütüphanesini kullandım.

Paketlerin seçildiği sayfada bazı iyileştimeler yaptım. Paketleri listelerken artık listview yerine mük-kemmel virtualtreeview bileşenini kullandım. Böylece kullanıcı hem istediği paketleri seçebiliyor, hem de klasör yapısını görebiliyor. Ayrıca ağaç üzerine sağ tıklayarak çıkan yardımcı menü ile bir dosya şablonu (*d7.dpk gibi) kullanarak da paketleri seçebiliyorsunuz. Şimdilik paket bağımlılıkları ile ilgili bir geribildirim verilmiyor fakat ilerideki sürümlerde bunu da ekleyeceğim. Böylece kendisine bağımlı bir paket kaldırıldığında, bağımlı paketler de otomatik olarak kaldırılacak. Şu andaki kod bunu yapmaya müsait, sadece bu özelliği mükemmelleştirecek zaman bulamadım.

Devam…

.Net’te test için NUnit’ten başka kütüphane kullanmıyorum. Uzun zamandır da 2.2 sürümünü kullanmaktaydım ve memnundum fakat geçenlerde 2.4 sürümündeki bir özellik dikkatimi çekti. NUnit.Framework.SyntaxHelpers namespace’inin altında testleri daha okunaklı kılacak bir takım yardımcı sınıflar ve metodlar eklemişler, güzel olmuş. Örneğin önceden yazdığımız bu testi:

Assert.IsNotNull(items);
Assert.AreEqual(2, items.Count);

Assert.That(items, Is.Not.Null);
Assert.That(items.Count, Is.EqualTo(2));

Bugün itibariyle Resharper 4 Release Candidate duyuruldu. Gidip indirin, deneyin. Son 2 haftadır çıkan gecelik sürümler zaten gayet düzgün çalışıyordu. Nihayet, NotImplementedException’ları gördüğümüz günlerden bugüne kadar geldik. Gecelik sürümleri kullandığım dönemde güvenemediğimden dolayı uzun bir süre VS’nin intellisense’ini kullanmayı tercih etmiştim fakat ilk beta sürümünde resharper’ın intellisense’ine geçtim ve hiçbir problemle karşılaşmadım, RC’de de ciddi bir problem ile karşılaşacağımı sanmıyorum. Zaten Jetbrains bir sürüme RC diyorsa, o sürüm Visual Studio’nun RTM’sine denk demektir. İçiniz rahat olsun.

Devam…

Dijkstra’nın en kısa yol algoritması (DJK) ya da Dijkstra’nın deyişiyle “benim en kısa yol algoritmam” graf üzerinde bir noktadan diğer tüm noktalara en kısa yolu çıkarır ve bunu n noktalı bir grafta en kötü olarak O(n*n) zorlukta tamamlar. Daha önceden bahsettiğim Floyd-Warshall algoritması ise tüm noktalar arasındaki en kısa mesafeyi O(nnn) zorlukta çıkarıyordu. Dikkat ettiyseniz birisi yolu diğeri mesafeyi çıkarıyor. Algoritmanın aşamalarını ayrı ayrı değerlendirdiğimizde anlamamız daha kolay olacaktır. Örnek olarak 10×10′luk bir tahtanın üzerinde olduğumuzu düşünün. İlerlemeye (0,0) noktasından başlayıp, (9,9) noktasına ulaşmaya çalışacağız. Tahta üzerindeki her karede bir sayı olsun ve biz o kare üzerine geldiğimizde orada yazılı olan sayı kadar saniye beklemek zorunda kalalım. Bu durumda hedefimiz olan (9,9) noktasına en kısa zamanda nasıl ulaşırız? Devam…

• AideRSS.com Okuduğunuz bir sürü blog var fakat hepsini okuyacak kadar zamanınız yok mu? İyi içeriği olan yazıları da kaçırmak istemiyor musunuz? O zaman bu site tam size göre. Okuduğunuz blogları buraya yazın ve içerik kalitesine göre filtrelenmesini sağlayın. Mesela ben codebetter.com‘u okuyorum fakat burayı takip etmeyi bir iki günlüğüne kaçırdığınızda okunmamış gönderi sayısı 30′u geçiyor. Bende aiderss ile sadece “en iyi” olarak puanlanmış içerikleri alıyorum. Rahat ediyorum. Hemen arayın!
• Project EULER Matematiğe ilginiz var ve ilginç matematik sorularını çözmeyi seviyorsanız Project Euler’i ziyaret edebilirsiniz. Bu sitede matematik ve geometri ile ilgili 170′in üzerinde soru var. İster kod yazarak ister kağıt kalem kullanarak bu soruları çözebilirsiniz. Çözdükten sonra forumdan diğerlerinin nasıl bir yaklaşım izlediğini görebilir, kendinizinkini paylaşabilirsiniz.
• Sphere Online Judge Project Euler’e benzeyen bir site ama bu sefer sadece kağıt kalem yok, sadece kod ile çözüyorsunuz ve kullanabileceğiniz programlama dilleri oldukça çeşitli: (Java, C/C++, Ruby, Mono .Net, Pascal, Pyhton, vs). Çeşitli yarışmalarda çıkmış problemlerin devasa bir arşivi diyebiliriz. Problemlerin hepsinde süre kısıtlaması var. Bazı problemlerde kaynak kod boyutu veya derleyici sınırlaması var. Ben baya sardım, tavsiye ederim.
• TopCoder SPOJ’un ticari ve popüler hali.
• StumbleUpon Bazen internette ne yapacağınız bilemiyorsanız ve zevkinize göre farklı websitelerini rastgele gezmek istiyorsanız, gidin tarayıcınız için uygun eklentiyi indirin, bir hesap açın, ilgilendiğinizi kategorileri seçin ve sörf yapmaya başlayın. Siz stumble düğmesine bastıkça karşınıza farklı websiteleri gelecektir. Saatleriniz geçer bunu yaparken, benden uyarması.

C#’ın gelişmiyle birlikte söz diziminde (syntax) de bazı iyileştirmeler olduğunu heralde duymuşsunuzdur. Bu yazıda c# 1′den itibaren c# 3′e kadar ne gibi değişikler olduğunu kısaca bir toparlayalım.

Bahsedeceğim iyileştirmelerin bir çoğunun temeli C# 2′de atıldı. Örneğin C# 1′de bir formu kapatmak için bir butona event handler eklemek istediğimizde aşağıdaki gibi bir kod yazmamız gerekiyordu. Devam…

Biraz da ReSharper’ın konumlanma, arama tarama özellikleri üzerinden bahsetmek istiyorum. Visual Studio’da bir dosyaya gitmek, bir tipe konumlanmak veya bir dosya içerisinde arama yapmak o kadar zor ve yavaşki Resharper’ın bu özellikleri altın değerinde oluyor. Devam…

Efendim, uzun zamandır yapmak isteyipte bir türlü zaman bulamadığım ReShaper yazı dizisine başlıyorum ziyadesiyle. Öncelikle ReSharper nedir bilmeyen arkadaşları onunla tanışmaya davet ediyorum. Hemen gidip Nightly Buildlerden “Works here” yazanlardan bir tanesini indirip kurun ki anlattıklarımın bir anlamı olsun. ReSharper için kısaca Visual Studio’yu kullanılabilir kılan bir eklenti diyebiliriz. Benzer bir ürün de Developer Express’in CodeRush‘ıdır. Fakat ikisini de tam anlamıyla denedikten sonra sizde benim gibi Developer Express otursun grid yazmaya devam etsin diyeceksiniz. ReSharper’ın belli başlı özelliklerini 4 kategoride toplayabiliriz:

• Kullanım kolaylığı sağlayan özellikleri (Smart Enter, Smart Code Completion, Surround With, vs)
• Konumlanma özellikleri (Find Type, Find Usages, Go To Inheritor )
• Refactoringler
• Kod analizi (Quick Fix, Context Actions, vs)

Floyd-Warshall Algoritması, graf olarak ifade edilebilecek herhangi bir veri yapısında herhangi iki nokta arasındaki en kısa yolu bulmak için kullanılabilecek kodlaması oldukça basit bir algoritmadır. İnternette bu algoritmayı anlatan birçok kaynak bulabilirsiniz. Benim burada anlatacaklarım ise minimum teori ile maksimum pratik sunmak olacak. Pseudo kod yerine örnekler ve kod parçaları üzerinden açıklamaya çalışacağım. Floyd-Warshall algoritmasının özü çok basit bir formülden oluşuyor. A,B,C diye 3 tane noktamız olduğunu varsayalım. Bu durumda A ile C arasındaki en kısa mesafe min(mesafe(A,C), mesafe(A,B) + mesafe(B,C)) kadar olacaktır. Devam…

Birçoğumuz [Agile Development][1], [Test Driven Development][2] (TDD) ve [Extreme Programming][3] gibi terimleri sıkça duyuyoruzdur. Altlı üstlü bu yöntemlerin tümünün uzlaştığı bir nokta ise yazılımımızın sağlığı için gerekli birim testlerin (Unit Test) yazılmasıdır.

Peki bu birim testleri nasıl yazmalıyız ki hem etkili olsunlar hem de bakımları kolay olsun? Aslında bu sorunun cevabının büyük bir kısmı sizin projenizin tasarımızla ilişkili. Çünkü birim testler adı üzerinde birimleri test etmelidir. Nesne yönelimli programlama (OOP) paradigması ışığında hazırlanmış bir yazılımın birimleri ise sınıflardır. Sınıflarımızı tasarlarken de hayatımızı kolaylaştırması için uymamız gereken belli başlı prensipler var. Mesela her sınıf değişime kapalı fakat genişletilebilirliğe karşı açık olmalıdır ki buna -Açık Kapalı Prensibi- denir. vs vs..

Devam…

Tanım: Sadece 1′ ve kendisine tam bölünebilen pozitif tam sayılara asal sayı denir. Peki bir sayının asal olup olmadığını nasıl kontrol edebiliriz? Sayımız n olsun. Bu durumda 2 ile n-1 arasında tüm tam sayılara tam bölünüp bölünmediğini kontrol ederek asal olup olmadığını söyleyebiliriz. Bu durumda (n-3) tane bölme işlemi yapmamız gerekiyor.

Bilgi: Tek çift asal sayı 2′dir. Bu bilgi ışığında; yaptığımız bölme işlemlerinin sayısını yarıya indirebiliriz. 2 hariç çift sayılar için asallık kontrolü yapmamıza gerek yok.

Teorem: Bir sayısı kareköküne kadar hiçbir sayıya tam bölünmüyorsa o sayı asaldır. Bu durumda yaptığımız bölme işlemlerinin sayısı baya bir azalacak, çünkü sadece çift olmayan ve karekök n’den küçük tam sayılar için bu testi yapmamız yeterli olacaktır.

public bool isPrime(int n)
{
  if (n < 2) return false;
  for (int i = 2; i*i <= n; i+=2)
    if (n % i == 0) return false;
  return true;
}

Visual Studio 2008‘in çıkmasının ardından .Net 3.5 kullanan yazılımlarda da artık bir artış bekleyebiliriz. Bana göre, .Net 3.0 ile gelen yeni teknolojilerden en göze batanı ise Windows Presentation Foundation. WPF ile yapılabilecekleri gördükten sonra insanın ağzının açık kalmaması mümkün değil. Görsellik, esneklik, doğrulama (validation) ve veri bağlama (databinding) gibi arayüz hazırlarken karşılaşılan bir çok güçlük için hazır yapılar WPF ile sunuluyor.

Bu kadar güzel olan bu teknolojinin bence eksik kalan taraflarından birisi veri dönüştürücüler (Data Converter). Arayüzde sunmak istediğiniz verinin bazı durumlarda dönüştürülmesini veya formatlanmasını isteyebilirsiz. Ne kadar gariptirki WPF ile hazır gelen dönüştürücü yok. En basitinden, DateTime tipindeki bir veriyi formatlayarak görüntületebilmenin tek yolu bunun için bir converter yazmak.

M.Orçun Topdağı, blogunda buna çok basit ve güzel bir çözüm sunmuş. Üstelik hali hazırda mevcut olan parçaları bir araya getirerek. Lamda expression’lardan faydalanarak veri dönüştürme nasıl olur diye merak ediyorsanız yazısını okumanızı tavsiye ederim.

tarih 5 haziran 1999. final maçı steffi graf ile martina hingis ile oynanıyor. graf uzun bir aradan sonra jubile yapmak için sahalara geri dönmüş ve finale kadar yükselmiş. hingis ise 16 yaşında graf’ı wimbledonda eleyerek adını duyurmuş, dolayısıyla bu final ikisi için de önemli. hingis genç, atik, teknik. graf ise tecrübeli ve yaşına göre oldukça iyi durumda. maç çok hızlı başlıyor kesinlikle tenisin en uç noktalarında ceyran ediyor, olmayacak toplar çevriliyor, kıran kırana bir birinci setin ardından hingis 6-4 önde ilk seti alıyor. Devam…

Resharper, JetBrains tarafından geliştirilmiş bir Visual Studio eklentisinin adı.

Bu eklenti kod yazmayı oldukça kolaylaştıran ve hatta bazı durumlarda olası buglar için bile sizi uyaran mükemmel bir araç. Resharper ile kod yazmanın nasıl olduğunu göstermek için 9 dakika civarında bir video hazırladım. Kullanabildiğim kadar çok özelliği kullanmaya çalıştım. Bazı yerlerde sırf neler önerdiğini göstermek için bilerek hatalı ya da eksik yazdım. Video bittikten sonra birde kendim seyrettim ve size şunu söyleyebilirimki videoda kullandıklarım Resharper’ın yapabildiklerinin sadece %10′u olabilir. Fakat size yinede fikir verir umarım.

Bir de son not olarak yazdığım kodun bir anlamı veya mantığı yok, sadece bir şeyler yazmak için yazdım

Videoyu izlemek için buraya tıklayın

GoF’un Design Pattern kataloğundan sonra da bir sürü pattern adı ortaya atıldı ve atılmaya devam ediyor. Bu iş tam bir çılgınlığa döndü. Aynen Extreme Programming paradigmalarından sonra Agile Development, Alt.Net adıyla bir sürü türevinin ortaya çıkması gibi.

Efendim, nedir bu Dependency Injection?

Bir sınıfın ne olduğuna bakmaksızın ortak bir arayüz veya ortak bir sınıfı kullanması, yani o sınıfa ya da arayüze bağımlı hale getirilmesi. Örneğin bir veritabanı bağlantısı için IDbConnection diye bir arayüz tanımlanmış olsun. MSSQL, MySQL, vb veritabanlarına bağlanmak için bağlantı sınıfları oluştururken doğal olarak bu arayüzü kullanarak sınıflar tanımlarızki araya bir katman koyalım da veritabanı bağlantısıyla işi olan sınıflar veritabanının ne olduğuna bakmasızın işlerini yapabilsinler. Aşağıdaki kodda da dependency injection yapmış oluyoruz. Hatta bunların türleri var: Devam…

Javada operator overloading yok. Baya bir süre neden koymuyorlar diye merak etmiştim, hatta bir yerde operator overloading’in kodun okunurluğunu azaltacağı için Sun’ın bu özelliği eklemeye sıcak bakmadığını okumuştum. O zaman da saçma gelmişti, şimdi de. Ne yani? Bir yerimizi keseriz diye evde hiç bıçak bulundurmayalım mı?

Elbette fütursuzca kullanıldığında kodun okunurluğunu düşürür fakat inanılmaz derecede arttıracağı yerler de yok değil.

.Net için Entity Spaces adında veritabanı katmanı var. NHibernate‘in aksine bu katman hiç reflection kullanmıyor, onun yerine veritabanı şablonuna göre kod oluşturuyor. Böylece xml ayar dosyalarıyla uğraşmıyorsunuz ve oldukça iyi performans elde ediyorsunuz. İşin en güzel yanı ise kod içindeki sorgular aynen bir SQL sorgusu gibi görünüyor ve okunurluğu arttırıyor. Peki bunu nasıl yapıyor? Operator Overloading ile… Devam…

İlk çıktığında Visual C# 2008 Express Edition Beta 2′yi indirmiştim ama fırsat buldukça kurcalıyordum. Özellikle WPF’yi kurcalıyorum fakat henüz beta olduğu için sürekli göçüp duruyor hatta belli bir zaman sonra doğru yazdığım XAML’i bile derleyemez hale geliyor ve hatalı olduğunu söylerek beni yanıltıyordu. Ben de bir süre WPF’ye ara verdim ve diğer yenilikleri inceleye başladım.

Mesela LINQ. Deneme olsun diye bir klasör içinde yer alan dosyalardan adında önce o sonra a harfi geçen kaç tane var bir saydırayım dedim. Efendim oldu bitti. Yaptım, gözlerim karardı bir an ve şöyle bir maziye gittim, taa pascal günlerine…

Turbo Pascal veya Delphi veya dinamik olmayan herhangi bir dilde bu işi yapmak için en az 5-10 satır kod yazmak lazım. Peki bu işlem c# 3.0′da kaç satır? Bu yazıyı yazdığıma göre 5 satırdan kısa ve büyük ihtimalle 1 satır. Evet bildiniz, ben kod ekrandan taşmasın diye birkaç satıra bölüp yazıyorum buraya ama aslında 1 satır.

Console.WriteLine(
  new DirectoryInfo(@"c:\downloads")
  .GetFiles()
  .Count(f => Regex.IsMatch(System.IO.Path.GetFileName(f.Name), "o.*a"))
);

Aynı dosyaların toplam boyutu??

Console.WriteLine(
  new DirectoryInfo(@"c:\downloads")
  .GetFiles()
  .Where(x => Regex.IsMatch(System.IO.Path.GetFileName(x.Name), "o.*a"))
  .Sum(x => x.Length)
);

Hiçbir döngü yok.