ACID - Repeatable Read Seviyesi Nedir ? - Benim Dokunduğum Satırı Kilitler Gibi Düşünülebilir

Giriş

Şeklen şöyle. Üçüncü satırda Repeatable Read görülebilir.

SQL Server için şeklen şöyle

Açıklaması şöyle

It ensures that the same select query will always return the same result, no matter how many times it is executed, even if some other concurrent transactions have committed new changes that satisfy the query.

Transaction içinde kullanılan tüm verinin her seferinde aynı değeri taşıyacak şekilde okunması garanti edilir. 

- Dirty Read problemini engeller. 

- Lost Update problemini engeller.

- Phantom Read problemini engellemez. Benim dokunmadığım satırlar kilitlenmediği için bunlar değiştirilebilir veya yeni satır eklenebilir

- Phantom satır kapsamında Write skew problemini engellemez.

Şeklen şöyle. Burada Transaction 1 başlıyor ve 2 numaralı satırı okuyor, ancak 3 numaralı satıra dokunmuyor. Transaction 2 ise 3 numaralı satırı değiştirip commit'liyor. Transaciton 2 3 numaralı satırı okusa bile eski veriyi görüyor.

Açıklaması şöyle

REPEATABLE READ isolation level guarantees that transactions see the committed view of the database snapshot taken by the first read. Unlike READ COMMITTED isolation level, data that is read at one point in the transaction is the same as data that is read at another point in the transaction.

... The concurrent transactions see the committed view of the snapshot taken within each transaction. Transaction 1 gets charlie, not chris, because Transaction 1 began before Transaction 2. To put it another way, the two concurrent transactions are performed in serial.

Note that the snapshot is taken by the table, not by the row or database. A first read to the table creates a new table snapshot. As to the above diagram, Transaction 1 creates a snapshot of the users table when issuing SELECT name FROM users WHERE id = 2. Once the transaction ends, the snapshot is deleted.

1. Lock Çeşitleri Nedir?

Açıklaması şöyle. Lock çeşitleri yanında lock'ın ne zaman bırakıldığı da önemlidir.

What are the locks in RDBMS?

Shared read lock: When a single row is read, a read lock is held. This allows another transaction from another thread to have a read lock on the same record — but no other transaction from another thread can impose a write lock to update it.

Update lock: When an update lock is held, other threads can only acquire a shared read lock — not update nor an exclusive write lock.

Exclusive write lock: An update lock is promoted to a write lock. I think this promotion is only possible when only one lock, which is this update lock (no other shared read lock), is locking this row. When a write lock holds a row, no other transaction from any other thread can hold any lock on that row.

-Shared read lock aynı anda okumayı engellemez, başkası yazamaz

-Update lock aynı anda okumayı engellemez, başkası yazamaz. Update lock, Exclusive Lock'a yükseltilebilir.

-Exclusive Lock başka herhangi bir lock'a müsaade etmez

2. Repeatable Read Gerçekleştirimi

Repeatable read gerçekleştirimi için iki tane yöntem var. Bunlar şöyle

1. With transaction 1 as Repeatable Read, other transactions can not update a row after it has been selected by transaction 

2. With transaction 1 as Repeatable Read, other transactions can update a row, but transaction 1 does not take into account those changes.

Çoğu veri tabanı 1. yöntemi seçiyor. 

1. Yöntem şu anlama gelir Kullanılan Lock - Okumayı Engellemez Ama Yazmayı Engeller

Repeatable Read "Update Lock" kullanır. Bu lock read committed seviyesinin aksine transaction bitmeden bırakılmaz. Yani bu lock çeşidi ile başkasının benim satırıma yazması engellenir.

SQLServer - 1. Yöntem

Açıklaması şöyle

With transaction 1 as REPEATABLE READ, you cannot update a row in transaction 2 after you selected it in transaction 1.

MYSQL - 2. Yöntem

Açıklaması şöyle

While many database systems will actually behave like your first version, for MySQL, version 2 is the expected behaviour, see the documentation about repeatable read:

Bu yüzden "select ... for update" kullanılıyor. Açıklaması şöyle

In MySQL, if you want to block another transaction from updating the rows in repeatable read, you need to lock them by e.g. using select ... for update. A simple select will not place a lock unless you are in serializable isolation mode.

PostgreSQL - 1. Yöntem

Repetable Read yazısına taşıdım.

Repeatable Read Kullanım Senaryosu Örnekleri

Örnek

Eğer bir mali rapor hazırlıyorsam ve kârı iki farklı yerde gösteriyorsam iki tane SUM cümlesi çalıştırırım. Eğer repeatable read kullanmazsam okuduğum veri güncellenebilir ve iki farklı sonuç elde ederim.

3. Lost Update Çözümü Nasıldır

Örnek

Lost Update için en açıklayıcı senaryo aşağıdaki gibi. İki thread'in aynı anda banka hesabındaki paradan 100 TL çekmeye çalıştığını düşünelim.

•     funds == 100; amount == 100
•     thread A enters withdraw / transaction A starts
•     thread A executes isEnoughFunds which evaluates to true
•     thread B enters withdraw / transaction B starts
•     thread B executes isEnoughFunds which evaluates to true
•     thread A executes decreaseFunds / thread A locks db record
•     thread B waits for thread A to commit transaction and release write lock
•     thread A exits withdraw / transaction A commits
•     thread B executes decreaseFunds / thread B locks db record
•     thread B exits withdraw / transaction B commits
•     funds == -100

Yukarıdaki örnekte para olmadığı halde 100 TL çekilebildi. Eğer Repeatable read kullanırsak B thread'i A'nın işini bitirmesini beklemek zorunda kalır, çünkü satırı güncelleme niyeti ile kilitlemek istediğini bildirecek ancak kayıt zaten A tarafından kilitlendiği için bekleyecektir. Kilidi alınca da ilk transaction commit yaptığı için çekme işlemi gerçekleşmez. Açıklaması şöyle

If two transactions attempt to modify the same record, the second transaction will wait for the first one to either commit or rollback. If the first transaction commits, then the second one must be aborted to prevent lost updates.

4. Select İşlemi - Phantom Read Problemi

Bu problem halen karşımıza çıkabilir

Örnek

Şöyledir

T1 begins

T1Queries select * from Tbl where X>100 → 3 rows

T2 begins

T2 Inserts 1 additional row with X=150.

T2 Commits.

T1 Queries select * from Tbl where X>100 → 4rows [Phantom Read].

5. Diğer Konular

Spring

Spring ile bu isolation level ile transaction başlatmak için aşağıdaki kod kullanılabilir.

@Transactional (isolation=Isolation.REPEATABLE_READ)

Oracle

Oracle bu isolation seviyesini desteklemez. Açıklaması şöyle.

REPEATABLE READ; Oracle does not normally support this isolation level, except as provided by SERIALIZABLE.

Vitess

Çoğu sharded veri tabanı gibi "Cross Shard" işlemlerde Repeatable Read seviyesi desteklenmez

Scrum - Product Backlog (Ürün Biriktirme Listesi) - Bu Kod Seviyesinde Bir Backlog Değildir

Giriş
Scrum'da 3 tane önemli yapı/çıktı var. Bunlar şöyle.

- product backlog,
- sprint backlog,
- sprint goal.

Backlog kelimesi "Biriktirme Listesi" olarak tercüme ediliyor. Ben bu yazıda backlog kelimesini kullanmayı tercih ettim.

Backlog'dan Ne Zaman Bir Şey Silinir
Artık o iş yapılmamaya karar verince silinir. Açıklaması şöyle. İşin çok sonraya ötelenmesi backlog'dan silinmesine gerekçe değildir.

For me, the only reason to delete (close) an item in the backlog is because you decide it will never be implemented, not because it won't be implemented for a while

Product Backlog'un Sahibi Kimdir ve Kim Önceliklendirme Yapar
Backlog'a girecek,çıkacak şeylere ve önceliklendirmeye normalde Product Owner karar verir. Açıklaması şöyle. Yani Product Backlog, Product Owner tarafından yapılması istenen herşeyi içerir.

the Product Owner is the person who has full authority of determining what goes in and comes out of the product backlog. 

Açıklaması şöyle

The Product Owner is the sole person responsible for managing the Product Backlog. Product Backlog management includes:

- Clearly expressing Product Backlog items;

- Ordering the items in the Product Backlog to best achieve goals and missions;

- Optimizing the value of the work the Development Team performs;

- Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next; and,

- Ensuring the Development Team understands items in the Product Backlog to the level needed.

PO'nun önceliklendirmesi bazı yerlerde uygulanmıyor. Açıklaması şöyle

Where I have worked previously, the PO owned the backlog, and the Product Manager would prioritize the backlog. 

Backlog User Story Şeklinde Olmalı

Açıklaması şöyle.

The product backlog includes features to be built, enhancements, fixes, quality attributes, etc. in the form of user stories.

Backlog Hazırlığı
Backlog geliştirme ekibinden önce gitmeli. Açıklaması şöyle.

Preparing the backlog well ahead of the next sprint(s) is a must.  You never want the team to run out of work to do, and that work must be of highest value at that point in time as prioritized by the Product Owner.  Being a Product Owner can be time-consuming.

Backlog'u Sırayla İşlemek - Pipeline
Backlog bir pipeline haline dönüştürülebilir. Buradaki soruda önce ekranların bitirilip sonra arkalarının doldurulması anlatılmış. 

Sıralama
Backlog sıralı bir şekilde tutulur. Açıklaması şöyle. Sıralama (ordering) ve önceliklendirme (prioritizing ) farklı şeyler

The Scrum Guide does not talk about prioritizing the Product Backlog. Instead, it talks about ordering the Product Backlog. Priority is only one factor that can be used to determine the ordering of the Product Backlog. Dependencies between work items is another factor, but the Product Owner can choose any factors that are appropriate to help maximize the delivery of value.

Sıralamada dikkat edilmesi gereken noktalar şöyle. Yani en fazla fayda getirecek maddeleri önce alıp en fazla verimi almaya çalışmak.

- Ordering the items in the Product Backlog to best achieve goals and missions;
- Optimizing the value of the work the Development Team performs;

Sıralama Ölçütünde Dikkate Alınabilecek Şeyler 

1. Yazılım Hataları
Eğer yazılımda bir hata varsa sıralamanın belirlenmesinde gravity ve frequency katsayıları kullanılabilir. Açıklaması şöyle.

Generally you have two axes for bugs: gravity and frequency.

So obviously something grave and frequent is of the highest priority. However, something that's serious but happens rarely should be weighed roughly at the same as something that's not serious but happens often. So supposing you rate gravity from 1 to 3 and frequency from 1 to 3, the types of bugs you should probably be fixing are those which cross the diagonal defined by gravity 1, frequency 3, and gravity 3, frequency 1.

2. Müşteri Tarafından Raporlanan Hatalar

Soru şöyle

When a user reports a bug should it go directly to the programmer or should it go to qa first and must be reproduced by qa before going to the programmer?

Cevap şirketine göre değişir. Eğer Product Owner üzerinden gidilecekse, açıklaması şöyle.

It depends on your policy if you have one. It could go either way.

It could also be that it goes to the PO and they should approve it before continuing with the fix or putting it in the backlog.

3. Uzmanlık Alanı

Burada ekipteki uzmanlık alanı gerektiren şeyleri yapabilecek insan sayısına dikkat etmek gerekir. Eğer sırası gelen işi yapabilecek insan müsait değilse çözüm olarak şu iki şeyden birisi yapılabilir. Açıklaması şöyle. Ya herkesi uzman yapmak gerekir. Ya da backlog'daki bir sonraki işi sprint'e almak gerekir.

This is where the Development Team and Product Owner need to come to some level of understanding and agreement on how to proceed.
- One option is to do what the Development Team is doing now - everyone focuses on their particular strength if they have the capacity, even if the work they take is not the next most important.

- The other option is to work on developing the skills of the Development Team members so that everyone is more capable of taking on any piece of work.

Yazılım Mimarisi - Monolithic Architecture (Tek Parça/Yekpare Mimari)

Giriş

Günümüz dünyasında microservice mimarisinin o kadar fazla reklamı yapılıyor ki, sanki tüm eski mimariler ve yaklaşımlar çöpmüş gibi düşünülüyor.

Aslında bu yazılımlar da çalışıyordu ve iş görüyordu. Eğer yukarıya doğru ölçeklendirme problemi yoksa bu mimariler halen daha kullanılabilir şeyler.

Monolithic Architecture Arap Saçı (Big Ball of Mud) Değildir

Big ball of mud yazılımlar aslında mimariden bağımsızdır. Microservice mimari kullanan çamur topu yazılımlar da olabilir. Aslında Monolithic mimarinin bu keşmekeş olmasının sebeplerinden birisi global nesnelerin çok fazla kullanılması olabiliyor. İşlevsel olarak bölünmüş (modular) yapı ile bölünmemiş yapı aradaki farkı gösteren bir şekil burada. Modular olmayan yapıda bir bileşeni bir sürü farklı alt modül de kullanıyor. Bileşende yapılan bir değişiklik bir sürü yeri de etkiliyor.

Proje Yapısı

Tek parça yazılımlar genellikle şu yapıdadır. Burada catalog, delivery, order modülleri temsil eder. application altında da uygulamayı ilgilendiren şeyler vardır

myshop/

+- application/

+- catalog/

+- delivery/

+- order/

...

Microservice mimariye geçince yapı şuna benzer. Burada her service bağımsız bir uygulama gibi olduğu için kendi altında gerekli şeyleri toplamıştır. 

myshop/

+- catalog/

|  +- application/

|  +- domain/

|  +- jdbc/

|  +- rest/

|  \- spring-boot-starter/

+- delivery/

|  +- application/

|  +- domain/

|  +- events/

|  +- jdbc/

|  +- rest/

|  \- spring-boot-starter/

+- order/

|  +- application/

|  +- domain/

|  +- events/

|  +- jdbc/

|  +- rest/

|  \- spring-boot-starter/

...

Monolith Yapıdan Microservice Yapıya Geçmek

Monolith Yapıdan başka bir yapıya geçmeye başlamadan önce ilk yapılması gereken şey kimilerinin "Horizontal Layering", kimilerinin de "Domain" dedikleri yapıyı çıkartmak. Bu yapı şeklen şöyle

Dikey yapı yani Vertical Layering genellikle daha anlaşılır oluyor, ancak Domain'leri çıkartmak veya kimin kiminle yatay olarak iletişim kurduğunu çıkartmak daha zor ve her şeyden önce bu mutlaka yapılmalı

Şeklen şöyle

Ortak Kullanılan Kendi Kütüphanelerimiz - Shared Custom Library

Ortak kullanılan kendi kütüphanelerimiz olsun diyenler ve olmasın diyenler diye iki grup var.

1. Eğer varsa kütüphaneler mutlaka sürüm numarasın ile kullanılmalı

2. Eğer ortak kütüphane istemiyorsak, kütüphane kodlarını bir servise taşımak ta bir diğer çözüm

Monolith Yapıdan Microservice Yapıya Geçmek

Bu iş için Strangler (Sarmaşık) Örüntüsü kullanılabilir. Açıklaması şöyle

Hierarchical Cache - Hiyerarşik Önbellek

Giriş

Bize önce bir tane multimap lazım. Ancak bu multimap concurrent bir multimap olmalı.

Şöyle yaparız

public class ConcurrentMultiMap<K> {
  ConcurrentHashMap<Class<? extends K>,ConcurrentSkipListSet<K>> map = ...
  ...
}

Elimizde şöyle bir nesne olsun. Bu sınıf güncellenecek veriyi ve bu verinin kalıtım hiyerarşisini saklar.

public class DataEvent {
  private MyBaseObject data = ...;
  private Collection<Class<? extends MyBaseObject>> hierarchy = ...;

  Collection<Class<? extends MyBaseObject>> getHierarchy(){
    return hierarchy;
  }
  ... 
}

DataEvent'leri işleyen bir sınıf olsun. Bu sınıf gelen veriyi tüm ata sınıflara da ekler.

public class DataEventListener {
  private ConcurrentMultiMap<MyBaseObject> map;

  public void addToMap(DataEvent dataEvent){
    Collection<Class<? extends MyBaseObject>> hierarchy = dataEvent.getHierarchy();
    for(Class<? extends MyBaseObject> clazz : hierarchy){
      map.add(clazz,data);
    }
  }
}

Burada eksik kalan şey DataEvent nesnesini oluştururken data yanında bu data'ya ait üst sınıfları da verebilmek. Bunun için elimizde şöyle bir kod olsun

public class ClassCapsule<C> {
  private Class<? extends MyBaseObject> clazz;
  private HierarchicalCollection<Class<? extends MyBaseObject>> hierarchy; 

  public ClassCapsule(Class<? extends MyBaseObject> clazz){
    this.clazz = clazz;
    this.hierarchy = new HierarchicalCollection();
  }

  public void setParent(ClassCapsule<C> parent){
    hierarchy.setParent(parent.hierarchy);
  }

  public Collection<Class<? extends MyBaseObject> getHierarchy(){
    return hierarchy;
  }
}

HierarchicalCollection şöyle olsun

public class HierarchicalCollection<T> extends AbstractCollection {
  private Set<T> set = new HashSet<>();
  private HierarchicalCollection<T> parent;
  
  public setParentCollection(HierarchicalCollection<T> parent){
    this.parent = parent;
  }
  public Iterator<T> iterator(){
    return Iterators.concat(set.iterator(),parent.iterator());
  }
  public boolean contains(T object){
    return set.contains(object) || parent.contains(object);
  }
}

Şimdi elimizdeki sınıfları kalıtıma göre indeksleyelim

public class ClassCapsuleIndexer<C> {
  private Map<Class<? extends MyBaseObject>,ClassCapsule<C> capsuleMap = ...;

  public ClassCapsule<C> getClassCapsule(Class<? extends MyBaseObject> clazz){
    ClassCapsule<C> capsule = capsuleMap.get(clazz) 
    if (capsule == null){
      capsule = new ClassCapsule<C>(clazz);
      Class<? extends MyBaseObject> superClass = findSuperClass(clazz);
      if (superClass != null){
        classCapsule.setParent(getClassCapsuleFroClass(superClass));
      }
      capsuleMap.put(clazz,capsule);
    }
    return capsule;
  }
  
  private Class>? extends MyBaseObject> findSuperClass(Class<?> clazz){
    Class<? extends MyBaseObject> result = null;
    try {
      clazz.getSuperClass().asSubclass(MyBaseObject.class);
    } catch (ClassCastException e){
      ...
    }
   }
}

Böylece ClassCapsuleIndexer ile istenilen sınıf tipine ait ClassCapsule bulunur. ClassCapsule sınıfının getHierarchy() metodu ile ata sınıfların listesi elimize geçer. Biz de bu hiyerarşi üzerinde dolaşıp ConcurrentMultiMap'teki ata sınıflara ait key değerlerine de güncelleme yapabiliriz.

UTC ve Leap Second (Artık Saniye)

Giriş

Önce UTC, GPS ve atomik saat arasındaki farkı bilmek lazım. Çünkü hem GPS hem de UTC uluslararası atomik zamandan türetilmişler. Açıklaması şöyle. 

Both GPS time and UTC are derived from the atomic time TAI ...

TAI

TAI 400 tane atomik saatin ortalamasıdır. Saatlerin çoğu Cesium saatleridir. Bu saat Cesium 133 atomunun saniyede 9,192,631,770 defa salınım yapmasına dayanır. Açıklaması şöyle. TAI 1958 yılından veri var.

Synchronized on existing UT2 on January 1 1958.

TAI saatinde artık saniye yoktur.

UTC

TAI'den sonra UTC 1970 yılında ortaya çıkıyor. İlk ortaya çıktığında TAI ile olan farkı 10 saniye. Özetlersek açıklaması şöyle. 

- Redefined in 1970 to include leap seconds.
- Resynchronized on January 1st 1972 to be exactly 10 seconds behind TAI.
- 27 leap seconds have been introduced since then.
- UTC is now 37 seconds behind TAI.
- UTC = TAI - 37s at present.

Şeklen şöyle

GPS

En son olarak ta GPS 1980 yılında ortaya çıkıyor. Açıklaması şöyle. Yani GPS ve UTC 6 Ocak 1980 yılında aynı olarak şekilde başlamışlar.

GPS time and UTC were equal on January 6 1980

Özetlersek açıklaması şöyle. GPS için "internal representation reset" ne anlama geliyor bilmiyorum.

- Defined as equal to UTC at midnight on January 6th 1980 when UTC was 19 seconds behind TAI.
- 18 leap seconds were added to UTC since then.
- GPS time is now 18 seconds ahead of UTC.
- The internal representation of GPS time was reset (due to week counter finite size) on August 21 1999 and April 7 2019, and this may happen every 1024 weeks. Conversion programs have to take this into account. While the start time is changed each time, the offset with TAI is not modified.
- GPS time = TAI - 19s (always).
- GPS time = UTC + 18s at present.

GPS Tekrar Ayarlanmamıştır

Açıklaması şöyle

GPS time is never resynchronized; its offset from TAI is the number of leap seconds which existed on January 6 1980, that is 19.

Açıklaması şöyle

GPS time was set to match UTC in 1980, but has since diverged. The lack of corrections means that GPS time remains at a constant offset with International Atomic Time (TAI) (TAI – GPS = 19 seconds).

Fakat UTC sürekli tekrar ayarlanıyor. Açıklaması şöyle. Dolayısıyla TAI ve GPS arasındaki fark hep sabitken, UTC gittikçe daha da geri kalıyor.

2017'de Durum

UTC, TAI'den toplamda 37 saniye, GPS'ten 18 saniye geride.

As of 1 January 2017, when another leap second was added, TAI is exactly 37 seconds ahead of UTC. The 37 seconds results from the initial difference of 10 seconds at the start of 1972, plus 27 leap seconds in UTC since 1972.

2020'de Durum

Açıklaması şöyle. UTC - GPS farkı halen 18 saniye

The UTC–GPS offset as of 5-March-2020 is 18 seconds.

2021'de Durum

Şeklen şöyle. GPS ve TAI arasındaki 19 saniye hep sabit. UTC, TAI'den toplamda 37 saniye geride.

UTC'nin Ayarlanması Nasıldır

UTC , UTC1 isimli dünyanın dönüşünü ölçen bir başka standarda göre ara sıra tekrar ayarlanır. UTC1 dünya çapındaki bazı gözlemevlerinin yaptığı ölçümlerin ortalaması gibi düşünülebilir. Eğer UTC1 artık saniye olmasına karar verirse, UTC de tekrar ayarlanır.

Artık saniye dünyanın dönüşündeki yavaşlamadan kaynaklanıyor. 

GPS Sinyali UTC Saati de Bildirir

GPS'te 3 tane saat var. Açıklaması şöyle

There are three kinds of time available from GPS: GPS time, UTC as estimated and produced by the United States Naval Observatory, and the times from each free-running GPS satellite's atomic clock.

POSIX Günü ve UTC Farklı Şeylerdir

POSIX günü 86,400 saniye uzunluğunda tanımlanmış. Ancak gerçek hayatta günler daha uzun veya kısa da olabilir. Bu tutarsızlığı gidermek için genellikle aynı saniyenin tekrarlanması çözümü kullanılıyor. Açıklaması şöyle.

POSIX time doesn't include leap seconds, and is not implemented the same way in every UNIX, so it routinely gets inconsistent for several seconds every couple of years. It is not a high-precision time scale, and there is little point correcting it for relativistic effects which are smaller than it can represent.

Aşağıda bu konuyla ilgili bir karikatür var.

Leap Second POSIX'te Problem Sebep Olur Mu?

Why Does the Leap Second Cause Problems? başlıklı soruda ntpd servisinin artık saniye mesajı alınca bazı Linux çekirdeklerinde hataya sebep olabildiğine dair bir soru ve açıklamalar mevcut. Anladığım kadarıyla ntpd adjtimex sistem çağrısını kullanarak saati ayarlıyor.

git merge seçeneği - Belirtilen Bir Dalı Alır ve Mevcut Dal İle Birleştirir

Giriş 

Belirtilen dalı mevcut dal ile birleştirmek için kullanılır. Bu komut yerine squash veya rebase kullanılabilir. Açıklaması şöyle

Merge the specified branch into the current branch

Merge ve Conflict

Merge işleminde conflict çıkma olasılığı var. Bu yüzden sıkça merge yapmakta fayda var. Açıklaması şöyle

Delaying things only means it's more likely for others to get code into your merge target, making the merge worse

Merge ve Unit Test

Her iki dalda da unit testlerin geçmesi, merge işleminde sonra da testlerin geçeceği anlamına gelmez. Dolayısıyla master branch'te de testlerin koşması gerekir.

Kullanım

Feature isimli branch açtığımızda şeklen şöyle olur

Merge işleminden sonra şöyle olur. Yani commit tarihçemizi veya sıramızı muhafaza eder

Pull Request vs. Merge Request

Açıklaması şöyle

Pull Request in Bitbucket and GitHub or Merge Request in GitLab are the features made for more convenient code review and change management. Though they have different names, these features are equivalent, as they both do the same git merge command to merge feature branches or forks with the existing code.

Bitbucket Pull Request şeklen şöyle.

Birleştirme işleminden sonra kaynak dalı silmek isteyebiliriz. Şöyle yaparız

Kullanım

Bulunduğumuz dala ismi belirtilen daldaki değişiklikleri birleştirir.

Örnek

Şöyle yaparız

git checkout develop
git merge feature/[JIRA-ID]-description

Yani "develop" dalına geçtikten sonra "feature/[JIRA-ID]-description" dalındaki değişiklikleri develop'a birleştirmek isteriz.

Örnek

Şöyle yaparız

# Get repo changes
git fetch origin

# Go to our feature branch
git checkout feature

# Commit some work
...

# Go to main branch
git checkout master

# Merge feature to main branch
git merge --no-ff feature

# Push to origin
git push origin main

# We can delete the feature branch safely
git branch -d feature

-squash seçeneği

Açıklaması şöyle. Yani commit tarihçesini veya sırasını muhafaza etmez, bizim commitleri en sona ekler.

In this case a new commit in the origin branch will be created, containing all of the commits created in our feature branch.

Şeklen şöyle olur

Örnek

Şöyle yaparız. release branch'e geçtikten sonra bugfix ve feature branch'lerini release branch'e birleştiririz

git checkout release/[YY.MM]
git merge --squash bugfix/[JIRA-ID]-description
git merge --squash feature/[JIRA-ID]-description

Örnek

Şöyle yaparız

# Get repo changes
git fetch origin

# Go to our feature branch
git checkout feature

# Commit some work
...


# Go to main branch
git checkout main

# Merge feature to main branch
git merge --squash feature

# Push to origin
git push origin main

# We can delete the feature branch safely
git branch -d feature

-X seçeneği

Örnek
Şöyle yaparız. otherbranch o anda checkout etmiş olduğumuz branch ile birleştirilir. Yani

develop <- otherbranch şeklindedir.

Burada patience git'e patience algoritmasını kullanması söyleniyor.

git merge -X patience otherbranch




Elektronik Taarruz Sistemleri - Elektronik Attack (Eski Adı Electronic Countermeasures)

Giriş

Bu konu çok karışık bir konu. O yüzden sadece anladığımı kabaca özetlemeye çalışacağım. Konuya da kesinlikle hakim değilim :)

Elektronik Taarruz Sistemleri eskiden Electronic Countermeasures (ECM) olarak isimlendiriliyordu. Dolayısıyla uçaklardaki sistemlere halen ECM Pod deniliyor.

Elektronik Taarruz Sistemleri

Şu şekilde tasnif edilebilir

- Radar Elektronik Taarruz
- Muhabere Elektronik Taarruz
- Dekoylar

Elektronik Taarruz'un aktif ve pasif olmak üzere iki türü vardır. Esasen karıştırmayı mekanik ve elektronik olarak ta gruplamak mümkün ancak ben yukarıdaki gibi gruplamayı daha uygun buluyorum.

Pasif Karıştırma basittir. Radarın huzmesi önüne atılan yansıtıcılar ile yapılan karıştırma tekniğidir. Bakınız chaff. 

1. Aktif Karıştırma

Radar Tipleri

Radarlar çeşitli şekillerde sınıflandırılabilirler

1. Konuşlandıkları ortam : 

İşlevleri şöyle olabilir 

Havada konuşlu, 

Karada konuşlu, 

Denizde Konuşlu gibi

2. İşlevlerine göre 

İşlevleri şöyle olabilir 

Arama Radarı

Takip Radarı

Atış Yeri Tespit Radarı

3. Dalga şekillerine göre

Dalga Şekilleri şöyle olabilir

- Sürekli Dalga (Continious Wave)
- Darbeli Dalga (Pulse Wave)

1.1. Radar Elektronik Taarruz Sistemleri

Açıklaması şöyle

Radar jamming and deception is a form of electronic countermeasures that intentionally sends out radio frequency signals to interfere with the operation of radar by saturating its receiver with noise or false information. Concepts that blanket the radar with signals so its display cannot be read are normally known as jamming, while systems that produce confusing or contradictory signals are known as deception, but it is also common for all such systems to be referred to as jamming.

Darbeli dalgada Darbe Genişliği ve Darbe Tekrar Aralığı belirtilir.

1.2 Jamming Yöntemleri 

Aktif Karıştıma da kendi içinde ikiye ayrılır.

1. Noise Jamming

2. False Target Generation veya Deception Jamming

Açıklaması şöyle. 

ECM can consist of (1) noise jamming that enters the receiver via the antenna and increases the noise level at the input of the receiver, (2) false target generation, or repeater jamming, by which hostile jammers introduce additional signals into the radar receiver in an attempt to confuse the receiver…

1.2.1 Noise Jamming

Açıklaması şöyle. Jammer tarafından gönderilen sinyal gürültü yaratır

Noise jammers modulate the jamming signal with AM or phase noise.

Uygulayabileceği bazı karıştırma (jamming) teknikleri şu şekilde tasnif edilebilir. 

- Spot (Nokta)
- Barrage (Baraj)
- Sweep (Tarama)

- Spot tekniğinde sadece belirtilen frekansta karıştırma yapılır. Açıklaması şöyle. Bu teknik frekans atlamalı radarlarda etkili değil.

Spot jamming or spot noise occurs when a jammer focuses all of its power on a single frequency. This overwhelms the reflection of the original radar signal off the targets, the "skin return" or "skin reflection", making it impossible to pick out the target on the radar display. This technique is only useful against radars that broadcast on a single frequency, and can be countered by changing the frequency or other operational parameters like the pulse repetition frequency (PRF) so the jammer is no longer broadcasting on the same frequency or at the right times. While multiple jammers could possibly jam a range of frequencies, this would consume many resources and be of little effect against modern frequency-agile radars that constantly change their broadcasts.

- Barrage tekniğinde merkez frekans belirtilir. Sağında ve solunda belirtilen aralıkta aynı anda karıştırma yapılır. Açıklaması şöyle

Barrage jammers attempt to overwhelm the radar receiver with an interfering signal in the received frequency band.

Bu yöntemde jammer'ın gücü azalır. Açıklaması şöyle

Barrage jamming is the jamming of multiple frequencies at once by a single jammer. The main drawback of this technique is that the jammer spreads it’s power across multiple frequencies, making it comparatively less powerful at a single frequency.

- Sweep tekniğinde belirtilen iki frekans arasında hızlıca atlayarak karıştırma yapılır. Açıklaması şöyle

Sweep jamming is the process of shifting a jammer’s full power from one frequency to another. This “sweeping” motion jams multiple frequencies in quick succession, although not all at the same time. 

1.2.2. False Target Generation

Açıklaması şöyle. 

Deceptive jammers use either a repeater or a memory to produce a replica of a radar return with appropriate modifications in time or frequency. Repeater jammers modify and retransmit received radar signals so the resulting echo relays inaccurate position.

Uygulayabileceği aldatma teknikleri şu şekilde tasnif edilebilir

- False Target (Sahte Hedef)
- Rage Gate Pull In (Mesafe Kapısı Çekme)
- Rage Gate Pull Off (Mesafe Kapısı İtme)
- Velocity Gate Pull In (Hız Kapısı Çekme)
- Velocity Gate Pull Off (Hız Kapısı İtme)
- Cross Polarization (Çapraz Polarizasyon)
- Cross Eye (Şaşı Göz)
- Blinking Jamming (Dönüşümlü Karıştırma)

1.2.3 Radar burn-through

Açıklaması şöyle. Jammer'a rağmen artık hedeften geri yansıyan sinyalin gizlenemediği yani radarın baskı altına alınamadığı mesafedir.

The burn-through range is the distance from the radar at which the jamming is ineffective. When a target is within this range, the radar receives an adequate target skin return to track it. 

1.2.4 Look Through - Ara Bakış

Elektronik Taarruz sistemi belli aralıklarla susarak, Elektronik Destek sisteminin karşı tarafı tekrar dinleyebilmesine izin verir.

1.2. Muhabere Elektronik Taarruz

Açıklama yaz

1.3. Decoy Sistemleri

Decoy (Türkçesi yem) kelimesinin açıklaması şöyle

Decoy, deceptive device used to draw an enemy away from a more important target.

Decoy Sistemleri platformun dışında çalışırlar. Bunlar şöyle olabilir

- Radar Decoy
- Towed RF Decoy (Çekili RF Dekoy)
- Air Launched Cruise Decoy
- Floating RF Decoy (Yüzer Dekoy)
- Disposable(Expendable) RF Decoy (Sarfedilebilir Aktif RF Dekoy)

 Towed Decoy

Açıklaması şöyle. Uçaklar tarafından kullanılır. RF güdümlü füzeleri üzerine çeker.

One method of defeating radar-guided missile attacks is to tow a decoy behind the host aircraft that is a more attractive radar target than the aircraft itself, so that the attacking missile chooses the towed decoy as opposed to the aircraft. 

Modern towed decoy sistemleri fiber-optik kablo ile uçağa bağlıdır ve uçaktan kumanda edilerek farklı tehditlere cevap verebilir.

Floating Decoy

Açıklaması şöyle. Gemiler tarafından kullanılır. RF güdümlü füzeleri üzerine çeker.

A ship having identifiable radar hot spots along its length is protected against radar homing missile attack by a floating decoy, which may be towed. The decoy has a plurality of radar return signal generators spaced along its length, with the amplitudes and spacing of the generators emulating the amplitudes and spacing of the hot spots. The homing missile is seduced away from the ship and toward the decoy.

Disposable RF Decoy

Açıklaması şöyle

Disposable decoys (also known as expendable decoys) are very small RF jamming devices that can be released by aircraft. Essentially, they are the mixture of ECM pod and chaff, they are released like chaff but operate like an ECM pod. Early generation of expandable decoy only consist of simple TWT and repeater, letting them retransmit signal with more power to appear like more attractive target, but modern expandable decoy such as Brite cloud are equipped with DRFM, thus allowing them to use many complex jamming techniques that traditionally only used by dedicate jamming systems.