Category: Programming

  • How do I publish my articles?

    With just a command:

    # terminal
    $ ENV=PROD ./do.sh deploy

    I have many projects using my script named DOSH and the parameters are mostly in common; deploystartstopruntests, etc. It can be a .NET Core or a Django project, or just a website using any static site generator like this one but I run all the projects with the same command: dosh start.

    In Windows, the command may be a bit longer than in the other operating systems. So it’s a good idea to shorten the command using some aliases, the default environment is DEV:

    # ~/.bash_profile
    alias dosh="winpty bash do.sh"  # or just type "./do.sh" in Linux or MacOS.
    # terminal
    $ dosh start  # in DEV
    $ ENV=PROD dosh deploy  # in PROD, my deploy parameter works only in production.

    Do you use PowerShell? No problem, I think it’s better to do the same thing in PowerShell, you can find the sample codes below, but let me show you how I use that, it’s a bit different than BASH:

    # powershell
    ~\Workspace\website [master ≡]> $env:ENV = "PROD"
    ~\Workspace\website [master ≡]> dosh deploy
    Environment: production
    Deploying updates to GitHub...
    Building sites …
                       | EN | TR
    +------------------+----+----+
      Pages            | 13 | 67
      Paginator pages  |  0 |  0
      Non-page files   |  0 |  0
      Static files     | 63 | 63
      Processed images |  0 |  0
      Aliases          |  1 | 12
      Sitemaps         |  2 |  1
      Cleaned          |  0 |  0
    
    Total in 748 ms
    [master 1686121] rebuilding site 12/30/2018 15:02:32
     1 file changed, 3 insertions(+), 3 deletions(-)
    Enumerating objects: 9, done.
    Counting objects: 100% (9/9), done.
    Delta compression using up to 12 threads
    Compressing objects: 100% (4/4), done.
    Writing objects: 100% (5/5), 628 bytes | 628.00 KiB/s, done.
    Total 5 (delta 3), reused 0 (delta 0)
    remote: Resolving deltas: 100% (3/3), completed with 3 local objects.
    To github.com:gkmngrgn/gkmngrgn.github.io.git
       733793b..1686121  master -> master
    DONE.

    Code samples

    You can find many sample codes here to write a deployment script and I didn’t think of this idea first but still, I’m sharing my scripts to be an alternative:

    ./do.sh

    #!/usr/bin/env bash
    
    BLUE="\\033[1;34m"
    GREEN="\\033[1;32m"
    NORMAL="\\033[0;39m"
    RED="\\033[1;31m"
    
    print_help() {
        echo -e "${BLUE}Available environments${NORMAL}"
        echo "  - DEV (default)"
        echo "  - PROD"
        echo "  - STAGING"
        echo ""
        echo -e "${BLUE}Available commands${NORMAL}"
        echo -e "  > deploy [:message]      Deploy the changes"
        echo -e "  > start                  Run development server"
    }
    
    deploy() {
        case ${ENV} in
            "PROD")
                echo -e "${BLUE}Deploying updates to GitHub...${NORMAL}"
                ;;
            *)
                echo -e "${RED}This command only works in production.${NORMAL}"
                exit
                ;;
        esac
    
        if [ $# -eq 1 ]
        then msg="${1}"
        else msg="rebuilding site `date`"
        fi
    
        hugo
        cd public
        git add .
        git commit -m "${msg}"
        git push origin master
        cd ..
        echo -e "${GREEN}DONE.${NORMAL}"
    }
    
    start() {
        hugo server -D
    }
    
    if [ -z "$1" ]
    then
        print_help
    else
        case $ENV in
            "PROD")
                env_str="production"
                ;;
            "STAGING")
                env_str="staging"
                ;;
            *)
                env_str="development"
                ;;
        esac
        echo -e "${BLUE}Environment:${NORMAL} $env_str"
        "$@"
    fi

    ./do.ps1

    <# Variables #>
    if ($env:ENV -eq "PROD") {
        $env_str = "production"
    }
    elseif ($env:ENV -eq "STAGING") {
        $env_str = "staging"
    }
    else {
        if ($env:ENV -ne "DEV") {
            $env:ENV = "DEV"
        }
        $env_str = "development"
    }
    
    <# Functions #>
    function Get-Help {
        Write-Host -ForegroundColor Cyan "Available Environments"
        Write-Output "  - DEV (default)"
        Write-Output "  - PROD"
        Write-Output "  - STAGING"
        Write-Output ""
    
        Write-Host -ForegroundColor Cyan "Available commands"
        Write-Output "  > deploy [:message]      Deploy the changes"
        Write-Output "  > start                  Run development server"
    }
    
    function Start-Deploy ([string] $subParams) {
        if ($env:ENV -eq "PROD") {
            Write-Host -ForegroundColor Blue "Deploying updates to GitHub..."
        }
        else {
            Write-Host -ForegroundColor Red "This command only works in production."
            exit
        }
    
        if ($subParams -eq "") {
            $msg = "rebuilding site $(Get-Date)"
        } else {
            $msg = $subParams
        }
    
        Invoke-Expression "hugo"
        Invoke-Expression "cd public"
        Invoke-Expression "git add ."
        Invoke-Expression "git commit -m '$msg'"
        Invoke-Expression "git push origin master"
        Invoke-Expression "cd .."
        Write-Host -ForegroundColor Green "DONE."
    }
    
    function Start-Server () {
        Invoke-Expression "hugo server -D"
    }
    
    <# Set default parameter as help. #>
    if ($args.Length -eq 0) {
        $param = "help"
        $subParams = ""
    }
    else {
        $param, $subParams = $args
    }
    
    if ($param -ne "help") {
        Write-Host -ForegroundColor Cyan -NoNewLine "Environment: "
        Write-Output $env_str
    }
    
    <# We use switch instead of alias because there are some constant variables like `start`. #>
    switch ($param) {
        "deploy" { Start-Deploy $subParams }
        "start" { Start-Server }
        Default { Get-Help }
    }

    Don’t forget to set the alias in your config file, for example:

    # ~\Documents\PowerShell\profile.ps1
    $env:ENV = "DEV"
    Set-Alias dosh .\do.ps1
  • Important Windows Environment Variables

    PowerShell and Git encoding problems

    To make git log command output properly display on Windows, we need to set a variable named LC_ALL:

    LC_ALL="C.UTF-8"

    Incorrect home folder in Emacs

    This problem is not only about Emacs. If you try to find a file from HOME variable, you may need to define the variable first:

    HOME="%USERPROFILE%"
    ;; place all backup files in one directory
    (setq backup-directory-alist `((".*" . ,temporary-file-directory)))
    (setq auto-save-file-name-transforms `((".*" ,temporary-file-directory t)))
    (setq default-directory (concat (getenv "HOME") "/Workspace"))

    More..

    Take a look at the other posts about my Windows development environment.

  • 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.

  • Emacs’e Nereden Başlamalı?

    Emacs’e Nereden Başlamalı?

    Yazılım dünyasının en eski editörlerinden Emacs, günümüzdeki diğer popüler editörlerden farklı bir kullanma ve öğrenme disiplini istiyor. Bazı temel özelliklerini öğrenmeden editörde bir dosya açmak bile zor. O nedenle Emacs’in kendi içinde gelen tutorial’ını en azından bir kez okumak, öğrendiklerini uygulamak ve birkaç hafta sabırla kullanmak gerekiyor.

    Emacs Linux, Windows ve macOS işletim sistemlerinde çalışıyor. Yükleyip editörü açtığınızda ilk hali muhtemelen arzu ettiğiniz gibi görünmeyecek. Bir yandan Emacs’i öğrenirken, bir yandan da kendi zevkinize göre özelleştirmeye başlamanızı öneriyorum. İnternette yüzlerce Emacs config dosyası bulabilirsiniz, bazı kullanıcılar işi bir adım daha ileriye götürüp SpacemacsStarterKit gibi projelerle kullanıcıların ortalama ihtiyaçlarına göre hazır config dosyaları sunuyorlar. Deneyebilirsiniz; ama bana göre bu iyi bir başlangıç olmaz. Elinizde neredeyse her şeyi yapılandırabileceğiniz bir editör var ve bunu başkalarının zevklerine göre ayarlamak yerine, kendi ihtiyaçlarınızı tespit edip, bu ihtiyaçları başkalarının nasıl çözdüğüne bakarak kendi editörünüzü kendiniz yapılandırmanız daha doğru bir yaklaşım olur.

    Spacemacs’te Emacs’in görünümü bu şekilde.

    Emacs kendine özel bir Lisp yorumlayıcısıyla birlikte geliyor. Config dosyalarınızı bir Lisp script’i yazar gibi hazırlıyorsunuz. Daha önce hiç Lisp yazmadıysanız, buradan başlayabilirsiniz:

    https://learnxinyminutes.com/docs/elisp

    Config dosyası genellikle kullanıcı ev dizininizde ~/emacs.el veya ~/.emacs.d/init.el olarak saklanıyor. Yapılandırma dosyası hakkında daha fazla bilgi almak için okumaya buradan başlayabilirsiniz:

    https://www.gnu.org/software/emacs/manual/html_node/emacs/Init-File.html

    Belgeyi okuyup config dosyası hazırlamak gözünüzü korkutmasın, size açıklayarak küçük bir örnek göstereceğim. Benim config dosyam, önce paketleri kontrol etmek, eğer kurulmamış paket varsa da kurmakla başlıyor. Paketler, editöre ekstra özellik kazandıran kodlar içerir ve bunlar genellikle küçük dosyalardan oluşmazlar, örneğin HTML kodları, içinde CSS ve JavaScript kodu barındırdığında parse etmesi çok zordur, bunun için ek paket kurmak isteyebilirsiniz veya Emacs içinde bir git istemcisi kullanmak isteyebilirsiniz. Helm paketi ile Emacs komut satırını daha da güçlendirmek isteyebilirsiniz:

    (require 'package)
    (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t)
    (package-initialize)
    (when (not package-archive-contents) (package-refresh-contents))
    (defvar my-packages
      '(auto-complete
        flx-ido
        helm
        helm-ag
        helm-ls-git
        js2-mode
        magit
        markdown-mode
        scss-mode
        web-mode)
      "A list of packages to ensure are installed at launch.")
    (dolist (p my-packages)
      (when (not (package-installed-p p)) (package-install p)))
    Lisp

    Editörü kullandıkça bazı ihtiyaçlar ortaya çıkmaya başlıyor. Örneğin bir projede çok uzun süre çalışıp daha sonra başka bir projeye geçmek istediğimde arka planda açık olan tüm dosya yedeklerini silmek istiyorum. Bunun için `kill-other-buffers` adında bir fonksiyon yazdım ve bu fonksiyonu bir klavye kısayoluna atadım (Ctrl c, k):

    (defun kill-other-buffers ()
     “Kill all other buffers.”
     (interactive)
     (mapc ‘kill-buffer (delq (current-buffer) (buffer-list)))
     (message “All other buffers are killed..”))(global-set-key (kbd “C-c k”) ‘kill-other-buffers)
    Lisp

    Emacs’i olabildiğince sade kullanmaya çalışıyorum. O nedenle menüyü, açılış ekranını kaldırdım, imleç pozisyonunu satır uzunluğunu anlayabilecek şekilde yapılandırdım, fontumu değiştirdim, dosya kaydederken beyaz boşlukların otomatik silinmesini sağladım, parantezlerin otomatik kapatılması gibi birçok ayarı etkinleştirdim:

    (setq-default truncate-lines t)
    (setq inhibit-splash-screen t)
    (menu-bar-mode -1)
    (scroll-bar-mode -1)
    (tool-bar-mode -1)
    (setq visible-bell 1)
    (column-number-mode t)
    (set-face-attribute ‘default nil :font “Fira Code” :height 105 :weight ‘normal :width ‘normal)
    (ido-mode 1)
    (ido-everywhere 1)
    (flx-ido-mode 1)
    (setq ido-enable-flex-matching t)
    (setq ido-use-faces nil)
    (setq-default indent-tabs-mode nil)
    (electric-pair-mode 1)
    (add-hook ‘before-save-hook ‘delete-trailing-whitespace)
    (ac-config-default)
    Lisp

    Editörde dosya açarken, aynı dizinde geçici bir dosya oluşturulduğunu göreceksiniz. Bu dosyaların ortalıkta değil de, başka bir yerde tek bir dizin içinde saklanmasını sağlıyorum:

    (setq backup-directory-alist `((“.*” . ,temporary-file-directory)))
    (setq auto-save-file-name-transforms `((“.*” ,temporary-file-directory t)))
    Lisp

    Son olarak, normalde uzun satırları kırmayı sevmiyorum, tek satırda göstermesi benim için daha iyi; ama metin dosyaları hariç, onlarda uzun satırları kırıp satırbaşıymış gibi göstermesini sağlıyorum:

    (add-hook ‘markdown-mode-hook ‘visual-line-mode)
    (add-hook ‘text-mode-hook ‘visual-line-mode)
    Lisp

    40 yıllık editör için yapılandırmam bundan ibaret. Yapılandırmanızı ne kadar basit tutarsanız o kadar iyi. Eğer Emacs ile ilgileniyorsanız, aşağıdaki linklere de göz atın, istediğiniz zaman yorum yazıp bana soru iletebilirsiniz.

    Kaynaklar

    1. Bilgem Çakır, “Kullandığım Araçlar: Emacs”, https://youtu.be/qXw0ocR_XBI
    2. Üstün Özgür, “Emacs: Özgür Yazılım Devriminin Editörü”, https://youtu.be/FsN3Yp05_aQ
    3. Örnek config dosyası: https://github.com/gkmngrgn/emacs-config/blob/master/init.el
    4. Spacemacs projesi: http://spacemacs.org/
    5. Awesome Emacs: https://github.com/emacs-tw/awesome-emacs

  • İşletim Sistemi Tercihini Geliştiriciye Bırakın

    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:

    1. Geliştiriciden projeyi, kullandığı sistemin içine kurmasını talep etmek.
    2. Geliştiriciye GNU/Linux kullanmaya mecbur bırakmak.
    3. 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.