Gökmen Görgen

Tag: software development

  • Geliştiriciler için Windows 10 Pro

    Geliştiriciler için Windows 10 Pro

    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:
    # kapatmak için
$ bcdedit /set hypervisorlaunchtype off# açmak için
$ bcdedit /set hypervisorlaunchtype auto
    Bash

    Son Söz

    Ö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!.

  • Vagrant ile Proje Geliştirme

    Monolitik yapıda bir web projesinin iskeletini oluşturup, projeyi geliştirmek için bir geliştirme ortamına ihtiyacımız var. Geliştirme ortamını hazırlarken bazı ayrıntıları göz önünde bulundurmak gerekir:

    1. Projede tek başıma mı olacağım? Tek başıma değilsem ekip arkadaşlarım kurulumda sorun yaşarlar mı?
    2. Tek başıma bile olsam, yerelimde yaşamadığım bir sorunu sunucuda yaşarsam bununla nasıl başa çıkacağım veya bu ihtimalın olmaması için ne yapabilirim?
    3. Bağımlılıklarda sürüm çakışması yaşarsam bunu nasıl çözeceğim? Geliştirme ortamımı diğerlerinden nasıl izole edebilirim?
    4. Geliştirme ortamımı yeni baştan kurmak istediğimde, başka bir bilgisayara geçtiğimde, her seferinde kurulum belgesi mi okuyacağım? Ve bu belge her işletim sistemi, her işletim sistemi sürümünde geçerli olabilecek mi?

    Amacımız şudur: 5 tane projemiz de olsa, ekibe sonradan katılıyor da olsak, hızlıca geliştirme ortamına sahip olabilmek ve bu ortamlar arasında kolayca geçiş yapabilmek, gerekirse hızlıca baştan kurabilmek.

    Sanallaştırma

    Vagrant sanallaştırma teknolojilerini kullanarak, kolayca yapılandırılabilir, tekrar tekrar kurulabilir ve taşınabilir geliştirme ortamı sağlayan bir araç. Bu sayede tek komutla geliştirme ortamımız hazırlanacak:

    $ vagrant up
    Bash

    Bu komutun bizim istediğimiz şekilde çalışabilmesi için bilgisayarımıza Vagrant ve bir sanallaştırma çözümü (örneğin VirtualBox) kurmamız, bir de proje dizinimizde Vagrantfile adında bir yapılandırma dosyası oluşturup hazırlamamız gerekiyor. Vagrant hakkında daha fazla bilgiyi şuradan edinebilirsiniz: https://www.vagrantup.com/intro/index.html

    Projelerimde kullandığım Vagrant yapılandırmamı şurada bulabilirsiniz, depoyu forklayıp siz de katkıda bulunabilirsiniz: https://github.com/gkmngrgn/vagrant-skeleton

    # -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure("2") do |config|
  config.vm.box = "ubuntu/xenial64"
  config.vm.network "forwarded_port", guest: 8000, host: 8000
  config.vm.provider "virtualbox" do |vb|
    vb.memory = "512"
  end
  config.vm.provision "shell", path: "increase_swap.sh"
  config.vm.provision "shell", path: "update_repositories.sh"
  config.vm.provision "shell", path: "install_java.sh"
  config.vm.provision "shell", path: "install_elasticsearch.sh"
  config.vm.provision "shell", path: "install_nodejs.sh"
  config.vm.provision "shell", path: "install_postgresql.sh"
  config.vm.provision "shell", path: "install_python.sh"
  [...]
end
    Ruby

    Vagrantfile dosyamızın içeriği çok basit. Bir Ubuntu 16.04 imajıyla sanal bir sunucu oluşturup, bir seferlik provision script’lerini çalıştırarak geliştirme ortamınızı hazırlıyor. Bu örnekte, 512 MB ram’lık sanal sunucumuza 1024 MB’lik SWAP alanı oluşturuyorum, sonrasında Elasticsearch, Nodejs, PostgreSQL gibi proje için gerekli paketleri kuruyorum, proje için veritabanı oluşturuyorum, Python için virtualenv’i hazırlıyorum.

    Sorunlar, Çözümler

    Bu yöntemde şimdiye kadar Windows ve MacOS kullanan geliştirici arkadaşlarda ciddi problem yaşamadık. Bazen sanal sunucunun internet erişiminin olmaması gibi sorunlar yaşadıysak da bir şekilde çözüldü. Fakat tuhaf bir şekilde Linux dağıtımı kullanan arkadaşlarda VirtualBox’un çalışmaması, paketlerin yüklenmemesi gibi sorunlar yaşadık ve onlar da provision script’lerini kendi yerel bilgisayarlarında çalıştırmayı tercih ettiler. Her zaman yaşanan sorunlar değildi; ama yaşandı mı uğraştıran sorunlardı. Diğer konulara değinecek olursak:

    1. Belli ve kurulumu denenmiş Vagrant ve VirtualBox sürümlerini kurulum belgemizde belirtmeye ve geliştiricilere de bu sürümleri kullanmalarını önermeye başladık.
    2. Mikro servisler için geliştirme ortamı hazırlamak monolitik yapıdaki projeler kadar basit olmayabiliyor. Örneğin sanal sunucumuzun içinde Docker kullanarak her bir mikro servis için bir container hazırlamak gerekebiliyor.
    3. Henüz denemedik ama provision script’lerinin bir kez çalıştırılıp, sanal sunucumuzu paketleyip, sonra bu paketi arkadaşlara dağıtmak sorunları biraz azaltabilir. Fakat bu durumda imajın boyutu artıyor ve birinin bu imajları oluşturmak için zaman ayırması gerekiyor.
    4. Değişikliklerin deploy edilmesi süreci kesinklikle geliştirme ortamının içinde değil, dışında olması gerekiyor. Geliştirme ortamının kolayca hazırlanması gibi, deployment ve test süreçlerinin de en baştan hazırlanması çok zaman kazandırır.