I still use some development tools that are used by most Linux users and these tools need some environment variables like LC_ALL, HOME, etc. When I have a new PC with Windows 10, I start to use with defining these variables. Take a look at this post for more detail.
PowerShell Core
It’s possible to use BASH on Windows indeed, but I think PowerShell Core is a good alternative. Git integration is working well, defining aliases and functions is easy:
Readline is a familiar extension for BASH users. If you want to use Emacs key bindings in PowerShell, I suggest you add Readline to the dependencies list.
What if we want to use a Linux command-line app? Like Nano? Indeed, it’s possible to use it as a default git-commit editor but, let’s consider it’s a program that only available in Linux. I use WSL for that case. Just install Ubuntu or another Linux distro with WSL, open PowerShell and run this command:
> wsl -e nano README.md
So you can reach all Ubuntu programs using this magic command. There’s only a little problem here, you have to keep your configuration files (like .nanorc) in your WSL instead of in your local. You can find my configuration repo here.
Git-apply EOL Problem
If you don’t ignore space changes in your patch command, you will get an error because the whitespaces in Linux environments. To solve this problem, use git-apply with these parameters:
Bu yazıda sözünü ettiğim işletim sistemi ve sürümü Windows 10 Pro’dur. Amacım yazılım geliştiriciler için Windows 10 Pro’nun alternatif bir geliştirme ortamı olduğunu anlatmaktır. Windows 8 değil, Windows 10 Home da değil, sadece Windows 10 Pro. Karar elbette sizin.
Genel Görünüm
Uzun süre Linux dağıtımı ve MacOS kullanan birisi olarak ilk Windows izlenimim çok kötüydü. Font rendering Ubuntu’dan bile kötüydü. Masaüstü ortamı KDE’den bile karışıktı. Klavye kısayollarını yeni baştan öğrenmem, alışmam gerekecekti. Ama şu detay beni Windows’ta tutabildi: Laptopu ilk açtığımdan itibaren ihtiyacım olup kuramadığım hiçbir program, eksikliğini hissettiğim hiçbir uygulama, kullanamadığım veya ayarlamak zorunda kaldığım mikrofon, kamera gibi hiçbir donanım olmadı. MacOS’ta olduğu gibi, Windows’u açtığımda kullanıcı hesabı oluşturmak, bulut depolama servisi OneDrive’i bağlamak gibi ilk kurulum ayarlarını yaptım ve bir daha ne format atma gereği duydum, ne de performans sorunu yaşadım.
Donanım
Eğer Macbook Pro gibi bir laptop arıyorsanız, gibisini değil aslını alın. Ona da Windows kurabilirsiniz. PC için tavsiye isterseniz:
Kurumlarda tercih edilen Thinkpad (Lenovo), Dell, HP gibi markalara öncelik tanıyın.
SSD şart, mümkünse 16 GB RAM ve son nesil i7 olsun (Yine Macbook Pro’dan ucuz olabilir).
Ekran çözünürlüğüne, kalitesine önem verin.
Başımdan geçen bir olayı anlatayım. Ben Thinkpad kullanıcısıyım, trende üzerime ve fermuarı açık olduğu için çantamın içine kaynar su döküldü, Thinkpad’i elime aldığımda suyun sıcaklığını hissettim. Laptopu açıp kontrol ettim epey, hiçbir sorun yoktu. O an o laptopun Macbook Pro olduğunu düşünemiyorum.
Antivirüs Programı
Yüklü geliyorsa kaldırmanıza gerek yok, gelmiyorsa almanıza gerek yok 🙂 Yine de olsun istiyorsanız, bir zararı yok.
Terminal ve POSIX Uyumluluğu
Windows’a yöneltilen eleştirilerin başında POSIX uyumlu olmaması var. İşin doğrusu bu konuda bir sıkıntı çekmedim, çünkü işletim sistemi ne olursa olsun bu zamana kadar hep sanallaştırma kullandım. Yani geliştirme yaptığım ortam her zaman bir Ubuntu LTS sunucusu oldu. Ancak Twitter’daki mesajıma yazılan cevaplardan gördüm ki sanallaştırmayı herkes kullanmıyor. Bana örnek bir sorun gösterilirse çözümü beraber tartışabiliriz. Ancak sanallaştırma bana göre tüm platformlar için en mantıklı çözüm.
Terminal konusunu ise bir tek Linux dağıtımları becerebiliyor. Ne MacOS, ne de Windows’ta aynı rahatlığı yakalayamadım. Fakat Powershell iş görmüyor mü? Görüyor. Pencere tabları kullanmak isterseniz ConEmu var. KDE’deki Yakuake gibi Quake-style kullanmak isterseniz cmder var. Zsh’siz olmaz derseniz Babun var. Bana Bash yeter derseniz de Git ile birlikte gelen Bash var. Bana bir SSH yeter derseniz Bitvise ve Putty var. Seçenek çok.
Paket Yöneticileri
Windows’ta ilk kullandığım paket yöneticisi Pacman oldu. Archlinux’taki Pacman’ın pek çok parametresini destekliyor.
Bir süre Chocolatey kullandım, bu MacOS’taki Bower’a daha yakın bir alternatif.
Şuan ise hiçbir paket yöneticisi kullanmıyorum. Masaüstü uygulamalarının bir kısmını Windows Store ile, bir kısmını doğrudan uygulamanın sitesinden indirerek yüklüyorum.
Git ve Dosyalarda CRLF ve UTF-8 Bom Sorunu
Git’i grafik arayüzüyle kullanmak isterseniz, çok güzel alternatifler var. Komut satırı tercih ediyorsanız, zaten Bash ile birlikte geliyor, onu kullanabilirsiniz veya Powershell tercih edebilirsiniz. Git’e dair hiçbir alışma problemi yaşamayacaksınız, bir konu hariç.
Windows’ta yeni bir dosya oluşturup yazmaya başladığınızda, satırbaşı için öntanımlı CRLF yöntemini kullanıyor. Yani dosyalarınızı Unix tabanlı bir işletim sistemi kullanan birisi okumak, açmak veya çalıştırmak istediğinde; veya bir repoya gönderdiğinizde, deploy ettiğinizde bir okuma, derleme, yorumlama problemiyle karşılaşmanız çok büyük olasılık.
Eğer bir sürüm kontrol sistemi kullanıyorsanız, bu tip sorunların üstesinden gelmek kolay: Dosyalarınızı commitlerken LF’ye zorlamak. Stackoverflow’da çözümü detaylı bir şekilde anlatılıyor. Buna ek olarak bir de kullandığınız editör ve IDE’lerde newline ayarınızı bir seferlik yapmanız gerekir.
Gelelim UTF-8 Bom sorununa. Bu sorun CRLF’ye göre anlaşılması çok daha zor ve sinsi bir sorun. CRLF ile aynı sorunları yaşıyorsunuz; ancak gözle görünür hiçbir problem yok, o nedenle file encoding’e dikkat etmeniz gerekiyor. BOM hakkında detaylı bilgi için Gökhan Şengün’ün buradaki cevaplarına bir göz atınız.
Sanallaştırma
Windows sanallaştırma konusunda gerçekten çok başarılı bir platform. Gerek VMware olsun, gerek Virtualbox, gerekse Hyper-V, elinizin altında çok sayıda alternatif var:
Henüz yeni kararlı sürüme erişmiş WSL (Windows Subsystem Linux) ile arada ek bir sanallaştırmaya ihtiyaç duymadan UNIX ortamına sahip olabilirsiniz. Ancak henüz web development yapmak için yeterli görünmüyor, terminali kapattığınızda alt sisteme erişimin kapanması gibi bir sorun var.
WSL kurulumu çok basit, Windows Store’dan Ubuntu veya Suse diye aratıyorsunuz.
Docker desteği çok güzel. Hyper-V ile birlikte kullanıyorsunuz.
Virtualbox ile Vagrant kullandığınız zaman, veya Android geliştirme yaparken emülatöre ihtiyaç duyduğunuzda Hyper-V’yi kapatıp bilgisayarı yeniden başlatmak zorundasınız. Bu ilk başlarda canımı sıksa da, artık alıştım. Hyper-V açıp kapatmak için Powershell’i Admin yetkisiyle açıp aşağıdaki komutu kullanabilirsiniz:
Önce kısayolları öğrenmekle başlayın, bu sizin işletim sistemine hakimiyetinizi ve iş yapma hızınızı her platformda etkiler. Vim ve Emacs severler üzülmesin, Windows altında çok güzel çalışıyorlar. Bir de 2018 mobil{in|yanın} yılı olacak!.
Bir yazılım projesine başlarken ihtiyaç duyacağımız ilk şey ne olur diye soracak olursak, sanırım buna “geliştirme ortamı” diye cevaplayabiliriz. Örneğin bir Android projesi için şunlar gerekli:
Android Studio veya Eclipse (ADT)
Android Java SDK
Android yüklü donanım veya emulator
İşletim sistemine göre emulator hızlandırıcı eklentiler (HAXM, qemu, vb)
Bu ortamı işletim sistemimize kurduğumuzda, iki şeye sahip oluyoruz: Birincisi kod yazabiliyoruz, debug edebiliyoruz, sorunları düzeltebiliyoruz; ikincisi sonucu görmek için uygulamayı yükleyip çalıştırabiliyoruz, test edebiliyoruz, yayınlayabiliyoruz. Bir Windows Phone veya IOS projesi olsaydı, geliştirme ortamı gereksinimleri arasına işletim sistemi de (Windows veya OS X) girecekti; ama Android SDK tüm popüler sistemleri destekliyor, tercih geliştiriciye kalmış.
Peki web projelerinde durum nasıl? Web projesi için geliştirme ortamı konusunda şu üç yoldan birine başvuruyoruz:
Geliştiriciden projeyi, kullandığı sistemin içine kurmasını talep etmek.
Emulator kullanmak, geliştiriciler için sanal sunucu paketi oluşturmak.
1.’si bence çok kötü fikir. Geliştirici Windows kullanıyorsa karşılaşacağı handikapların sonu yok, production için fayda etmeyecek bir sürü gereksiz düzeltme yapmak zorunda kalabilir. 2.’si de bence kötü fikir. Geliştiricinin alışkın olmadığı bir sistemde, alışkın olmadığı birtakım araçlar kullanarak verimli ve pragmatik olmasını beklemek ne kadar doğru? Velev ki işe alımlarda GNU/Linux kullanıcısı olmak diye bir filtremiz olsun, doğru geliştiriciyi işe almada ne kadar adil ve yardımcı olabilir? Daha önemli bir soru, neden kişisel kullanım için tasarlanmış bilgisayarı bir server’a dönüştüresin?
O nedenle, tıpki mobil uygulama geliştirirken kullandığımız gerçek donanım veya emulator gibi, web geliştirmede de benzer bir yöntem uygulamalıyız. VMware veya Virtualbox ile, olabildiğince production’u taklit edebilmeliyiz. Ben bunu vagrant ile çok kolay bir şekilde yapabiliyorum, istediğim işletim sisteminde kullanabiliyorum ve taşıyabiliyorum. Bir başka geliştiriciyle de geliştirme ortamımı paylaşabiliyorum.
İşletim sistemi tercihi, IIS’ye ihtiyaç duymak gibi çok özel durumlar olmadıkça geliştiriciye bırakılmalı. En verimli nasıl çalışabileceğini en iyi geliştiricinin kendisi bilir.
