Bunun için Nuget içerisindeki Microsoft.EntityFrameworkCore.InMemory paketini kurduk öncelikle. Bu size in-memory olarak bir veritabanı sağlıyor. Daha sonra entity framework içerinde nasıl DbContext‘ten bir sınıf türetip içerisinde DbSet‘ler kullanarak tablolar oluşturuyorsak burada da aynı yapıyı kullanıyoruz. Sonrası aşağıdaki gibi;
Yazılım mühendisliği diğer mühendisliklere göre yeni bir alan aslında. Yeniliklere de oldukça açık. Genelde takım halinde icra edilen bir mühendislik olan yazılımı takım kimyasını koruyup, egoları bir kenara bırakıp nasıl yapılacağı ile ilgili yol gösterir bu kurallar.
1. Understand and accept that you will make mistakes.
Orhan Gencebay’ın dediği gibi, “hatasız kul olmaz“. Yazılımdaki hatalar çok az sektörde ölümcül durumlara sebep olur. Önemli olan bu hatalardan ders çıkarmak, öğrenmek, bu hatalara gülebilmektir. Bu hataları canlı ortamda tecrübe etmeden bulmak en önemli amaçtır.
2. You are not your code.
Geliştiricilerin kodları incelemesinde amaç hataları bulmaktır, ve hatalar daima olacaktır. Bu hataları kişisel olarak algılamayıp birinci maddeyi hatırlamalısın. Herkes hata yapabilir fakat önemli olan bu hataları çözmektir.
3. No matter how much “karate” you know, someone else will always know more.
El elden üstündür. Yazılım dünyasında benim en sevdiğim konulardan biri bu. Tecrübeye bakmaksızın her hangi bir kişiden yeni bir bakış açısı, yeni bir yöntem veya daha kolay bir çözüm öğrenebilirsiniz. Öğrenmek için hep çaba sarf edin, sormaktan çekinmeyin.
4. Don’t rewrite code without consultation.
Önemli bir şeyi değiştirmeden önce danışmak faydalı olur. Code review zaten yanlış bir değiştirmenin önüne geçecektir ama danışmaktan zarar gelmez. Hatalı kodu düzeltmek ile kodu yeniden yazma arasındaki farkı iyi anlamamız gerekir.
5. Treat people who know less than you with respect, deference and patience.
Yazılım ile alakası olamayan kişiler veya daha az tecrübeli, daha az bilgili yazılımcılar ile çalışırken saygılı, sabırlı ve geri bildirime açık ol. Yazılımcılar her zaman itiraz eden, üstten bakan kişiler olmamalıdır.
6. The only constant in the world is change.
Efesli Herakleitos‘un dediği gibi, “Değişmeyen tek şey değişimin kendisidir”. Yazılım için çok önemli bir söz. Durmadan değişen, gelişen teknolojiler ile baş başayız. Yenilikleri olumlu şekilde karşılamalı ve yeni meydan okumalar olarak görmelisin.
7. The only true authority stems from knowledge, not from position.
Bilgi yetkinliği, yetkinlik ise saygıyı doğurur. Saygı görmek istiyorsanız daha bilgili olun. Kendinizi her zaman geliştirin ve yetkin bir insan olun.
8. Fight for what you believe, but gracefully accept defeat.
Fikirlerini doğru şekilde savunmalısın ama fikrinden daha iyi fikirler daha doğru çözümler olduğunda vazgeçmeyi bilmelisin. Takım kararlarına saygı göster. Bazı durumlarda sana daha az mantıklı gelen tercih uygulanabilir. Bu karar sonucunda çıkan sonuçlara da saygılı olmalısın. Sonuç olarak senin fikrin doğru çıkmış olsa bile “ben demiştim ama” gibi kalıpları fazla kullanmaktan kaçınmalı, sadece gerekli yerde kullanmalısın. Olaylar yaşanır geçer, önemli olan daha önce de bahsettiğimiz gibi bunlardan en faydalı sonuçları çıkarmaktır.
9. Don’t be “the guy in the room.”
Karanlık bir köşede sessizce çalışan yabani kişi olmayın. Çalışma ortamınızdaki herkesle ilişki kurun. Sadece yazılım takımı değil herkesle. Yazılımcıların işi hep bilgisayarlarla olduğu için iş ortamında doğal olarak daha az sosyal etkileşimde bulunurlar. Bunu değiştirin.
10. Critique code instead of people – be kind to the coder, not to the code.
Kişileri değil kodu eleştir, kodlara değil kodu yazan kişiye nazik ol. kod içerisinde bir hata gördüğünde veya değişiklik olmasını istediğinde “bunu niye böyle yaptın” diye bir yaklaşım yerine “bunu böyle yapsak daha iyi olmaz mı?” yaklaşımı her zaman daha avantajlıdır. İstediğin değişikliğin sebebinde açıklayıcı ol, teknik olarak neden gerekli olduğu doğru bir şekilde anlat. Aynı hataları senin de yapacağının farkında ol ve ona göre davran.
Daniel Habib isimli bir programcı, yazılım görüşmelerinde konu ne olursa olsun nasıl bir yaklaşım sergilemeniz gerektiği konusunda bir spreadsheet oluşturmuş.
Bir gün karşınıza Ozan Güven çıkıp ta “Kaç yaşındasın sen?” derse ne yapardınız? Basit bir soru değil mi bu? Ancak, sorunun ayrıntı düzeyine ve bakış açınıza bağlı olarak cevap değişebilir.
Peki soruyu şöyle değiştirelim o zaman; “Kaç dakikadır yaşıyorsun?”. Bu soruyu yanıtlamak için, kolayca elde edilebilecek olandan çok daha fazla bilgiye ihtiyacımız var:
Doğum tarihiniz ve tam saati
Doğumunuzun zaman dilimi (veya konumu)
Bir yaz saati uygulamasına geri dönüş geçişi sırasında doğduysanız, (bazı saat dilimlerinde) saatler geriye doğru hareket ettiğinde – örneğin, 2:59:59 AM’den 2:00:00 AM’ye kadar. 2:30’da doğduysanız, o gece 2:30 saati aslında iki defa yaşandığı için hangisinde doğduğunuzu bilmeniz gerekir.
Çoğu insan tüm bu bilgilere düzenli olarak sahip değildir ve genellikle umursamıyoruz da bu tarz bilgileri. Neden umursayalım ki? Birisi ne kadar süredir hayatta, ölü, evli, çalışıyor veya benzeri bir soru sorduğunda, genellikle “30 yıl” veya “6 ay” veya bazen “2 yıl, 4 ay ve” gibi takvimsel bir cevap veriyor oluruz.
Bu, bir takvimin kullanılması anlamına gelir ve genellikle modern zamanlardaki Gregoryen (yani Miladi) takvimini önemsiyoruz.
Burada temel şudur; takvimsel bir ölçü birimi, zaman geçişinin insanlaştırılmış bir ifadesidir. Bu, bilgisayarın tipik olarak ölçtüğü ve programcılar için genellikle kafa karışıklığı yaratan geçen süreden oldukça farklı bir kavram.
Üstelik buna “Doğu Asya yaş hesaplaması” gibi kavramları eklemiyorum bile. Binlerce yıldır Kore, Japonya, Vietnam, Çin gibi ülkelerde insanlar 1 yaşında doğuyorlar. Ve yaşları doğum günlerinde değil de, yılbaşında artıyor. Yani bir bebek 31 Aralık’ta doğduğunda, ertesi gün aslında iki yaşına giriyor. Sizinkinin ne olduğunu öğrenmek istiyorsanız, şu basit denklemi takip edin: İçinde bulunduğunuz yılı alın, doğum yılınızı çıkarın ve bir ekleyin.
Üstelik Kore gibi ülkelerde, “yaş” kavramı çok önemlidir. Sizden yaşlı insanlara karşı saygılı olma Kore kültürünün önemli bir parçası. Bir kişi sizden 1 yaş büyük bile olsa, o kişi ile birlikte bir şeyler yemenizi, içmenizi ve hatta konuşmanızı değiştirebilir. Çin ve Vietnam’da bu hesaplama genellikle yaşlı insanlar tarafından kullanılırken, Kore’de bu herkes tarafından kullanılıyor.
Yüzlerce yıldır Koreliler yaşı hesaplamak için dünyanın çoğundan farklı bir yöntem kullandılar. Bazen ay yaşı, nominal yaş veya Doğu Asya yaşı hesaplaması olarak anılır, ancak Kore’de buna sadece Kore yaşı denir. Yöntemin kökenleri Asya’nın farklı bölgelerine yayılmadan önce Çin’dedir, ancak bugün Güney Kore herkesin hala kullandığı tek ülkedir.
Ozan güven “Kaç yaşındasın sen?” diye sorduğunda karşısındaki kişi “19” demişti. Buna karşılık olarak ta Ozan güven “16 yaşında bi tane adamsın.” diyerek karşılık vermişti. Yaş kavramının bu kadar karışık olduğu bir dünyada, belki de ozan güven haklıdır, kim bilir..
2038 yılında bilgisayar sistemlerini etkileyebilecek bu problemi açıklamaya çalıştım bu videoda.
Bundan önce daha iyi anlaşılması adına bahsetmek istediğim y2K, yani 2000 yılı bug‘ı.
Bildiğiniz gibi bilgisayar sistemleri 1950’li yıllarda geliştirilmeye başlandı ve günümüze kadar devam etti. Bu süreçte birçok program yılları yalnızca son iki basamakla temsil ederek 2000 yılını 1900’den ayırt edilemez hale geldi. Bu da 1 ocak 2000’de bir çok sistemde problemler yaşanacağına dair kehanet oluşmasına neden oldu.
2038 yılı problemi ise, birçok dijital sistemde zamanı 1 Ocak 1970 UTC gece yarısından (Unix time) bu yana geçen saniye sayısı olarak temsil etmek ve onu işaretli bir 32-bit tamsayı olarak saklamakla ilgilidir. Bu tür uygulamalar, 19 Ocak 2038’de UTC 03:14:07’den sonraki süreleri kodlayamaz. Y2K sorununa benzer şekilde, Yıl 2038 sorunu, zamanı temsil etmek için seçilen yetersiz sayıda bit (rakam) nedeniyle oluşur.
Nedenleri;
1 Ocak 1970’den bu yana, işaretli bir 32-bit tamsayı kullanılarak depolanabilen en son zaman, 19 Ocak 2038 Salı günü 03:14:07’dir (2^31 − 1 = 1 Ocak 1970’ten sonra 2.147.483.647 saniye).
Bu tarihten sonraki süreyi artırmaya çalışan programlar, değerin dahili olarak negatif bir sayı olarak saklanmasına neden olur ve bu sistemler, 13 Aralık 1901 Cuma günü 20:45:52’de (1 Ocak 1970’den 2,147,483,648 saniye önce) meydana geldiği şeklinde yorumlayacaktır. ). Bu, sayacın kullanılabilir ikili rakamların veya bitlerin bittiği ve bunun yerine işaret bitini çevirdiği tamsayı taşmasından kaynaklanır.
Hangi sistemler savunmasız?
Öncelikle embeded olarak çalışan ve özellikle tarihleri hesaplama veya loglama için kullanan sistemler. Özellikle uçuş sistemlerinde ve otomobillerde yoğun olarak kullanılıyor bu tarz sistemler. Bu sistemlerdeki ABS gibi kilitlenme önleyici fren sistemleri, ESC ve ESP gibi elektronik stabilite kontrolü yapan kısımlar ve GPS alıcıları kullanıyor olabilir. Ancak bu, tüm bu sistemlerin Y2038 sorunundan etkileneceği anlamına gelmez, çünkü bu tür birçok sistem tarihlere erişim gerektirmez. Bunu yapanlar için, mutlak saatler/tarihler değil de, yalnızca saatler/tarihler arasındaki farkı izleyen sistemler hesaplamanın doğası gereği büyük bir sorun yaşamayacaktır.
Ayrıca mysql’in 2021 ağustos sürümünden önceki versiyonlarında, UNIX_TIMESTAMP fonksiyonu 19 Ocak 2038 Salı günü 03:14:07’den sonra 0 döndürüyormuş.
Problemi veri yapıları hangileri?
Günümüzde kullanılan birçok veri yapısı, gömülü 32 bitlik zaman temsiline sahip. Ama tam bir liste vermek neredeyse imkansız.
Dosya sistemleri (birçok dosya sistemi, süreleri temsil etmek için yalnızca 32 bit kullanır), binary dosya biçimleri (32 bit zaman alanlarını kullanan), veritabanları (32-bit zaman alanları olan), UNIX_TIMESTAMP() benzeri komutlara sahip SQL gibi veritabanı sorgu dilleri vs..
Kısaca 32-bit zaman gösterimleri içeren veri yapılarını kullanan herhangi bir sistem risk arz edecektir.
Peki çözümü nedir?
2038 Yılı sorunu için evrensel bir çözüm yoktur. Örneğin Freebsd ve OpenBsd gibi işletim sistemleri bazı değişiklikler yapmışlar ama bazı değişiklikleri de “backward compatibility” nedeniyle yapamamışlar.
Neden umursayalım ki daha 17 sene var?
Bazen gelecekte bazı şeyler olur ve bunun ne zaman olacağını bilmek isteriz. Bazen, 17 yıllık bir ipotek gibi, 17 yıldan fazla bir süre sonra planlanması gerekir. Bu sorun zaman geçtikçe daha da kötüleşecek, çünkü yazılım geliştirici olmanın en sinir bozucu yanlarından biri, her zaman upgrade yapmayan birilerinin olmasıdır. Ve her zaman, asla upgrade yapmayan bir çok insan olacak, emin olun.
64 bit işlemcileri kullanmaya başladığımızda sorun ortadan kalkacak, değil mi?
64 bit işlemci kullanmanız, 2038 yılı bug’ı konusunda temiz olduğunuz anlamına gelmez. Örneğin, yeni Apple bilgisayarınızda 64 bit işlemci var ama işletim sistemi hala 32 bit tam sayılar ve 32 bit time_t ile çalışıyor.
Tamsayı boyutunu değiştirdiğinizde, tüm yazılımınızı yeniden derlemeniz gerekir. O zaman Mac uygulamalarının 32 bit ve 64 bit sürümleri göndermesi gerekir. Ancak bu durum hem geliştirici, hem de kullanıcı için acı verici ve sorunlu bir süreç.
Ve sırf yeni bir 64 bit işlemci kullanıyor olmanız, herkesin kullanacağı anlamına da gelmez. 32 bit işlemciler sadece PC’lerde ve eski donanımlarda değil, arabanızda, telefonunuzda, saatinizde, TV’nizde, DVD oynatıcınızda da ucuz ve bol bol duruyor olacak.
Texas üniversitesinin sitesinde bulunan, Adnan Aziz’in yazdığı “”Rob Pike: Programlamanın 5 kuralı” makalesini inceledim.
Rob Pike kimdir peki? Kendisi programlama dünyasında çok saygı duyulan bir abimiz. 2002 – 2021 yılları arasında Google’da çalışmış bu abimiz en fazla Go programlama dilinin yaratıcılarından biri olarak bilinir. Ek olarak Unix takımında yer alıp, Bell laboratuvar‘ında çalışmış. Ayrıca Ken Thompson ile UTF-8’i geliştirmiş.
İşte o 5 kural;
1. Yazdığınız bir programın zamanı nerede harcayacağını bilemezsiniz. Darboğazlar şaşırtıcı yerlerde meydana gelir, bu nedenle darboğazın nerede olduğunu kanıtlayana kadar ikinci bir tahminde bulunmaya ve bir hız kesme işlemi yapmaya çalışmayın.
3. Havalı algoritmalar, n küçük olduğunda yavaştır ve n genellikle küçüktür. Havalı algoritmaların büyük sabitleri vardır. n’nin sıklıkla büyük olacağını bilene kadar, süslenmeyin. (n büyüse bile, önce Kural 2’yi kullanın.)
4. Havalı algoritmalar, basit olanlardan daha karmaşıktır ve uygulanması çok daha zordur. Basit veri yapılarının yanı sıra basit algoritmalar kullanın. (Kararsızsanız, brute force kullanın)
5. Veri domine eder. Doğru veri yapılarını seçtiyseniz ve işleri iyi organize ettiyseniz, algoritmalar neredeyse her zaman belli olacaktır. Algoritmalar değil veri yapıları programlamanın merkezindedir.
Yazıda alıntı yaptığı kısmı şu şekilde özetleyebilirim;
Bir seramik öğretmeni okulun ilk gününde sınıfı iki gruba ayırdığını duyurur. Sınıfın sol tarafındakilerin tümü, yalnızca ürettikleri işin miktarına göre derecelendirileceğini, sağdakilerin ise yalnızca kalitesine göre derecelendirileceğini söyler. Yaptığı prosedür basit; günün sonunda, tartıyı getirerek sol taraftaki gruptan 50 kiloluk “A” kalitede ve 40 kiloluk “B” vb. devam eden kalitede ürün çıkartılması beklenirken, sağ taraftaki gruptan sadece 1 kiloluk “kaliteli” ürün ürün çıkartılması beklenmiş.
Değerlendirme zamanı gelir ve ilginç bir sonuç ortaya çıkar; en yüksek kalitede eserlerin tümü, miktar açısından derecelendirilen grup (sol taraftaki) tarafından üretilir. Görünüşe göre, “nicelik” grubu yığınlar halinde iş yapmakla ve hatalarından ders alırken, “nitelik” grubu “mükemmellik” hakkında teoriler üretmekle meşguldü.
Yani, yaptığınız ve üzerinde uzun süre düşündüğünüz tasarım ve teorilere istinaden, bu harcanan zamanın bir şeyleri “geliştirmek,” üzerine daha iyi harcanabileceğidir. Buradaki temel düşünce, erken şekilde başarısızlık için harcadığınız zaman, “doğru şekilde yapmaya çalıştığınız” her şeyi öğrenmek için harcadığınız zamandır. Bu, “yanlış” şeyi geliştirmek için zaman harcayarak elde edemeyeceğiniz bir fayda. Bu orijinal ya da yeni bir fikir değil tabi ki. İşin güzel tarafı, Jeff Atwood burada çömlek yapmaktan yazılım geliştirmeye, veya blog yazısı yazmak için gerekli disiplinler için nasıl geçerli olduğunu açıklamış.
Bu tavsiyeyi değerli kılan, bize hata yapmaktan “korkmamayı” öğretmesi. Sadece bu değil, hatalarımızı “kabul etmeyi” de öğrenebiliriz çünkü sonuçta bu şekilde gerçekten “öğreniriz”. Eğer bir şey durgunlaşmışsa, – bu bir yazılım geliştirmesi de olabilir, kişisel bir ilişki de- bu durgunluktan çıkmak için rastgele bir şey yapmanın hiç bir şey yapmamaktan daha iyi olabileceğini düşünüyorum. Bunu yaparsanız, sonuçları analiz edebilir ve neyi “düzeltmemiz” gerektiğini anlayabiliriz.
Bir sayının 2’nin bir tam kuvveti olup olmadığını nasıl bulabileceğinizi, hem iteratif yolla hem de bit manipülasyon yöntemleri ile anlatmaya çalıştım.
Matematikte ikinin kuvveti, n bir tam sayı iken 2^n şeklinde gösterilebilen sayıdır. Bu üslü sayıda 2 taban, n ise üstür.
Sadece tam sayılar içinde düşünülecek olursa, n ancak pozitif bir değer alabilir. Bu durumda sonuç, 1, 2 ya da 2’nin belirli kere kendisiyle çarpılmasıyla elde edilen sayı olacaktır.
İki ikili sayı sisteminin de tabanını oluşturduğundan, ikinin kuvvetlerine bilgisayar biliminde sık rastlanır. Bu sistemde ikinin bir kuvveti her zaman onluk sayı sistemindeki onun kuvvetleri gibi 100…000 ya da 0.00…001 benzeri bir şekilde yazılacaktır.
Programlamada fibonacci serisi ve belirli sıradaki fibonacci sayısı nasıl hesaplanır? Binet formülü kullanılarak belirli fibonacci sayısı nasıl hesaplanır?
Fibonacci dizisi, her sayının kendinden önceki ile toplanması sonucu oluşan bir sayı dizisidir. Bu şekilde devam eden bu dizide sayılar birbirleriyle oranlandığında altın oran ortaya çıkar, yani bir sayı kendisinden önceki sayıya bölündüğünde altın orana gittikçe yaklaşan bir dizi elde edilir.
/// <summary>
/// N adet fibonacci sayısını bir dizi olarak döner.
/// </summary>
static int[] Fibonacci(int n)
{
var fibSequence = new int[n];
var prev = 0;
var curr = 1;
for(var i = 1; i < n; i++)
{
fibSequence[i] = curr;
curr = curr + prev;
prev = curr - prev;
}
return fibSequence;
}
/// <summary>
/// N index'li fibonacci sayısını dinamik programlama kullanarak döner.
/// </summary>
static int FibonacciNth(int n)
{
if (n == 0) return 0;
if (n == 1) return 1;
var curr = 1;
var prev = 0;
var counter = n - 1;
while(counter > 0)
{
curr = curr + prev;
prev = curr - prev;
counter--;
}
return curr;
}
/// <summary>
/// N index'li fibonacci sayısını Binet formülünü kullanarak döner.
/// https://en.wikipedia.org/wiki/Fibonacci_number#Closed-form_expression
/// 1 ile 75 arasındaki n sayıları için geçerlidir.
/// </summary>
static int FibonacciNthClosedForm(int n)
{
var rootOfFive = Math.Sqrt(5);
var phi = (1 + rootOfFive) / 2; // (≈ 1.61803)
return (int)Math.Floor(Math.Pow(phi, n) / rootOfFive + 0.5);
}