# Gökmen Görgen > Hello there. I'm a polyglot programmer, a former startup founder, and a car guy. My career started with contributing a Linux distribution called [Pardus](/2024/04/18/how-did-i-meet-pardus/). I worked as a software engineer on web projects for a long time. Now I'm busy with data engineering on artificial intelligence technologies, and try to be an indie developer. ## Posts ### Duymadan Duyabilmek > URL: https://gokmengorgen.net/tr/2025/12/03/duymadan-duyabilmek/ | Published: 2025-12-03 00:00:00 +0000 UTC | Categories: entertainment, lifestyle | Tags: işitme cihazı, duymak > "… Sonra seni hatırlıyorum. Birden zindanım aydınlanıyor. Kuşlar cıvıldıyor içimde. Yaşamak istiyorum." _Cemil Meriç, Jurnal Cilt 2_ --- Bazen kendimi kör insanların yerine koyuyorum. 30 yıl boyunca hiç görmemiş birisi olarak, diğer insanlar gibi görebilmeyi sağlayan bir teknolojiye sahip olmayı mı daha çok isterdim; yoksa görmeden de hayatımı kolaylaştırabilecek bir teknolojiye sahip olmayı mı? İşitme engelimin ilk farkına vardığımda, hep kulağımı tıkayan bir şey olduğunu, o şeyi çıkarınca herkes gibi duyabileceğimi defalarca arzuladığımı hatırlıyorum. Teşhisi koyan doktor, “Benimle bu kadar iyi konuşabildiğine göre senin çok iyi bir dudak okuyucu olman lazım; çünkü test sonucuna bakılırsa sen neredeyse sağırsın.” demişti. İlk işitme cihazı kullanmaya başladığımda, aklıma kuş cıvıltıları ile ilgili kitaplarda okuduğum metinler geldi. Babam bana roman ve şiir okuma alışkanlığı kazandırmıştı çocukken, kuş cıvıltısı ile ne kastediliyor pek anlamıyordum. Bilmiyordum çünkü. İşitme cihazımı takıp ilk duyduğumda dehşete kapıldım. Son derece rahatsız edici, kulak zarlarımı patlatacak, ürkütücü tuhaf sesler. O an anladım ki, meğer duymanın iki organı varmış. İnsan sadece kulakla değil; beyinle de duyarmış. Bir müddet parklarda kendimi bu sese maruz kalıp bu sesi nasıl yorumlamam gerektiği konusunda beynimi eğitmek için uğraştım. Bazen bir serçe ya da kanaryanın sesini duyduğumda sevecek gibi olsam da, hala bu sesin bende yaşama isteği uyandırdığını söylemem güç. Sadece empati kurabiliyorum. Bunca geçen sessiz bir hayattan sonra, işitme cihazlarının benim için yapabileceği en iyi şey, daha iyi bir amplificator olmak değil; sesi tanımlamak, onları duyabileceğim frekans veya desibellere dönüştürmek, filtrelemek, hatta yazıyla veya koluma dokunarak bana mesajı iletmek. Bu aynı zamanda, kendi yaş grubunda beklenen işitme sağlığına sahip insanlar için de hayat kalitesini artırabilecek bir teknoloji. Mesela bebek ağlaması ve çocuk bağırmasını filtreleyebilmek, arkadaşlarının ne dediğini anlayabilmek, güzel olmaz mıydı? Eskiden duyabilmeyi çok isterdim, ama yaşlandıkça kulaklarım daha da yıpranıyor. Şimdi, duymadan da yaşam kalitemi koruyabilmek ümidindeyim. ### Python'da Kurulması Kolay Uygulama Yapmak > URL: https://gokmengorgen.net/tr/2025/10/25/pythonda-kurulmasi-kolay-uygulama-yapmak/ | Published: 2025-10-25 00:00:00 +0000 UTC | Categories: software-engineering | Tags: python, pyapp, astral-uv, dosh, conda, pyinstaller, pyapp, nuitka, self-executable, self-contained Eskiden projelerde `do.sh` adında bir shell scripti kullanırdık. `Makefile` ile benzer işlevi görüyordu; ancak bu scriptte yeni fonksiyonlar yazmak, env değişkenlerini kullanmak gibi ekstra şeyler de yapıyorduk. Bütün fikir, `README.md` dosyasında neyi hangi komutlarla yapacağımızı belirtmek yerine, o komutları sırayla çalıştıran, komutların çalışması için gerekli kurulumları otomatik yapan veya sistem gereksinimlerini kontrol eden, çalıştırabilmek için sadece **Bash**'e ihtiyaç duyan bir script yazmaktı. Sonra ben bunu [DOSH](https://github.com/gkmngrgn/dosh) adında Python projesine çevirdim. Altyapı olarak hazır, ihtiyaç oldukça geliştirmeye, yeni özellikler eklemeye devam ediyorum. Bash yerine Lua syntax'ini kullanarak benzer scriptler hazırlayabiliyoruz. Fakat DOSH ile birlikte birkaç yeni problem ortaya çıktı: 1. **Sıfır bağımlılık kuralı.** Bash scripti olunca, MacOS ve Linux'ta (hatta WSL varsa Windows'ta), o scripti çalıştırmak için ekstra bir şey yüklemenize gerek yoktu. Bir Python uygulamasında bunu nasıl yapacağız? 2. **Sürekli geliştirme ihtiyacı.** İhtiyaç hiç bitmiyor. [yt-dlp](https://github.com/yt-dlp/yt-dlp/tree/master/yt_dlp/extractor)'de olduğu gibi herkesin özel bir amaç için bir yerinden tutup bir fonksiyon yazması gerekiyor ki projenin bir anlamı olsun. Örneğin ben blogumdaki resimlerin boyutunu küçültmek için tinypng kullanıyorum. Onun yerine `dosh compress-images` dediğimde, ya da deploy etmeden önce (`dosh deploy-blog`) önce otomatik olarak tüm imajların boyutunu sıkıştırabilmeyi isterdim. İkinci maddeyi bir kenara bırakıp, konumuza dönelim. _Bir Python projesinde sıfır bağımlılık kuralını nasıl sağlayabiliriz?_ Okumaya başlamadan önce başlıklara kabaca bir göz atmanızı öneririm. ## Ne Yapmak İstiyoruz? Kurulması kolay ve kullanabilmek için ek bir talimat gerektirmeyen bir uygulama yapmak istiyoruz. Yani uygulamayı çalıştırmak için [python.org](python.org) sitesine gidip Python indirmemeliyim. Biz buna **self-executable** diyoruz. Uygulamamız tek bir dosyadan ibaret olabilir, böylece indirmesi ve kurulması daha kolay olur; bir arşiv dosyası içinde birden fazla dosya ve dizinden de oluşabilir. İki yöntemin de birtakım avantajları ve dezavantajları var. Örneğin bizim ilk tercihimiz muhtemelen tek bir dosyadan ibaret uygulama dosyası indirmek olacak; ama komutu her çalıştırdığımızda o dosyayı parse etmesi, yorumlaması için zaman kaybedecek. Bir desktop uygulaması için bu zaman kayıpları belki gözardı edilebilir ama CLI uygulaması ise, milisaniyeler içinde de olsa başlangıçta beklemek bir noktadan sonra can sıkıcı olmaya başlayacak. Bir kavram daha var, **self-contained**. Bu yöntemde, adından da anlaşılacağı üzere, sadece interpreter değil, bağımlılıklarının da paketin içinde tutulduğu; sadece programın başlatılması için değil, tüm fonksiyonları ile çalışabilmesi için asgari tüm gereksinimlere sahip olması kastediliyor. Arada ince ama net bir fark var. Tekrar edelim, bir Python uygulamasını başlatabilmenin yolu, bir Python interpreterine sahip olmak. Ama bir de programın bağımlılıkları var, örneğin arayüz için Qt kullanıyorsanız ve siz bilgisayarınıza Qt ve Qt Python bağlayıcılarını kurmadıysanız, uygulama eksik bağımlılık nedeniyle çalışmayacaktır. "Ya madem interpreteri içine koydun, bağımlılıkları niye dahil etmez ki bir insan?" diye düşünebilirsiniz. Zaten Python'da paylaşımlı kitaplık (shared library) kavramı pek kullandığımız, ihtiyaç duyduğumuz bir şey değil. O daha çok C++, C#, Java gibi dillerde ihtiyaç olan bir durum. Belki denk gelmişsinizdir, bir oyun yüklersiniz Steam'den, sonra çalıştırmak istediğinizde "Microsoft Visual C++ 2015 Runtime" bla bla bileşenini yükleyin diye bir popup açılır ve oyun kapanır. O bir shared librarydır. Binlerce oyunun içine tek tek gömmek yerine siz onu bir kere yüklersiniz, bütün oyunlar artık aynı kitaplığı kullanarak çalışır. Bu gibi çok fazla ortak bileşen olunca oyun başına indirme maliyetini düşürmek açısından paylaşımlı kitaplıkları kullanmak mantıklıdır. Şimdi yönteme karar verelim. ## Hangi Yöntemi Tercih Etmeliyiz? Elimizdeki seçenekleri bir gözden geçirelim. Bütün seçenekleri Python özelinde değerlendireceğiz: ### İşletim Sistemlerinin Paket Yöneticilerini Kullanmak Windows'ta WinGet, MacOS'te Homebrew, Linux'ta... Ubuntu için .deb paketi, Fedora için .rpm, Arch Linux için AUR'da PKGBUILD, veya tüm distrolar için Flatpak, ya da Snap... Yazarken yoruldum. Tek bir uygulama için bu kadar emek harcamaya değer mi? Belki, sadece MacOS desteklememiz yeterli olsaydı mantıklı. Veya çok sağlam bir komuniteniz varsa herkes bir yerinden tutup tamamlar. Ama bir de bunların güncellenmesi, bakımının yapılması, otomasyonu var. Ayrıca, başta belirttiğim sıfır bağımlılık kuralını birazcık ucundan çiğniyor. MacOS için Homebrew paketini hazırladınız; ama kullanıcı Homebrew kullanmıyorsa ne olacak? Belki MacPorts kullanıyor, onun da mı paketini yapmalı? Yaptınız diyelim, repoya kabul edilmesi kolay olacak mı, ne kadar zaman alacak? Kısaca, mantıklı olduğu özel durumlar olabilir ama DOSH için hayır. Bu yöntem, self executable'a bir örnek. ### Python Paket Yöneticilerini Kullanmak Bazı uygulamalar amacı gereği bir Python interpreterinin sistemde kurulu olmasını gerektirebilir. Örneğin bir AI engineersiniz ve Anaconda kullanıyorsunuz. Benim uygulamam Anaconda kullanıcılarının kullanımına yönelik ise, bir [conda paketi](https://docs.conda.io/projects/conda-build/en/stable/user-guide/tutorials/build-pkgs.html) yapmak mantıklı olabilir. Diğer Python distrolarını desteklemek gerekirse PyPI'ya yüklemek daha mantıklı olabilir. Ben DOSH'u dilden bağımsız bir uygulama olarak tasarladığım için bu yöntem benim işime yaramadı. Ancak tek bir istisnası var. O da [astral-uv](https://docs.astral.sh/uv/). Uv, diğer Python paket yöneticilerinin kısmen yaptığı her şeyi tek başına yapabiliyor. Yani Python interpreteri yüklemeden, hatta uygulamanızı da öncesinde kurdurmadan uygulamanızı denettirebilirsiniz. Sadece iki adım: 1. Uv'u kur. 2. Bu komutu çalıştır: `uvx ` Oldukça basit, tek ihtiyacınız olan şey, uygulamanızın [PyPI](https://pypi.org/)'da olması. Bu yöntem ne bir self-executable, ne de self-contained örneği. Çünkü interpreter'i yüklüyoruz, ve onun paket yöneticisiyle bağımlılıklarını yüklemeye çalışıyoruz, veya sadece `uv` yüklüyoruz. ### Zipapp Açıkçası ben self-contained bir uygulamanın aynı zamanda self-executable olmasını bekliyorum ama [zipapp](https://docs.python.org/3/library/zipapp.html) biraz bunun dışında kalan bir yöntem. Bir interpreter kurulumuna ihtiyacınız var; ama hiçbir bağımlılık kurmanıza gerek yok. Çünkü zipapp sayesinde tüm bağımlılıkların içinde olduğu bir arşiv paketi oluşturuyorsunuz. Bu ne zaman işe yarar? İlk aklıma gelenler: 1. Şirket içinde kullandığınız, PyPI'ya gönderemediğiniz, ama CodeArtifact gibi registry sistemlerle uğraşmak istemediğinizde. 2. Basit projeler için Docker containerization ile uğraşmak yerine sadece uygulamayı paketleyip deploy etmek istediğinizde. 3. Veya on-premise bir servis için code obfuscation sürecinin bir parçası olarak kullanabilirsiniz. Ne kadar işe yarayabilir, araştırmak gerek. Kısacası, bu yöntemin de mantıklı olduğu alanlar var; ama DOSH için hayır. ### PyInstaller, Nuitka, PyApp, ve Diğerleri Son seçenek olarak, sıfır bağımlılık ve kullanıma hazır paketler hazırlamak için yapılmış uygulamaları değerlendirelim. Niye en baştan bunlara bakmadık; çünkü hem göründükleri kadar kolay değiller, ekstra efor ve bakım gerektiriyor, hem de "there's no silver bullet.", yani diğer seçenekler gibi bunların da hiçbiri bir problemi tam olarak çözmüyor. Benim tavsiyem, mümkün mertebe diğer basit seçeneklerle sorunu çözmeye çalışmak, onlar işe yaramadığında PyInstaller gibi araçların sorunu çözeceğine kendimizi ikna etmek. Bunların her birinin farklı bir yaklaşımı ve önceliği var. Tek dosya veya tek dizin haline getirebilirsiniz. Sadece self-executable haline getirip bağımlılıkların sonradan kurulmasını sağlayabilirsiniz. Veya tamamen offline çalışabilecek bir kurulum paketi haline getirebilirsiniz. Bunların bir kısmı executable path'e otomatik eklendiği için direkt komuta erişebilir hale geliyor; bir kısmı için dizini veya dosyayı doğru path'e taşımanız gerekebilir. Hatta bir kısmı da code obfuscation problemlerini kendisi çözebiliyor, eğer kodun gizliliği ile ilgili kaygınız varsa tercih sebebi olabilir. Ama her seçeneğin bir dezavantajlı noktası var. Tek dosya yapınca performans düşüyor, sadece executable yaparsanız bağımlılıkları yüklemek için internete bağımlı oluyorsunuz vesaire. ## Ben Nasıl Yaptım? DOSH, zaten internete bağımlı bir uygulama olduğu için self-contained olmasını önemsemedim. Tek istediğim, hiç Python bilmeyen birisinin bile kurup kullanabileceği bir uygulama yapmak. [PyApp](https://ofek.dev/pyapp/latest/) CLI performansı ve oluşturulan paketin boyutu konusunda bana göre en iyisiydi ve onu tercih ettim. Önce, executable dosyanın oluşturulabilmesi için bir BASH scripti yazdım: ```bash export PYAPP_PROJECT_NAME="dosh" export PYAPP_PROJECT_PATH="$(find $(pwd)/${{ inputs.dist-path }} -name "dosh*.whl" -type f | head -1)" echo "Packaging DOSH binary: ${{ inputs.dosh-binary-name }}" echo "Using wheel: ${PYAPP_PROJECT_PATH}" # download pyapp source code, build it curl https://github.com/ofek/pyapp/releases/latest/download/source.tar.gz -Lo pyapp-source.tar.gz tar -xzf pyapp-source.tar.gz mv pyapp-v* pyapp-latest cd pyapp-latest cargo build --release # and rename the binary mkdir -p ../${{ inputs.output-path }} mv target/release/pyapp "../${{ inputs.output-path }}/${{ inputs.dosh-binary-name }}" chmod +x "../${{ inputs.output-path }}/${{ inputs.dosh-binary-name }}" echo "Binary packaged successfully at ${{ inputs.output-path }}/${{ inputs.dosh-binary-name }}" ``` Sonra, bu scripti GitHub Actions'ta, her yeni sürüm çıkardığımda otomatik olarak Linux (x86_64, arm64), MacOS (Apple Silicon), Windows (x86_64) platformlarında çalıştırmak için [action](https://github.com/gkmngrgn/dosh/blob/main/.github/actions/package-dosh/action.yml) olarak tanımladım. Workflow'un tamamını [buradan](https://github.com/gkmngrgn/dosh/blob/main/.github/workflows/release.yml) bulabilirsiniz, sadece Linux'tan örnek gösteriyorum: ```yaml package-on-linux-arm64: runs-on: ubuntu-24.04-arm needs: - build steps: - uses: actions/checkout@v4 - uses: ./.github/actions/package-dosh with: dosh-binary-name: dosh-linux-arm64 dist-path: dist output-path: bin ``` Ben her sürüm tagı eklediğimde bu workflow çalışacak, binaryleri oluşturacak ve bu dosyaları artifact olarak saklayacak. Bu arada binary boyutlarına aldanmayın, PyApp ile bir uygulamayı paketlediğinizde, uygulamayı ilk çalıştırırken bootstrap ediyor, dolayısıyla en azından ilk kez çalıştırmak için internete bağımlılığınız var. Ama benim için kabul edilebilir bir dezavantaj: ![](/images/dosh-github-actions.png) Bir sonraki adım olarak, bu build edilmiş executable dosyaların son kullanıcının kullanımına açık olması için GitHub Release'da yayımlayacağız: ```yaml - uses: ncipollo/release-action@v1 with: artifacts: "dosh-*/dosh-*,release-dists/*" ``` ![](/images/dosh-github-release.png) Artık uygulama, son kullanıcıya açık! İndirip kullanabilirler. Bu bir CLI uygulama olduğu için, biraz daha pratiklik sağlamak için [`install.sh`](https://github.com/gkmngrgn/dosh/blob/main/install.sh) ve [`install.ps1`](https://github.com/gkmngrgn/dosh/blob/main/install.ps1) scriptleri oluşturdum. Böylece `README.md` dosyasında, kullanıcılara terminalden yükleme yapmalarını tavsiye ediyorum: ```shell sh <(curl https://raw.githubusercontent.com/gkmngrgn/dosh/main/install.sh) ``` Windows kullanıcıları için: ```powershell iwr https://raw.githubusercontent.com/gkmngrgn/dosh/main/install.ps1 -useb | iex ``` Aynı workflow'da ikinci bir seçenek olarak, paketi PyPI'ya gönderiyorum. Basit ve yedek bir kurulum alternatifi olarak kullanıcıya pip veya uv ile kurma şansı bırakıyorum: ```yaml - name: Publish release distributions to PyPI uses: pypa/gh-action-pypi-publish@release/v1 with: packages-dir: release-dists/ ``` ```shell $ alias dosh="uvx --from dosh-cli dosh" $ dosh ``` Artık yapısal bir değişiklik olmadığı müddetçe, bir daha paketleme için efor sarfetmeme gerek kalmadı. ## Son Söz Paketleme yönteminizi seçerken, eğer kapalı kaynak kodlu bir proje geliştiriyorsanız, lisansları ve code obfuscation konusunu da göz önünde bulundurmanız gerekiyor. Umarım bu sorunla uğraşanlar için yol gösterici olmuştur. DOSH henüz bitmiş veya kullanıma hazır bir proje değil; ancak ilginizi çekerse katkılarınızı bekliyorum. Yorumlarınız için bana sosyal medya veya email üzerinden ulaşabilirsiniz. ### En Zevksiz Otomobiller Dönemindeyiz > URL: https://gokmengorgen.net/tr/2025/10/19/en-zevksiz-otomobiller-donemindeyiz/ | Published: 2025-10-19 00:00:00 +0000 UTC | Categories: family | Tags: automobile, tesla, electric-vehicle Bu yazıyla belki bir sonraki otomobilinizi seçerken tercihlerinizi etkileyebilirim. Kararsız olanların hızlı karar vermesine, kararlı olanların da doğru karar verdiklerine emin olmalarını sağlamak istiyorum. Çok zevksiz otomobillerin olduğu bir dönemdeyiz. Arada güzel şeyler çıksa da fiyat/performansı, ülkenin durumu, teknolojik gelişmeleri göz önünde bulundurduğumuzda sevdiğimiz otomobili satın almaktan vazgeçmek zorunda kalabiliyoruz. Otomobil en nihayetinde bir ulaşım aracı; ancak hayatınızın belli bir kısmı onun içinde geçtiği için, zamanınızı ve maddi durumunuzu da etkilediği için, ulaşım dışında başka beklentileriniz oluyor. Sessizlik, konfor, güç, dayanıklılık, ucuzluk, belki de prestij... Ancak beklentinizin genel beklenti sınıflamalarına veya o dönemin modasına uygun olması gerekiyor. Beklenti sınıflaması diye bir kavram var mı bilmiyorum, belki istem mekanizması demeliyiz. Ama neyi kastettiğimi anlatmak için Çetin Altan'ın **Limonata ve Rafadan Yumurta** yazısından alıntı yapacağım. O yazıyı bulup mutlaka okumanız gerekiyor. Ben şu kısma çok takıldım, diyor ki; iyi bir rafadan yumurta yapmak için, yumurta biçiminde ve yumurta büyüklüğünde, kapağı vidalı çelik bir kaba ihtiyaç var. Peki bu kabı nereden bulacağız, şöyle yazıyor: > Hiçbir yerde bulamazsınız. Neden? Çünkü o kabın üretilmesi, genel istem mekanizmasıyla ilgilidir. Kimse yaşam zevkini, enfes bir rafadan yumurtaya kadar bile inceltmemişse, öyle bir kap bulunmaz. Bu da ultra süper bir zenginlik sorunu değil, bir yaşam sevgisi sorunudur. Şimdi burada biraz durup düşünelim. Şöyle dediğiniz oldu mu, ya bu station wagonlar, kombiler güzeldi, çok işlevseldi, ne oldu da şimdi bulması zor? İşte o alıntıladığım yazı bunu bence iyi anlatıyor. Örnek veriyorum SUV'lar (Sport Utility Vehicles); önceleri yerden yükseltilmiş, arazi koşullarına uyum sağlayan, gerektiğinde asfaltta hız yapabilen araçlarken, şimdi bu saydıklarımın hiçbirisini tam olarak yerine getiremeyen modeller piyasayı domine ediyor. Eskiden MPV'lar (Multi-Purpose Vehicle) vardı, SUV'un her özelliğini taşımasa da en azından birkaç özelliğini çok daha iyi yerine getirirdi. Daha fazla yolcu veya bagaj alabilir veya koltukları yatırıp kamp yapmak amaçlı kullanabilirdiniz. Şimdi kalmadı mı böyle alışkanlıklarımız, zevklerimiz? Elbette bizde de değişiklikler oldu, ama otomobil firmaları da artık eskisi gibi otomobil satmak için uğraşmıyorlar. İstem mekanizması yerine kar maksimizasyonuna odaklandılar. Tırnak değse çizilen "piano black" tasarımlar, fake difüzorler, fake egzoz çıkışları; fiziki butonların, mekanik viteslerin kaldırılıp, yerine ortaya kocaman bir tablet konulması, vs.. Ve biz bunu satın aldık. Hepsi bir anda olmadı; ama ufak ufak alıştırdılar. Bu nedenle "artık müşteri böyle talep ediyor." düşüncesine katılmıyorum. Otomobil firmaları artık eskisi gibi istem mekanizmalarımıza hitap eden otomobil yapmak konusunda becerikli değiller. Peki ne yapacağız? Bence birinci adım, eğer uzun zamandır tek marka veya ekol tercihiniz varsa, sadakati bırakmanın zamanı geldi. Onlar geldikleri ekolü temsil etmek konusunda sizin kadar istekli değillerse, sizin de sadakatinizin çok bir önemi yok. Vazgeçebilirsiniz, onların rakip belledikleri markalara bakabilirsiniz. Aracınızı yenilemek istediniz, eskisinde olan anahtarsız çalıştırma, otomatik klimayı almak için ekstra para mı istiyorlar? Fiziki butonları mı kaldırdılar? Tepkinizi göstermek için güzel bir fırsat. İkinci adım, bir tercihiniz olsun ama fanatizmden uzak durun. Başkalarının tercihlerine de fazla anlam yüklemeyin. Bunun için SWOT analizi tekniğini kullanabilirsiniz. Bütçenize ve kriterlerinize uygun birkaç marka ve modeli dört kutucuktan birine yerleştirin, hangisi özellikler sizin için daha önemli ise onlara odaklanın. ![](/images/cars_swot.drawio.png) Üçüncü adım, yaptığınız tercihlere büyük anlamlar yüklemeyi bırakın. Örneğin Tesla veya herhangi Çin markası elektrikli araç tercih ettiniz. SWOT analizine bakarak zaten bu markaların satış sonrası desteklerinin Türkiye'de çok zayıf olduğunu bilerek satın aldınız, bu konuda daha fazla kendinizi memnun etmeye çalışmayın. Önleminizi alın, umarım kaza olmaz ama olursa da servis yetersizliği ile karşılaşabileceğinizin bilincinde olun. Satış sonrası destek sizin için önemli ve bu yüzden Toyota seçtiyseniz, aracın performansı için kendinizi yalandan avutmanıza gerek yok. Uzun ömürlü olsun istediyseniz, konfor konusunda Japon otomobillerini Alman otomobilleriyle kıyaslamayı bırakın (bir Lexus değilse tabi). Son olarak, şu sıralar kaçınılmaz gibi gözüken bir elektrikli araç dönüşümü söz konusu. Gözümüzü kulağımızı tamamen kapatmak yerine, istem mekanizmamızı tekrar devreye alıp, otomobil markalarına bizim nasıl bir otomobil beklediğimizi tercihlerimizle, tepkilerimizle anlatmamız gerekiyor. Yoksa gittikçe hepsi birbirinin kopyası olacaklar. ### Işın İzlemeyi GPU Sunucusunda Çalıştırmak > URL: https://gokmengorgen.net/tr/2025/10/10/isin-izlemeyi-gpu-sunucusunda-calistirmak/ | Published: 2025-10-10 00:00:00 +0000 UTC | Categories: software-engineering, artificial-intelligence | Tags: python, rust, nvidia, cuda Birkaç yıl önce ışın izlemeyi daha iyi anlayabilmek için [Ray Tracing in One Weekend](https://raytracing.github.io/books/RayTracingInOneWeekend.html) kitabını okudum. Orijinal kod örnekleri C++ ve ben okudukça Python'a çevirip yazıyordum. Evet, korkunç bir fikir olduğunu baştan biliyordum; ama merak. Python'un performans açısından yetersizliğini en iyi gözlemleyebileceğiniz yöntemlerden biri, ışın izleme algoritmasını, genişliği 1000 pixel olan resim üreterek test etmektir. Fakat 300 pixel bile epey zaman alıyor. Dolayısıyla ya interoperability, ya multiprocessing, ya da GPU kullanımı gibi alternatif çözümlere başvuruyorsunuz. Bu da ışın izlemeyi öğrenirken beraberinde çözmem gereken eğlenceli ve ekstra bir iş olarak karşıma çıktı. Kod [GitHub reposunda](https://github.com/gkmngrgn/rayt), indirip terminalden kullanabilirsiniz. Aynı zamanda [Hugging Face Spaces](https://huggingface.co/spaces/goedev/rayt-web) üzerinden deneyebilirsiniz; ancak GPU'yu aktif etmek için repoyu forklayıp GPU'nun olduğu bir sunucuda çalıştırmanız gerekiyor. Benim bu çalışmayla ilgili paylaşmak istediğim birkaç konu var: 1. Dünyanın en popüler dillerinden biri olan Python neden yavaş? 2. Hugging Face sunucusunda Rust kodu çalıştırabilmek, cross-compilation. 3. CUDA'yı anlamak, GPU'yu backend projelerinde kullanmak. 4. Buradaki bilgileri bir şablon olarak göz önünde bulundurmak. ## Python Neden Yavaş? Aslında cevabı basit: Python yorumlamalı (interpreted) bir dil. Makineyle dil arasında bir yorumlayıcı var ve dil odaklı yapabileceğin optimizasyonlar limitli. Örneğin yorumlayıcının en büyük getirisi olan GIL (Global Interpreter Lock), C/C++ gibi dillerde manual olarak yapılan birçok işi otomatik yaparak hem kodun okunurluğunu sağlayıp hem de esas işe odaklanmanıza yardımcı olurken, diğer taraftan CPU'nun tüm performansından yararlanmanıza engel olur. Işın izlemede pixel sayısı arttıkça, for döngüleri artıyor ve her döngüde nesnelerin oluşturulması, algoritmanın çalışması, hafızanın temizlenmesi gibi maliyetler katlanarak artıyor. Bir de çoğu Python programcısının sıkça duyduğu şey var: "Python'da neredeyse her şey bir objedir.". Yani C++'ta bulunan temel veri tipleri ile Python'daki int, string aslında birebir aynı şeyler değiller. Peki performans konusu Python'da bu kadar umutsuz vaka mı? Tamamen ne beklediğimize ve ne ile tatmin olabileceğimize bağlı. Bir kere ışın izleme için CPython yorumlayıcısını kullanmanın kötü bir tercih olduğunu baştan kabul etmek lazım. Ama dediğim gibi biz ürün odaklı bir şey yapmak yerine merak gidermek ve ileride benzer bir şeye muhtaç kaldığımızda neler yapabildiğimizi görmek istiyoruz. İlkiyle başlayalım, **diller arası birlikte çalışabilirlik**. ## Python - Rust Birlikte Çalıştırabilirlik Biliyorum, ilk akla gelen çözüm aslında multiprocessing olmalıydı. Ama Peter Shirley'in C++ kodunda da bununla ilgili herhangi bir şey yok, zaten gerek de yok. RAYT ilk yazmaya başladığımda pure Python'du, tek CPU çekirdeği ile ve korkunç derecede yavaş çalışıyordu. Multiprocessing'in beklediğim iyileştirmeyi vereceğinden emin değildim; ama interoperability'nin mutlak bir katkısı olacağından emindim. Tek sıkıntı, Python dışında seçeceğimiz yardımcı dili öğrenmemiz gerekiyor. Peki küçük bir soru: Madem başka bir dilden destek alacağız, neden sadece o dilde yazmıyoruz? Motivasyonumu ara sıra hatırlatmama izin verin. Benim amacım, ışın izleme yazmak değil. O onlarca dilde, farklı geliştiriciler tarafından defalarca yazıldı zaten. Benim amacım, çalıştığım herhangi bir Python projesinde bir performans problemini çözmek zorunda kaldığımda neler yapabilirimin cevaplarını aramak. İlk önce, hazırda C++ kodu varken [pybind11](https://github.com/pybind/pybind11) ile Python'da çalıştırılabilir hale getirmeyi düşündüm. Ama sonra paketlemede, bağımlılıkların yüklenmesinde, cross-compilation yapabilmek için Rust'ta daha az efor sarfedeceğimi düşündüm. Bu arada Python'un paket yöneticilerinin ne kadar başarısız olduklarını hep başkaları kullanırken fark ediyorum. Conda içinde pip kullanmalar, pyenv ile poetry kullanmalar, `pyproject.toml` dosyasına sahip olup paketleri yüklemek için `requirements.txt` kullanmalar. Tam bir kaos; ama suç paket yöneticilerinde. Her neyse, bu konuya girmeyeceğim, şu anda daha iyisi gelene kadar [uv](https://docs.astral.sh/uv/) bana göre en iyisi ve Rust interoperability desteği çok iyi, ne de olsa kendisi de Rust ile yazılmış bir Python aracı: ```shell uv init --build-backend maturin rayt-rust ``` Bu sihirli komut, Rust kodunu Python'da kullanabilmeniz için gerekli dosyaları ve dizin yapısını sizin için oluşturuyor: ``` rayt-rust └── src └── lib.rs └── rayt_rust └── __init__.py └── _core.pyi └── README.md └── Cargo.toml └── pyproject.toml 2 directories, 6 files ``` Rust kodu `src/` dizininde olacak, bağımlılıklar `Cargo.toml` dosyasına yazılacak. Kabaca bu kadar, `uv build` komutunu çalıştırdığımızda `rayt_rust` paketi Python'da kullanıma hazır hale gelecek. Fakat bir sorun var, yine motivasyonumuza geri dönecek olursak, bizim amacımız bütün kodu Rust ile yazmak değil; sadece performans açısından kritik olan kısmı Rust'a taşıyıp, geri kalanı Python'da tutmak. Bunun da iki yolu var: 1. Performans kritik kısımlar için ayrı bir kütüphane hazırlayıp, Python projesine bağımlılık olarak kurmak. 2. Tüm modülleri tek bir paket içinde barındırmak. Ben RAYT için ikincisini seçtim. `src/` dizininde `rayt/` ve `rayt_rust/` adında iki farklı dizinin olmasının sebebi budur. Böylece `uv run one-weekend` komutunu çalıştırdığımda, Rust kodu otomatik olarak build edilmiş ve kullanıma hazır hale geliyor. Ancak birinci seçeneğin örneğini de Hugging Face sayfasında göstereceğim. ## RAYT'i Hugging Face Spaces'te Kullanmak [Gradio](https://www.gradio.app/), ML modelleri için web arayüzü hazırlamanızı sağlayan basit ve kullanışlı bir Python kütüphanesidir. Hugging Face Spaces ise Gradio'yu çalıştırabileceğiniz, GPU desteği olan, benzer pratiklikte bir servis. Şimdi GPU kısmını bir kenara bırakalım ve basit bir web arayüzü ile RAYT'ı çalıştıralım. Gradio ile yapılmış web uygulamasını [buradan](https://huggingface.co/spaces/goedev/rayt-web) deneyebilir, kaynak kodlarını inceleyebilirsiniz, dikkatinizi ilk çekmek istediğim şey `requirements.txt` dosyası: ```requirements.txt gradio numba-cuda[cu13] https://huggingface.co/spaces/goedev/rayt-web/resolve/main/rayt-0.1.0-cp310-abi3-manylinux_2_34_x86_64.whl ``` Hem yerelde, hem HF Spaces'te çalışabilmesi için gerekli tüm bağımlılıkları yazdım. RAYT bir link olmak zorunda, çünkü sanırım deployment sırasında HF Spaces `requirements.txt` dosyasını farklı bir dizine kopyalıyor ve `.whl` dosyasını bulamıyor. Repo dışarıya açık olduğu için ilk aklıma gelen çözüm bu oldu, bir diğer çözüm kendi Dockerfile dosyanızı hazırlamak. İkinci sorun, RAYT artık derlenebilen bir kitaplık olduğu için, hangi Python sürümünü kullandığınıza, hangi işletim sistemi için derleyeceğinize dikkat etmeniz gerek. HF Spaces varsayılan olarak Python 3.10 ve Linux kullandığı için ona göre geliştirme ortamı hazırlamanız gerekiyor. Normalde yerelde RAYT'ı test etmek için [rustup](https://rustup.rs/) (Rust ve cross-compilation için) ve [uv](https://docs.astral.sh/uv/) (Python için) kurmanız, sonrasında bu adımları takip etmeniz yeterli: ```shell gh repo clone gkmngrgn/rayt && cd rayt uv build ``` Yanlış bilmiyorsam rustup, ilk kurulduğunda gerekli olan [target](https://rust-lang.github.io/rustup/cross-compilation.html)'i, kullandığınız platforma göre yüklüyor. Yerelde RAYT CLI kullanmak istediğinizde sorun yok; HF Spaces için özel bir build almanız gerekiyor. Interoperability için Rust seçmemin bir nedeni de bu, C++ kodunu WASM'de çalıştırmak için attığım taklaları düşününce, Maturin'in sağladığı konforun daha iyi farkına varıyorum. Şimdi doğru target'i yükleyip, build etmeyi deneyelim: ```shell rustup target add x86_64-unknown-linux-gnu uv tool install maturin uvx maturin build --target x86_64-unknown-linux-gnu ls target/wheels/ ``` ```shell rayt-0.1.0-cp310-abi3-manylinux_2_34_x86_64.whl ``` Güzel, Python distrosu CPython, versiyon 3.10, işletim sistem Linux, işlemci mimarisi x86_64. Alles gut. Şimdi bunu web uygulamamızda kullanabiliriz. Bu basit bir şablon proje olduğu için olabildiğince kompleksiteden kaçınıyorum. Her projenin ihtiyaçları, tercih edilen araçlar farklı farklı olduğu için. Normalde bu iş, DevOps sürecinin bir parçası olmalı; yeni sürüm çıktığında build işlemi CI/CD sunucularında başlamalı, artifactlar CodeArtifact gibi bir servise yüklenmeli, web projeleri paketleri bu servisten kurabilmeli vesaire. Repo ile ilgili ikinci dikkat çekmek istediğim şey `.gitattributes` dosyaya bakalım: ```.gitattributes *.parquet filter=lfs diff=lfs merge=lfs -text *.pb filter=lfs diff=lfs merge=lfs -text *.pickle filter=lfs diff=lfs merge=lfs -text *.pkl filter=lfs diff=lfs merge=lfs -text *.pt filter=lfs diff=lfs merge=lfs -text *.pth filter=lfs diff=lfs merge=lfs -text *.rar filter=lfs diff=lfs merge=lfs -text *.safetensors filter=lfs diff=lfs merge=lfs -text saved_model/**/* filter=lfs diff=lfs merge=lfs -text *.tar.* filter=lfs diff=lfs merge=lfs -text *.tar filter=lfs diff=lfs merge=lfs -text *.tflite filter=lfs diff=lfs merge=lfs -text *.tgz filter=lfs diff=lfs merge=lfs -text *.wasm filter=lfs diff=lfs merge=lfs -text *.xz filter=lfs diff=lfs merge=lfs -text *.zip filter=lfs diff=lfs merge=lfs -text *.zst filter=lfs diff=lfs merge=lfs -text *tfevents* filter=lfs diff=lfs merge=lfs -text *.whl filter=lfs diff=lfs merge=lfs -text ``` Büyük dosyaları repoda tutmak iyi bir fikir değil. Örnek vermek gerekirse, bazen projelerde çalışmak için bu dosyalara ihtiyaç yoktur, bu dosyaların boyutu arttıkça repoyu clonelamak gereksiz zaman alır. [Git LFS](https://git-lfs.com/), [Xet](https://xethub.com/), [DVC](https://dvc.org/), bu sorunu çözmek için kullanılan araçlardan bazıları. 304 kb'lik bir pakette bu çok büyük bir problem olmayabilir ama şirket projelerinde önlemi baştan almanızda yarar var. Peki `.gitattributes` nasıl oluşturuluyor? Öncelikle `git-lfs` yüklemeniz gerekiyor: ```shell git lfs install git lfs track *.whl git add .gitattributes ``` Bundan böyle `*.whl` dosyası commitleyip pushladığınızda, LFS bu dosyayı ayrı bir storage'de tutacak. Bir web projesinde, Rust ile yazılmış Python kitaplığını nasıl kullanacağımızı artık biliyoruz. ![RAYT HF Arayüzü](/images/rayt-hugging-face.png) ## Rust, RAYT'ın Performans Problemini Çözdü mü? Bir C++ kadar hızlı değil, hatta tamamen Rust ile yazılmış bir CLI kadar bile hızlı değil muhtemelen. Ama, Python'dan katbekat hızlı. Performans problemini büyük ölçüde çözdü diyebiliriz; peki ya bir GPU kullanmak istersek? Hem Rust interoperability, hem Rust üzerinden GPU'ya erişim?? Yok bekle, o kadar değil, o kadar vaktim yok. Ama muhtemelen onu da yapmak mümkün, sunucuda CUDA destekli bir GPU varsa, neden olmasın? Ama Rust'i şimdilik bir kenara bırakalım ve başka bir konuya odaklanalım. Python kodu yazarak, CPython kullanarak, GPU'nun gücünden yararlanabilir miyiz? Bunu yapmanın eminim birden fazla yolu vardır; ben Numba ile denedim. ## Numba ve Numba CUDA - [Numba](https://numba.pydata.org/), LLVM derleyici kütüphanesini kullanarak Python kodunu runtime aşamasında optimize edilmiş makine koduna çevirip CPU'da çalıştırılmasını sağlayan (başka nerede çalışacak?) bir Just-In-Time (JIT) derleyicidir. - [Numba CUDA](https://nvidia.github.io/numba-cuda/), Python kodunu PTX koduna (Parallel Thread Execution) çevirip CUDA GPU çekirdeklerinde çalışmasını sağlayan bir ek pakettir. - [CUDA](https://developer.nvidia.com/cuda-toolkit) (Compute Unified Device Architecture), bizim NVIDIA'nın grafik işlem birimlerinin (GPU) muazzam işlem gücünü, GPGPU olarak bilinen genel amaçlı hesaplamalar için kullanmamıza olanak tanıyan bir platformdur. Özetle, Numba'yı bir JIT Compiler, CUDA'yı bir target olarak düşünebilirsiniz. RAYT'ı Rust ile yeniden yazmamızdaki aynı temel motivasyonu içerir. Fakat Numba CUDA kullanmak için başka bir programlama dili öğrenmeye ihtiyacınız yok, sadece CUDA mimarisinin nasıl çalıştığını bilmemiz gerekiyor, onun dışında GPU memory allocation/deallocation için bile hiçbir şey yapmanıza gerek yok. Fakat Numba CUDA'nın iki dezavantajı var: 1. JIT compilerların ilk çalıştırmada kod çeviri ve derleme için bir bekleme süresi olur. Toplam süreyi düşündüğünüzde gözardı edilebilir bir süre. 2. Tahmin edebileceğiniz gibi grafik ekran kartına, ekran kartını kullanabilmek için driverlara ve CUDA'yı kullanabilmek için ek paketlere ihtiyacınız var. Şimdi tekrar RAYT koduna geri dönelim ve Rust dışında diğer seçenekleri gözden geçirelim. Kod tekrarlarını biraz önlemek için, kritik olduğunu düşündüğüm bazı fonksiyonları Numba'ya taşıyıp, geri kalan kısmı için Rust kodunu kullanmaya devam ettim, ama farz edin bunda Rust kodu hiç yok ve sadece Numba kullandık, gerçek bir projede ikisine birden ihtiyaç olacağını pek sanmıyorum. Her ne kadar sadece Python kodu yazıyor olsak da, bazı kısıtlar mevcut: - `try - except` kullanamıyoruz. - Context management (`with`) yok. - Generator yok. - list, dict, set ile yapılan comprehensionlar yok. - Debugging biraz sandığımızdan farklı yapılıyor. - En kötüsü, typing desteği kısıtlı ve biraz alışılmışın dışında. Ama NumPy kullanabiliyoruz ve bunun önemini şöyle anlatayım: Siz CPython kullanacaksınız, sizin belli veri tiplerinde Python'da tanımladığınız değerleriniz olacak ve bunları NumPy arraylarına dönüştürerek Numba fonksiyonlarına parametre olarak iletebileceksiniz. Aynı şekilde, bu fonksiyonların döndürdüğü değerleri yine NumPy array olarak geri alabilecek veya fonksiyonlar arasında birbirlerine gönderebileceksiniz. Bunu nasıl yaptığımı anlayabilmek için en güzel örnek `_prepare_scene_data` metodu: ```python import numpy as np import numpy.typing as npt from rayt_rust._core import Camera, HittableList, get_color, Color from rayt.numba_optimized import render_pixel_numba class NumbaRenderer: """Numba-optimized ray tracer renderer""" def __init__(self) -> None: self.spheres_data: npt.NDArray[np.float64] | None = None self.materials_data: npt.NDArray[np.float64] | None = None self.camera_data: npt.NDArray[np.float64] | None = None def _prepare_scene_data(self, world: HittableList, camera: Camera) -> None: """Convert scene objects to NumPy arrays for Numba""" # Sphere data: [center_x, center_y, center_z, radius] self.spheres_data = np.array(world.get_sphere_data(), dtype=np.float64) # Material data: [type, param1, param2, param3, param4] # Type 0: Lambertian [type, albedo_r, albedo_g, albedo_b, unused] # Type 1: Metal [type, albedo_r, albedo_g, albedo_b, fuzz] # Type 2: Dielectric [type, ref_idx, unused, unused, unused] # Default to Lambertian with white color self.materials_data = np.array(world.get_material_data(), dtype=np.float64) # Camera data: [origin, lower_left_corner, horizontal, vertical, lens_radius, u, v] self.camera_data = np.array(camera.get_data(), dtype=np.float64) ... ``` Bunu test etmek için Rust'taki bazı performans kritik kodları JIT compiler'a [taşıyarak](https://github.com/gkmngrgn/rayt/blob/main/src/rayt/numba_optimized.py) başladım. [Web projemizde](https://huggingface.co/spaces/goedev/rayt-web) `Engine` olarak `numba` seçerek deneyebilirsiniz. Denemeden önce sizce Rust'a göre performansı nasıl olmuştur, bir düşünün. İpucu aynı sayfada var. İkisinde de CPU kullanıyoruz. Benim izlenimim, üzerinde çalıştığımız projenin gereksinimlerini gerçekten çok iyi anlamamız ve iki seçeneğin avantajları ve dezavantajlarını subjektif bir şekilde ortaya koyarak, maliyeti doğru hesaplamamız gerekiyor. Numba da pure Python'a göre performans açısından bir katkı sağlıyor; ama Rust kadar değil. Daha fazlasına ihtiyacımız var mı, onu yapabilecek bilgi birikimimiz, zamanımız, kapasitemiz var mı? Hepsi göz önünde bulundurulmalı. Numba'da bence esas olay CUDA ile başlıyor. Numba kodunu CUDA ile çalışabilir hale getirirken ilk öğrenmem gereken konu Thread Hierarchy oldu. ## Kernel ve Thread Hierarchy CUDA'nın özünde başardığı en önemli şey, biz programcılara binlerce çekirdeğin tekrarlayan işleri eş zamanlı olarak başlatma imkanı vermesidir, yani paralel processing. Bu işlem kabaca şöyle gerçekleşir: 1. **Verinin RAM'dan VRAM'e taşınması.** VRAM, grafik işlemci biriminin kullandığı video random-access memory. Veri ilk önce buraya taşınmak zorunda çünkü işlemi GPU'ya yaptıracağız. 2. **GPU'da kernel adı verilen hesaplamanın çalıştırılması.** Bu talimati biz CPU'ya veriyoruz, CPU da Numba CUDA sayesinde GPU'ya iletiyor. GPU eş zamanlı olarak VRAM'deki veriyi veya bütün çekirdeklerini paralel olarak kullanarak hesaplamayı yapar. 3. **Hesaplanan verinin VRAM'den RAM'e geri taşınması.** Biz host olarak CPU kullanıyoruz ve iletişimimizi hep CPU üzerinden yaptığımız için bu aşamaya da ihtiyaç duyuyoruz. Biz `python run main.py` dediğimizde, CPU'ya bu programı çalıştırması için talimat vermiş oluyoruz. Fakat bir hesaplamanın GPU'da çalıştırılmasını istediğimizde bizim kernel adını verdiğimiz özel fonksiyonlar tanımlamamız gerekiyor. RAYT'teki kernel fonksiyonu [çok uzun](https://github.com/gkmngrgn/rayt/blob/0e79a0e20048b2c4d06f909c182511a02462fc30/src/rayt/cuda_optimized.py#L426-L545) ama burada kırparak birkaç noktaya değinmek istiyorum: ```python @cuda.jit def render_pixels_cuda(image_width, image_height, samples_per_pixel, ...): i = cuda.blockIdx.x * cuda.blockDim.x + cuda.threadIdx.x j = cuda.blockIdx.y * cuda.blockDim.y + cuda.threadIdx.y if i >= image_width or j >= image_height: return ... # Store result (note: j is flipped for correct image orientation) output[image_height - 1 - j, i, 0] = pixel_color[0] output[image_height - 1 - j, i, 1] = pixel_color[1] output[image_height - 1 - j, i, 2] = pixel_color[2] ``` `@cuda.jit` dekoratoru, `render_pixels_cuda` kernel fonksiyonumuzun native GPU koduna (PTX) dönüşmesini sağlar. Daha sonra bu fonksiyonu grid ve block size parametreleri üzerinden çalıştırıyoruz: ```python # Calculate optimal block and grid sizes block_size = 16 grid_size = ( (image_width + block_size - 1) // block_size, # Point.x (image_height + block_size - 1) // block_size, # Point.y ) render_pixels_cuda[grid_size, block_size](image_width, image_height, samples_per_pixel, ...) ``` **Grid ve Block size nedir?** Bunu anlamak için tek thread ve CPU üzerinden programlama yaptığımızı düşünelim. Normalde oluşturmak istediğimiz imajın her bir pixeli için ışın rengini hesaplamamız gerekiyor: ```python for j in range(image_height, 0, -1): for i in range(image_width): ... ``` İç içe iki for döngüsü aslında bize bir ızgara oluşturuyor. Fakat problem şu: Bu ızgaradaki bir noktada renk hesaplaması bitmeden ikincisine geçemiyor, her şey sıralı ilerliyor. GPU'da ise, daha kernel fonksiyonunu çalıştırmadan, elde etmek istediğimiz imajın genişlik ve uzunluğu ile orantılı bir ızgaraya sahibiz. Yani GPU, kernel fonksiyonunu çalıştırdığında ışın hesaplaması resmin her noktasında aynı anda başlamaya hazır olacak. Sanırım ızgara boyutu konusu anlaşıldı, aklınızda oluşturmak istediğiniz bir imaj canlandırın ve bu imajın her bir noktası ile bir block ilgileniyor. Bir de her bir block için ayıracağınız thread var, o da ikinci parametre `block_size` ile tanımlanıyor. Bu thread'i CPU thread ile karıştırmayın, oldukça farklı bir mantıkta çalışıyor. Bir block içindeki threadler, ızgaranın bir noktası ile ilgili talimati, veri kümeleri bölüştürülerek, birbirleriyle eş zamanlı bir şekilde yerine getiriyorlar. Şimdi CUDA'da `i` ve `j`'yi tanımlamak için neden bir `for` döngüsüne ihtiyacımız olmadığı net, öyle değil mi? ```python i = cuda.blockIdx.x * cuda.blockDim.x + cuda.threadIdx.x j = cuda.blockIdx.y * cuda.blockDim.y + cuda.threadIdx.y ``` Aslında bu bilgi, en başta sorduğumuz "Python neden yavaş?" sorusu ile ilgili önemli bir ipucu barındırıyor. 640x480 pixel boyutunda küçücük bir resim hesaplatmak için bile 307200 kere renk hesaplamasını tek tek yaptırmaya çalışıyoruz. GPU ise bu ızgara yapısı, ızgarada bulunan her bir blok ve her bir blok içindeki threadlar, toplamda yüzbinlerce thread sayesinde bizi bu darboğazdan kurtarıyor. İşte bu yapıya Thread Hierarchy deniyor. ## Peki Hugging Face'de CUDA Kullanmak, Mümkün mü? Teorik olarak, mümkün. Pratik olarak? Denemedim; ama mümkün olacağını düşünüyorum. RAYT web arayüzünde engine olarak `cuda` seçip deneyebilirsiniz; ama önce onu GPU olan bir sunucuya deploy etmeniz gerekiyor. ![Hugging Face Spaces GPU Seçenekleri](/images/hugging-face-spaces-gpu-options.png) Bir de GPU ile uyumlu CUDA toolkit ve numba-cuda paketlerini kurarsak, çalışmaması için bir neden göremiyorum. Bir NVIDIA ekran kartınız varsa repoyu klonlayıp yerelinizde deneyebilirsiniz, farklı engine'lar ile sonuçları karşılaştırabilirsiniz. ## Son Söz ![TIOBE Index Programlama Dilleri Popülerlik Sıralaması 2025](/images/tiobe-index-programming-languages-2025.png) Sosyal medyada bir tartışma vardı, dünyanın en yavaş dili (mi?) olmasına karşın en popüler dili Python ise, performans önemli midir, değil midir üzerine. Bir kere Machine Learning, NLP işlerinde GPU kullanımının artması zaten hızın önemini anlatıyor, buna ek olarak maliyeti de göz önünde bulundurmak gerekiyor. Hız, performans bana göre her zaman önemli olacak, ister GPU ve CUDA programming ile, ister Rust/C++ interoperability ile, ister Python subinterpreterlar veya free-threading kullanarak. Öte yandan, gelişmeler çok hızlı ilerliyor ve kimsenin öğrenmesi, kodlaması, derlemesi, okuması zor dillerle kaybedecek vakti yok. Python'un popülerliği bundan. ### Python 3.14 Yayımlandı, 3.9'u Bırakma Zamanı Geldi > URL: https://gokmengorgen.net/tr/2025/10/08/python-314-yayimlandi-39u-birakma-zamani-geldi/ | Published: 2025-10-08 00:00:00 +0000 UTC | Categories: software-engineering | Tags: python, gil, uv Python 3.14 ile gelen yeniliklere hızlıca göz attım. Aşağıdaki kodları yerelinizde denemek için [uv](https://docs.astral.sh/uv/) yükleyin ve REPL'i aşağıdaki komutla çalıştırın: ```shell uv python upgrade 3.14 uvx python@3.14 ``` # [PEP 750](https://peps.python.org/pep-0750/): Template Strings Template stringleri (kısaca t-strings), hazırda var olan f-strings'teki önemli bir eksikliği gidermek için sunulmuş bir öneriydi ve 3.14 ile birlikte artık kullanıma hazır. Önce problemi göstereyim: ```python >>> name = "Gökmen" >>> f_hello = f"Hello, {name}" >>> t_hello = t"Hello, {name}" >>> type(f_hello) >>> type(t_hello) ``` `f_hello` tipi `str` olduğu için, artık içinde değişkenler neydi, hangi kısımlar statikti anlamak için ekstra kod yazmak gerekiyordu. ama tip `Template` olunca bu bilgilerin hepsine erişim mümkün: ```python >>> dir(t_hello) ['__add__', '__class__', '__class_getitem__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__getstate__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__iter__', '__le__', '__lt__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__str__', '__subclasshook__', 'interpolations', 'strings', 'values'] >>> t_hello.values ('Gökmen',) >>> t_hello.strings ('Hello, ', '') >>> t_hello.interpolations (Interpolation('Gökmen', 'name', None, ''),) ``` Buna niye ihtiyaç vardı? Dinamik değerler üzerinde string işlemleri yapmak pratikleşiyor: ```python >>> from string.templatelib import Interpolation >>> "".join([part.value.upper() if isinstance(part, Interpolation) else part for part in t_hello]) 'Hello, GÖKMEN' ``` `Template` ile basit bir [Jinja](https://jinja.palletsprojects.com/en/stable/) clone'u bile yapılabilir. # [PEP 649](https://peps.python.org/pep-0649/), [PEP 749](https://peps.python.org/pep-0749/): Annotationlarda `NameError` Probleminin Kalkması Aşağıdaki kod Python 3.13'te `NameError` hatası veriyor, çünkü `X` tanımlı değilken `a` tipini tanımlamaya çalışıyoruz: ```python >>> a: X | None = None ... class X: ... ... Traceback (most recent call last): File "", line 1, in a: X | None = None ^ NameError: name 'X' is not defined ``` Bu problemi çözmek için ya `X`'i string yapıyorduk; ya da [`__future__.annotations`](https://docs.python.org/3/library/__future__.html#future__.annotations) kullanıyorduk. Şimdi artık hiçbirisine gerek yok: ```python >>> a: X | None = None ... class X: ... ... >>> ``` # [PEP 734](https://peps.python.org/pep-0734/): Çoklu Yorumlayıcı Kullanmak İçin Yeni Modül: `interpreters` Artık [C-API](https://docs.python.org/3.14/c-api/init.html#sub-interpreter-support)'nın derinliklerinde kaybolmadan, Python kodu içinde kalarak aynı process içinde birden fazla interpreter üzerinden Python kodunu çalıştırmak mümkün hale geldi. Normalde ana interpreter altında başlatacağınız tüm alt interpreterler birbirlerinden izoledirler. Siz aynı Python kodunu 100 tane interpreter'de başlatsanız bile, birbirleriyle iletişim, veri aktarımı olmadığı sürece bunun performansa bir katkısı olmuyordu. Şimdi bu yeni modül, paylaşımlı objeler sayesinde iletişimi mümkün hale getiriyor. Belki bunu daha sonra [RAYT](https://github.com/gkmngrgn/rayt)'ı optimize ederek gösterebilirim, şimdilik [buradan](https://peps.python.org/pep-0734/#synchronization) örnek kodu paylaşıyorum: ```python import interpreters from mymodule import load_big_data, check_data numworkers = 10 control = interpreters.create_queue() data = memoryview(load_big_data()) def worker(): interp = interpreters.create() interp.prepare_main(control=control, data=data) interp.exec("""if True: from mymodule import edit_data while True: token = control.get() edit_data(data) control.put(token) """) threads = [threading.Thread(target=worker) for _ in range(numworkers)] for t in threads: t.start() token = 'football' control.put(token) while True: control.get() if not check_data(data): break control.put(token) ``` # [PEP 758](https://peps.python.org/pep-0758/): Çoklu Exceptionlar'da Parantez Kullanmaya Artık Gerek Yok En çok yaptığım syntax hatalarından biriydi, artık exception'ları parantez kullanmadan yazmak geçerli bir syntax: ```python >>> try: ... x() ... except NameError, ValueError: ... print("achtung!") ... achtung! ``` # [PEP 765](https://peps.python.org/pep-0765/): `finally` İçinde `return`/`break`/`continue` Kullanımının Kaldırılması Planı Geriye uyumluluğun korunması için şimdilik sadece `SyntaxWarning` alıyoruz. `finally` aslında her koşulda çalıştığı için `return` kullanımında epey kafa karıştırıcı oluyordu: ```python >>> def bool_return(): ... try: ... return True ... finally: ... print("you tried to return True but you will also see this message?") ... return False ... :6: SyntaxWarning: 'return' in a 'finally' block >>> bool_return() you tried to return True but you will also see this message? False ``` Bu arada.. REPL iyice metin tabanlı editör haline gelmiş, syntax highlighter güzel çalışıyor. ![Python 3.14, REPL Syntax Highlighter](/images/python-314-repl-syntax-highlighter.png) # [PEP 768](https://peps.python.org/pep-0768/): Breakpoint Eklemeden Debug Edebilme İmkanı Bu galiba biraz açık kalp ameliyatı gibi; production'da ve production kodunda test ve development sürecine dair herhangi bir kod parçasının repoya commit edilmesine bile izin verilmez. Bunun için genelde Sentry gibi servisler kullanılır ve yapılacak en iyi şey şu anda logging'i efektif kullanmak. Nadir de olsa bazen daha kolay bir debugging olsun arzusunda olabiliyoruz. PEP 768 buna bir alternatif olabilir. `remote_exec` adında fonksiyon bu konuda bize yardımcı oluyor. Bu fonksiyonun birinci parametresi, debug etmek istediğimiz Python process'in PID numarası: ```python import sys import uuid # Execute a print statement in a remote Python process with PID 12345 script = f"/tmp/{uuid.uuid4()}.py" with open(script, "w") as f: f.write("print('Hello from remote execution!')") try: sys.remote_exec(12345, script) except Exception as e: print(f"Failed to execute code: {e}") ``` # Diğer Yenilikler ve Python 3.9 3.13 ile gelen Free-Threaded modu, garbage collection, REPL, standart modüller geliştirildi. Hata mesajları typo'larda öneri sunabiliyor (whillle yazdığınızda "while mi demek istediniz" diyor). Bu arada her yeni major sürümde, bizi bu yeniliklerden alıkoyan en önemli şey de eski sürümlere olan desteğin sürdürülmesi. Artık Python 3.9 güvenlik güncellemeleri gelmeyecek. Bence projelerimizde 3.9'u desteklemeyi bırakmanın zamanı geldi. Bu sayede: 1. Structural Pattern Matching (`match - case`) kullanabileceğiz. [Buraya](https://peps.python.org/pep-0636/) bir göz atın. 2. Tek `with` ile birden fazla context'i aynı anda yönetmek için [parantez kullanabileceğiz](https://github.com/python/cpython/issues/56991). 3. `Union[bool, None]` yerine `bool | None` gibi pipe kullanımı geçerli olacak. Python projelerini güncel tutmak için bir rehber arıyorsanız bu yazıma göz atabilirsiniz: - [Keeping Python Projects Up to Date](https://gokmengorgen.net/2025/03/30/keeping-python-projects-up-to-date/) # Kaynaklar - [Python 3.14 ile gelen yenilikler](https://docs.python.org/3.14/whatsnew/3.14.html#whatsnew314-free-threaded-cpython) - [Python 3.9'u desteklemeyi bıraktığınızda sahip olacağınız yeneilikler](https://docs.python.org/3.10/whatsnew/3.10.html) ### Elektrikli Araçla Yurt Dışı Yolculuğu > URL: https://gokmengorgen.net/tr/2025/01/18/elektrikli-aracla-yurt-disi-yolculugu/ | Published: 2025-01-18 00:00:00 +0000 UTC | Categories: entertainment, family | Tags: automobile, tatil, tesla Elektrikli araçla daha önce kısa yol deneyimim oldu, Ankara ve Tekirdağ arası, 575 km’lik yol. Bununla ilgili deneyimlerimi anlatan bir [blog yazım](/2024/10/27/elektrikli-aracla-ilk-tatilim/) da var. Şimdi o yolu beşe katladım, toplam üç gün sürdü. Geride uzun, huzurlu, çok şükür kazasız belasız, tadında bir hikaye kaldı. Bunu sizlerle paylaşmak istiyorum. Zaman zaman sosyal medya paylaşımlarımdan bana ulaşıp tavsiye isteyenler oluyor, tavsiye konusuna en baştan bir açıklama yapmak istiyorum. Bu yazıda **bir elektrikli araç tavsiyesi, övgüsü veya karalaması yok.** Beklentilerden alışkanlıklara kadar tercihleri belirleyen o kadar fazla parametre var ki, öngörülmesi o kadar zor detaylar var ki, birine araç konusunda tavsiye vermek benim için çok zor. Bizzat kendim için söylüyorum; bir elektrikli araca sahip olarak ne fiyat - performans, ne masraf - tasarruf, ne de ailemin ihtiyaçlarını karşılamak konusunda en ufak bir dezavantajını görmedim. Kullandığım elektrikli araç, ihtiyacım olanın çok daha fazlasını veriyor; ama bir otomobil tutkunu olarak da aklımın bir köşesinde hep bir Mazda 3 AWD veya Lexus IS 300h sahibi olmak, ona uzun yıllar binmek, bakımını bizzat kendim yapmak var. Bazen arzularla ihtiyaçlar, duygularla mantık birbiriyle örtüşmüyor. Ailemin tercihi, mutluluğu için kendi sürüş zevkimden feragat ettim. Onun için herhangi bir tavsiye vermek yerine bu yazıyı veri ağırlıklı yazmayı, arada kişisel düşüncelerimi paylaşmayı planladım. Bazı detayların epey yoruma açık olacağını, kimisinin normal karşılayıp duruma sıcak bakacağını, kimisinin ise bu yeni akıllı araçlardan soğuyacağını şimdiden tahmin edebiliyorum. ## Sözlük Çok sık tekrarladığım kelimeleri burada kısaltıp anlamını yazıyorum: - **SC:** SuperCharger, Tesla'nın resmi hızlı (DC) şarj istasyonları. - **MY:** Tesla Model Y, şu anda Türkiye'de de satışı olan tek Tesla modeli. - **AC:** Alternating Current, alternatif akım. Araç şarj olurken gelen elektriği doğrusal akıma dönüştürüp bataryaya iletir. Enerji çıkış kapasitesi düşüktür, aracı şarj etmesi uzun sürer. - **DC:** Direct Current, doğrusal akım. Yüksek enerji çıkış kapasitesi vardır, enerji direkt bataryaya iletilir ve şarj etme süresi daha kısadır. ## Hava Durumu, Araç, Sürüş Profili Önceki yolculuğum kısa ve yaz sıcağındaydı. Tek aksilik, Ankara’dan Tekirdağ’a giderken Bolu Tüneli’nin kapalı olmasıydı. Bir saat yaz sıcağında trafikte kaldık, sonrasında yokuş aşağı, düşük hızlarda, araç kendini şarj ede ede gitmişti bir süre. Araç BYD Atto 3, LFP bataryalı bir araçtı. Bunlar hep enerji tüketimini etkilediği için baştan belirtme gereği duyuyorum. Bu seferki yol koşullarında şöyle değişiklikler var: - Araç **MY**, uzun menzilli, çift motor, dört çeker, NMC bataryalı. - Hava sıcaklığı çoğunlukla 1 - 3 derece arasında, bazen eksi, bazen 8 dereceye kadar çıktı. - Kış lastikleri takılı. - Kar yağışına denk gelmedik; ama kırağı, yağmur, kaygan yollara denk geldik. Hele Bolu Tüneli’nde 30 metre ötesini göremeyeceğimiz kadar sis vardı. - Uzun süreli trafik kitlenmesi veya gümrüklerde bir saati aşan bekleme süresi olmadı. Bu yolculukta da öncekinde olduğu gibi yine hız limitlerine uygun gidildi. Yani hız limiti neye izin veriyorsa o hızda gidildi, menzil uzatmak veya tasarruflu olmak için 130 kmh hız limitinin olduğu yerde 100 ile gidilmedi, onu kastediyorum. Ancak yolun durumuna veya trafiğe bağlı olarak zaman zaman hızımızı azaltmak zorunda kaldık. Özellikle kaygan yollarda otonom sürüşü devre dışı bırakıp olabildiğince temkinli ve yavaş kullandım. Düz, sakin ve temiz yollarda, fırsat buldukça otonom sürüşü kullandım, yani toplam yolun %20 - 30’unda yardımcı pilotum benim yerime aracı kullanmış oldu, tabi eller yine direksiyonda. Son olarak, uzun molalarda, şarj sırasında veyahut aracı kullanırken klimadan hiçbir kısıntı yapmadık. Ben genelde paltomu çıkararak rahat araç sürmeyi seviyorum, ama beni mayıştıracak kadar fazla sıcağı da sevmiyorum. Genelde 20 - 21 derece tercih ettim, koltuk ve direksiyon ısıtma da kullanıldı. ## Planlama Çoğunlukla tarihleri biz seçemiyoruz, çocuğumuzun okul tatili, işyerinden izin alma durumumuz, yolculuğa katılacak bireylerin sağlık durumu zaten epey kısıtlayıcı; ama yine de birkaç kritere bakmak çok önemli. Bunlardan birincisi ve bence en önemlisi geçeceğiniz gümrük kapılarının yoğunluğu. Ben ilk olarak 23 Aralık’ta yola çıkmayı planlamıştım, o tarihte yolda olan bir arkadaşımın 6 saat Sırbistan gümrük kapısında beklediğini duyunca vazgeçtim ve kameralardan yoğunlukları takip ettim. İnternetten gümrük kapılarını izleyebiliyorsunuz, yazının sonunda linkleri paylaştım. Bu yoğunluğun azalması neredeyse üç gün sürdü ve 27’sinde yola çıkmaya karar verdim. ![](/images/prag-cars.jpeg) ### Rota ve Duraklar Almanya’dan Türkiye’ye kadar şu beş ülkeden geçmeyi planladım, çıkış noktamız Berlin, varış noktamız Ankara: 1. **Çekya:** Dresden’den çıkıp önce Prag’a, sonra Brno’ya uğruyoruz. 3. **Slovakya:** Avusturya’ya yakın bir sınırdan, ama Slovakya içinde kalarak Bratislava’ya uğruyoruz. 5. **Macaristan:** Győr‘dan geçip Budapeşte’ye doğru yolumuzu tutuyoruz, ancak Budapeşte’nin içine girmeden Szeged’e kadar ilerliyoruz. 7. **Sırbistan:** Röszke Horgos sınır kapısından Sırbistan’a geçiyoruz ve Belgrad’a uğramadan Niš’e kadar devam ediyoruz. 9. **Bulgaristan:** Kalotina sınır kapısından Bulgaristan’a geçiyoruz ve önce Sofia’ya, ardından Plovdiv’e uğruyoruz.
![](/images/IMG_0005-1024x681.jpeg)
Prag gezisi ve konaklamaları içermeyen, temsili rota.
İşin doğrusu gezilecek yerlere, kalınacak otellere, yolların kalitesine göre güzergah belirlemek iken; ben rotayı belirleme işini tamamen Tesla’ya bıraktım. En azından şunu biliyordum; Tesla beni menzil anlamında riske atmadan, sadece SC’leri kullanarak Edirne’ye kadar götürecekti. Edirne’den sonra ise önceki şehirlerarası yolculuğumda tecrübe ettiğim gibi Trugo şarj istasyonlarını kullanacaktım ve Ankara’ya kadar otobandan çıkmayacaktım. İlk defa ülkeler arası uzun yolculuğa çıkma heyecanım ve biraz da elektrikli aracın yaşattığı tedirginlik yüzünden tek isteğim Ankara’ya sorunsuz varabilmekti. Onun için genelde spontane ilerledi her şey. Gezdiğim yerleri haritada belirtmedim; ama Prag Kalesi’ni es geçmediğim için çok mutluyum. Çekya ayrı bir güzel, Prag ayrı bir güzel, Brno karanlıkta kaldı ama o da ayrı bir güzeldi. Dönüşte muhtelemen farklı bir ülke seçip benzer bir gezi yapmayı planlıyorum. Belki Belgrad, belki Budapeşte, biraz eşime ve çocuklarıma bağlı. ### İnternet Almanya’dan satın aldığınız Tesla’nın internet bağlantısı Sırbistan ve Türkiye hariç rotamdaki tüm Avrupa ülkelerinde vardı. Türkiye’deki Tesla sahipleri muhtemelen Avrupa’ya çıktıklarında internete erişemeyecekler. Her iki durumda telefonda internetin olması birçok açıdan gerekli: - SC dışında başka bir şarj istasyonuna muhtaç kalırsanız, şarjı başlatabilmek için gerekli. - E-vinyet satın almak için gerekli. - Olur da navigasyon yardımcı olmazsa ikinci bir navigasyona bakmak için gerekli. - Diğer iletişim ihtiyaçlarınız için gerekli. Sanırım ilk talihsizlik şu oldu. Sırbistan’da Tesla’nın navigasyonu çalışmayınca, telefonumun internetini aracımla paylaştım, meğer araca güncelleme gelmiş ve beş dakika içinde paketi kemirdiği için telefonumdaki internetimden de oldum. Şimdiki aklım olsa kesinlikle bağlamam ve Google Maps veya Apple Maps offline harita özelliklerini kullanabilmek için yola çıkmadan önce ayarlardım. Aslında Tesla’da bu özellik var ama sanırım sadece aracı satın aldığınız ülkenin haritası önceden indirilmiş oluyor. ### Vinyetler, ENP, HGS Bazı ülkelerde otoban ve köprüleri kullanmak için geçiş kartı satın almanız gerekiyor, buna toll veya vinyet deniliyor. Vinyetleri nasıl satın alacağımı araştırırken, fark ettim ki bazı ülkelerde eletrikli araçlara bir istisna getirmişler. Her ülke için ayrı ayrı başvurmak, gerekli evrakları toplayıp elektronik imza ile onaylayıp göndermek gerekiyormuş. Bunlarla uğraşmak için yeterli zamanım olmadı; ama en azından Çekya ve Slovakya’da vinyet almak zorunda kalmazdım. Bir diğer önemli konu **vinyetlerin geçerlilik süresi**. Çoğunlukla günlük vinyet satın alıyorsunuz ve gece saat 00:00 olduğunda tekrar vinyet satın almanız gerekiyor. Yani akşam 11’de Bratislava’dan Macaristan’a girdiniz, o günün son bir saati için bir vinyet, eğer bir saat içinde Macaristan’dan çıkamazsanız ertesi gün için bir vinyet daha satın almalısınız. Üstelik Macaristan vinyetleri en pahalılarından biriydi. Ben vinyetleri her ülkenin kendi resmi sitesine girerek online olarak aldım. Vinyet uygulamaları var, bence çok bir işlevi yok, biraz daha pahalıya geliyor; ancak sitelerle ayrı ayrı uğraşmak yerine tek bir yerden tüm vinyetleri satın almak kolaylığı sağlıyor. Kolaylık olsun diye yola çıkmadan önce tüm vinyetleri satın almanızı da tavsiye etmem, belki dönmek zorunda kalırsınız, belki gümrükten geçemeyeceksiniz, belki de yorgun olacaksınız ve dinlenmek isteyeceksiniz, ülke değiştirme günleriniz değişecek, her şeye hazırlıklı olmakta fayda var. İnternetiniz olduğu müddetçe vinyet almak oldukça kolay. Sırbistan’da vinyet yerine Türkiye’deki gibi bir sistem var. ENP cihazı için başvuruda bulundum ancak cihaz hala elime ulaşmadı. Dolayısıyla otomatik geçiş gişelerini kullanamadım ve her gişede kartla ödeme yapmak zorunda kaldım. Son olarak Türkiye’de ücretli otobanları kullanmak için HGS başvurusu yapmak gerekiyor. Eğer ikametiniz Türkiye’de ise, internet üzerinden HGS başvurusu yapıp etiketin adrese gönderilmesini talep edebiliyorsunuz. Onun dışında ilk HGS satış ofisine uğrayıp elden teslim almanız gerekiyor. Ben tabi Türkiye’ye gece geç saatlerde giriş yaptığım için açık bir ofis bulamadım ve hala Edirne’den Tekirdağ’a kadar olan ücretlerin plakaya yazılmasını bekliyorum. Bir borç veya ceza gözükmediği için ödemeyi yapamadım. ## Şarj İstasyonlarının Durumu Benim planım mümkün mertebe SC kullanmak, mümkün olmadığı durumlarda Trugo, Aral, Ionity, artık ne bulursam onu kullanmaktı. SC'lerin birkaç avantajı var, bazı avantajlar MY kullanıcısı olmama bağlı: 1. En büyük avantajı elbette kullanım kolaylığı, sadece soketi takmanız yeterli, kendiliğinden şarj etme işlemi başlıyor, ekstra bir efor sarfetmeye, bir yerlere üye olmaya gerek kalmıyor. 3. İkinci önemli avantajı, Tesla navigasyonu üzerinden SC'ye gitmek istediğinizi belirttiğinizde, bataryaları otomatik olarak ısıtıyor ve bu işlem şarj süresini oldukça kısaltıyor. 5. SC'ler genelde daha ucuz. 7. Araç zaten rotayı ona göre çiziyor, çoğunlukla menzil tahminlerinde başarılı. 9. Bu şarj istasyonlarını tercih eden kullanıcı profili genelde bilinçli ve saygılı. Bazen benim de yeni öğrendiğim şeyler oluyor ve bana nedenini düzgünce söylediklerinde hatamı düzeltmek için elimden geleni yapıyorum. Örneğin eski SC'lerde iki soket var, bazen boş sanıp eski uyumsuz soketi alıyorum, uyarıyorlar. Veya arkada boş soketler olduğunu söylüyorlar, onu kullanırsam şarj hızımızın yarıya düşmek yerine aynı hızda kalacağını, daha kısa sürede şarj işleminin biteceğini anlatıyorlar. Anlayış olunca problemler çok çabuk çözülüyor. Dezavantajları: 1. SC'lerin konumu yol uzatıyor. Çoğunlukla otobandan çıkmak zorundasınız. Ya bir AVM’nin otoparkında, bahçesinde, ya da bir restoran veya otelin otoparkında, çoğunlukla trafiğin yoğun olduğu, bozuk yolların olduğu yerlerde. 3. 30 dakikalık şarj için 45 dakika beklediğim oldu. Şarj soketine arkadan yanaşıp hakkımı gasp eden de oldu, o da Tesla kullanıcısı değildi. SC tasarımı her marka elektrikli araçların düzgünce park edip soketi kullanmasına elverişli değil, bütün düzeni bozuyor. Olur da Tesla olmayan bir aracın birden fazla park yerini işgal edecek şekilde park ettiğini görürseniz, sebebi kablonun kısalığı, soketin yerinin standart dışı olması. Bence Tesla buna izin vermemeliydi. Bu sadece SC eleştirisi değil; ama AVM gibi yerlerde DC şarj istasyonlarının olması bana göre mantıksız. Zaten AVM’ye giden insanın vakti bol, yarım saat değil en az 1 - 2 saat vakit geçirecek çoğu. 10 tane DC şarj istasyonu yerine 100 tane AC şarj soketi koysalar, AVM’nin bile işine gelir sanki. Otobanlarda DC’ye daha çok ihtiyaç var. Bu konuda Trugo’nun politikasını ben açıkçası çok başarılı buluyorum. Otobanlardaki -şimdilik hepsinde olmasa da- çoğu Shell istasyonlarında Trugo hızlı şarj istasyonları olduğunu bilmek bana güven veriyor. ## Menzil Anksiyetesi Evet gelelim zurnanın zırt dediği yere, hepimizin aklına takılan menzil konusuna. Hesap kitap bölümünü hazırlarken gördüm ki tam **16 kez şarj etmek için durmuşum**. Yalan yok. Durdukça durmuşum, canım istedikçe durmuşum, sıkıldıkça durmuşum. Şimdi diyeceksiniz, 3000 km’de 16 kere durduysan, bu araç 200 km bile gidememiş, menzili bu kadar mıymış uzun yolda? Tabi ki değil. Benim eskiden beri olan bir huyum var. Göstergelerde benzin uyarı lambası yanar yanmaz hemen gözler benzin istasyonu arardı, halbuki istesem bir 150 km daha yaparım. Öte yandan depoyu asla tam doldurmazdım, yarıdan fazla doldururdum, bu da 300 km yapmama yeterdi. Aynı alışkanlık elektriklide de devam ediyor, yenemedim. Biraz da NMC batarya ömrü tedirginliği var, sanırım LFP için bu kadar endişe etmezdim. Her seferinde tahmini %10 - %15 şarj kalacak şekilde bir sonraki şarj istasyonuna doğru yola çıktım. Ve her seferinde en fazla %85 - %90 doldurdum, bazen %60, bir defa da %45 ile yoluma devam ettim. Bir benzinli araç ile yola çıkmış olsaydım belki her seferinde yakıt almayacaktım, ama yine 10’dan fazla kez mola vereceğimi tahmin ediyorum, her seferinde de en az yarım saat dinleneceğimi. Ama içten yanmalıda bu bir opsiyonken, elektrikli araçta zorunluluk. Belki yeni batarya teknolojileriyle birlikte menzil 1000 km’ye çıktığında elektrikli araçlar için de opsiyonel olacak ama ben artık çok takılmıyorum o konuya eskisi kadar. Huylu huyundan vazgeçmez, gene 200 km yerine 300 km’de bir şarj ederdim bu sefer. Dönüşte 200 - 250 km'de bir değil de, 300 - 350 km'de bir şarj etmeyi deneyebilirim; ama söz veremiyorum. Araçta çocuklar varken mola vermeden uzun süre gitmek zor oluyor. Mola verince de şarj istasyonu bulmuşken kullanırım diye düşünüyorum. ## Maliyet Beklentisi Daha önce yapmış olduğum şehirlerarası yolculuklarda maliyetin benzinliye göre fazla arttığını gözlemlemiştim. Bu yolculukta da bir ucuzluk beklentim yoktu. Hem kış koşulları yüzünden, hem de sürüş profilim yüzünden enerji tüketiminin katlanarak artacağını biliyordum. ![](/images/tesla-trip-status-1024x661.jpeg) Düz bir karşılaştırma hesabı için daha önce defalarca sıla yolculuğu yapmış birisinin Toyota Aygo ile yaptığı son yolculuk ile ilgili paylaştığı verileri kullanacağım, [videosunu](https://youtu.be/pj-02EhiyYk?si=geifgSreGb5GEdbC) ayrıca izlemenizi tavsiye ederim: 1. Videoda Mehmet Asır özetle diyor ki: Gidişte ortalama yakıt tüketimi **5.86lt/100km**, dönüşte **6.39lt/100km** olmuş. Giderken 100 km'de **8.38 EUR**, dönüşte **9.77 EUR** masraf yapmış. Bu fiyatları etkileyen bir sürü faktör var, yine sürüş profili, yakıtı aldığın yer, geçtiğin yolun kalitesi vesaire. 3. Birebir aynı yol, aynı zaman, aynı koşullar, hatta aynı segment araç olmadığı için sağlıklı karşılaştırma olmayacağını biliyorum; ama ben 1 kWh enerjiyi ortalama **0.40 EUR** ile satın alsam, toplamda **264.4 EUR** masraf yapmış olmam lazım. Paylaştığım Tesla ekranında gördüğünüz gibi **661 kWh** enerji tüketimi olmuş, bu veriyi kullanıyorum. 5. Benim yaptığım km'yi Mehmet Bey yapsaydı, 2776 km için gidişte **232.63 EUR**, dönüşte **271.22 EUR** tutacaktı. Yani ben toplam şarj maliyeti **270 EUR** tutsa şaşırmayacaktım, kendimi ona göre hazırlamıştım. Şimdiki aklım olsaydı, Sırbistan ve Bulgaristan’da %100 şarj ederdim, bu hesapları yaparken **oralarda şarjın bedava olduğunu** bilmiyordum. Zaten bu bedavalar olmasa, kendim açımdan elektrikli araçların ekonomik olduğundan bahsetmek biraz zor. GigaFactory'e yakın bir konumda oturduğum için aracımı fabrikada **ücretsiz şarj edebiliyorum**. Aracın MTV’si **0 EUR**, aracı satın alırken devlet teşviği fırsatını kaçırdım ancak ödediğim faiz %0. Bu detaylarla birlikte elektrikli araç ucuza mı gelir pahalıya mı gelir daha iyi ölçülür. Yoksa sadece 300 km’lik yol için içten yanmalıyla ne kadar masraf yapardım, elektrikliyle ne kadar yapardım diye bakarsak, bir elektriklinin ortalama 238 Wh/km ile çok bir şansı yok. Belki şehir içi tüketim masrafının azlığı toplam maliyeti dengeleyebilirdi, bilmiyorum. Bir de bu bedavalar hep böyle kalacak mı? Onun için maliyet beklentisi ile ilgili net bir şey söylemek zor. Otobanda 90 kmh hızla gidip şu kadar menzil, şu kadar masraf yaptım diyenlere de pek kulak asmıyorum. ## Hesap Kitap Verileri aşağıda detaylıca vereceğim ancak bir özetini şurada belirteyim: - Toplam vinyet ve otoban ücreti: **90.38 EUR**. Daha önce dediğim gibi eğer evrakları hazırlayıp başvurabilseydim Çekya ve Slovakya için ücret ödemeyecektim. Türkiye'de HGS ödemelerini TRY hesabım üzerinden yaptım, o günkü kura göre EUR'a çevirdim, diğerleri direkt EUR olarak hesaplanmış şekilde çekildi. Bulgaristan'da da haftasonuna denk geldiğimiz ve gece orada kaldığımız için iki günlük vinyet almak yerine bir haftasonu için aldım. - Toplam şarj ücreti: **210.53 EUR**. Bunun beklediğimin (270 EUR) çok altında olması beni mutlu etti. Ücretsiz olanları hesaba katmadan, diğer SC'ların ortalaması **0.36 EUR/kWh** olmuş. - 10.08 + 10.07 + 25.48 + 22.34 + 28.96 + 18.40 + 20.59 + 17.08 = **153 EUR** - 37.96 + 54.39 + 48.60 + 62.98 + 55.06 + 62.80 + 51.67 + 51.69 = **425.15 kWh** - 153 ÷ 425.15 = **0.359872986** - Toplam **603 dakika** (10 saat 3 dakika) şarj etmişim ve buna şarja takmak için sırada beklediğim süre **dahil değil**, farz edelim 2 saat de oraya gitmiş olsun. Buna acayip şaşırdım. Elektrikli araç işine uzak bakan birisi olsam sanki 12 saat elimde soket, ayakta aracı şarj ediyor vaziyette ağaç gibi dikilmişim gibi anlarım. Öyle bir şey olmadı tabi, onun yerine dinlendim, yemek yedim, kahve içtim, gezindim, tuvalete gittim, kısaca zorunlu mola verdim. Vaktin nasıl geçtiğini anlamadım bile. - Bunun dışında konaklama, yeme - içme, alışveriş, gezi benzeri masraf kalemleri var; paylaşmama gerek yoktur sanıyorum. ### Vinyetler, Otoban Ücretleri Bütün vinyetler online olarak satın alındı, kaynaklar bölümünde nereden aldığımı paylaştım: | Tarih | Ülke | Süre | Ücret | Ücret (EUR) | | --- | --- | --- | --- | --- | | 27.12.2024 | Çekya | 1 Gün | CZK 200 | 7.95 EUR | | 27.12.2024 | Slovakya | 1 Gün | 5.40 EUR | 5.40 EUR | | 27.12.2024 | Macaristan | 1 Gün | 10300 Ft | 24.95 EUR | | 28.12.2024 | Sırbistan | Süre Önemsiz | 2949 RSD | 25.32 EUR | | 28.12.2024 | Bulgaristan | 1 Haftasonu | 9 лв. | 4.60 EUR | | 29.12.2024 | Türkiye | Süre Önemsiz | 810.50 TRY | 22.16 EUR | Sırbistan’da vinyet yok, onun yerine ENP cihazı satın alıp ENP gişelerini kullanmak veya ilk girişte kart alıp sonrakinde ödeme yapmak var. Türkiye’deki HGS’ye benzer bir sistem: | İstasyon | Ücret | Ücret (EUR) | | --- | --- | --- | | Putevi Srbije | 800 RSD | 6.87 EUR | | JP PUTEVI ALEKS RUDNIC | 970 RSD | 8.33 EUR | | EKO SERBIA 1230 NIS 2 | 509 RSD | 4.37 EUR | | DIMITROVGRAD | 670 RSD | 5.75 EUR | Türkiye’de HGS’yi Tekirdağ’da bir gece dinlendikten sonra aldım. Edirne’den Tekirdağ’a kadar olan ücretli otobanın ücretini bir türlü öğrenemedim. İki haftadır ne bir ceza var, ne de karttan çekim yapıldı. Ama diğerlerini paylaşıyorum: | Giriş İstasyonu | Çıkış İstasyonu | Ücret (TL) | | --- | --- | --- | | KMO KINALI GİŞESİ | FATIH ALIN GISESI | 120,00 | | TERMINAL | TERMINAL | 9,00 | | KARGO | KARGO | 5,50 | | ODAYERİ | KURNAKÖY | 265,00 | | KURNAKÖY ALIN GISESI | TEM AKYAZI | 280,00 | | TOPAĞAÇ SGS | AKINCI (MÜRTED) | 131,00 | ### Şarj Ücretleri Tabloya geçmeden önce burada bir fotoğraf paylaşmak istiyorum. O fotoğrafı çekerken, uygulamaya yabancı olduğumdan olsa gerek kWh ücretine bakmadan (yani ne kadar pahalı olabilir ki...) işlemi başlatmıştım ve hayatımın en pahalı elektriğini aldığımın farkında değildim: ![](/images/aral-pulse-1024x768.jpeg) Zaten tablodan da ne kadar pahalı olduğunu görebilirsiniz. Onun dışındakiler gayet makul fiyatlardaydı: | Tarih | Ülke | İstasyon | Kapasite | Süre | Ücret | Ücret (EUR) | | --- | --- | --- | --- | --- | --- | --- | | 27 Aralık 10:31 | Almanya | SC | 37.96 kWh | 20 dk | 17.08 EUR | 17.08 EUR | | 27 Aralık 11:33 | Almanya | Aral Pulse | 28.14 kWh | 22 dk | 27.29 EUR | 27.29 EUR | | 27 Aralık 13:53 | Çekya | SC | 54.39 kWh | 36 dk | CZK 516.74 | 20.59 EUR | | 27 Aralık 17:57 | Çekya | SC | 48.60 kWh | 42 dk | CZK 461.66 | 18.40 EUR | | 27 Aralık 21:28 | Slovakya | SC | 62.98 kWh | 63 dk | 28.96 EUR | 28.96 EUR | | 28 Aralık 00:21 | Macaristan | SC | 55.06 kWh | 37 dk | HUF 9,139.13 | 22.34 EUR | | 28 Aralık 08:46 | Macaristan | SC | 62.80 kWh | 44 dk | HUF 10,424.96 | 25.48 EUR | | 28 Aralık 12:35 | Sırbistan | SC | 61.71 kWh | 36 dk | 0 RSD | 0 EUR | | 28 Aralık 15:03 | Sırbistan | SC | 55.52 kWh | 39 dk | 0 RSD | 0 EUR | | 28 Aralık 19:32 | Bulgaristan | SC | 44.11 kWh | 71 dk | BGN 0.00 | 0 EUR | | 28 Aralık 22:24 | Bulgaristan | SC | 39.37 kWh | 54 dk | BGN 0.00 | 0 EUR | | 29 Aralık 01:50 | Türkiye | SC | 51.67 kWh | 29 dk | TRY 366.82 | 10.07 EUR | | 29 Aralık 17:00 | Türkiye | Trugo | 44.23 kWh | 32 dk | TRY 424.61 | 11.66 EUR | | 29 Aralık 19:33 | Türkiye | Trugo | 55.69 kWh | 36 dk | TRY 534.62 | 14.68 EUR | | 29 Aralık 22:25 | Türkiye | Trugo | 14.80 kWh | 7 dk | TRY 142.10 | 3.90 EUR | | 29 Aralık 23:41 | Türkiye | SC | 51.69 kWh | 35 dk | TRY 366.99 | 10.08 EUR | ## Yazıya Destek Olur da bir gün kendi özgür iradenizle bir elektrikli araç satın almak isterseniz, bu bir Tesla olacaksa referansımı kullanıp indirimden yararlanabilirsiniz:

Order Tesla products Through Gökmen's Referral

Diğer tüm destekleriniz ve sorularınız için iletişim sayfasından veya sosyal medya hesaplarımdan bana ulaşabilirsiniz. ## Kaynaklar 1. Trugo ve Shell ortaklığı ile ilgili [bir kaynak](https://www.shell.com.tr/medya/media-2022/togg-trugo-ve-shell-turkiye-yi-sarj-cihazlariyla-donatmak-icin-guclerini-birlestirdi.html), gelecek planlaması ile ilgili bilgi de mevcut. 2. Sırbistan gümrük kapısındaki kamera yayınlarını [buradan](https://kamere.amss.org.rs/) izleyebilirsiniz. 3. Türkiye ve Bulgaristan sınır kapılarındaki kamera yayınlarını [buradan](https://alltrafficcams.com/) izleyebilirsiniz. 4. Online vinyet satın alma sayfaları: [Çekya](https://edalnice.cz/en/), [Slovakya](https://eznamka.sk/en/), [Macaristan](https://ematrica.nemzetiutdij.hu/), ve [Bulgaristan](https://www.bgtoll.bg/). 5. Mehmet Asır, Sıla Yolu konusunda epey tecrübeli bir insan, [YouTube kanalına](https://www.youtube.com/@MehmetAsir/) bakmanızı öneririm. 6. Bir başka YouTube yayıncısı, [Hüseyin Yoldaş Öztürk](https://www.youtube.com/@hsynozturk35/), o da benim gibi bir MY kullanıcısı. ## Son Söz Şu scooter kullanıyormuşum hissi olmasa aslında elektrikli araçlar güzel de... Şaka bir yana, şuna kanaat getirdim. Bu güzergahta gezilecek, görülecek çok fazla güzel yerler var. Size sorun çıkarmayacak, sizi yarı yolda bırakmayacak, sizi yormayacak; sorun çıkardığında da teknik servisine güvenebileceğimiz bir araç her şeyden daha önemli. Benim tek canımı sıkan, birkaç ülkede şarj istasyonlarının yetersizliğini hissetmek oldu. Resmen benzin kuyruğu gibi sırada bekledik. Onun dışında ne menzil, ne şarj süreleri, hiçbir şey bana problem olarak gözükmedi. Muhtemelen bir Lexus olmadığı sürece Tesla'da kalmaya devam edeceğim. Herkese gönlüne göre bir otomobil dilerim. ### Elektrikli Araçla İlk Tatilim > URL: https://gokmengorgen.net/tr/2024/10/27/elektrikli-aracla-ilk-tatilim/ | Published: 2024-10-27 00:00:00 +0000 UTC | Categories: family | Tags: automobile, tesla Bir haftalık Türkiye tatilimde şehirlerarası yolculuklarda denemek üzere elektrikli araç kiraladım. Şunu gördüm ki, gelecekteki değişim sadece aracın özellikleriyle sınırlı kalmayacak. Kişisel alışkanlıklarımız, beklentilerimiz, yol ve otopark düzenlemeleri, mola yerleri; kısaca yola çıktığımız noktadan varacağımız noktaya kadar uğradığımız veya muhtaç olduğumuz her şeyde bir değişikliğe hazır olmamız gerekiyor. Yazımın sonuna geldiğinizde şaşırmayın diye şimdiden belirtmek istiyorum. Ben elektrikli araçları da, içten yanmalı araçları da seviyorum. Mümkün mertebe araç kiralayıp farklı markalar denemeyi de seviyorum. Elbette tercihlerim var; ancak burada bahsetmeyeceğim. ## Ne Planladık? Aracı Ankara Esenboğa Havalimanı'ndan teslim aldık, Tekirdağ'a yakın bir bölgede tatilimizi yapıp geri dönmeyi planladık. Haritadan baktığımızda yolla ilgili herhangi bir endişemiz yoktu, zaten bu kadar çok sık kullanılan bir yolda da elektrikli araçla ilgili bir sıkıntı yaşayacaksak bu yazıyı burada kesip konuyu kapatabilirdik, elektrikli araç almak deli cesareti olurdu. Benim beklentim oldukça basitti: - Bolu Tüneli'nin gidiş yolu kapalı, alternatif yoldan gidecektik ve şarj istasyonu bulamayabilirdik. Buna rağmen şarj istasyonu denk geldikçe ve ihtiyacım oldukça duracaktım. Başka bir planlama yapmak istemedim. - Bir içten yanmalı aracı nasıl kullanıyorsam öyle kullanmaya devam edecektim. Yani menzili uzatacağım diye 120 kmh ile gitmeyi kesinlikle istemiyordum. Hız limitleri ve trafiğin hızına uyum sağlayarak yolculuğumuzu tamamlayacaktık. Tek şaşırdığım, alternatif yol hep aşağı eğimli olduğu için, bir de trafik ve viraj nedeniyle hızımızı düşük tutmak zorunda kaldığımız için araç 30 - 35 km boyunca elektrik tüketmedi, tam tersine az da olsa regenerative frenleme sayesinde kendini şarj etti. ## Birinci Sorun: Yazılım Kiraladığımız aracın CarPlay entegrasyonu çok kötüydü. Haritayı kaydırmak çalışmıyordu mesela, sağda solda neler var göremiyordum. Ondan daha kötüsü, ters yöndeki şarj istasyonlarını göstermesiydi. Evet, en yakın istasyon o olabilir ama 10 km gidip U dönüşü yapmak, sonra şarj edip tekrar kendi yoluma dönmek yerine, yolumun üzerindeki istasyonları tavsiye etmesini, göstermesini beklediğim çok oldu. Bir başka sorun da aracı çalıştırmadan klimayı açamıyor olmamdı. Doğrusu bunu içten yanmalı araçlarda da yaşıyorum; ama elektrikli araçlarda kontak, START düğmesi vesaire bence çok anlamsız ve sembolik artık. Kucağımda bebek ve sırtımda çanta var, sadece klimayı açmak için: 1. START düğmesine basmam gerekiyor, yetmiyor. 3. Ayağımla frene basmam gerekiyor, o da yetmiyor. 5. Koltukta ağırlık sensörü olduğu için sürücü koltuğuna da oturmam gerekiyor. Klimayı, camları, radyo veya müziği, hatta kameraları telefondan yönetebiliyor olmak, hatta otomobil için ayrı anahtara ihtiyaç duymuyor olmak ne büyük nimetmiş. Kiraladığımız araçta eSIM desteği olmadığı için uzaktan erişmek de mümkün olmadı. Bu tip şeylerin kıymetini yokluğunda anladım doğrusu. En azından aracın şarja ihtiyacı olup olmadığını, ne kadar yol kat ettiğimi telefondan görebilmek isterdim. Uzaktan erişim, güncel navigasyon verisi ve kaliteli yazılım olmadıktan sonra elektrikli aracın avantajını anlamak da, anlatmak da çok zor. ## Tabelalar, Yönlendirmeler Her ne kadar araçlar yazılım teknolojileriyle içiçe hale geldiyse de gözümüz hep yollarda, tabelalarda, ışıklarda. Bir taraftan CarPlay rezaleti ile uğraşırken, öbür taraftan tabelaları takip edip acaba bir sonraki istasyonda şarj edebilecek miyim diye durup durmayacağıma karar vermeye çalışıyordum. Almanya'da tabelalara bakıp elektrikli şarj istasyonu olup olmadığını anlamak mümkün; Türkiye'de ise sadece Dörtdivan'da gördüm şimdilik, o da yetersiz. ![](/images/IMG_2474-1024x768.jpeg) ## Şehiriçi veya Şehirlerarası Evimin park alanında hem AC hem DC şarj istasyonu var. Günlük kullanımda herhangi bir problem yaşamadım. Yakıt ve bakım masraflarının, vergilerin nispeten daha düşük olması şehiriçi kullanım söz konusu olduğunda elektrikli araçları daha avantajlı yapıyor ve bu avantaj Almanya'da Türkiye'ye göre daha belirgin, bu da neden benim elektrikli araç tercih ettiğimi açıklıyor. Ancak çok sık şehirlerarası yolculuk yapan birisi iseniz işin rengi biraz değişiyor. Almanya'da yine çok büyük bir sorun değil; çünkü hem şehiriçi toplu taşıma çok iyi, hem de şehirlerarası elektrikli şarj istasyonu yoğunluğu ülkenin genelinde iyi. Ancak aynı şeyi Türkiye için söylemek şimdilik zor. ## Hesap Kitap Aracı şarj edebilmek için beş uygulama yüklemek zorunda kaldım. Türkiye'de en çok memnun kaldığım uygulama Trugo oldu. Bunda Shell ile işbirliği içinde olmalarının oldukça payı var çünkü Almanya'da da zaten Supercharger bulamadığımda Shell istasyonlarını kullanıyorum. Harcamalarımı şöyle özetleyebilirim, sadece şehirlerarası gidiş ve gelişimi kapsıyor:
TarihSaatKapasiteÜcretŞarj İstasyonu
22 Ağustos15:08 - 15:3422.80 kWh270.72 TRYPleco
22 Ağustos18:31 - 18:5419.64 kWh174.80 TRYoncharge
22 Ağustos19:54 - 20:2626.61 kWh236.83 TRYoncharge
22 Ağustos21:59 - 22:2624.05 kWh230.88 TRYTrugo
25 Ağustos11:34 - 12:2848.49 kWh465.48 TRYTrugo
25 Ağustos14:19 - 15:1043.96 kWh422.05 TRYTrugo
25 Ağustos16:18 - 16:4526.61 kWh255.46 TRYTrugo
Giderken Trugo'nun hesaplı olduğunu biraz geç farkettiğim için dönüşte hep genellikle Trugo tercih ettim. DC şarjlarda 1kWh ücreti bu yolculuk sırasında **9.60 TRY** idi. Giderken toplam **913.23 TRY**, dönerken ise **1142.99 TRY** şarj yüklemesi yapmışım. Tabi iki yönde de yola en az 400km menzil gözükecek şekilde şarjlı çıktığımı belirtmeliyim ve ilk şarjlar dahil değil. Benzinliye göre sağlıklı bir karşılaştırma yapabilmek 100 km'de kaç kWh tükettiğine bakmak en iyisi. Bu konuda okuyucular kusura bakmasın, ben zannediyordum ki Tüketim Grafiği yol boyunca ortalama tüketimimi kaydedecek ve ben günlere göre tüketim ortalamasını görebileceğim. Malesef sadece son 50 km verisini gösteriyormuş ve ben Esenboğa Havalimanı'na aracımı bırakmaya gidiyordum en son. Onun için aşağıdaki ekran görüntüsünde görünen **15.5 kWh/100km** gerçekçi bir veri değil. Benim ara ara şehirlerarası yolculuğumda gördüğüm sayılar 20 - 22 kWh idi; ama ben 25 ve 30 kWh tüketim için ayrı ayrı hesaplamak istedim: ![](/images/img_2482-1.jpg) - Yolumuz yaklaşık **575 km**. - En rahat bulunan şarj istasyonu Trugo idi, onun 1kWh DC ücreti **9.60 TRY**. - Klimalar açık, tüm hız limitlerine uyuldu, yani 130kmh hız limitinin olduğu yerde kaplumbağa gibi 90 ile veya sorumsuz insan gibi 160 ile gitmedik, 130 ile gittik. Tasarruf derdinde olmadık, elbette kurallara da uyduk. - 100 km'de **30 kWh** tükettiğimizde: 575 / 100 \* 30 \* 9.60 = **1656 TRY** - 100 km'de **25 kWh** tükettiğimizde: 575 / 100 \* 25 \* 9.60 = **1380 TRY** - Hadi bir de şehiriçi için fikir versin diye **15.5 kWh** üzerinden iş - ev - şehir merkezine uğrayarak 575 km yaparsak ne kadar tutarmış diye hesaplayalım. Benim eve yakın yerde AC şarj istasyonu var, Trugo değil ama yine de fiyatlar yakın olduğu için onu hesaba katacağım, AC ücreti **6.96 TRY** - DC tercih edilirse: 575 / 100 \* 15.5 \* 9.60 = **855.6 TRY** - AC tercih edilirse: 575 / 100 \* 15.5 \* 6.96 = **620.31 TRY** - Son olarak bir önceki seyahatımda benzinli aracımın şehirlerarası yakıt tüketimi **5.9 litre** idi. Şu anda Shell'de 95 Oktan benzin litre fiyatı **43** TRY'den fazla. Aynı yolu benzinli araçla gittiğimde yol masrafım: 575 / 100 \* 5.9 \* 43 = **1458.78 TRY** - Benzinli araçlarda elektrikli araçların tam aksine şehiriçi yakıt tüketimi daha fazla oluyor. Sadece şehiriçi yakıt tüketimini hatırlamıyorum ama karma tüketim **7.1** litre idi. 575 km'yi iş - ev - şehir merkezine uğrayarak yapsaydım: 575 / 100 \* 7.1 \* 43 = **1755.48 TRY** Bu sayılar çok değişken. Ama ben bu tip hesaplamaları arasıra araç kiralayarak veya kendi elektrikli aracımla test ederek şunu tekrarlayabiliyorum, şehiriçi kullanımda tasarruf yaparak şehirlerarası yakıt tüketimini dengeleyebiliyorum. ## Sonuç Bir yanım manuel vites, atmosferik motor, hidrolik direksiyon arıyor, otomobil kullanmanın zevkini alarak seyahat etmek istiyorum. Diğer yanım ailemin konforunu düşünüyor ve kendi zevkimden feragat etmek zorunda kalıyorum. Uzun yolda gürültünün ne kadar yorucu bir şey olduğunu elektrikli araç kullanınca fark ettim. Herhalde otonom teknolojiler geliştikçe araç kullanmak diye bir şey kalmayacak. Elektrikli araçların bu tip avantajları zamanla içten yanmalı araçlara entegre edildikçe, o aradığım sürüş zevki iyice yok olacak. İyi mi kötü mü bilemiyorum. Şarj istasyonu ağının henüz yeterli seviyede olmadığını göz önünde bulundurmak gerekiyor. Biz tatilimizde Longoz Ormanları'na bu yüzden gidemedik, şarjsız kalma riskini göze almak istemedik. Onun dışında yolların asfalt olmasına özellikle dikkat ettim çünkü aracın altı bildiğiniz bataryadan ibaret. Bozuk köy yollarında taş veya görmediğiniz tümsekliğin bataryaya zarar vermesini istemezdim. Son olarak, eğer elektrikli araç almayı düşünüyorsanız, sosyal medya ve forumlardaki fanatik yorumlara gözünüzü kulağınızı kapatsanız hiçbir şey kaybetmezsiniz. Bazı şeyleri zamana bırakmak gerek, geleceğimizi fanatikler değil; deneyimli kullanıcılar, deneyimli servisler, yaşadığımız sıkıntılar ve alışkanlıklarımız belirliyor. ### Lost in Conversation > URL: https://gokmengorgen.net/tr/2020/03/28/lost-in-conversation/ | Published: 2020-03-28 00:00:00 +0000 UTC | Categories: remote-working _Bill Murray’ın Scarlett Johansson ile birlikte oynadığı 2003 yapımı Lost in Translation filmini, bu karantina günlerinde izlemenizi tavsiye ediyorum. Ben seneler önce ilk izlediğimde çok sıkılmıştım; ama sonra tekrar tekrar, severek izledim ve bir şekilde hayatımda yer edindi. Bu yazının başlığını oradan türettim._ 2018'de Berlin’e göç ettik. Eski iş arkadaşımın tavsiyesiyle merkeze uzakta yaşamaya karar verdik. Aileye uygun, bizi tatmin eden bir ev bulduk. Evimize beş dakika yürüme mesafesinde olan kreş de kızımızı kabul edince kendimizi epey şanslı hissettik. Ofise gitme zorunluluğum olmadığı için istediğim yerden çalıştım. Eskiden ev dışında kütüphane ve Bäckerei denilen kafelerde çalışmak mümkünken, şimdi evden çalışmak tek seçenek. Bu yazıyı yazdığım gün yaklaşık üç haftalık gönüllü karantinayı, stoktaki eksikliklerimizi tamamlamak üzere deldik ve sonrasında karantinaya devam edeceğiz. Yıllar sonra bu yazıyı okuduğumda, herhalde Covid19'u unutmam; ama bu günlerde başka nelerle uğraştığımı da iyi hatırlamak isterim. 2019 yılı Temmuz ayında doktora gittim ve yaşadığım sağlık sorunlarının çözümü için doktorum ameliyat olmamı tavsiye etti, bir cerraha yönlendirdi. Tedaviye başladık ancak sürecin ortasında bir virüs salgını yüzünden eve kapandık. Eşimin arkadaşı bir gece bizi arayıp “Size eşyalarımı bırakacağım, ben Çin’e dönüyorum.” deyince, Almanya’daki durumun ciddiyetini kavradık, Çin o dönemde daha iyi durumdaydı. Ardından seyahatler yasaklandı, tuvalet kağıdı bulamaz olduk, markete girmeden önce içerideki insanların çıkmasını bekledik, el teması olmaması için nakit kullanmaz olduk. En kötüsü, ameliyat olacağım hastane kapandı, tedavim durdu, uçak biletlerim iptal oldu, katılmak istediğim etkinlik ertelendi, buluşmayı planladığım arkadaşlarla buluşamadım. Muhtemelen yaz tatilimizi de iptal edeceğiz. Benim karantinam tecrit gibi geçiyor. 8 yıllık uzaktan çalışmanın hiçbir döneminde böyle bir psikolojiyi deneyimlediğimi hatırlamıyorum. Normal zamanda birisi bana üç hafta evden çıkmadan durabilir misin dese bunu rahatlıkla yapabileceğimi söylerdim; ama dışarıda bir tehdit olduğunu bilmek başka bir duygu. Bu dönemin kendine özel sıkıntıları var; neyse ki çözümsüz değil. Şuanda yaşadığım en büyük sıkıntı, **hareketsizlik**. Çok fazla oturuyorum ve üniversite zamanlarımdan kalma, gitarın omzumda bıraktığı ağrıyı tekrar hissetmeye başladım. Çalışırken kullandığım bir oyuncu koltuğum var, rezalet. Bu koltuklar çok rahat; uzun süre bilgisayar başında oturmanıza yardımcı oluyor. Bu koltukların tek avantajı, bir taburede bile uzun süre oturma kabiliyetiniz varsa, oradan gelecek olan hasarı minimize etmek. Ama esas sorunu çözecek olan şey hareket etmek, hareketsiz saatlerce oturmamak. Ayrıca bu koltuklar genelde sıcak günlerde terin sırtınızda birikmesine veya kurumasına sebep oluyor. Hala koltuk arayışındayım, **Varier Variable Balans** almayı düşünüyorum. İkinci büyük sıkıntı, **duyguların kısa süreli ve sürekli olarak dışarıdan gelen şoklarla değişmesi**. Şok Doktrini kitabında bir işkence metodu olarak, günlerce karanlıkta ve hapiste kalmış insanların, ani bir ışık ve yüksek gürültüye maruz bırakılması ve bunun belirli aralıklarla sürekli yapılması anlatılıyordu. Bunun kıyaslamasını yapmak çok haksızlık olur, farkındayım. Ama şöyle düşünün, akşam işiniz bittiğinde, kahve veya çay içerken hafif bir beyin yorgunluğu oluyor ve tam da bu zamanda dinlenip enerji toplamak yerine, online medya kaynaklarından gelen haberlerle duygusal şoklar alıyorsunuz. Paylaşımlar çoğunlukla üzücü, şikayet dolu, negatif duygular içeriyor. Hep iyi şeyler okumak da sıkıntılı. Modunuz iyiyken canınız bir şeye sıkılabiliyor, kötüyken birden canlanabiliyorsunuz. Çözmeniz gereken sorunları, hoşunuza gidecek paylaşımlar okuyarak unutup erteleyebiliyorsunuz. İnsanın duygusal stabilite için bazen gerçekten offline olması, yalnız kalması gerekiyor. Bir diğer sıkıntı da **erişilebilirliğe gereken önemin gösterilmemesi**. Benim özellikle herkesin uzaktan çalıştığı bu dönemde beklentim, iş yaparken erişilebilirliğin artmasıydı; ama şuan gördüğüm kadarıyla ters istikamette seyrediyor. Herkes toplantılardan şikayetçiydi, bu toplantılar niye sıklaştı ve uzun hale geldi? Zaten Slack başıma belaydı, şimdi yerini Zoom’a bırakmış gibi. Anlık iletişim araçları üzerinden işin detaylarını konuşup, sonra “toplantıda konuştuğumuz gibi” diye bir görev açıklaması yazılmamalı. Text, erişilebilirliği en yüksek iletişim yöntemi. Unutmak diye bir şey yok, istediğin zaman okuyabilirsin, istediğin zaman cevap yazabilirsin. Konuşmak istediğinde bile on dakikada anlatacağın işi iki dakikada anlatmana yardımcı olur, toplantı süreleri kısalır. Niye yazmak ve okumak sevilmiyor, anlamıyorum. Beden sağlığı, duygusal balans, ve erişilebilirlik. Bu üç şeyi ne kadar iyi çözerseniz, uzaktan çalışmak o kadar verimli ve zevkli, iletişim o kadar kolay ve güzel. İsterdim size önerilerle geleyim; ama herkesin durumu kendine özel. ### Geliştiriciler için Windows 10 Pro > URL: https://gokmengorgen.net/tr/2017/12/10/gelistiriciler-icin-windows-10-pro/ | Published: 2017-12-10 00:00:00 +0000 UTC | Categories: software-engineering | Tags: operating-systems, windows _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](https://twitter.com/gokmengorgen/status/931072726407708672) 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](https://conemu.github.io/) var. KDE’deki Yakuake gibi Quake-style kullanmak isterseniz [cmder](http://cmder.net/) var. Zsh’siz olmaz derseniz [Babun](https://babun.github.io/) var. Bana Bash yeter derseniz de Git ile birlikte gelen Bash var. Bana bir SSH yeter derseniz [Bitvise ve Putty](http://www.putty.org/) var. Seçenek çok. # Paket Yöneticileri ![](/images/ms_store-1024x536.webp) - 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](https://git-scm.com/download/gui/windows) 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ü](https://stackoverflow.com/questions/2517190/how-do-i-force-git-to-use-lf-instead-of-crlf-under-windows#13154031) 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](https://twitter.com/ahmetpirimoglu/status/899727196205576197) cevaplarına bir göz atınız. # Sanallaştırma ![](/images/image.png) 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 > URL: https://gokmengorgen.net/tr/2017/07/01/vagrant-ile-proje-gelistirme/ | Published: 2017-07-01 00:00:00 +0000 UTC | Categories: software-engineering | Tags: vagrant 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: ```bash $ vagrant up ``` 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](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](https://github.com/gkmngrgn/vagrant-skeleton) ```ruby # -*- 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 ``` `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ı? > URL: https://gokmengorgen.net/tr/2017/04/24/emacse-nereden-baslamali/ | Published: 2017-04-24 00:00:00 +0000 UTC | Categories: software-engineering | Tags: emacs 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 [Spacemacs](http://spacemacs.org/), [StarterKit](https://github.com/technomancy/emacs-starter-kit) 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.
![](/images/spacemacs-1024x533.webp)
_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](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](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](https://github.com/emacs-helm/helm) 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](https://youtu.be/qXw0ocR_XBI) 2. Üstün Özgür, “Emacs: Özgür Yazılım Devriminin Editörü”, [https://youtu.be/FsN3Yp05\_aQ](https://youtu.be/FsN3Yp05_aQ) 3. Örnek config dosyası: [https://github.com/gkmngrgn/emacs-config/blob/master/init.el](https://github.com/gkmngrgn/emacs-config/blob/master/init.el) 4. Spacemacs projesi: [http://spacemacs.org/](http://spacemacs.org/) 5. Awesome Emacs: [https://github.com/emacs-tw/awesome-emacs](https://github.com/emacs-tw/awesome-emacs) ### Göç > URL: https://gokmengorgen.net/tr/2016/10/01/goc/ | Published: 2016-10-01 00:00:00 +0000 UTC | Categories: lifestyle | Tags: istanbul _Bir arkadaşım, “Metroya binerken yüzü gülen insan görmüyorum.” demişti. İstanbul’a geldim geleli, insanların gözlerinin içine baka baka yürürüm. Yüzlerdeki ciddiyet, bana zihinlerinde çok farklı şeyler gezindiğini hissettiriyor. Sanki yüzleriyle zihinleri arasındaki bağlantılar kopmuş gibi. Bu o kadar bulaşıcı bir şey ki, ben de çoğu zaman pek gülümsemiyorum._ Katre adında bir kadın. Bir bankacı, sabahı ve akşamı belli. Kahvaltısı bir poğaçadan ibaret, ancak yürürken yiyebiliyor, bir on dakikalık yürüme mesafesinden sonra metrobüse, oradan aktarma yapıp metroya binecek, sonrasında yine bir beş dakika daha yürümesi gerek. Diğer birçok işe giden insanlarla aynı vakitte işte olmak ve aynı yoldan gitmek zorunda olduğu için kendini kalabalığın ve telaşın içinde buluyor. Bu kadar zamandır işe gidip geliyor ve her gün binlerce insanla göz göze geliyor; ama bir gözü bir kere daha görebildiğini pek hatırlamıyor.
_Bu yazı, bu şarkıdan önce biter._
Katre, karşıdan karşıya geçmek için araçların yol vermesini bekliyor. Yok hayır, bu İstanbullu için çok komik bir senaryo oldu. Doğrusu şöyle olmalı: Katre, adımlarını zihninde öyle hesapladı ki, karşıdan karşıya geçerken durma ihtimali yüksek bir sürücüye denk getirdi ve kaldırımdan yola adımını attıktan sonra artık sürücüyle göz temasını kesti, dikkatini duymaya verdi. Sürücü de “Sen bana bakmıyorsun; ama ben sana yol vermek istemiyordum, bana resmen üstünlük taslamış gibi hareket ediyorsun.” dercesine tüm hızıyla yaklaşıp son anda frene basıyor. Katre karşıya geçmiş, sürücü de yoluna devam etmiş oluyor; ama zihinlerinde çok başka senaryolar var. Katre içinden “Ezseydin bir de!” diyor, sürücü bağırıyor, laf atıyor. Katre dikiz aynasını kırmak istiyor, sürücü ezmek…
![](/images/alt_gecit-1024x576.webp)
_En sevdiğim alt geçitlerden biri. Biraz ürkütücü._
Ben uzun boyluyum, dolayısıyla adım mesafelerimin daha uzun olmasını, daha hızlı yürüyebileceğimi varsayıyorum. **İstanbul’da kadınlar erkeklerden daha hızlı yürüyor**. Bazı kadınları geçmek için koşmam gerekiyor. Katre de öyle yürüyor. Erkek hegemonyasının içinde kendini güvende hissetmediği için mi bu böyle? İşe her gün geç kaldığı için mi? Yoksa burada herkes hızlı yürüyor, öyleyse ben de hızlı yürümeliyim diye düşündüğü için mi sadece? Bir kere yavaş yürümeyi denedim. Yüzüme bakıp uyaracak kimseye denk gelmedim; ama omzuma dokunup, elime çarpıp başını çevirmeden geçip giden çok oldu. Sanki, hayallerinde kolumdan tutup kenara çekip sorguya çekmek istiyorlardı da, gerçekte sadece bunu yapabilmişler gibi. Bir kere yürüyen merdivenin solunda durmayı denedim, bir kadın söylene söylene yanımdan geçti. Bir keresinde de bir öğrenci önümü keser gibi yapıp geçti yanımdan. Kuralların olması hayatın akışını kolaylaştırmak için iyi şeyler de, burada çok başka bir durum söz konusuydu. Burada daha çok insanlar kendi içinde biriktirdikleri öfke ve nefreti bir bahane bularak boşaltma ihtiyacı duyuyordu. Tıpkı metrobüsün şoförüne [şemsiyeyle saldıran yolcu](https://www.google.com.tr/webhp?sourceid=chrome-instant&ion=1&espv=2&ie=UTF-8#q=metrob%C3%BCs+kazas%C4%B1+%C5%9Femsiye&tbm=nws&pws=0) gibi. Sorsak Katre’ye neden hızlı yürüyorsun diye, bir cevabı yok belki de. Sabah yarım saat daha erken çıksa yine hızlı yürüyecek, önüne çıkan engele yine omzundan ittirerek tepkisini gösterecek; ama hayalinde ona kıçından tekmeyi basacak. O da diğer yürüyen herkes gibi bunu arzulayacaktı.
![](/images/otobus_kazasi-1024x768.webp)
_Tekirdağ plakalı, welcome to İstanbul! Bir şemsiye darbesiyle sanat eseri çıktı ortaya._
Her gidişin bir de dönüşü var. Katre, dönerken “Yer yok kardeşim, buraya yanaşma.” diyen insanların kapıya dizildiği yerden metrobüsün içine atlayıp “İşte bak, yer varmış.” diyerek diğer yolcularla sanal kavgaya tutuşacak, her gün olduğu gibi metro çıkışlarında, girişlerinde asansörü deneyecek. Asansör meselesine gelmişken yine bir hikayemi anlatmak isterim. İTÜ / Maslak’a giden metronun en arkadan bir önceki vagonundan inilince asansörün olduğu araya denk geliyorsunuz. O vagondan inenler, diğer vagonlardan inenlerden daha hızlı adım atarlar. Hızlı adım atanın esas nereye varmak istediği biz İstanbullu çalışan sınıfının kabak gibi bilebileceği şeylerden biridir. Bir keresinde ben bunu taklit ettim. Metro durunca vagon kapısından fırladığım gibi yürüyen merdivenlere yöneldim. Sürü psikolojisine güzel bir örnektir. Katre’nin kullandığı bu yollar tam bir dövüş arenası gibi. Yaşlılara yer yok, çocuklar servis araçlarına mahkum, engellilerin durumu hakkında çok bir bilgim yok. Simto Alev’in [yıllar süren kaldırım direği hikayesi](http://www.simtoalev.com/6-ayda-2-baba-dikemedik/) aslında bir özet gibi. Normal bir insanın empati eksikliği yüzünden hiç önemsemediği minik şeyler bu şehri sadece belli kalıplara uyan dar bir kitlenin rahat yaşayabilmesine imkan tanıyor. Nüfusu İstanbul’un onda biri olan Zürih’te gördüğüm engelli sayısı burada gördüğümden çok daha fazla. Oranın da tehlikeli mahalleleri var, orada da sokakta yaşayan dilenciler, yere çöp atan sorumsuzlar, ırkçı tavır takınan insanlar var; ama orada engelliler dışarı çıkabiliyorlar, kaldırımlar tekerlekli sandalyeyle çıkılabilecek yükseklikte, hayvanat bahçesinde kendi başlarına takılabiliyorlar, **çocuklar kaldırımda scooter kullanabiliyor**. Çok üzgünüm; ama yaşını başını almış bir engelli görememenin sebebi hakkında [söylenenler doğru olabilir](https://seyler.eksisozluk.com/cevremizde-neden-hic-yasini-basini-almis-zihinsel-engelli-birini-gormuyoruz). Vebali Katre ve benim, hatta siz değerli okuyucumuzun boynuna.
![](/images/muhammed_ali.webp)
_“Yeneceğim seni, İstanbul!” diye arattım, bu çıktı._
Sizi bilmem ama Katre’de benden izler var. Her işe gidip geldiğimde, sürekli etrafa negatif enerji yayan insanlar var ve haliyle ben de istemeden yayıyorum. Biraz gülümsemekten ne zarar gelir? Serdar Kuzuloğlu’nun [bir blog yazısında](https://www.mserdark.com/turklerin-ortak-nefreti-turkler/) dediği gibi, **gülmek sadece selfie çekince aklınıza gelmesin**. İçinizden gelmese bile gülümseyin. Bir deneyin. Hatta bir gülen insanlar hareketi başlatalım. Gülümseme hareketi, tebessüm hareketi, ismi ne olursa olsun. Yapacağımız tek şey arada bir yüzümüzü kontrol etmek. _Bu yazının başlığını, Selçuk Şirin’in jüri üyesi olduğu_ [_bir yarışmanın_](http://www.kisakes.org/pitching-1) _temasından aldım. Göçle ne alakası var bu yazının bilmiyorum; ama o yarışmayı duyduğumda aklıma bunlar gelmişti. Öyle sanıyorum ki, bu_ **_işini sevmeyenler memleketi_**_nde koşturup duran insanların (işini sevenler dahil) akıllarından en az bir kez bu hayat silsilesinden bıkıp göç etmek geçmiştir._ ### Kitapları Sanallaştırmak > URL: https://gokmengorgen.net/tr/2016/07/09/kitaplari-sanallastirmak/ | Published: 2016-07-09 00:00:00 +0000 UTC | Categories: lifestyle | Tags: ebook, kindle Geçen gün esas niyetimi fazla açıklamadan Twitter üzerinden, kitapları dağıtırsam pişman olup olmayacağım üzerine bir soru sordum: > Siz olsanız evdeki kitapları dağıtmaktan pişman olur muydunuz? Bundan sonra sadece ebook alan biri olarak soruyorum. Seçimler arasında çok bir uçurum olmaması beni bir süre kararsız bıraktı; ama cevap olarak yazılanlar faydalı oldu. Özetlemek gerekirse: 1. Kitap kokusu, kitabın eskiyen sayfalarına dokunmak gibi romantik duygularla pişman olurdum diyen kesim var. Elbette bunu savunana saygım sonsuz; ama benim için hiç ikna edici değil. 3. Bir önceki maddeye benzer, ama daha çok okuyucunun üzerinde bıraktığı iz nedeniyle kitabı basılı olarak rafta tutmayı tercih eden kesim var. Bu benim açımdan anlaşılabilir neden. Eski şarkıların, dinleyicinin kendi geçmişiyle ilgili bir an barındırması gibi, daha sonra tekrar hatırlandığında, sayfalar karıştırıldığında okuyucuya güzel duygular hissettirebilir. Bu da benim için kitabı dağıtmamam için ikna edici olmadı. Mesela Alacakaranlık Kuşları’nın e-kitabını **bulabilirsem**, yine aynı hissi yaşarım gibi geliyor. 5. Bir kesim, kitabı saklamak ve istediğin zaman erişebilmek konusunda e-kitabın basılı kitaplar kadar başarılı olmadığını söylüyor. Bu benim için endişe verici bir ayrıntı oldu. Amazon batarsa, Kindle’da DRM-Free olmayan kitaplarımıza nasıl erişeceğiz? Bir arkadaşım, Amazon’un istediği zaman Kindle’imizdaki satın aldığımız kitabı silme hakkına sahip olduğunu [söylüyor](https://twitter.com/zekzekus/status/751025245889392640). Bir de DRM-Free olsa bile Amazon, Kindle’daki bir kitabı dışarı aktarmana [izin vermiyor](http://www.wetasphalt.com/content/you-cant-download-your-mobi-files-amazon-anymore-even-if-theyre-drm-free). Kısaca, e-kitaba sahip olabilmek sıkıntılı. 7. Bir kesim de tamamen mantıksal açıdan, e-kitap ile basılı kitap arasında hiçbir işlev farkı olmadığını söylüyor. Bu da benim için ikna edici değil. Mesele işlevi değil, birbirini ne derece ikame edebildiği. Bir önceki maddede yazdığım gerekçeler nedeniyle e-kitaba sahip olabilmek, basılı kitaba sahip olabilmek kadar kolay değil. 9. Bir de Osmanlıca yazılmış tarihi kaynaklar gibi, bazı kitapların elektronik versiyonu olmasının çok çok düşük olasılık olduğunu söyleyenler oldu. Şimdiye kadar hiç öyle bir kitabım olmadığı için bunu da geçtim. Benim soruyu sormaktaki amacım şuydu: Evde bulunan fazla eşya beni rahatsız ediyor. Çok fazla giysim yok, çok fazla eşyam yok, çok sık kullanmadığım ne varsa elden çıkarmayı tercih ediyorum. Sahip olduklarımı da bozulana, işlevini görmeyene kadar kullanmayı seviyorum. Tenhalık bana huzur veriyor. Ama kitap konusu, evde bu kriterlere uymayan belki de tek şey. Hem çok nadiren baktığım, kullandığım, hatta hiç yüzüne bakmadığım kitaplar var; hem de onların orada bir şekilde durması hoşuma gidiyor. Hoşuma gidiyor ama bir taraftan da bunların e-kitap olarak cebimde, her zaman erişebileceğim şekilde olması daha iyi olmaz mıydı diye kendi kendime soruyorum. Evde atılacak başka eşya kalmamış gibi bunlara takmış olmam benim sorunum. Ama e-kitap konusu güven veriyor olsa, sanırım bunu denerdim. Sonuç olarak, sahip olmak istediğim kitapları tutmaya, istemediklerimi de dağıtmaya karar verdim. Bu arada yeri gelmişken gelecek öngörümü de belirteyim: Evlerin metrekareleri daha da düşecek, konteyner hizmetleri değerlenecek, mobil yaşam diye bir kültür bu topraklara da gelecek. ### Uzaktan Çalışmak > URL: https://gokmengorgen.net/tr/2016/05/23/uzaktan-calismak-remote-working/ | Published: 2016-05-23 00:00:00 +0000 UTC | Categories: remote-working | Tags: coworking Bağımsız çalışmak (freelance) ile uzaktan çalışmak (remote) çok karıştırılıyor. Bağımsız çalışanlar aynı zamanda uzaktan çalışıyor veya uzaktan çalışanlar fiziki bir ofise sahip bir şirkette çalışıyor olabilir. Yani uzaktan çalışıyor olmanız, sizi bağımsız çalışan (freelancer) yapmıyor. Ben yazılımcıyım. Bağımsız çalışmak konusunda çok deneyimim yok. Bu konudaki gözlemim, en azından Türkiye’de hem işi verenin, hem de işi yapanın çok da profesyonel davranmadığı. Bağımsız çalışmak ayrı bir disiplin gerektiren, kendine özgü şartları ve anlaşması olan, hobi veya ek iş olarak bakılamayacak kadar ciddi bir çalışma biçimi. Fatura nasıl keseceksiniz, vergi nasıl ödeyeceksiniz, gelirinizi devlete nasıl beyan edeceksiniz, etmeyecekseniz neye güveneceksiniz, alacağınızı tahsil edemediğinizde ne yapacaksınız, sağlık sigortanız ne olacak? Bu konu, ayrı bir yazının konusu olabilir; ama dediğim gibi Türkiye’de serbest çalışmak, yaşam standardını para karşılığı düşürmekten başka bir şey değil. Serbest çalışmak istiyorsanız, günde 8–9 saat mesai gerektiren bir iş **yapmamalısınız**. Uzaktan çalışmak ise, bana göre herkesin muhakkak deneyimlemesi gereken bir şey. İstanbul metropol bir kent. Zaman trafikte harap edilemeyecek kadar kıymetli. Ben yazılım firmalarının yakın zamanda mülakatlarda “Uzaktan çalışma deneyiminiz var mı?” diye soracaklarını düşünüyorum. Örneğin Crossover tamamen uzaktan çalışmaya uygun iş pozisyonları için çalışan arayan bir platform ve Türkiye’de faaliyete geçti. Hiç mülakatlarına katılmadım; ama eminim bu soruyu soruyorlardır. İnternet artık sesli ve görüntülü konuşma yapmak için daha elverişli (en azından telefonla konuşmaya tercih edilebilir durumda), ortak çalışma alanları (co-working space) artık eskisinden daha yaygın. Gürültüden etkilenmiyorsanız, bir kafede kahve içerken saatlerce oturup işinizi yapabilirsiniz veya evinizin bir odasını çalışma odasına çevirebilirsiniz. Peki, uzaktan çalışmak ile şirket ofisinde çalışmak arasındaki tek fark çalışma ortamı mı? Hayır. Şirket ofisi size şunları da sağlar: - Susadığınızda su her zaman var. Çay, kahve çoğunlukla hazırdır. Oda temizlik hizmeti size bedava, bulaşık derdi yok, tuvalet kağıdının bitmesi neredeyse imkansız, acıkırsanız yemek yiyebileceğiniz yer size çok yakındır. - Ofise gittiniz ve internetiniz veya elektriğiniz yok, bu şirketin problemi. Gidip başka bir çalışma ortamı aramak zorunda değilsiniz. Çünkü çalışmak zorunda olduğunuz yerde herkesin elektriği, interneti aynı anda kesilmiştir! - Hastaysanız muhtemelen ofisteki klimadan hastalandınız, zehirlendiyseniz muhtemelen yemekhanedeki bir yemek size dokunmuştur. Geneli böyle olduğu için size pek bir soru sorulmaz. Bir rapor alırsınız, iyileştiğinizde şirkete iletirsiniz. - Ofisteyseniz, çalışıyorsunuzdur. Değilseniz, çalışmıyorsunuzdur, **çalışmamalısınız**. Bu kadar net. - Ofisin kuralları vardır, beraber vakit geçirdiğiniz insanlara karşı saygılı olursunuz. Sosyalleşirsiniz, samimi arkadaşlıklarınız olur. İşinizde yardımlaşır, iş dışında haftasonu piknik, kamp planları yaparsınız. Bu şekilde anlatınca ofiste çalışmak uzaktan çalışmaktan daha iyiymiş gibi oldu, farkındayım. Uzaktan çalışmak imrenilen, özenilen, çok basit bir şeymiş gibi göründüğü için, önce neleri kaybedeceğinizi anlattım. Peki bu durumda uzaktan çalışmayı neden tercih edersiniz? Cevap basit. Genelde siz tercih etmezsiniz, koşullar onu gerektirir. Şirketiniz yurtdışında olabilir ve siz henüz yurtdışına çıkış şartlarınızı sağlamamış olabilirsiniz. Şirketiniz işinizde daha verimli olmanız için, çalışma ortamı tercihinizi size bırakabilir. Eve gidip gelirken harcadığınız zamanı spor yaparak veya ailenizle birlikte geçirmek, ertesi gün daha verimli olmanızı sağlayacaksa; ofise gelmekle evden çalışmak arasında bir fark görünmüyor ve şirket de masrafları kısıp çalışanın maaşına zam yapmayı düşünürse (ki her ne kadar klasik bir yaklaşım olsa da para iyi bir motivasyon aracıdır) şirket uzaktan çalışmayı çalışanları için bir seçenek olarak görebilir. Siz elinizde bu imkan varsa yararlanırsınız. Uzaktan çalışan arkadaşlarımın en çok şikayet ettiği konulardan biri yalnızlık. Etrafınızda çoğu zaman muhabbet edebileceğiniz, beraber çay içebileceğiniz bir insan olmuyor. İş yapmadan zaman geçmiyor, kendi kendinizi motive etmek, kendi disiplininizi sağlamak zorundasınız. İş dışında kalan zamanlarınızı nasıl değerlendirdiğiniz daha bir önemli oluyor, sosyalleşme ihtiyacı duyuyorsunuz, hobiler daha bir anlam kazanıyor. İş bitsin, eve geçeyim demek yerine, daha bir kendinizi dışarı atmak için can atıyorsunuz. Buna ne kadar çabuk alışırsanız, uzaktan çalışma gerektiren işlere psikolojik olarak o kadar çabuk uyum sağlarsınız. Bu konu üzerine benim söyleyebileceklerim bunlar. Uzaktan çalışmaya başladığınızda iletişim araçlarına hakim olmak, zamanı yönetmek, hatta akşamları veya haftasonları yapacağınız aktiviteleri tekrar gözden geçirmek önem kazanacak. Son olarak, bu konuyla ilgili daha önce yazılmış paylaşımlara göz atmanızı öneririm: - [Remote Work](https://speakerdeck.com/farslan/remote-work), Fatih Arslan - [Evden Çalışmak](https://medium.com/turkce/evden-%C3%A7al%C4%B1%C5%9Fmak-e8429a7966bb), Abdullah Uğraşkan - [Maaşlı İşini Bırakıp Kendi İşini Kurmak Üzerine Düşünceler](https://medium.com/@osmanun/maa%C5%9Fl%C4%B1-i%C5%9Fini-b%C4%B1rak%C4%B1p-kendi-i%C5%9Fini-kurmak-%C3%BCzerine-d%C3%BC%C5%9F%C3%BCnceler-34a94bd72659), Osman Ungur - [Uzaktan Çalışmak](https://ufukuzun.wordpress.com/2015/05/17/uzaktan-calismak-remote-working/), Ufuk Uzun - [Remote](https://37signals.com/remote/), 36Signals ([Burada](http://tauslu.com/2015/06/kitap-tanitimi-remote-office-not-required/) Tayfun Uslu’nun incelemesi var) ### Not Tutma Alışkanlığı Kazanın > URL: https://gokmengorgen.net/tr/2016/02/06/not-tutma-aliskanligi-kazanin/ | Published: 2016-02-06 00:00:00 +0000 UTC | Categories: lifestyle | Tags: düşünce, not tutma Amir’in [**Reactive vs. proactive development**](https://medium.com/hacking-and-gonzo/reactive-vs-proactive-development-180017c47fda) yazısını okuyunca (hayır, reaktif / proaktif programlama paradigmaları ile ilgisi yok), benimsediğim yaklaşım daha bir pekişti. Ben sadece işte değil, hayatımla ilgili verdiğim birçok kararda proaktif bir yaklaşım içinde oluyorum; ama olası bir krizde ne yapacağımızı da iyi bilmek gerekiyor. Bu zamana kadar hiç kapıda anahtar unutmamış olmam, bundan sonra da unutmayacağım anlamına gelmiyor. Bir örnek üzerinden gidelim. Öğrencisiniz, bir sebepten sınavlara çalışamadınız, son günündesiniz. Ne yapmalı? Eğer biraz proaktif olabilseydiniz şunları yapabilirdiniz: 1. Her şeyden önce dersi dinlerdiniz. Hocanızın önemini vurguladığı yerleri not alırdınız. Altını renkli kalemle çizer, haftasonları bir göz atardınız, konuları pekiştirip bir dahakinde çabuk anlardınız. 3. Kendinize en çok fayda getirecek çevreyi seçer ve üyeleriyle aranızı iyi tutardınız. 5. Dersi geçmiş arkadaşlarla irtibat kurup önerilerini dinlerdiniz vesaire. 7. Aynı sınıftakileri davet ettiğiniz bir Whatsapp grubu kurardınız veya var olan gruba katılırdınız. Sosyal bir grupta olduğunuz için aldığınız kadar vermeye çalışırdınız. Ama şimdi çalışmadınız ve krizdesiniz, ne yapabilirsiniz? 1. Kahve - kola karışımı denersiniz, bütün gece sınavı geçmenizi sağlayacak kısımlara çalışırsınız. 3. Sınavla ilgili herhangi bir duyum, tüyo var mı araştırırsınız. 5. Sınavda kopya çekersiniz. 7. Dersi bırakır, ümidinizi kaybedersiniz. İş hayatında da benzer tecrübeler yaşıyoruz. Krizin olmaması için önlemler almak gerekiyor; ama kriz olduğunda da elimiz kolumuz dolanmaması gerekiyor. Sakince düşünüp, o krizi çözebilecek en iyi yöntemi bulup uygulamak gerek. Reaktif modu krizden çıkmanıza yardımcı olur, proaktif modu ise krizi önlemenize. Benim en çok sıkıntı çektiğim konular öncelikleri sıralama ve işin kapsamını zamana göre daraltma. Bunun için not alma alışkanlığımı geliştirmeye çalışıyorum. Şöyle bir akış diyagramı düşünün: 1. Uzun emek isteyen bir işin ortasındasınız. Proaktif moddasınız. Bıraksanız, tekrar başlamanızın maliyeti en az 1 saat. 3. Bir iş geldi, ne yapmalı? Reaktif moda gir: 5. Eğer acil değilse not al. Basitçe bir not, iş açmak, kendine atamak falan değil. Not defterine tek satır yazmak bile olur. 7. Eğer acilse, bu sefer şuan yaptığın işin en son kaldığın yeri not al. Ben en son bilmemne işini yapmak için bir modele yeni bir field ekledim ve migrationları yapıyordum, bundan sonraki iş bu özelliği arayüzde kullanılabilir hale getirmek gibi. 9. Aciliyetine göre önünüzdeki işi bitirdin, sırada ne var? Notlara bak ve önem sırasına göre bitir. 11. Notlar bittiyse, iş takip sistemindeki işlere geri dön. 13. Bu döngüyü her iş için devam ettir. Bu döngü, anlattığım kadar basit olmayabiliyor. Hele ki proaktif moddan reaktif moda geçiş sanıldığı kadar kolay değil. Ama basit notlar tutmayı mutlaka deneyin. Ben bunun için Evernote kullanıyorum. ![](/images/multitasking_tiny.gif) Unutmamanız gereken iki şey var. Birincisi, eğer siz de benim gibi müzik dinleyerek iş yapıyorsanız, beyniniz artık daha fazla işi bir arada kaldıramaz. İnsan beyninin çoklu işleme elverişli olmadığı konusunda çeşitli yazılar var, [**Multitasking is killing your brain**](https://medium.com/life-tips/multitasking-is-killing-your-brain-79104e62e930) başlıklı yazıyı okumanızı öneririm. İkinci önemsemeniz gereken şeyse, stresiniz. Stres hormonu olarak bilinen kortizol belli bir seviyenin üstüne çıktıkça iş veriminiz bundan oldukça olumsuz etkilenecek. [**Günümüzün Seri Katili: Stres!**](https://medium.com/turkce/g%C3%BCn%C3%BCm%C3%BCz%C3%BCn-seri-katili-stres-7573e5e90e4d) başlıklı yazı da stresle ilgili ikinci önerim. İşleri önem sırasına göre sıralamak, zaman sınırını göz önünde bulundurarak işi iyi planlayarak yapmak ve işi teker teker yapmayı deneyin. Böylece bitmiş olan işler, bir sonraki işleri de aynı motivasyonla bitirmenize katkıda bulunur. Müsait olmadığınız zamanda da çevrenizdekilere hayır demeyi bilin. ### Zurna da Olsa Enstrüman Çalınız > URL: https://gokmengorgen.net/tr/2016/01/25/zurna-da-olsa-enstruman-caliniz/ | Published: 2016-01-25 00:00:00 +0000 UTC | Categories: entertainment, hobbies | Tags: müzik Enstrüman çalmak bir insanın kendi hayatına yapabileceği en güzel yatırımlardan biridir. Sıkıntılı olduğunuzda moraliniz düzelir, öfkeli olduğunuzda sakinleşirsiniz. Hayatınızda boş vakit nedir, boş durmak nedir bilmezsiniz, üretkenliğinizi artırır. Ürettiğiniz sesin sonucunu o an dinleyebiliyor olmak bile bir zevktir insan için. İlgim müziğe olduğu için böyle söylüyorum; ama insan fotoğraf çekmeli, şarkı söylemeli; iş ile ev, okul ile yurt arasında mekik dokumanın dışında bir şeyler de yapmalı insan… Basgitara ilgim nasıl başladı hatırlamıyorum. John Myung’in yeşil renkli Yamaha’sı (RBX6JM) ile Erotomania çalışını dinlemek, izlemek çok hoşuma giderdi. Öyle ki, çok dinlemekten ara ara bıkmış ve sonra tekrar dinlemişimdir. Son ara verişim çok uzun olmuş. Bugün tekrar dinlediğimde şunları hatırladım: 1. Basgitar almak için okuduğum kitapları sattığımı hatırladım. Alabileceğim en iyi gitar için İstanbul’a günü birlik gidip geldiğimi hatırladım. ’98 yapımı Fender Mexico Jazz Bass’ım vardı. 3. Anfim olmadığı halde çıplak sesi duyarak akordu anlamayı, düzeltmeyi hatırladım. Her gece notaları anlamaya çalışmak, sevdiğim şarkıları taklit etmek, parmaklarım iyice alışana kadar bıkmadan usanmadan aynı şarkıları tekrar tekrar çalışımı hatırladım. 5. Sırf benim istediğim şarkıları çalabiliyor diye (As I Am, yine Dream Theater) şehirdışındaki bir müzik grubuna katılmayı ve yemeğimden kısıp bu grupla stüdyoya girmek için günü birlik şehirlerarası yolculuk yaptığımı hatırlıyorum. Şimdi düşünüyorum: MANYAKLIK!! 7. Her şeyden önemlisi, şarkıların bende yarattığı psikolojik etkiyi hatırlıyorum. Erotomania’nın içinde bir başka hikayem, Deftones’tan My Own Summer’in içinde bir başka hikayem, Depeche Mode’dan Never Let Me Down Again’in içinde bambaşka bir hikayem var. Yaşadım bunları ben, iş hayatımda bile göremeyeceğim samimiyette iyi arkadaşlıklar edindim. Sahne aldım, küçük de olsa bir turne macerası yaşadım. Tek amacın eğlenmek olduğu bir dünyanın zevkini çıkardım. Tüm bunlardan önemlisi, istediğim zaman, evde veya dışarıda bir müzik icra edebilme lüksüne sahibim. Bu benim hayatım için her zaman güzel bir detay olacak. Bu arada, eski müzik arkadaşlarımın bazılarının isimlerini hatırlamakta zorlanıyorum. Dream Theater şarkıları çaldığımız gruptan gitarist Berkeley’e başvurmayı hazırlanıyordu, Umarım başarmıştır. Klavyeci Kültür Üniversitesi’nde ekonomi okuyordu sanırım, umarım iyi yerdedir. Bir de çok iyi twin kullanan baterist vardı, artık yüzlerini görsem hatırlayamayacağım insanlar. Bana ulaşırsanız, blogunu okudum deyin, kahve ısmarlayacağım. ### Geliştiriciden İşverene Dağıtık Manifesto > URL: https://gokmengorgen.net/tr/2015/10/19/gelistiriciden-isverene-dagitik-manifesto/ | Published: 2015-10-19 00:00:00 +0000 UTC | Categories: remote-working | Tags: düşünce _**Not:** Çok eski bir yazımdır. Aslı [burada](https://gist.github.com/gkmngrgn/9c433eeb6c88d71059a9) durmaktadır._ İdeal bir dünyada yaşamadığımız malum. İşimizi yaparken birçok problemle karşılaşıyoruz; bağırarak yanımızda telefonla konuşanlar, oje sürerken kokusunun ne kadar rahatsız edici olduğunu bilmeyenler, laptopta kullanmak amacıyla bir fare ihtiyacımızı kimin karşılaması gerektiğini tartışanlar veya başkalarına aldırış etmeksizin klimanın ayarlarıyla oynayanlar.. Bunlar her zaman karşımıza çıkacaktır, şuanki dünya düzenini ele alacaksak yapacak çok fazla bir şey yok. Fakat bir nebze de olsa, aklımızdan geçenleri burada manifesto tadında sıralamak faydalı olabilir düşüncesindeyiz. Siz de aynı sıkıntıları yaşıyorsanız, iş arkadaşlarınızla (hatta gücünüz yetiyorsa işvereninizle) paylaşın; maddeler eksik veya yazıyla ilgili eleştiriniz varsa, yorum yazın, forklayın, harekete geçin. ## Sevgili İşverenler 1. “Sen ne gerekiyorsa bana söyle, işini güzel yapman için gerekli ortamı sağlamak benim görevim” diye düşünüp hareket ederseniz, biz de işimizi düzgün yapmak için elimizden geleni yaparız. 2. Bize telefon, hat, bilgisayar gibi araçları sağlamanın sizin sorumluluğunuz olduğunu düşünürüz. Tablet, dizüstü bilgisayar, gold konuşma paketi vb. sahibi olmamız bu durumu değiştirmez. Hele bilgisayarımıza normalde tercih etmeyeceğimiz yazılımlar kurmak zorunda kalırsak iyice mutsuz oluruz, bu da işe yansır. 3. Nasıl ki sizin sağlık ve aile öncelikliyse, bizim için de öyle. İş çabuk bitsin diye fazla mesaiye zorlanmak, sıradaki işler ve ailemiz için yeterli enerjimiz kalmaması anlamına geliyor. 4. Bir işin ne zaman biteceğine ne biz, ne de siz karar verebilirsiniz. Doğru geliştiriciyi, doğru işte çalıştırırsanız, tahmini süreyi, ne gibi problemlerle karşılaşacağınızı ona sorabilirsiniz. “İki dakikalık iş” diye bir şey yoktur. 5. Müşteri sabırsızdır, bunu biz de biliyoruz. Bize işleri kısa zamanda bitirmek için psikolojik baskı yapmak yerine, harcanacak fazladan çabanın karşılığını verin. 6. Acil durumlarda alanımız dışında işlere girebiliriz ama normal günler için görev dağılımı gereklidir. Bir geliştiriciyi hem ön yüz, hem sunucu bakımı, hem de yazılımın geliştirilmesi için kullanmaya çalışırsanız, üstüne üstlük bir de “bizim yeğenin okulunun sitesi var sen çıkarıverirsin aradan” derseniz, o adam kaçar. Biz isviçre çakısı değiliz. 7. Eğer geleceğimiz ve ailemiz için endişe duyarsak, iş değiştirmemiz çok doğal. Bu nedenle önümüze süreli iş sözleşmesi, verilmiş sözler, hisse vaatleri sunarak bizi kendinize bağlamaya çalışmayın. Ne istediğimizi öğrenin, teklif edin. Bazı şeylerin “zamanında” mutluluğu daha önemlidir. Bir aile, her şeye bedel. 8. Bizi motive etmek istiyorsanız, projeye ne kadar masraf yaptığınızı, nelerden feragat ettiğinizi anlatmayın. Elbette çalıştığı şirket hakkında bazı bilgiler edinmek güzeldir; ama bize “Eğer bu iş bitmezse, çocuğumuzu keserler.” diyerek işlerin daha çabuk biteceğini, bizim işi bırakmaktan vazgeçeceğimizi beklemeyin. Duygusal sömürüden uzak durun, bizim feragatlarımızı görmezden gelmek durumunda kalabilirsiniz. 9. Biz uzun süreler için yoğunlaşmamız gereken bir iş yapıyoruz. Her gün toplantı yapmak her ne kadar “önemli iş yapıyoruz” duygusunu pekiştirse de, bizim dağılmamıza sebep oluyor. Toplantı sadece 5 dakika olsa bile bize saatler kaybettirebiliyor. Eğer konu birkaç kişiyi ilgilendiriyorsa, bütün ekibi toplantıya davet etmenin anlamı yok. Maksat herkesi bilgilendirmekse, bunun için e-posta göndermek, şirket içi paylaşım sayfalarında blog girdisi yazmak gibi çok daha az rahatsız edici yöntemlere başvurun. 10. Bize verdiğiniz maaşın neyi temsil ettiği konusunda bizimle anlaşın. Biz, yaptığımız iş için değil, o işe harcadığımız zaman için ücret talep ederiz. Gün boyunca hiç kod yazmamış olmamız, o gün çalışmadığımız veya o gün için ücret almayacağımız anlamına gelmez. İşte geçirdiğimiz süreye veya yazdığımız kodun satır sayısına göre performansımızı ölçemezsiniz. Mal ölçecekseniz tuğla fabrikası açın, akşamları eve gitmeden sayarsınız. 11. Bir işi yapmamız, bitirmemiz için ekip ile çalışılmıyorsa veya bütün ekibin ofiste olması gerekmiyorsa, bizim ofiste bulunma zorunluluğumuz saçmalıktan ibarettir. ## Notlar - Bazı maddelerin nasıl anlaşıldığı, nasıl yazılmasının daha doğru olacağı konusunda birçok kişinin görüşleri alınmış ve onların görüşleriyle beraber maddeler tekrar tekrar yazılmıştır. Yazıyı yazarken görüş bildiren herkese teşekkürler. - Görüş bildirenlerin bazıları kendi yaşadıkları tecrübelerini belli ortak maddelerde paylaşmıştır. - 11\. maddeyle ilgili olarak, 37signals’in CEO’su Jason Fried’in “Why work does not happen at work” isimli konuşmasını izleyebilirsiniz: [http://www.ted.com/talks/jason\_fried\_why\_work\_doesn\_t\_happen\_at\_work.html](http://www.ted.com/talks/jason_fried_why_work_doesn_t_happen_at_work.html) ### İşletim Sistemi Tercihini Geliştiriciye Bırakın > URL: https://gokmengorgen.net/tr/2015/03/22/isletim-sistemi-tercihini-gelistiriciye-birakin/ | Published: 2015-03-22 00:00:00 +0000 UTC | Categories: software-engineering | Tags: linux, vagrant, windows 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. 3. Geliştiriciye GNU/Linux kullanmaya mecbur bırakmak. 5. 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? ![](/images/vagrant.webp) 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. ### Özgürlük Yazarları: Filmin Düşündürdükleri > URL: https://gokmengorgen.net/tr/2015/01/11/ozgurluk-yazarlari-filmin-dusundurdukleri/ | Published: 2015-01-11 00:00:00 +0000 UTC | Categories: entertainment | Tags: film _Geçen gün tesadüfen izledim, daha önce film hakkında bilgim yoktu. Filmin sonunda gerçek hikaye olduğunu öğrendim. Filmde bir öğretmenin, birbirinden kötü geçmişi olan öğrencilerin olduğu sınıftaki iş hayatını anlatılıyor. İş hayatı demek biraz kaba oluyor; çünkü öğretmen o kadar çok seviyor ki işini, öğrencilerin eğitim masraflarını karşılamak için geceleri tezgahtarlık yapıyor. İzlemeye değer._ * * * Ben filmin içeriğinden çok bana neleri düşündürdüğünü yazacağım. Kaynak bulduğumda paylaşacağım, bir anket çalışması yapılıyor Türkiye’de, bir halk örneklemine basit bir soru soruluyor: “Türkiye’de herkese kendi anadilinde eğitim olmalı mı, olmamalı mı?”. İlk oylama sonuçları, katılımcılara açıklanıyor, sonra kendi aralarında tartışmaları, birbirlerini ikna etmeleri için iki saat süre veriliyor. Daha sonra tekrar aynı soru için oylama yapıldığında, genellikle iyiye yönelik, öncekine göre daha olumlu sonuçların çıktığı görülüyor. Filmde de öğretmen, kendi acılarıyla meşgul olan öğrencileri birbirine yakınlaştırmanın tek yolunun, birbirlerine acılarını, dertlerini anlatabilmek, aralarında söz söylemeye bir alan açabilmek olduğunu keşfediyordu. Buradaki en güzel mesaj şu: “Söz, silahın karşıtıdır.” Filmi izlerken bir başka aklıma gelen, 12 Angry Men filmiydi. Çok eski ama çok akıcı bir film, eğer Freedom Writers izlemeye niyetliyseniz, bence önce 12 Angry Men izlemelisiniz. Konusu çok basit; bir cinayet davasında henüz karar verilmemişken 12 kişilik jüri, sanık için karar vermek için uzun bir süre bir odaya kapanırlar ve kendi aralarında tartışırlar. Film boyunca, tartışmanın başından sonuna kadar jüri üyelerinin nasıl karar değiştirdiklerini, birbirleriyle nasıl tartıştıklarını, birbirlerini nasıl ikna ettiklerini izliyorsunuz ve size tartışmanın nasıl faydalı ve nasıl zararlı olabileceği konusunda ciddi bir tecrübe kazandırıyor. Freedom Writers, gerek düşünsel, gerek yapısal anlamda size tek tip olmanın gerçek dünyaya çok aykırı düştüğünü anlatırken, 12 Angry Men ise farklılıklar arasında uzlaşma için size bir yöntem sunuyor. Bir başka uzlaşma örneği olarak Diyarbakırlı kasap Sait Şanlı aklıma geldi. Onun ünü, aralarında kan davası olan aşiretleri barıştırmaktan gelir. Barış için öyle ilginç bir yöntemi var: Öncelikle öldürenin adalete teslim olması ve tarafların buna eninde sonunda ikna olması şart. Ama barışmak için bu yeterli değil. Tarafların birlikte geçirdiği güzel zamanları hatırlatmak, onları tekrarlamak; hiç yoksa, ortak hoşlandıkları bir konuyu konuşmak ve o konuda beraber bir şeyler yapmak; tüm bunlardan sonra da birbirlerine verdikleri zararı birlikte karşılamak için uzlaşma çabası içine girmek, kasap Sait Şanlı’nın yöntemiymiş. Dikkat ederseniz bunda bile her şey “söze alan açmakla” başlıyor. İnsanların birbirlerine dertlerini doğru bir şekilde anlatabilmesi benim son zamanlarda çok önemsediğim bir konu. İstanbul’da yaşıyorum ve neredeyse her gün bu konuya örnek olabilecek bir olayla karşılaşıyorum. Bir bakıyorsunuz, metrobüs durağında burnu dayaktan kırılmış kanlar içinde merdivende yardım bekleyen insanla karşılaşıyorsunuz; bir bakıyorsunuz, metrobüste kimse yer vermez diye çocuğunu sürükleye sürükleye kapıdan girmeye çalışan, o esnada da çocuğunun kalabalığın arasında ezildiğini farketmeyen bir kadını izliyorsunuz; bir bakıyorsunuz kaldırıma çıkıp yayayı ezdiğini bile bile durmayıp yoluna devam eden sürücüyü; bırakın tüm bunları, kahkaha atan insanlara bile tahammülümüz sıfır, diğer tüm meselelerde ahlak ve terbiyede bir numaraymışız gibi geldik başka insanların kahkahasına ayar çekmeye çalışıyoruz. Bizim bir durulmamız, birbirimizi dinlememiz gerekiyor. Bir uzlaşıya, barışa gönüllü vicdanlara ihtiyacımız var. 12 Angry Men’deki gibi tartışmanın yol ve yordamını, Diyarbakırlı kasap gibi barışmanın usulunu, Freedom Writers gibi de birlikte yaşamanın bir yolunu bulmamız gerekiyor bizim. Şuan tek ihtiyacımız bu.