Yazılımın ilk 250 günü - Part 6
18 dk okuma
51. Gün
CSS ve HTML konularında artık bir zorluk çektiğimi hissetmiyorum. Tasarımın nasıl olacağına dair düşünceler ve yapılabilecek şeylerin olasılığı çok fazla olduğu için neyin, nasıl ve nerede kullanılacağı zaman alıyor biraz. Sadece Javascript kullanılan yerlerde kodlamayı kullandığımız için elbette daha uğraştırıcı oluyor. Geçenlerde bir İranlının “a mystery is simple when its solved” gibi bir sözünü duymuştum. Gerçekten de öyleydi. Çözüme ulaşıldığı takdirde kolay görünse de, öncesinde zor olabiliyor. Javascript ya da herhangi bir dilde istenilen çözüme ulaşmak için bir problem çözme yeteneği gerekse de çözüldüğü zaman kolay olduğu anlaşılıyor.Bugün HTML ve CSS tasarımları tamamen bitti verilen site tasarımı için. Font awesome yerine ufak icon görselleri kullanmıştım o kısımları düzelttim. Ürün Card’ları biraz düzelttim ve üzerlerinde bulunan efektleri düzenledim. Sıralama kısmını ve karosellerin hemen yanında bulunan resimli kısmı yaptım. Eksik ya da sorunlu kısımlar şunlar: Kodumdaki gereksiz ayrıntıları silip düzenlemedim bazı yerlerde. Onlara tekrar bakmam gerekli. İkinci karoseldeki fotoğraflar birinci döngüden sonra çok hafif kalıyor görünen kısımda. Ve sıralama butonununda buton dışında bir yere tıklayınca içerik kayboluyor. Oysa ki butona ikinci kez tıklayınca da kaybolması gerekiyor. Onu da fırsat olursa düzelteceğim. Ama genel istenen tasarım yapısının tamamlandığını düşünüyorum.
52. Gün
Bugün SOLID kavramını araştırdım, öğrenmeye çalıştım. 5 tane prensibimiz var bir class-obje yapısının solid olabilmesi için. Güzel bir örnek bulup onun üstünden anlamaya çalıştım bu yapıyı. Öncelikle referans olarak en anlaşılır bulduğum kaynak buydu: Solid Principles- The first five principles of object oriented design
Amacımızın bazı şekillerin alanını bulmak olduğunu farz edelim. Normalde bunu hiçbir prensip kullanmayarak da yapmak mümkün olsa da bizim konumuz SOLID yapısını kullanmak olduğu için ona uygun şekilde tasarlayacağız kodumuzu. Şekillerimizin birinin kare, diğerinin de daire olduğunu düşünelim. Alanlarını bulmak için bilmemiz gereken şeyler kenar uzunluğu ve dairenin yarıçapı her ikisi için ayrı olarak. Biz de bunlar için iki sınıf oluşturabiliriz. Ve alanları hesaplamak için de ayrı bir sınıf oluşturup yine bu sınıfta çıktısını üretebiliriz öyle değil mi? Ama bir sorun var. Eğer bizim çıktımızın JSON formatında olmasını istersek yine hesaplama yaptığımız sınıfta bunu yapmamız gerekecek çünkü çıktımızı o sınıf sağlıyor. Oysa SOLID prensiplerinden birincisine bu durum aykırı. Çünkü birinci prensip diyor ki “bir sınıf sadece tek bir amaca hizmet etmeli ya da sadece tek bir görevi olmalı bir işi yapabilmek için”. Dolayısıyla hesaplamaların yapıldığı sınıftan farklı olarak çıktının ister JSON formatında ister HTML formatında üretildiği bir başka sınıf yaparsak birinci prensibi sağlamış oluruz.Sonuç olarak, şekiller girilir. Sonrasında alanlar hesaplanıp toplanır ve çıktıları alınır. Tüm işlemler farklı class’lar ile gerçekleştirilir. Her sınıf ya da modül farklı bir göreve sahip olur bu şekilde.
İkinci prensibimiz ise “Open-Closed Principle”. Bu prensip der ki “bir sınıf genişletilebilir fakat sınıfın kendisi değiştirilmez”. Az önceki örneğimizden devam edelim. Diyelim ki kullanıcı alan hesaplamalarının yapıldığı sınıfa farklı şekiller, yani farklı hesaplamaları gerektiren veriler girdi. Bizim burda normalde yaptığımız şey yeni if/else statement’ları açarak o sınıfta değişiklikler yapmaktı. Ama ikinci prensip diyor ki, sen her yeni değişikliği bu sınıfta oluşturma. Sınıfın içeriğini değiştirme. Ve bu matematiksel işlemleri, şekillerin bulunduğu sınıflarda method olarak yap. Bunu yaptıktan sonra ise karşımıza şöyle bir problem çıkıyor. Hesaplama yaptığımız sınıfta, kullanacağımız şekil sınıfından gelecek olan method’un varlığını nasıl bilebiliriz? İşte burada interface kavramını kullanmamız gerekmektedir. Şekillerin bulunduğu sınıfta yapacağımız alan hesaplamanın bulunduğu method’u bir interface aracılığı ile deriz ki “bu şekil sınıfı, bu interface’i implement etmekte yani uygulamaktadır”. Bu sayede şekil sınıflarımızın interface’ımızın instance’I olup olmadığını check edebiliriz ve eğer o uygulamıyorsa o interface’I hata mesajı vermesini sağlayabiliriz.
Üçüncü prensibimiz ise “Liskov Substitution Principle”. Der ki “ her alt class veya türetilmiş class, parent class’I için değiştirilebilir olmalı”. Ufak bir özet ve sonrasında devam edelim:
Şimdiye kadar ne yaptık? Şekillerin alanını bulmak istiyorduk. Her şekil için ayrı bir sınıf açtık. Sınıflarda şekillerin property’leri ve method’u vardı. Alan hesaplamak için gerekli property ve alanlarının hesaplanması için gerekli matematiksel denklemlerin olduğu fonksiyonlar. Alanları farklı bir sınıfta hesapladık bu denklemler ile ve kullanıcın girmiş olduğu sınıfta öyle bir method var mı yok mu sorgusunu normalde yapamayacağımız için interface kullandık. Dedik ki her şekil o interface’i implement etsin, yani uygulasın/kullansın. Sonrasında da farklı bir sınıfta çıktılarımız üretilsin. Bu sayede ilk iki prensibi sağlamış olduk.
Diyelim ki şimdi hacim hesaplaması yapacağız. Ve bunun için de alan hesaplaması yaptığımız class’ı extend ettiğimizi düşünelim. Sonuçta biliyoruz ki hacim hesabı için alan da gerekmektedir. Fakat bu hesaplamayı yaptıktan sonra oluşan çıktımızda “error: array to string conversion” gibi bir hata ile karşılaşabiliriz. İşte burada son oluşturduğumuz sınıfta bir değişim yaparak bu hata mesajından kurtulabilir ve çıktımızı dizi yerine bir integer değer olarak alabiliriz. Bu yaptığımız değişim Liskov’un değişim prensibine örnek olarak verilebilir (Açıkçası vermişler, ben onu söylüyorum şu anlık. Çünkü farklı farklı kaynaklardan bunu teyit edebileceğim araştırma henüz yapamadım).
Dördüncü prensibimiz ise “Interface Segregation Principle”. Bu prensip der ki “ client, kullanmayacağı method’lara maruz kalmamalı ya da kendisiyle alakası olmayan ve kullanmadığı arayüz implement edilmemeli”. Daha önce oluşturduğumuz arayüzde sadece 2 boyutlu şekiller için alan hesaplaması vardı. Diyelim ki 3 boyutlu cisimler/şekiller için de hacmi hesaplayacağız. Ama kare gibi şekillerin hacmi yok, yani bu interface’I açıkça dayatmak zorunda kalacağız 2 boyutlu şekillerin sınıflarına da. İşte burada arayüz ayrımı prensibi devreye giriyor. Yani 3 boyutlu cisimlerin hacmini hesaplamak için ayrı bir arayüz oluşturalım. Bu sayede tek bir arayüzde hem hacim hem alan hesaplaması yapmaya çalışırken, alanı olmayan şekillere de aynı arayüzü dayatmayalım. Çünkü onlar da o arayüzde bulunan hacim hesaplama metodu bulunamaz. Bunun üstüne bir geliştirme daha yapılabiliyor. İki ayrı arayüzü tek bir arayüzde birleştirme ya da yönetme işlemi uygulanıyor. Yani tek bir API kullanıyoruz gibi düşünebiliriz. Örneğin bu arayüzde bir hesapla fonksiyonu olursa, hem alan hesabını hem de hacim hesabını bu fonksiyon üstünden yönetebiliriz.
Beşinci prensip ise “Dependency Inversion Principle”. Bu prensip der ki, “class, module gibi kodumuzda bulunan ‘varlıklar’ somutlamanın aksine soyutlanmak zorundadır.” Bu da şu manaya gelir: High level module’ler, low level module’lere bağlı olmak zorunda değildir ve sen bunları birbirinden soyutlamalısın. Sebebine gelelim:
Bir sınıfımız olsun şifre hatırlayıcı diye, ve bu sınıf veritabanına farklı bir sınıf aracılığı ile bağlansın. Veritabanı ile bağlantı oluşturulan sınıf low level, şifre hatırlamak için oluşturulan sınıf high level diye geçer. Böyle adlandırılmalarının sebebi ise: Bir tool ile execution’ın yapıldığı sınıf high level, execution’ın yapılabilmesi için var olan tool ise low level olarak geçmektedir. Devam edelim. Veritabanımızın MYSQL sunucusu olduğunu ve bağlantının MYSQL’e yapıldığını düşünelim. Eğer biz bir gün veritabanı motorunu(engine) değiştirmek istersek, Bunun için ayrıca şifre hatırlama sınıfında da değişiklik yapmak zorunda kalacağız. Bu da “open-closed” yapıya ters düşecektir. Amaç şu: high level sınıf, low level’e olabildiğince az bağlı yani soyutlanmış olmalı. Örneğimizde low level sunucunun mysql’e bağlanması ya da başka bir veritabanı motoruna bağlanması high level sınıfı etkilememelidir. Bunun için de yine arayüz kullanılır. Arayüzü MYSQL bağlantısı oluşturacağımız sınıf implement eder. Bu şekilde de high level sınıfta kullanabiliriz. Bu sayede high level ve low level sınıflar biribirinden soyutlanır.
Zaman olursa çok daha iyi araştırıp anlamaya çalışacağım.
Not
Dün yazdığım raporda SOLID yapısı hakkında detaylı bir örnekle açıklamalarda bulunmaya çalışmıştım. Yeterli olduğunu düşünmekle birlikte tekrar bir özet geçtikten sonra kendimce bir örnekleme girişiminde bulunacağım. Benzetme başarısız olabilir ama üstünde düşünmek keyifli olur diye bu şekilde düşündüm. Önce özetleyelim SOLID'i:SOLID yapısı OOP için kullanılsa da functional programming'e de uyarlanabiliyor kısmen. Evet bu yapıyı obje-class yapılarımız için düşüneceğiz ama bunun da REST API kavramı gibi "inanç,felsefe, kavramsal tasarım, optimize sonuçlar için oluşturulan kurgusal tasarım modelleri, design pattern, mimari" nasıl adlandırırsak adlandıralım bunun kodumuzu yazarken dikkat etmemiz gereken bir fikirler bütünü olarak ele almamızda fayda var.
İlk prensip her modülün tek bir işi olması gerektiğini ve bu işte iyi olması gerektiğini söyler. Modüllerin farklı farklı amaçlar ya da rollere bürünmesi değil tek bir işi olmasını öğütler. "Make the best thing you can" gibi. Demet Akalın'ın işi şarkı söylemekse mesela, bu objeyi(class'ı ya da modülü veya genel anlamda entity'yi), yani Demet Akalın'ı Tokyo Olimpiyatlarında Türkiye'yi kurbağalama 200 metre için temsil etmesini ve yarışmasını istemek abesle iştigal olur. Yani onun işi bir tane olmalı. Onu en iyi yapmalı.
İkinci prensip diyor ki modüllerimiz değiştirilmemeli sürekli, ama genişletilebilmeli. Bunu yapmanın bir nedeni şu: Yazılan class'ın yazarına bağlı kalmamak. Ya da başka bir açıdan eğer bizim bir kodumuz varsa ve bunu 3. parti olarak dışarıdaki kullanıcıya açtıysak, kullanıcının class'ımızda bir değişiklik yapmamasını isteriz. Sadece istediğimiz alanlara erişsin, izin verdiğimiz ölçüde kendince oynasın, bir şeyleri genişletebilsin diye. Burada yine Demet Akalın'ı devreye sokabiliriz. Şimdi biz dedik ki bu kadın, bu obje, bu varlık sadece şarkı söylemeli. Olimpiyatlarda yüzmeye gitmesi gerekenler bu konunun ehli sporcular. Şimdi diyoruz ki Demet Akalın başka şeyler de yapsın. Ama şimdi bunun kodlama ile bağlantısını nasıl kurabiliriz onu düşünelim. Normalde Open-closed prensibinde Demet Akalın class'ından farklı olarak başka class'ları da düşünelim. Mesela yüzücümüzü örnek verebiliriz. İkisinin de farklı method'ları meşgaleleri var. Ben bu ikisini de bir restaurant'a koydum diyelim. İkisi de yemek yiyecek. Ve onların property'lerinde (default olarak) yemek yeme, bir şeyler içme özellikleri de var. Bu insanların yemek yeme hızlarını, biçimlerini, yemek yerken konuşmalarını, garsona tavırlarının hepsi ayrı bir method aslında. Ve bizde bu methodların toplandığı farklı bir class oluşturabiliriz. Yani davranışlarının olduğu bir class olabilir bu. Yani bu class'ımızın ismi de amel defteri olsun. Burda herkesin amel defterinde işlemler yapılıp ayrı ayrı sonuçlar elde ediliyor olsun ve hepsi toplanıp bir yere kaydedilsin. Şimdi her işlem öncelikle birinci prensip gereği farklı class'larda olmalı ki SOLID'e uysun. Bizim bu amel defterinde matematiksel işlemlerimizi yaptığımız yerde sadece veriler gelip çıktıları sayısal olarak ya da bir array içinde tutarak döndürmemiz gerekiyor. Ama Demet Akalın, Snopp Dogg, Ricky Martin, Hz. İsa, Buğra, Ömer Hayyam gibi insanların hesaplamaları için kullanılan hesap yöntemleri farklı. Evet Hepsinin adı hesaplama fakat hepsi farklı şekilde hesaplanıyor. O yüzden biz bu class'ta sadece ilgili class'lardan gelen metodları kullanıp hesaplamamzıı yapıyoruz. Demet Akalın'ı değerlendirildiği ilahi formüller farklı, yüzücününki farklı oluyor. Peki, bir sorun var mı? Şimdi biliyoruz ki doğmamış bebekler direkt cennete gidiyor konusu var buna örnek olarak verilebilecek. Yani onların bir methodu yok diyebiliriz. Direkt geçiş hakkına sahipler işlemsiz. Ama bizim bu hesaplama class'ında doğmamış bebek, şehit veya başka birçok dinlerde olan "iyi insan"ı nasıl hesaplamaya dahil edeceğiz. Methodları yoksa ve hesaplanmaya çalışılırsa fatal error alabiliriz. İşte o yüzden diyoruz ki biz her insanın kullandığı bazı aynı arayüzler vardır. Hepsi yemek yer, hepsi uyur, hepsi doğar ve ölür, hepsi yalan söyler ya da ağlar(En azından bir kere) diye. Biz bunların hepsini bir arayüzde toplayabiliriz. Ama bu arayüzdeki method'ların hepsine uygun olması gerekir. O arayüzdeki bir metodu kullanmayan bir insan, direkt fatal error'la sistemi sonlandırır. Sonuç olarak çok uzatsam da şuraya gelmeliyim: hesapların yapıldığı class'ta her metodun uygulanışını farklı farklı defalarca kez tanımlamakla uğraşıp, defalarca kez değiştirmek ve sisteme kötü sonuçlar doğurabilecek hatalar verdirmek yerine hepsini bir arayüz kullanarak yapmak ve bu işlemi ayırmak çok daha iyidir bizim için.
Liskov üçüncü prensibinde özetle şunu söyler: Eğer bir şey, diğer şey ile aynı şekilde davranıyorsa, sen bunu değiştirebilmelisin. Obje class yapısında daha çok inheritance mantığında buna şöyle bakılır: Parent'ın bir özelliğini bir çocuk alır. Ve bunu değiştirebilir kendince. Mesela Demet Akalın'ın babası çok fena bir alkolik olabilir fakat Demet Akalın sadece her akşam bir bardak viski içiyor olabilir. Genetik ya da öğrenilmiş/davranışsal mirasın hepsini sürdürmek zorunda değildir. Ama her zaman onun izlerini taşımak zorundadır. Demet Akalın bir gün yabancı ülkelere gidip oralarda yaşamak istese ve bundan çok mutlu olacağını düşünse de, kendinden kaçamayacağını bilmelidir. Geçmişinden, öğretilenlerden. Ama ufak değişiklikleri elbette yapabilir.
Dördüncü prensibin özeti ise, client'a istediğini ver. Yani ona kullanmayacağı arayüzü sunma ya da onu zorlama gereksiz şeylerle. Demet Akalın'a geri dönelim. Demet Akalın konserde şakı söylüyorsa eğer psikoloğunda anlattığı problemlerini konserde anlatmamalı. Eğer çok hisli ya da dertli ise bunun üstüne şarkı yazıp client'a yani hayranlarına duygularına aktarabilir ama onlara istemediği şeyleri vermemeli.
Beşinci prensibimizde ise high level ve low level entity'ler arasındaki bağda soyutlamayı kullanmalısın. High level entity(modül, sınıf, obje, ne derseniz), işlemlerini yapmak için low level entity'leri kullanır. Ve low level entity'i biraz soyutlamamız gerekir high level'den. Bu sayede low level'deki bir değişimde high level entity'imizde bir değişim yapmamıza gerek kalmaz. Tabii ki bu yapı için de interface kullanılabilir. Gördüğüm örneklerde en azından o şekilde kullanılmış soyutlamak için. Diyelim ki Demet Akalın'ın sevgilisi var. Ve ona çok bağımlı, düşkün, onsuz yaşayamam diyerek gizli gizli "Join me in death" dinliyor hâlâ. İşte bu çok hatalı. Yani sen Demet Akalın'sın. O senden ayrılırsa çok üzülür kendini değiştirmek zorunda kalırsın onu tekrar elde edebilmek için. Ama prensibimiz diyor ki, "Demet ilişikide değer görmek istiyorsan çok değer vermiceksin."Onu da diğer erkeklerden bir farkının olmadığını düşün. Biri gelir biri gider gibi düşünüp ahlaksız ol(neye göre kime göre). Bu sayede kimle sevgili olsan yıpranmazsın. Hemen alışır kabul edersin.".
Entity olarak Demet Akalın'ı seçmek hiç aklımda yoktu ve büyük ihtimal çok kötü bir fikirdi ama yine de denemek istedim. Normalde obje/class olarak galaksileri alıp, kodumuzu evren olarak düşünmek istemiştim ama konu nerden Demet Akalın'a geldi ben de anlamadım.
Örneklem, dün baktığım siteden öğrendiklerimle konu ile bağlantılı olarak oluşturulmaya çalışıldı daha çok.
53. Gün
Bugün SOLID ve OOP prensiplerini iyice kavramaya çalıştım. SOLID mimarisini kendimce örnekledim. SOLID için hem dün hem de gün içinde anladıklarımı ve örnekler üstünden anlatmaya çalıştığım için, Bu rapor biraz daha aklımda kalan farklı şeylerle alakalı oldu. Bütün bunları en özetinde neden kullanıyoruz? Kodumuzu parçalıyoruz aslında. Her görev için farklı bir obje yapısı oluşturuyoruz. İleriki aşamalarda kodumuzun belirli bir kısmında değişiklik yapmak istediğimizde systemin tamamına zarar vermeyecek ya da etkilemesini engellemek ve çok daha iyi bir şekilde düzeltme işlemini yapabilmek için SOLID yapısını kullanıyoruz. Bu tabii ki SOLID’in tüm maddeleri için geçerli. Clean code, agile gibi kavramlarda bu mimari felsefeyle beraber işlemektedir. SOLID yapısını kullanınca ister istemez çok daha clean bir kod yapısına sahip oluyoruz.Bu kod üstündeki sonrasında yapılacak değiştirilme hâli “maintenance ve extending” olarak düşünülebilir. Veritabanı motorunda bir değişim yaparsak eğer, arayüz kullanarak bu değişimden etkilenecek olan high level bir module kolayca adapte olabilir yeni sistemimize soyutlamayı kullanarak örneğin.
Peki biz SOLID mimarisini anlamaya çalıştık ve pratik yapmadan okuyarak ne kadar anlaşılabiliyorsa anladığımızı düşünüyorum. SOLID’ e bugün çalışırken biraz OOP kavramlarını araştırdım çünkü biz neden OOP üstüne bir tasarım gerçekleştirmeliyiz bunu da anlamam gerekiyordu. Aslında basitti. OOP’nin sağladığı en güzel sonuç onun yapısındaki Encapsulation ilkesi ile ilgili. Kodumuzun bir yerinde hata oluştuğunda normalde OOP kullanmayacak olsaydık nerede hata olduğunu bulmak çok daha zor olurdu fakat belirli bir objede bir sorun varsa diyebiliyoruz ki demek ki onun bulunduğu sınıftan kaynaklanan bir sorun olmalı. Araba objem bozuksa eğer, araba class’ımda bir sorun var diyerek sorunun kaynağını çözümleyebilirim. Kodun tekrar kullanılabilirliği konusunda, Araba class’ımızda birçok farklı aracı ve özelliklerini child class olarak ekleyebiliriz. Base class ta yapılan değişiklik ile hepsinde bir değişim yaratabilir, ya da her araba objesi için ayrı method’lar yaratıp onlara özel yapabiliriz. Üstelik tek bir “sür” fonksiyonu ile tüm araba objeleri için(child class’lardan oluşacak instance’lar olarak yani) bir method belirleyebiliriz. Ya da bunu interface olarak yaratıp her class bu interface’I implement ediyor diyebiliriz. Bize obje/class yapısının vermiş olduğu en iyi yarar, çok daha verimli bir şekilde problemleri çözme yeteneği sağlamasıdır diyebiliriz (top-down language-C gibi-, functional style language-Haskell veya ML gibi- mimarilere göre). Son kez 1 cümlede toplayacak olursak faydalarını: kolay bir şekilde sorunları gidermek için modular yapı kullanması (yapboz gibi her parçanın yeri belli bu modular yapıda), inheritance ile kodun tekrar kullanılabilirliğinin sağlanması, polymorphism ile flexibility’nin sağlanması, ve tabii ki vermiş olduğu vermeli problem çözme yetisi.
54. Gün
Öncelikle bu akşam eve döndüğümde uyuyakalmışım, sonrasında çalışacaktım oysa ki. Gelelim ne yaptığıma dün. SOLID’I okurken güzeldi, çoğunluk olarak anladığımı düşünüyordum ama iş pratiğe gelince istenen şekilde yapamadım. En azından denedim diyorum. Yine bir gizem çözülünce kolay göründü tabii. Aslında inheritance yapısını oluştursam benim kodum da neredeyse olacakmış fakat benim aklıma hiç gelmedi ineritance I o şekilde oluşturmayı düşünmek. Çünkü eğer bir fonksiyonn varsa parent ta ve child bunu değiştirip kullanmıyorsa ne gerek var ki bu akrabalığa diyordum fakat anladım ki hem değiştirip hem de parent’taki haliyle de kullanabiliyormuş.55. Gün
Bugün Depenedency Injection kavramını net olarak öğrendim. Bu bir design pattern, bir teknikmiş. Design pattern’lerde anladığım kadarıyla net bir kural yok. Her durum için farklıbir şekilde oluşturulabiliyorlar. Mesela Dependency Injection'ı kullanmak için, bağımlılığı bulunan class’ımıza, farklı bir class’tan obje alırken contructor ya da seeter method’larında parametre olarak alıyoruz. Bu konuda şu anlık bir sorunum yok gibi.XML ile alakalı işlemlerde hep benzer yerlerde sorunlar yaşıyordum ama hala kendimi sorun çözmede yetersiz hissediyorum. Yani önceleri çok daha fazla sorunla karşılaşırken şu an basit gibi görünen bir şeyi neden bu kadar bol zamanda yapamadım ben de anlamadım. Büyük ihtimal aynı hataları alıp, aynı işlemleri tekrar ediyorum. Yani kendimi tekrar ediyorum. Günün sonuna doğru yanlışlıklarımı biraz tamamladım. Gün sonunda da hatanın tam olarak nereden kaynaklandığını buldum. Ama yarına kaldı artık. asXML() bize bir string döndürüyor evet fakat XML formatında döndürüyor. Oysa ki başlangıç taglarını tekrar bizim yazmaya ihtiyacımız yok. Oysa ki ben de yazıyordu. Yarın sabah asXML() kullanmadan nasıl objeyi string’e dönüştürebilirim (XML ile alakalı fonksiyonlarda başka bir seçenek var mı ona da bakacağım) ona bakacağım.
Bazı konularda sebep-sonuç ilişkisini ve yine bazı konularda çok şeyi merak ettiğim için gelişimime katkı sunduğu için sevinsem de 2 ay olmasına rağmen hâlâ daha kodda aldığım hatayı düzeltebilmek için uzun zamana ihtiyaç duyma ihtiyacımın olması ya da olma ihtimali(basit olduğunu hissettiğim yerlerde) üzüyor. Ama bir yandan da daha da merak ettirip hırslandırıyor. Her şey çok karışık bu düşüncelerimizin dünyasında. Neyse bu konulara girmeyelim. İstediğim gibi olacağıma dair inancımı hiç bozmayaraktan.
56. Gün
Bugün öğrendiğim ve pratikte gördüğüm konular genel olarak OOP ile alakalı konulardı. Trait’in kullanımı, class’ların eğer aynı isimde olurlarsa farklı namespace’ler ile o dosyaların tutulması gerekliliği yoksa birbirlerini etkilemeleri gibi yeni şeyler öğrendim. Sabah dün yaptığımız görevi tamamladım. Öğleden sonraki görevi açıkçası tam anlamamıştım ve anladığım kadarıyla yapmaya çalıştım. Biraz kesin kuralları olmadığı için genel olarak her yerde fonksiyon kullanmıştım. Bugün genel olarak araştırmalarla dolu geçti. SOLID prensiplerinin örneklerini tekrar inceledim farklı kaynaklardan. Bir tekrar niteliğinde gibiydi.57. Gün
Dün raporu unuttuğum için bugün gönderiyorum. Dün sadece clean code ile alakalı güzel bir dokümanı inceledim. Her ayrıntıyı öğrenmeye çalıştım. Okurken ve incelerken neredeyse her şeyin sebebini anlayabiliyordum, gerçekten iyi yazılmış bir kod ve kötü yazılmış bir kodun farkını kavrayabiliyordum. Bu iş(yazılım), dedikleri gibi okuma yazma öğrenmek gibi. Her okuma yazmayı bilen insan iyi bir edebiyatçı olmuyor. Cümleleri iyi kuramıyor ya da imla kurallarına dahi uymayabiliyor. Evet ben de hem php hem de javascript ile okuma yazmayı biraz öğrendiğimi düşünüyorum. Fakat bu işin cümle kurmalarını, uzun yazılar, hikayeler, romanlar yazmayı çok istiyorum. Bunu da yapabileceğime inanıyorum kesinlikle. Sadece bol bol prtaik yapmam gerekecek. Aklıma çok takılan bir sorun olmadı Cumartesi günü. O yüzden o tür bir şey belirtemiyorum. Competitive programming diye bir şeyi keşfettim. Ve o açıdan da harika kaynaklar buldum. Boş zamanlarımda kodlama becerilerimi, düşünce yapımı, makine ile en iyi anlaşabileceğim seviyeye getirmek için o konulara bakacağım. O kısım, işte bize verilen görevlerle çok alakalı olmadığı için mesai saatleri dışında bakacağım.58. Gün
Bugün, verilen görevle geçti tamamen. Tasarım neredeyse aynısı oldu. W3Schools JavaScript kısmında yardımcı oldu. Henüz bitmesine var çünkü başta çok kolay gibi görünse de detayları biraz uğraştırdı. Genel olarak istenen yapı oluşuyor fakat günün sonlarına doğru bazı yerlerde javascript kodunun bazı kısımlarını tam oluşturamadığım için(ya da gözümden kaçan kısımlar olduğu için) istenilmeyecek sonuçlar oldu. Defalarca aynı hatayı yapıp durmaktansa (Ve aklıma farklı bir çözüm yolu henüz gelmediği için) yarın sabah tekrar bakmak daha faydalı olacaktır diye düşündüm. Ve dinlenmek istedim. Bugünlük bu kadardı.