Maddenin En Son Yapıtaşı Higgs Bozonu – Christophe Grojean, Laurent Vacavant

Bazı nükleer çekirdekler kendiliklerinden, ışık hızına yakın hızlarla hareket edebilen değişik enerji ışınları yayarlar : sözgelimi belli bir sayının üstünde nötronu olan bir potasyum atomu beta parçacıklarıyayan bir kalsiyum iyonuna dönüşecektir. Henri Becquerel bu beta parçacıkları kütlesi üstündeki elektrik yükünün e/m’sini ölçer ve bulduğu değerin sabit ve ayrıca elektronin e/m’siyle özdeş olduğunu saptar. Yayılan elektronun toplam enerjisi elektronun kütle enerjisine eşit minimal bir değer ile maksimal bir eşik arasında gidip gelmektedir. Dolayısıyla enerji kaybolmuş gibidir. Wolfgang Pauli’ye göre, problemi çözmek için elektrik yükü açısından nötr, kütlesi sıfır olan ve ayrıca hiçbir şekilde gözlemlenemeyen bir parçacığın olması gerekiyordu. Bu düşüncelerini bir makalede yayınlama cesaretini gösterememiştir. Buluşunun deneyle doğrulanması ve sonunda bir nötrinonun gözlemlenebilmesi için altı yıl beklemek gerekecektir. Nötrinolar maddeyle o kadar zayıf ilişkiler içindediler ki bir kurşun levhadan geçmeye çalışan nötrinoların yaklaşık yarısını durdurabilmek için bu levhanın bir ışık yılı yani 10000 milyar kilometre kalınlığında olması gerekir.

Güçlü nükleer kuvvet, protonu oluşturan kuarkları bir arada tutan kuvvettir. Hidrojen atomundaki elektronun bağlantı enerjisi bu atomun kütle enerjisinin sadece on milyarda biriyken bir helyum çekirdeğindeki protonların ve nötronların bağlantı enerjisiçekirdeğin kütlesinin yüzde biridir. Dahası protonlardaki ve nötronlardaki kuarkların bağlantı enerjisi kütlelerinin %99’una denk düşer. Sonsuz küçük içinde maddenin yapılanmasını sağlayan üç temel kuvvet vardır, hadronlar içinde kuarkları tutan güçlü kuvvet, nükleer dönüşümü gerçekleştiren zayıf kuvvet ve atonlardaki elektronları döndüren ve atomlar arasında bağlantı kuran elektromanyetik kuvvet. Dördüncü temel kuvvet Newton’un kuvvetidir, bu kuvvetin sonsuz küçük dünyada yeri yoktur çünkü diğerlerinden çok zayıftır.

Temel parçacıkların Higgs alanıyla etkileşimleri hareketlerinin önünde bir engeldir ve bu nedenle kütleleri hareketsizdir. Dolayısıyla temel parçacıklar kütlesinin sorumlusu olarak Higgs alanı gösterilir. Ama bu Higgs alanının evrendeki madde kütlesine katkısı çok azdır.Sözgelimi proton üç kuarktan oluşur ama bu kuarkların kütlelerinin toplamı esasen kuarkları kendi içlerinde birleştiren güçlü etkileşimlerin enerjisine bağlı protonun kütlesinin %1’inden küçüktür. Dolyaısıyla kütlenin kökeninin Higgs alanı olduğunu iddia etmek abartı olur. Bununla birlikte şu da bir gerçektir ki yukarı ve aşağı kuarklar Higgs alanı aracılığıyla kütleye sahip olmasalardı proton nötrondan daha hafif ve atom çekirdekleri de kesinlikle istikrarsız olurdu.

LHC’de toplam 9600 mıknatıs vardır. Bu mıknatıslar dev bir manyetik alan oluşturur ve 7 TeV’luk bir protonun yörüngesini 27 kilometrelik bir tünelin eğimini izleyecek biçimde eğmesi gerekir.: 8.3 Tesla. 8.3T’lik bir alan yeryüzü manyetik alanından 200000 kat daha yoğundur. Bir insanın ara sıra maruz kalabileceği en güçlü manyetik alan 1.5 Tesladır. Bu tür mıknatısları tasarlamak LHC için en önemli teknolojik güçlüklerden biri olmuştur. Bu elektrikli mıknatısların bobinleri çok ince telden yapılır (7 mikrometre kalınlığındadır yani bir saç telinden incedir). LHC’nin bütün mıknatıslarının üretilmesi için bir buçuk bilyar kilometre tel gerekir; Dünya ile Güneç arasındaki mesafenin beş katıdır bu! İçinde protonların dolaştığı boş tüpün çevresine mıknatıslar sarılır ve -271,3 derecede soğutulmuş bir kap içine yerleştirilirler. Olası en soğuk ortam mutlak sıfırın 2 derece kadar fazlasıdır. Bu ısı mıknatıslar sisteminde 120 ton süper akışkan helyumun dolaşmasıyla elde edilir. 37000 tonluk LHC’yi 27kilometrelik bir alanda soğutmak ve bu ısıda tutmak için eşi görülmemiş bir soğuk üretmek , 170 kW gücünde bir soğutma yapmak gerekir. Dolayısıyla LHC dünyanın en güçlü soğutucusudur.

Domain Driven Design

Domain-Driven Design, karmaşık yazılım sistemleri geliştirirken karşılaşılan temel problemlere çözümler öneren bir yaklaşım. DDD, yazılım tasarlanırken tüm süreçlerin domain’i esas alarak kurgulanmasını tavsiye ediyor. Konunun ehli Eric Evans “Domain-Driven Design – Tackling Complexity in the Heart of Software” isimli kitabında, kompleks sistemlerde oluşan problemlerin kaynağının çoğunlukla domain’in içinde gizli olduğunu söylüyor. Peki nasıl uygulanıyor bu DDD?

Diyelim ki bir havayolları yazılım sistemi geliştiriyoruz. Biz yazılımcı olarak, ne uçakların hangi koşullarda iniş yaptığını, ne kargoların hangi formüllerle hesaplandığını, ne de havayolu trafiğinin nasıl yönetildiğini biliriz. Bunları bilen kişiye “domain expert”, yani işin ehli diyoruz. Bu kişiler yazılım geliştirmeyi bilseler herşey çok güzel olabilirdi ama, o konuda bize ihtiyaç duyuyorlar. Dolayısıyla bize havayollarını anlatmaları gerekiyor.

Bize tüm işi güzel güzel doğal dille anlatıyorlar, dinliyoruz, not alıyoruz. İhtiyaçlarını belirliyoruz, sistemi modellemeye başlıyoruz. Bir seferde olmuyor ama tabi, tekrar tekrar sorular soruyoruz çünkü bizim işimiz domain’in problemini yazılım dünyasında ifade etmek ve yazılım dünyasında ona çözüm üretmek. Yalnız yazılım dünyasıyla gerçek dünya arasında çok fark var. Biz dünyayı sınıflar, metodlar, algoritmalar olarak görüyoruz, aklımıza polymorphism, inheritence geliyor, pattern’ler geliyor, ama aslında bu gerçek dünya için hiçbir şey ifade etmiyor. Yani ayrı dillerden konuşuyoruz. Bu noktada DDD diyor ki, ilk önce bir ortak dil geliştirmek lazım, bu dile de “Ubiquitous Language” diye komik bir isim verelim. Domain ile ilgili bilgiyi veren kişiler ile ortak bir dil geliştirelim, onlar bize anlatacaklarını hep o dilin kelimeleriyle anlatsınlar, biz de sınıflarımıza, metodlarımıza o dilin kavramlarını kullanarak isim verelim. En azından aşağı yukarı aynı şeylerden bahsediyor hale gelelim.

Dil konusundan sonra, biraz da yazılımı modelleme esnasında katmanlı bir yapı oluşturmaktan bahsediyoruz. Domain Driven Design, “Presentation Layer”, “Application Layer”, “Domain Layer” ve “Infrastructure Layer” olarak dört katman üzerinde sistemi kurgulamayı öneriyor. Burada Domain katmanı sistemin temelini oluşturuyor ve tüm domain nesneleri, iş kuralları (business rules) gibi domain’le alakalı kavramları burada tanımlıyoruz. Son olarak domain katmanını mümkün olduğunca diğer katmanlardan izole etmeye, yani bağlılığını azaltmaya çalışıyoruz. Basitçe ifade etmek gerekirse, domain katmanında işi tanımlıyor ve diğer katmanlları domain katmanına servis edecek şekilde tasarlıyoruz. DDD, katmanlı yapıyı bu şekilde tasarlayabilmemiz için bazı tasarım blokları öneriyor. Eric Evans yukarıda bahsedilen kitabında bu blokları detaylı olarak anlatıyor.

Biliyoruz ki “Refactoring” karmaşık sistemler için çok baş ağrıtan bir konu. Kompleks bir sistemi tam olarak modellemek oldukça zordur, mutlaka açıkta kalan, net olmayan konseptler olacaktır. Domain Driven Design bu konuda bazı öneriler sunuyor. DDD’ye göre, refactoring sürekli devam etmeli ve domain’in soyut olarak kalmış tüm kavramları aranarak bunlar somut olarak sistemde ifade edilmeli. Yani anlaşılmamış veya belirsizlik içeren herşey açıklığa kavuşmalı. Bunu sağlamada yardımcı olması amacıyla üç yöntem öneriliyor (Constraint, Process, Specification). Aşağıda bağlantısını verdiğim araştırma makalemden bu yöntemler hakkında detaylı bilgi edinebilirsiniz.

DDD’nin son olarak dikkat çektiği konu, model bütünlüğünü sağlamak. Büyük sistemlerin modelleri de büyük olur ve bir noktadan sonra modelin bütününe yukarıdan bakmak pek mümkün olmayabilir. Modelin alt modelleri, servisleri, modülleri gibi tüm alt elemanları tek başlarına bile oldukça kapsamlıyken, modelin bütünlüğünü sağlamak ve sürdürmek başlı başına bir mesele olacaktır. DDD, bir modelin alt elemanlarını gruplayıp, her alt modelin fonksiyonalitesine ve karakteristiğine göre onları verimli şekilde organize etmek konusunda yardımcı olacak bazı yöntemler ve pattern’ler tanımlıyor. Bu pattern’ler de detaylı olarak makaledeki kaynaklardan incelenebilir.

Eric Evans bir röportajında diyor ki Domain-Driven Design yazılım dünyasının popüler konularından birisi oldu ve kapsamlı yazılım projelerinde kullanılıp faydası görüldükçe yaygınlaşacak, ilgili konseptleri daha da geliştirilecek. Buna ek olarak, “Görmemişin DDD’si olmuş, tutup projesine takmış” durumuna da düşmeyin diyor. DDD’yi heryerde kullanmıyoruz, yalnızca gerektiği yerde gerektiği oranda uygulayıp, gerekmediği yerde unutuyoruz. Çünkü Domain-Driven Design,  olduğu gibi alıp projenizi üstüne oturttuğunuz bir kalıp değil, bazı yöntemler öneren teorik bir yaklaşım.

DDD ile ilgili yazdığım araştırma makalesi : https://alifindik.files.wordpress.com/2011/06/domain-driven-design-findik_ali.pdf

The Origins of Pattern Theory by Christopher Alexander – OOPSLA Speech

Cristopher Alexander, mimari dünyasındaki pattern dilinin mucidi. Dünyada şimdiye kadar yapılmış ve genel olarak “güzel” sıfatını edinebilmiş tüm yapıların ortak özelliklerini inceleyip, bir yapıyı “güzel” hale getirecek bazı kurallar havuzu geliştirme fikrini ortaya atıyor. Bunu duyan yazılımcılar, “sonuçta biz de yapı inşa ediyoruz,  benzer pattern’ler kullansak uygulamalarımız daha güzel olur mu?” diyorlar. Bunun üzerine Alexander, 1996’da California’da yazılımcılara bir konferans veriyor ve bununla ilgili görüşlerini açıkça ifade ediyor.

Konuşmaya mimari dünyasındaki son durumdan ve o güne kadar yaptığı çalışmaların beklediği oranda bir fayda sağlayamamış olmadığından ötürü duyduğu mutsuzluğu dile getirerek başlıyor. Ona göre mimarlığın temel amacı, “yaşayan yapılar” üretmek olmalı. Dünyadaki mimari yapılanmanın “cansız” olduğunu açıklıyor ve günden güne daha da kötüye gitmesinden kaynaklanan ümitsizliğinden bahsediyor. “Pattern” teorilerini ortaya atmasının ve bununla ilgili çalışmalar yapmasının temel nedeninin, yaşayan yapılar üretmek için bazı “genel doğru”lar geliştirmek olduğunu söylüyor.

Mimarideki şablon kavramının yazılımcıların şablonlarından temel farkının, üretilme amacı olduğunu ve mimaride şablonların üretilmesinde “göze hitap etme, güzellik” kavramının temel unsur olduğunu ifade ediyor. “Tarihteki tüm güzel olarak nitelendirilmiş yapıların ortak özellikleri nelerdir, bu özellikler yeni yapılara uygulanırsa ne gibi güzellikler ortaya çıkabilir?” sorusunun cevabından türeyen mimari şablonlarının, beklediği güzelliği beklediği oranda oluşturamadığını da üzüntüyle dile getiriyor. Yazılımdaki şablonların üretilme amacının ise kullanım kolaylığı, sorunlara ortak çözüm üretme gibi kavramlardan doğduğunu söylüyor. Yazılımdaki şablonlar yazılımın “göze güzel görünür” olmasını değil, ideal çalışmasını amaçlıyor. Bu farka katılıyorum, fakat yazılım dünyasında bu “ideal çalışma” talebinin oluşma nedeninin, dünya üzerindeki “çirkin” yapıların yaratılmış olma nedeniyle aynı olduğunu düşünüyorum. Büyük yazılım projelerinde karmaşık sorunlara çözüm üreten şablonlar, karmaşık problemlere sahip olduğumuz, kalabalık dünya için geçerli. Tüm mimarlar dünyadaki çirkin yapıları düzeltmeye kalksa, çok küçük bir oranını bile düzeltemeyeceklerini söylüyor Alexander. Yazılımda da şablonlarla sadece geleceğin ruhsuz yazılımlarının oluşturacağı karmaşık dünyayı daha kolay ve ideal yöntemlerle baştan yaratıyoruz. Dünya bu kadar kompleks bir yer olmak zorunda mıdır? Şu an erişebildiğimiz bilginin ne kadarına ihtiyacımız var?

Alexander’a göre doğadaki düzeni sağlamak için, doğanın dinamiğine uygun yapılar geliştirmek gerekli. Kendi kendini besleyen canlı sistemlerin sürekliliği ve güzelliği getireceğini düşünüyor. Mimari dünyasında ikinci dünya savaşı dönemlerinden beri canlı yapıların geliştirilmediğinden bahsediyor. Bu canlılık konusunda ilginç bir noktaya değiniyor ve, bilişim teknolojilerinin canlı sistemler üretme yöntemini baz alarak geliştiğini söyleyerek, bilişim ve yazılım dünyasından yardım istiyor. Yazılımın geleceği belirleyecek en önemli gelişim alanlarından biri olduğunu öngörüyor ve yazılımdaki bu “yenileyici” sürecin mimari dünyasına da adapte edilmesi gerektiğini, dünyanın ancak bu şekilde daha güzel bir yer olabileceğini söylüyor. Güncel örnek verelim, para kazanmak amacıyla bir web sitesi yapacaksanız, içeriği kendiniz gireceğiniz bir sitedense, insanların besleyeceği bir siteyi tercih edersiniz. Tüm büyük başarılı(!) örnekler bu şekilde çalışmıyor mu? Eğer Alexander’ın bahsettiği canlı sistem kavramı bu ise, bunun yarattığı ve yaratacağı bilişim dünyasının, mimari dünyanın şu an gelmiş olduğu durumdan farklı olacağını sanmıyorum. Doğadaki canlılık, Alexander’ın en başta yola çıktığı “moral” noktasından başlamalı. Bir ormandan bir fotoğraf karesi aldığınızı düşünün, bu karede bir ağacın yapısını, üzerindeki delikte yaşayan hayvanı, dalına yapılmış olan kuş yuvasını, yanından geçen dereyi ve tüm canlılığın uyumunu düşünün. Doğanın ne bir şablon, ne de bir yöntem kullanarak bunu kurguladığını düşünmüyorum. Aynı Alexander’ın dediği gibi, içinde yaşayacak olan kişiler yaşayacakları yerleri bizzat oluşturursalar, doğanın bize zaten sağladığı canlılığı simüle etmek zorunda kalmayız. Bilişim dünyasına dönelim, bilgisayar teknolojisi, önceden yapılan işleri kullanarak daha büyük işler yapan sistemler geliştirmek üzerine kuruldu ve ilerliyor.  Robotlar yaşamımıza girdi, girecek, eğer Turing yanılmış ise belki bir gün akıllı robot üreten robotlar da üretilecek. Alexander’ın “Generative Process” olarak nitelendirdiği ve medet umduğu yazılım dünyasının gelişimini kurgulayan bu kavram, getireceklerinden fazla götürecek gibi geliyor bana. Ya da bilimkurgulardan çok etkileniyorum belki de. Bana kalsa, dünyayı emanet edeceğim son meslek grubu bilgisayarcılar olurdu herhalde.

Konferansın metni : http://www.patternlanguage.com/archive/ieee/ieeetext.htm