Merhaba Linux Ubuntu Desktop

9 Eki

İş dünyasındaki sunucu ortamlarda sürekli haşır neşir olduğum linux işletim sistemi, son yıllarda container ortamların iyice yaygınlaşmasıyla birlikte yol arkadaşım oldu.

Kişisel bilgisayarımda Linux işletim sistemine taşınmak, uzun süredir aklımda olan planlardan biriydi. Bunun en önemli nedeni, bilgisayrımda yaşadığım kaynak yetersizliğiydi. Bu yetersizliğin en önemli nedenlerinden biri de Windows işletim sistemi üzerinde Linux tabanlı araçlarının kurulabilmesi için yüklenen sanallaştırma platformlarıydı. Bir süre sonra windows üzerinde terminali bile linux tabanlı kullanmaya başlamıştım. O halde uzun süredir kullandığım Windows işletim sisteminden Linux ortamında bir desktop dağıtıma geçme vaktinin geldiğine karar verdim. Community desteğinin de geniş olması nedeniyle seçimim Ubuntu desktop oldu.

Linux dünyasına geçmeden önce geliştirme araçlarımın linux desteğini inceledim ve artık geçişi başlatmaya karar verdim. Refus programı ile bir USB kurlum olşuturdum ve yedekteki SSD diskim üzerine kurulumu yaptım.

Windows çok kullanışlı ve alışık olduğum bir işletim sistemi olması nedeniyle, Linux desktopa alışamam bir hafta kadar sürdü. Kurulumlar, dosya sistemi, sürücülerin tanıtılması vs. derken bir hafta sonunda acemiliğimi atmış oldum. Server versiyondan alışık olduğum için bir çok kurulumu terminal ile yapmaya çalıştım.

Performans konusunda gayet memnun kaldım. Windows üzerinde container ortamlarda ayağa kaldırdığım araçları Linux üzerinde kaldırdığımda kaynak kullanımı neredeyse %50 civarında fark ettiğini gördüm. Bilgisayarın rahatlamasıyla bende rahat bir nefes almış oldum.

Sonuç olarak, eğer geliştirme değil de ofis veya ev amaçlı bir desktop işletim sistemi seçecek olursam yine windows tercih ederdim. Ancak yazılım ve mühendislik amaçlı kullanımda Unix tabanlı bir işletim sistemini (Linux veya Mac) tercih ederim.

Git commit edilmemiş işlerin yeni bir branch üzerine taşınması

9 Ağu

Giriş

Git günümüzde oldukça popüler bir sürüm kontrol sistemidir. Bu yazıda, master branch üzerinde yapılmış ancak henüz commit edilmemiş değişikliklerin yeni bir branch üzerine nasıl taşınacağını inceleyeceğiz. Git hakkında temel bilgiler için buradan faydalanabilirsiniz.

Git projesine yeni özellik eklenmesi

Git tarafından yönetilen bir projeye yeni bir özellik eklerken kullanılan genel akışı şu şekildedir.

  • Yeni bir “feature/development” benzeri isimde branch oluşturulur, ardından o branch’e geçilir.
  • Geliştirme tamamlanır ve local repository üzerinde commit edilir.
  • Feature branch (feature/development) remote repository üzerine push edilir ve pull request oluşturulur.
  • Pull request, takım üyeleri tarafından incelendikten sonra yeni değişiklikler master branch veya yayın yapılacak olan branch ile birleştirilir.

Problem

Bazen değişiklikler yapmaya başlarız fakat yeni bir feature branch oluşturmayı ve buna geçmeyi unutabiliriz. Sonuç olarak, değişikliklerimizi gerçekleştireceğimiz zaman, yanlış branch üzerinde olduğumuzu fark edebiliriz. Örneğin bütün değişiklikleri master branch üzerinde yaptığımızı fark edebiliriz. Çoğu zaman remote master branch, üzerine doğrudan commit edilemeyecek şekilde yapılandırılır. Bu nedenle yeni bir feature branch oluşturmamız ve commit edilmeyen işleri yeni branch üzerine taşımamız gerekir. Burada önemli olan nokta, ana branch üzerinde bir değişikliğin yapılmamasıdır.

Örnek bir senaryoyu aşağıdaki adımlarla inceleyebiliriz. Branch durumlarını görüntülemek için komutlar aşağıdaki gibidir.

$ git branch
* master

$ git status
On branch master
nothing to commit, working tree clean

Yukarıdaki çıktıdan da görebileceğimiz gibi, şu anda master branch üzerindeyiz ve temiz bir branch olduğu görünüyor.

Projemize login.html diye bir dosya ekleyerek değişiklikleri izleyecek olursak:

$ git status
On branch master

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        login.html

nothing added to commit but untracked files present (use "git add" to track)

Yukarıdaki çıktının gösterdiği gibi, yeni bir login.html dosyası eklendi. Şimdi tam bu anda, işin master branch yerine bir fature branch üzerine eklenmesi gerektiğini fark ediyoruz.

Git yeni branch oluşturma

Yeni bir brach oluşturmak için git checkout <BranchName> komutu kullanılır. Yeni brach oluşturup oluşturulan brach’e geçiş yapmak için git checkout -b <BranchName> komutu kullanılır. Ayrıca, bu komut mevcut branch’i olduğu gibi bırakacak ve tüm commit edilmemiş değişiklikleri yeni branch üzerine getirecektir.

$ git checkout -b feature/login
Switched to a new branch 'feature/login'

$ git status
On branch feature/login

No commits yet

Untracked files:
  (use "git add <file>..." to include in what will be committed)
        login.html

nothing added to commit but untracked files present (use "git add" to track)

Yukarıdaki komutlardan anlaşıldığı gibi, feature/login isimli branch oluşturuldu ve commit edilmeyen tüm değişiklikler master branch üzerinden dan feature/login branch üzerine taşındı. Artık, değişikliklere stage ve commit işlemleri uygulanabilir. İki işlemi bir arada yapan komutlar aşağıdaki gibidir.

$ git add . && git commit -m "Created login page."
[feature/login (root-commit) 0f18133] Created login page.
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 login.html

Şimdi master branch üzerinde onu değiştirmeden bıraktığımızdan emin olmalıyız.

$ git checkout master
Switched to branch 'master'

$ git status
On branch master
nothing to commit, working tree clean

Master branch üzerinde her hangi bir değişiklik olmadığı görülüyor.

İşler yeni branch üzerinde commit edildiğinden dolay bu branch (feature/login) remote repository’ye aktarılabilir.

$ git push -u origin feature/login

Remote repository üzerinde değişiklikler yine feature/login branch üzerinde oluşturulmuştur. Artık remote repository de, pull request ile değişiklikler master branch üzerinde birleştirilebilir. Birleştirme işleminden sonra local repository üzerinde master branch’e geçilerek pull işlemi ile master branch güncellenir.

$ git checkout master
Switched to branch 'master'

$ git pull origin master

Local repository master branch güncellenmiş olur.

Kibana Timezone (Zaman Dilimi) Yönetimi

7 Ağu

Kibana Discover uygulamasında, sorgulamalar belli bir zaman dilimine göre yapılabilmektedir. Bu yazıda Kibana sorgulamalardaki zaman diliminin nasıl yönetildiği incelenmektedir. Aşağıdaki ekran görüntüsünde Kibana Discover uygulamasının arayüzü gösterilmektedir.

Kibna Discover

Bu ekran yardımı ile Kibana sorgu ve filtreleri oluşturularak istenen kayıtlar aranabilmektedir. Takvim kutucuğu yardımıyla aramaları istenen bir tarih aralığında yapabilmek mümkündür.

Discover ekranındaki Inspect penceresinde, Kibana’nın sorguyu dönüştürdüğü Elasticsearch DSL query ifadesi bulunmaktadır. Tarih aralığı seçildikten sonraki sorgu penceresi aşağıdaki gibi olacaktır.

Burada @timestamp alanında, tarih kutucuğundan seçilen tarihlerin -3 saat olarak ayarlandığı görünmektedir. Bunun nedeni, Kibana’nın tarihleri otomatik olarak UTC zaman dilimine çevirmesidir. Tarih formatı sonunda bulunan “Z” harfi, bu saat ifadesinin UTC olduğunu gösterir ve ISO 8601 standardına uygundur.

Kibana tarayıcının zaman dilimini kullanır. Bu nedenle @timestamp alanındaki tarihler tarayıcının zaman diliminden UTC formatına dönüştürülür. Tarih seçimi yapıldığında belirtilen saat, bizim local timezone’umuz olduğundan, UTC dönüşümünde saat farkı oluşmaktadır.

Zaman dilimi farkı

Uluslararası bir şirketin, dünyanın farklı noktalarında bulunan iki ofisinde aynı zaman aralığını seçerek sorgulama yapan kullanıcılar, farklı bölgelerden UTC dönüşümü elde edileceğinden dolayı Elasticsearch sorguları da farklı olacaktır. Bu nedenle aynı sonucu göremeyeceklerdir.

Farklı zaman dilimlerinde yerel saatler

Elasticsearch tarihleri UTC saat diliminde döndürürken Kibana bunları tarayıcımızın saat dilimine göre biçimlendirir.

Şirketin Belçika’da olduğunu ve tarihleri UTC zaman diliminde tuttuğunu varsayalım. Bu durumda İstanbul ve Belçika’da raporlara bakan kullanıcılar aşağıdaki gibi farklı grafik raporlar görecektir.

Durumun farkında olmayanlar, satışların 10-12 veya 9-11 arasında arttığının ayrımını anlayamazlar. Bu da yanlış kararlar verilmesine neden olabilir.

Kibana timezone ayarları

Kibana timezone ayarları, ana menü seçeneklerinden Stack Management seçiminden sonra açılan uygulamanın Advenced Settings bölümünde bulunur.

Bu ayarlardan Time Zone, varsayılan olarak Browser seçilmiştir. Bunu UTC olarak ayarlayabiliriz. Day of week ise Monday olarak seçilebilir.

Bu durumda sorgunun nasıl değiştiğini görebiliriz.

Sorguda artık local timezone dönüşümü yapılmamaktadır.

SQL IN Operatoru ile Kapasiteden Fazla Çoklu Sorgulama

24 Haz

SQL sorgularında IN operatoru kullanarak WHERE şartı içerisinde çok fazla sayıda kriter belirleyerek sorgulama yapılabilmektedir.

SELECT 
   * 
FROM 
   Customers
WHERE 
   Country IN ('Germany', 'France', 'UK');

Bazı database engine’ler IN operatörü içerisinde kısıtlamalar getirir. Örneğin oracle IN içerisine default ayarlarda en fazla 1000 kayıt almaktadır. Bu gibi durumlarda kısıtlama ayarlarına müdahale edilemiyorsa IN operatorlerini OR ile birleştirerek kullanabilirsiniz.

SELECT 
   * 
FROM 
   Customers
WHERE 
   Country IN ('Türkiye', 'France', 'UK', ...) //1000 adet
   OR
   Country IN ('Italy', 'China', 'Russia', ...) //1000 adet
   OR
   Country IN ('Japan', 'Spain', 'Germany', ...) //1000 adet;

Bu yöntemi gerektirecek durumlara çok sık rastlanmasada dış kaynaklardan gelen Excel, XML, vs dosyalarından gelen verilerde arama yapmak durumunda kaldığınızda size bir çıkış yolu olabilir.

Fullstack Developer Nasıl Olunur?

16 Nis

Fullstack developer doğulmaz, fullstack developer olunur. Peki o zaman fullstack developer nedir? Fullstack deceloper olanlar neleri bilmelidir?

“Her şey hakkında bir şey öğrenmeye ve bir şey hakkındaki her şeyi öğrenmeye çalışın.” demiş Thomas H. Huxley. Uzmanlık alanında geliştirme yapmak, bu felsefeye uygun olsa da, fullstack olmak her şey hakkıında biraz daha fazla şeyler bilmeyi gerektirir.

O halde fullstack developer olanların alet çantasında neler bulunmalıdır? Başlıklar halinde belirtmek gerekirse;

  • Front End
  • Back End
  • Database
  • Mobile
  • Dev/Ops

Front End

  • Temel Bilgiler
    • HTML
    • CSS
    • JS
  • Framework ve Kütüphaneler
    • Angular
    • React
    • Vue
  • Arayüz Tasarım Araçları
    • Bootstrap
    • Material Design
  • Paketleme araçları
    • Babel
    • Webpack

Back End

  • Programlama Dilleri
    • C#
    • Java
    • Python
    • Javascript (Nodejs)
    • Ruby on Rails
  • ORM Araçları
    • Entity Framework
    • NHibernate
    • Hibernate
  • Cache Araçları
    • Redis
    • Memcached
  • Mesaj Kuyruk Yapıları (Message Queuing)
    • RabbitMQ
    • Kafka
  • Programlama Paradigmaları ve Disiplinleri
    • Object Oriented Programming
    • Functional Programming
    • Design Patterns
    • API (REST/SOAP)
    • SOLID Prensipleri

Database

  • RDBMS (Relational Database Management Systems)
    • PostgreSQL
    • Oracle
    • MsSQL
    • MySQL
    • SQLite
  • NoSQL
    • MongoDB
    • Cassandra
    • CouchDB

Mobile

  • Android
    • Java
    • Kotlin
  • iOS
    • Objcetive-C
    • Swift
  • Hybrid
    • React Native
    • Ionic Framework
    • Xamarin
    • Unity

DEV/OPS

  • Altyapı (Infrastructure)
    • AWS
    • Azure
    • Google Cloud
    • Heroku
  • Otomasyon (Automation)
    • Azure Devops
    • Jenkins
    • GitLab
    • Github
    • Travis CI
    • Circle CI
    • TeamCity
  • Sanalaştırma (Virtualization)
    • VMWare
    • Hyper-V
    • VirtualBox
  • Konteynırlaştırma (containerization)
    • Docker
    • Hyper-V Containers
    • Kubernetes
    • Openshift

Fullstack developer olanlar yukarıda belirtilen araçların hepsini birden çantasında bulundurmak zorunda değildir. Ancak her başlıktan bir araç seçerek o araç hakkında bilgi sahibi olmalıdır. Avantaj ve dezavantajlarını hakkında fikir sahibi olmalıdır. Bu sayede developer, bir projede hangi aracı kullanması gerektiği hususunda bilgi sahibi olacaktır.

IIS Rewrite ve Olası Hatalar

7 Mar

IIS üzerinde bulunan Rewrite modülü, URL için yeniden yazma diye adlandırılan kuralları uygulamayı sağlar.

  • Dış dünyaya açık olmayan iç sunuculara erişimin kontrolü
  • Kurumunuzdan tek bir IP üzerinden erişim sağlanabilen URL adreslerine erişimin çoğaltılabilmesi ve güvenlik altına alınabilmesi

gibi bir dizi kuralların uygulanması URL Rewrite modülü ile gerçekleştirilebilir. Bunun için IIS üzerinde bir Web site veya bir web site içerisine oluşturulan bir uygulama üzerinden bu kurallar tanımlanabilir.

Kurallar IIS arayüz ekranından tanımlanabildiği gibi, web sitesi dizininde bulunan Web.config dosyasında de tanımlanabilmektedir. Zaten arayüzden yapılan ayarlar da Web.config içerisine yazılmaktadır.

Örnek Kurallar

Bu kurallara göre,

  • Kuralı uyguladığınız siteye, örneğin http://uygulama.com/api şeklinde gelen talepler http://172.16.10.11/api adresine yönlendirilir.
  • http://uygulama.com/api?a=1&b=2 ile gelen querystring parametreleri aynı şekilde yönlendirmeye taşınır.
  • http://172.16.10.11/api adresindeki api, basic authentication ile doğrulama gerektiriyor. Kullanıcı adı ve şifre bilgileri Base64 string olarak kodlanıp sunucu değişkeni(server variable) olarak eklenmektedir.

Server Variable Hatası

Kurallara ServerVariables eklendiğinde karşılaşılabilecek olası hatlardan biri 500 internal error olacaktır.

Hata sayfasında hata hakkında detaylı bilgi bulunmamaktadır. Detaylı bilgileri alabilmek için Web.config içerisinde hata aşağıdaki ayarları yapabilirsiniz.

<system.webServer>    
   <httpErrors errorMode="Detailed" />     
</system.webServer> 
<system.web>     
    <customErrors mode="Off"/>
</system.web>

Bu ayarlamadan sonra hata detaylarını şu şekilde görebilirsiniz.

HTTP Error 500.50 – URL Rewrite Module Error.

The server variable “HTTP_Authorization” is not allowed to be set. Add the server variable name to the allowed server variable list.

Hata detayına göre Server Variable olarak kullanılacak bilginin IIS web sitesinde önceden belirtilmesi gerekmektedir. Bunun için URL Rewrite penceresinde, sağ taraftaki View Server Variables kısmından HTTP_AUTHORIZATION değişkenini eklemelisiniz. Bu sayede URL Rewrite modülüne, Authorization header tanıtılmış olacak ve hata ortadan kalkacaktır.

Hayat kavanozuna önce önemli şeyleri yerleştirin

6 Şub

Bu videoda, insan hayatının bir kavanoz misali nasıl doldurulması gerektiği anlatılmaktadır. Önce kavanozda topların üzerine sizi eksik yapan şeyler yazılmış ve kavanozun içerisine atılmış. Bunlar; aileniz, arkadaşlarınız, sevgiliniz, yedikleriniz, içtikleriniz, hobileriniz veya tutkularınız olabilir. Tüm bunlarla dolu bir hayatta, başka hiç bir şeye yer yokmuş gibidir. Ama hayatınıza başka şeyleri de sığdırabilecek boşluklar hala vardır. Toplarla dolu bir kavanoza ince çakıl taşları döküldüğünde topların arasındaki boşluklara sığdığı gibi. Bunlar sizin işiniz, mesleğiniz, arabanız, eviniz, paranız olabilir. Bunlar önemlidir, ancak bunlar olmasa da hayatınız yine de doludur. Siz bunların hepsine birden sahipseniz gerçekten şanslısınız. Çakıl taşları eklenen kavanozda hala boşluklar vardır. Bu boşluklar da daha ince kum taneleri ile doldurulabilir. Bunlar izlediğiniz filmeler, maçlar, oynadığınız oyunlar, spor aktiviteleriniz olabilir. Bunlar nefsinize hitap eden şeylerdir ve önemsizdir.

Şimdi boş bir kavanoza önce ince kum tanelerini, sonra çakıl taşlarını ve sonra da topları doldurmayı deneyin. Topların yarısı dışarda kalacaktır. Yani hayatınızı önce hobilerinizle, sonra iş para ile, sonra da asıl ihtiyaçlarınızla doldurmaya kalktığınızda asıl ihtiyaçlarınıza yer kalmayacaktır.

Yerleşim sıralamasının hayatınızı nasıl etkilediğini gördünüz mü?

Arcgis Server Domain Query

17 Oca

Arcgis ile oluşturulan Geodatabase üzerinde tanımlanan attribute domain yani kod listeleri arcgis server üzerinden yayınlanmaktadır.

Tanımlanan attribute domain’ler feature class üzerindeki alanlara eklenebilmektedir. Örneğin tablodaki land_type alanına yukarıdaki LandValue tipi atanabilmektedir. Kullanıcılar ekranda “Residential” değerini görürken değer olarak “Res” kullanırlar. Bu yöntem web ortamındaki combobox ile benzer özelliktedir.

Tanımlanan kod listelerine arcgis server yayınları üzerinden erişmek mümkündür. Yayınlanan FeatureServer veya MapServer aresindeki queryDomains adresi sorgulamak için gerekli arayüzü sağlar.

Aşağıdaki örnekte örnek arcgis server adresinden bir kesit sunulmuştur.

https://sampleserver6.arcgisonline.com/arcgis/rest/services/Water_Network/FeatureServer/queryDomains?layers=16&f=html

"domains": [
  {
   "type": "codedValue",
   "name": "piPipeMaterial",
   "description": "Pipe material types based on NASSCO standards",
   "codedValues": [
    {
     "name": "ABS Plastic",
     "code": "ABS"
    },
    {
     "name": "Asbestos Cement",
     "code": "AC"
    }],
   "fieldType": "esriFieldTypeString",
   "mergePolicy": "esriMPTDefaultValue",
   "splitPolicy": "esriSPTDefaultValue"
  }

Liste çok uzun olduğu için bir kısmı alınmıştır.

Elde edilen bu kod listesini web veya desktop uygulamalarda kullanmak mümkündür. Bu şekilde alan tipinden policy tiplerine kadar bütün bilgileri edinebiliyoruz.

ArcGIS Subtype Kullanılan FeatureClass ile Domain Kullanımı

7 Oca

ArcGIS platformunda oluşturulan coğrafi veri tabanları (geodatabase) üzerinde attribute domain’ler oluşturarak veri tabanındaki bütün FeatureClass’lar üzerinde kullanabilirsiniz. Attribute domain’ler FeatureClass üzerinde tanımlanan filed veri tipi ile uyumlu olmalıdır. Çünkü her attribute domain bir veri tipine sahiptir. Bu veri tipleri:

  • Short
  • Long
  • Float
  • Double
  • Text

Örnek bir attribute domain aşağıdaki gibi tanımlanabilir.

Burada “su_tipi” adında bir attribute domain oluşturulmuştur. Aldığı değerler ise code ve description alanlarına doldurulmuştur.

Hazırlanan attribute domain, bir feature class içerisindeki field üzerine aşağıdaki şekilde eklenip defalut değeri seçilebilir.

Artık siz içmesuyu ana hat çizimi yaparken su tipleri otomatik olarak “Arıtılmış” değerlerini almış olacaktır.

Dikkat

Ancak, eğer tanımladığınız feature class(şekilde içmesuyu ana hattı) üzerinde oluşturduğunuz bir subtype varsa attribute domain değerleri otomatik olarak gelmeyebilir. Bu durumda Arcgis Pro üzerinde attribute domain neden çalışmıyor diye düşünebilirsiniz. Ancak Arcgis Pro üzerinde subtype oluşturulduğunda her type için farklı attribute domain özelliği tanımlayabilme yeteneği getirilmiştir. Bu nedenle siz her bir subtype için değerleri yeniden belirlemek durumunda kalabilirsiniz. Eğer tanımlamazsanız çizim yaparken attribute değerleriniz null olarak gelebilir.

Yukarıdaki içmesuyu ana hat feature class üzerinde “*hat_tipi” field biraz daha koyu renkle ve “*” ile işaretlenmiştir. Bunun nedeni, hat_tipi alanında bir subtype tanımlanmış olmasıdır. Bu durumda her bir subtype üzerinde attribute domain tanımlamalarını tekrar gözden geçirmek durumunda kaldım. Eğer attribute domain tanımlamanızı, subtype oluşturduktan sonra yaptıysanız bu ayarları mutlaka kontrol etmelisiniz.

Subtype ekranında her bir su_tipi alanının belirlenmiş olduğunuzda artık bir sorun ile karşılaşmazsınız.