Blog
Yazılımın ilk 250 günü - IntroBu blog serisinde yazılım ile ilgili bir işe girdikten sonra çırak olarak ustama yazmış olduğum "rapor-günlük"ler bulunuyor. İçerik olarak ciddi ve resmi bir raporda olması gerekenler ile, duygusal birçok his, yapılan hatalar ve başarılar sunuldu. Nazım Hikmet'ten bir şiir de bulunmaktaydı bir raporda, OOP'nin varoluş amacı ve nesne yönelimli bir dilin çıkış amacı ile hangi SOLID prensibinin örtüştüğüne dair Alan Key'in belirttiği düşüncelere kadar. Bug fix'leme ve bulma raporlarından, kendimi salak gibi hissettiğim bir günde yazmış olduğum rapordaki "yine de bu işi yapabileceğime ve başarabileceğime dair inancıma" kadar. Kullandığm dillerin yapılarının en detaylı kısımları üzerine düşüncelerden, UML diyagramlarına kadar. Blog içeriği tamamen ustamın günlük raporlar sunmamı istemesi ile kendiliğinden oluşmaya başlamıştı. Her gün yaşadıklarımı detaylı olarak anlattığım için de büyük bir içerik oluşmuştu. Ve bu içeriği de paylaşmak istedim. Hem kendimi ifade etmek için, hem başka bir "yeni başlayan"a fikir verebilmesi için, hem de bu yaşananların bir yerde kalması için.
5 dk okuma
Yazılımın ilk 250 günü - Part 25..."Bugün bir kez daha anlıyorum ki, aslında hocalarım “mühendis kimdir ve ne iş yapar” sorularına en iyi cevabı bulmamı sağlamışlar. Mühendis problem çözer. Problem çözen mühendis doğu ve batının bakış açısının sentezidir, rapor yazar, verir ve okur. Mühendisin yazılı rapor vereni makbuldur. Rapor yazarken problem tanımlar, yaratıcı çözümler bulur, görmediklerini görme imkanı olur, yazdıklarını yorumlamak ve sonuç çıkarmak zorundadır ve yazı kalır sözse uçar gider. İyi rapor yazan mühendis iyi rapor okur, iyi sorgular. Bu gerçeği gören mühendis bireysel kurumsallaşmasını tamamlamıştır ve isterse çok iyi bir yönetici adayıdır. Bu gerçeğin farkında olan üst düzey yöneticiler ellerindeki hazinenin değerini bilirler. Göremeyenler ise maddi ve manevi kayıplarını daha sonra anlarlar."
5 dk okuma
Yazılımın ilk 250 günü - Part 24...Bugünün en güzel teknik dışı paylaşımı: Yaşamaya dair (Nazım Hikmet): ...Yani, öylesine ciddiye alacaksın ki yaşamayı, yetmişinde bile, mesela, zeytin dikeceksin, hem de öyle çocuklara falan kalır diye değil, ölmekten korktuğun halde ölüme inanmadığın için, yaşamak yanı ağır bastığından...
3 dk okuma
Yazılımın ilk 250 günü - Part 23...Son betimlemeyi de yapmak isterim ki içimde kalmasın. Framework bir inanç/kültür gibi. Aynı framework’ü kullanan geliştiriciler ortak bir paydada bulunup birbirleri ile anlaşıyorlar ve hoşgörü içinde yaşayıp gelecek kuşaklarda aynı inancı ve kültürü devam ettirerek mutlu mesut yaşıyorlar. Bu inanç/kültür’ün bulunduğu dil, geliştiricilerin konuşma dilleri. Kimi geliştiriciler inanç/dil milliyetçiliği yapabiliyor. Kimileri “make peace don’t war” diyerek multicultural olarak her dil ve inançtan polen alıp bal yapıyor. Laravel, Yahudilik gibi. Eski bir inanç ve o da başka inançlardan türemiş. Ve başka inançlara da kapı açmış. Çok güçlü bir yapısı var ki kendisi ve türetildiği inançlar çok sağlam takipçilere ulaşmış. Kullandığı dil artık pek yaygın değil. Ve başka diller oldukça revaçta. Bu da o dilin ölmesine sebep olmasa da popülerliğini azaltıp community’sini gitgide azaltıyor.
6 dk okuma
Yazılımın ilk 250 günü - Part 22...Bugün uygulamayı direkt electron’a geçirdim aslında. Eskiden çalışan her yer normal olarak hâlâ çalışıyordu. Inter Process Communication kısmı benim anladığım kadarı ile şu (tekrar yazıyorum çünkü ileriki zamanlarda bu notlara bakabilirim): Chrome veya herhangi bir tarayıcı çalışırken kullanıcı birden fazla sekme açabilir. En ilkel tarayıcılar tek bir sekme olarak düşünülmüş anladığım kadarı ile. Birden fazla sekme olma durumunda her sekmenin javascript işlemlerini, bellek işlemlerini ayırma gereği duyulmuş. Çünkü bir sekmede eğer bir site patlarsa diğer tüm sekmeler etkileniyormuş ve bu yüzden tarayıcı çöküyormuş (Çok uzak bir zamanda olduğu için zor hatırlıyorum ama evet böyle bir şey vardı). Her sekmeye ayrı bir process denilmiş ve tüm bu küçük process’ler main bir process ile yönetilmiş. Bu yöntem diğer tüm tarayıcılarda da sonrasında benimsenmiş. Electron’da buradaki mantığı uygulayarak main process ve rendering process olarak ikiye ayırmış. İki ayrı context olarak da düşünülebilir gibi geldi.
6 dk okuma
Yazılımın ilk 250 günü - Part 21...Bugün authentication kısmı olmasa da genel chat mantığının bulunduğu kısım nesne yönelimli hâle getirildi. Yarın amaç authentication ile ilgili kodları da o hâle getirip sonrasında klasörlendirme konusuna başlamak ve bitirmek planlanıyor. Bugün epey düzeltme yapıldı diye düşünüyorum. Yarın authentication kısmı da tamamlandığında çok sorun kalmayacak OOP üzerine diye düşünüyorum. Sorun çıkarsa da zorlanmadan düzeltilir diye düşünüyorum. SSO sunucusunun backend kodlarını da ayrıca nesne yönelimli hale getirmem gerekli elbette. Onu da sonrasında tamamlayacağım. Tüm bunlar bittiğinde ise knowledge base ve bug tracking konularını içeren bir uygulamanın temel özelliklerini çıkarılacak. Bu özelliklere uygun olarak özet niteliğinde bir yazılım gereksinim dokümanı hazırlanabilir, ya da sisteme implemente etmeden önce genel gereksinimler ve bu gereksinimlere uygun kullanım senaryoları ile nesnelerin template’i çıkartılabilir. Elbette bu konularla (bug tracking ve kb) ilgili bir rapor da yazılacak.
5 dk okuma
Yazılımın ilk 250 günü - Part 20199. Gün. Bugün WebRTC’ye giriş olarak Google’ın sunduğu dökümanları okumaya başlamıştım. Okuduğum doküman direkt kodlama kısmı ve kodların yorumları ile başladığı için olayın özünü bildiren ve kullandığı teknolojilerin yapısını ve mantığını açıklayan kapsamlı herhangi bir şey okumamıştım. Sonrasında vikipediden ve farklı birkaç kaynaktan daha konuyu araştırdım. Konu hakkında biraz daha fikir edinip (tatilde de fırsat olursa konuyu biraz daha araştırarak) elimi kirletmem gerekli. Perşembe günü sisteme bu durumları da entegre etmeye başlayacağım (deneyeceğim). 200. Gün. Bugün sizin gösterdiğiniz kısımlar üzerinde kodda değişiklikler yaparken birtakım anormallikler gerçekleştiği için yarın dikkatlice düzeltmeler yapacağım. Ondan öncesinde tamamen WebRTC ile canlı (stream peer-to-peer comm.) veri alışverişini öğrenmeye, uygulamaya çalıştım. Önce bulduğum örnekleri birebir kopyalayarak ve kodları okuyarak anlamaya çalıştım fakat biraz zorlandım. Uygulamamı nesne yönelimli hale getirdikten sonra tekrar bu kısma döneceğim.
4 dk okuma
Yazılımın ilk 250 günü - Part 19181. Gün. Bugün dosya yükleme, kullanıcıya dosyayı iletme, backend tarafında uygun olduğunu farzettiğim bir veri yapısını kullanma kısımları tahmin ettiğimden daha kısa sürede bitti. Kullanıcının, farklı kullanıcıları ve kendi geçmiş sohbet içeriklerini aramasını sağlamalıyım. Bu sayede henüz sohbet başlatmadığı kişileri de ekleyebilir. Konuya direkt olarak girecektim fakat sonrasında anlamsız biçimde algoritmalar kitabında arama ile ilgili algoritmalara bakmak istedim. Bakınca oradaki farklı tipteki sorunlar ve çözümleri sadece okudum. Ve tabii ki üzerlerine düşündüm. Örneğin “Travelling salesman problem” vardı graf algoritmalarına bakarken karşılaştığım. Pazar günü onun üzerine düşünmek, uygulamalarına bakmak istiyorum. Anladığım kadarı ile genel bir çözüm metodu yoktu ve ilgimi çekti. Yarın normal şekilde kaldığım yerden devam edeceğim.
5 dk okuma
Yazılımın ilk 250 günü - Part 18171. Gün. Bugün front end konusunda en çok kullanmam gereken işlevleri (basit bir mesajlaşma uygulaması üzerine) yazdım. Hala en basit seviyede ama socket.io kullanarak anlık iki yönlü iletişimi sağlamam için gerekli front end kısmını içeriyor. Yarın ve bu haftanın geri kalanında sunucu ve client arasındaki iletişimi kurmaya çalışacağım. Amacım cumartesi websocket ile ilgili kısmı tamamlayabilmek. Bu akşam çalışıp eksik kalan kısımları tamamlamayı düşünüyordum fakat fırsat olmadı (Aile ve arkadaşlara vakit ayrılan vakit neticesinde). Onun dışında görevi yapabileceğimi düşünüyorum. Bu hafta isterlerimi tamamlayabilirsem çok sevineceğim kendi adıma. Yarın direkt socket.io’daki basit chat uygulaması örneğini kendi yazdığım sisteme uyarlayıp en temelden geliştirmeyi deneyeceğim. Sistemli bir şekilde ilerlediğimi düşünüyorum (Kendi çapımda bir sistemli ilerleyiş tabii ki de). Temel kısımları tamamlayıp eksiklerle karşılaştıkça da sorunları çözeceğimi düşünüyorum.
12 dk okuma
Yazılımın ilk 250 günü - Part 17161. Gün. Single sign on konusunda izlemem gereken adımları daha çok öğrendim. Detaylı şekilde her kısmını düşünmüş olmasam da basitçe bir otorizasyon ve doğrulamanın nasıl yapılması gerektiği üzerine bir şemayı takip edip kodlamaya çalışıyorum. Bugün yaşadığım problem günün sonunda da çözemedim açıkçası. Bir sunucu diğer sunucuya post metodu ile istek gönderip cevabı da almak istediğinde (axios kullanarak), cevabını normal ve sıradan değişkenleri alırken problem çıkmadan alabiliyor fakat session bilgisini alamıyor. Oysa ki session bilgisi o sunucudaki kalan diğer her yerden ulaşılabiliyor. Hatta get metodu ile o sunucudan veri alırken de session verisine basitçe erişiliyor. Yarın sabah tekrar odaklanarak problemin ana kaynağını bulup çözmeye çalışacağım ya da alternatif olarak get metodu ile çözümleyeceğim. Ek olarak, geçişleri express’in sağladığı redirect metodundan client side’da normal şekilde farklı bir url’ye aktarımı sağladım. Her kullandığım yerde. Ona rağmen devam etmekte.
12 dk okuma
Yazılımın ilk 250 günü - Part 16151. Gün. Bugün programlama hakkındaki en büyük sevincimi kendi içimde yaşadım: Yazılan kodun kendinin farkında olabildiğini gördüm, gösterdiniz. Sanki yapılabilecek ve öğrenilebilecek o kadar çok şey varmış gibi hissediyorum ki, düşünmesi bile oldukça fazla haz veriyor. Onun dışında bugün yine Laravel dokümantasyonuna baktım genel olarak. Cross site request forguery’nin nasıl engellenebileceğini ve mvc’deki yerini gördüm. View kısmına bakarken Blade template engine ile karşılaşınca ofEngine’I hatırladım ve daha çok dikkatimi verdim. Laravel’deki Blade ile ilgili kod biraz fazla karışık geldiği için çok dikkatli inceleyemedim ama en temel seviyede template engine’in ne iş yaptığını ve nasıl çalıştığını anladığımı düşünüyorum.
9 dk okuma
Yazılımın ilk 250 günü - Part 15141. Gün. Öncelikle ustama karşı bugün bir yanlışım olduysa özür dilerim. Çok bilmiş gibi görünüyorsam bazı konularda, o benim gafletimdir. Çok az şey bildiğimin farkındayım. Sadece bazen kesin bir dille konuşma yanılgısına kapılabiliyorum. Bugün başlangıçta bir görev olmadığı için kendimce react-native ile ilgili iki konuya baktım: internet bağlantısı kontrolü nasıl yapılır ve klavye nasıl saklanır farklı bir yere tıklayınca. Onların yollarını okudum. Sonrasında aklıma bir şey gelmeyince dün gördüğüm bir makaleyi (yazılım dizaynı ve programlama üzerineydi genel olarak) okudum. Ama bitiremedim. Bitirince burada özet geçeceğim diye umuyorum. Sonrasında mobil uygulamanın kaynak kodlarını siz verdiniz. Sizlerin yazdığı konu, uygulamanın arka tarafta nasıl çalıştığını, bağlantıları ve ilişkileri kavramaya çalıştım. Yüzeysel olarak bir şeyler anladığımı düşünüyorum. Ternary operator’ları, clean code’u görünce etkilendiğimi söylemeliyim.
7 dk okuma
Yazılımın ilk 250 günü - Part 14...Bu sabah sizin yaptıklarınızı dikkatle izledim çünkü babamın aşçılıktan öğrenip bana sıkça söylediği “elin değil gözün hırsız olsun” düsturu ile davrandım. Sonrasında drawer navigasyonunu yapmaya çalıştığımda ise yine version hatasından dolayı bir kütüphane ile ilgili hata ile karşılaştım. Sorunu Google’ladığımda farklı çözüm yöntemleri buldum. Dosyalardaki bazı kodlarda değişiklikler yaparak ve ilgili kütüphaneyi kaldırıp farklı bir sürümünü ekleyerek çözüme ulaşabildim. Başta daha da bozarım düşüncesi ile elim titrese de sonrasında “korkanın çocuğu olmaz” düsturu ile elimi korkak alıştırmadan ve dikkatle çözüme ulaştım. Sonrasında sayfaları dosya ve klasör yapısına dönüştürme problem vardı. Kendi oluşturduğum proje ölçeğinde bir yapı kurmaya çalıştım. Web’te bu konu üzerinde araştırma yaptığımda arketipe göre değil özelliğe (group by feature, or group by archetype) göre sınıflandırma yaparak bir dosya-klasör düzeni kurmamız genelde öğütleniyordu. Mobil tarafında da aynı ilkeyi düşünsem de örneklerde en sık screen-component yapısını gördüğümden dolayı on duruma yakınsayan bir çözüm oldu. Son verilen görevde yarın kaldığım yerden devam edeceğim.
15 dk okuma
Yazılımın ilk 250 günü - Part 13121. Gün. Sabah takvime bakınca çok şaşırdım. Çünkü bugünün Çarşamba olduğunu sanıyordum. Bu hafta nasıl geçti hiç anlamadım. Yapmak istediklerimi zamanında yapamadım. Bugün kendi koduma bakınca solid’deki OCP (open-closed principle)’nin cinayetinden sorumluymuşum gibi hissettim. Çünkü hem open for extension hem open for modification oldu özellikle bugün yazdığım koda bakılırsa. Daha önce yaptığım hataların farkına varıp sonra yapmamaya çalışıyorum. Yeniliyorum. Sonra tekrar deniyorum. Bugün genel olarak aynı yerlerde çokça takılı kaldım. Bu da kendi hatalarımdan kaynaklanıyordu. Akşam hatalı yerleri düzelttim. Yarın daha hızlı olacağım.
8 dk okuma
Yazılımın ilk 250 günü - Part 12...Yukarıdaki örnekler aslında tamamen Java dilinde nesne ve sınıf arasındaki ilişki üzerine kuruludur. Şimdi ise PHP’de durumun nasıl olduğuna bakalım: Esas kaynak olarak PHP Manual’ına bakınca da nesne ve sınıfın yine Java’ya benzer şekilde bir ayrıma sahip olduğunu görülmektedir. Peki bu ayrım her dilde var mı? İşte burası karışık çünkü her dil farklı bir konsepte sahip anladığım kadarı ile. Objective-C’de her sınıfın bir nesne olduğunu okudum. Her sınıf bir nesne imiş. Ama bu sınıflarda bir nesne olduğu için farklı bir class’tan türemek zorunda ve bu class’a da metaclass adı verilmiş. Bir nesnenin sıradan instance ifadesi oluşu gibi, metaclass’ta bir sınıf nesnesinin ifadesiymiş (Hiç bilmediğim, ama bilenleri referans alarak söylediğim için bol miktarda -miş’li zamana yer verdim).Smalltalk’ta ise sınıfların, sayıların, stringlerin, hatta programın kendisi dahi nesneymiş. Kafam biraz karıştı açıkçası ama raylar yerine oturacak diye tahmin ediyorum.
13 dk okuma
Yazılımın ilk 250 günü - Part 11101. Gün. Composition ve dependency kavramlarının ayrımını örneklendirmek istedim ve bir tane ürettim. İnsan, dağ, Dünya. İnsan ve dağı Dünya içerir. Burada bir sahiplik ve part-whole ilişkisi bulunur. Dünya varolmak için dağa ya da insana bağımlı değildir. Yani burada bir dependency dünya için yoktur. Burada en genel manada association bulunur. Association için ayırt edici bir örnek olarak Ay'ı verebiliriz. Dünya bulundurduğu okyanus nesnesinde gelgitleri sağlamak için Ay uydusunu kullanabilir. Burada sahiplikten öte kullanmak vurgulanır. Bu da bir accosication'dır. İnsan dünyanın bir parçasıdır fakat insan dünya nesnesi dışında da var olabilir (Uygun şartlar oluştuğunda farklı gezegenlerde, uydularda yaşamını sürdürebilir). Dağ ise dünya dışına çıkamaz. Dünya her ikisine sahip olsa da böyle bir fark bulunmaktadır Dünya-insan ve Dünya-dağ arasında. Dünya-insan ilişkisi üst kümesi asscociation olan bir aggregation ilişkisidir. Dünya-dağ ilişkisi ise üst kümesi association olan bir composition ilişkisidir. Bu düşünce sınırlarını genişletirsek örnek verimsiz olabileceği için bu dar çerçeveden bakarak konsepti kavrayabiliriz.
13 dk okuma
Yazılımın ilk 250 günü - Part 10...Daha sonra Actor Model’e baktım. Alan Key’in Quora hesabı varmış ve oradan birçok soruya yanıt vermiş. Bunu görünce çok fazla etkilendim çünkü gözümde masallardaki kahramanlardan biri olmuştu. Actor Model’in OOP’den aslında çok da bir farkı olmadığından bahsetmiş. Aslında o ilk oluşturulan pure object oriented mantığı, sonrasında biraz daha class oriented’e döndüğü için; Actor Model’in pure OOP’ye güncel olarak kullanılan OOP’den daha çok benzediğini söylemiş. Sebebi ise mesajlaşmaya odaklanması anladığım kadarıyla. Eşzamanlılık konusundaki artısını anladım fakat pratikte görmediğim için sadece mantık olarak kavradım. Onun dışında Actor Model PHP’de de kullanılabiliyormuş sanırım. Peki neden şimdi Actor Model şu an kullanılan OOP yerine kullanılmıyor diye düşündüm. Bulduğum cevaplar vardı. Fakat tam anlamadım. Tek bağdaştırdığım nokta, şu an neden SmallTalk un kullanılmadığı ile ilgili bir benzerlik olabilir. Tabii ki kullanılıyor bu arada, ayrık (mikroservis gibi. Sadece kavram olarak biliyorum. Detaylarını dair bir fikrim yok) sistemler için özellikle. Fakat çok yaygın olmadığını anladım.
12 dk okuma
Yazılımın ilk 250 günü - Part 981. Gün. İlk defa kendi açımdan responsive’liğe uyduğunu düşündüğüm bir tasarıma yaklaştım. Konu CSS olunca biraz sihir gibi hissetmiyor değilim, her ne kadar kurallara uyulduğu sürece istenilen çıktıları vereceğini bilsem de. Bugün toplantıda konuştuğumuz konular tekrar bazı konuları düşünmeme ve farklı açılardan bazı problemleri düşünmeme katkı sağladı. Ve gerçekten zamanın o esnada nasıl geçtiğini ve ne kadar zaman geçtiğini farketmemiştim. Gün sonuna doğru farklı farklı CSS örneklerine baktım tekrar. Mesela SCSS’in CSS’e çeviren online formatter’larda varmış bunu bilmiyordum. Codepen’deki birçok güzel tasarımda SCSS kullanılıyordu ama onları direkt es geçiyordum kullanmayıp ve dikkatle incelemeyip. Artık onun da bir kısayolunu öğrenmiş oldum eğer işime yarayacaksa. Bugün genel olarak tasarımı güzelleştirmeye çalışmak ve arta kalan zamanlarda benzer konuları, örnekleri araştırmakla geçti.
12 dk okuma
Yazılımın ilk 250 günü - Part 8...Bir cümlemiz var. Biz onu nasıl okurken anlamlandırıyorsak, makine için de aynısını yapmamız gerekiyor. Gelen veriyi anlamlı hale getirmek amacımızdı. Son örnekte ("mer(h)aba" ("a" asd) benim "sss" asdasd`) tırnak işareti içindeki parantezin de tırnak işaretinin bir parçası olduğunu ve ayrı bir anlamı olmadığını nasıl ifade edebilirdim? Ve tabii ki aynı şey diğer kısımlardaki benzer durumlar için de geçerliydi. O zaman şu yapılabilir: Verideki her bir eleman tek tek gezilir. Eğer bir iç içelik söz konusu ise (anlamı oluşturmak için kullanılan anahtar kelimelerde), iç kısımda bulunan anahtar elementin pozisyonunu(index’ini) eğer bir yere kaydedersem ve onu sonrasında anlamlı yapıyı oluşturmak için kullanmazsam sorun çözülür. Bu iç içelik durumunda görmem gereken sadece içteki elemanı anahtar element olarak görmemek olacaktır o örnek için. Fakat iç içe yapılarda alt düğüm(sub-node) oluşturacaksam, elbette onu da yine hesaba katmam gerekecektir. Kısacası, karşımızda bulunan soruna göre farklı sonuçlar üretebiliriz. Makinenin dilini kullanabilmek için en temel mantıksal çıkarımları yapmak gerekiyor sanırım. Ve bu şekilde bir yapı oluşturmak ya da oluşturmaya çalışmak, felsefe ve matematiğin içine itiyor insanı. 4 ay önce bana bunları dese inanmazdım herhalde. Ancak yapay zeka gibi içinde “fazla zekice görünen kelimeler” bulunan konularda sanırdım. Oysa ki bir string varlığı anlamlı hale getirmek bile gayet “zekice” bir konuymuş.
13 dk okuma
Yazılımın ilk 250 günü - Part 761. Gün. Bugün sizin bize yorumlamamız için gönderdiğiniz javascript kodlarını hayranlıkla okudum. O kadar iyi düşünülmüş ki ben 5 gün düşünsem yine de yapamazdım gibi geldi. 2 ayda okur yazarlık edinildi fakat iyi bir yazar,edebiyatçı,şair olmak için çok uzun bir yol var bugün yine anladım. İngilizce için söylenen “anlıyorum ama konuşamıyorum” ifadesini çok iyi hissettim bugün. Evet yazılan kodun amacını, kullanılan terimlerin anlamını biliyorum ya da kısa bir araştırmayla hemen bulabiliyorum ama iş yapmaya gelince kıvrak ve zeki bir yaklaşımı hâlâ sergileyemiyorum. Biraz da tecrübe ile gelişir diye umuyorum. Çok inanıyorum olacağına, çünkü çok seviyorum. Çok fazla umut, inanç,sevgi gibi pozitif içerikli kelimeler kullandım sanırım. Sebebi ise mesai bitiminde DOM ve event handlers konusuna tekrar bakarken dinlediğim Daft Punk şarkısı sanırım. “Work it harder, make it better Do it faster, makes us stronger More than ever, hour after hour Work is never over”
31 dk okuma
Yazılımın ilk 250 günü - Part 651. 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.
18 dk okuma
Yazılımın ilk 250 günü - Part 541. Gün. Bugün daha önce çalıştığımız ve Javascript’te kodladığımız bir programın PHP haline dönüşümünü inceledik, yaptık. Açıkçası PHP’ye dönüştürmek zor değildi. Aslında hiçbir şey zor değil(en azından gördüklerimiz kadarıyla). Sadece hâlâ yeni olduğumuz için ve ilk defa gördüğümüz terimlerden dolayı zorlandığımızı düşünüyorum. Bugünün en güzel noktası daha önce yaptığımız bir çalışmaya katkı yapmamızdı. Sil baştan bir yapı kurmamız beklenseydi daha zor olurdu evet. Bundan sonra zorlaşacağını düşünüyorum tabii ki, çünkü bu sadece alıştırma gibiydi. Terimlere, PHP’de yazmaya aşinalık olsun diye gibiydi sanki. Ne, ne işe yarıyormuş çalışması gibi. Server tarafı olduktan sonra (ne kadar optimize şaibeli olsa da), HTML-CSS-Javascript ile birleştirmeye çalıştım. Javascript kısmından önce form işlemlerinin nasıl yapıldığı konusunda biraz tıkandım. Sonrasında sizin de yardımınızla o problemi çözdüm. Server tarafında işlem yapınca hiç bir problemle karşılaşmasam da, client’tan veri geldiğinde işlerken bazı sorunlar oluyor. Onu kendime “future development” olarak koydum (future derken, yarın olursa da şaşırmam).
12 dk okuma
Yazılımın ilk 250 günü - Part 431. Gün. Bugün öğrendiğim en iyi şey: İngilizce kaynaklar bolluktan geçilmezken, asla Türkçe kaynaklara bakıp, yazarın İngilizce kaynaklardan okuduğu ve dar bir pencereden sunma ihtimalinin olduğu metinlere önce bakmamak. Öncelikle iyice bakmaya fırsat bulamadığım ama yarın sabah (7saat sonra) bakacağım ilk site ve REST API ve API örnekleri olan site: "What is rest?". Günün konusu REST API idi. Başlangıçta birkaç kaynak buldum ama onlara takılı kaldığım için ve işim mantığından çok teknik tarafındaki terimleri açıklamakla zamaınımı aldıkları için araştırdığım şeyin varolma sebebini anlamamıştım. Bunu maalesef yine stackoverflow’dan araştırıp güzel kaynaklara erişerek anlayabildiğimi düşünüyorum. Günün öğrenilenleri: REST, web’in mimarisel prensibinin temelidir.
16 dk okuma
Yazılımın ilk 250 günü - Part 321. Gün. 21 gün nasıl da geçmiş gerçekten anlamadım. Çok çalışmak istiyorum, çok öğrenmek istiyorum çünkü işimi çok iyi yapmak istiyorum. 21 gün bu kadar hızlı geçtiyse, her güne daha çok şey sığdırmalıyım diye düşünüyorum. Hayat kısa, göreceli de olsa. Evet bu girizgâhtan sonra bugüne dönebiliriz. Sonraki paragraf isle alakası olmamasına ragmen yine de yazdım. Direkt geçebilirsiniz. Bugün event, event listener gibi konuların ne olduğuna, bir websitesi için ne anlam ifade ettiğine ve nerde kullanıldığına bol bol baktım. Kâh dökümanlar içinde, kâh problemler ve çözümleri içinde kayboldum. Gün sonundaki sizin anlattıklarınız da yararlı oldu.
17 dk okuma
Yazılımın ilk 250 günü - Part 211. Gün. Bugünün de verimli geçtiğini düşünüyorum. Objeler ve diziler üstüne birçok örnek ile biraz daha pekiştiğini düşünüyorum konuların. 11 gün geçmiş ve birçok konuda fikirlerim oluşmaya başladı. Bugün bir tane site buldum görevlerden arta kalan zamanda: latentflip. Bu sitede birkaç kendi yazdığım kodu ve bulduğum setTimeout içeren ve diğer benzeri kod yapılarını içeren kodları, çalıştırıp çalışma şekillerine baktım. Call stack, callback queue, ve web api’ler üstüne Biraz daha fazla fikrim oluştu asenkron yapının çalışma şekli hakkında. Özellikle async…await ile alakalı örneklere baktım ve array-object konularından sonra onlar üstüne de çok çalışmak istedim fakat fırsat pek olmadı. Bugün verilen son odevi yarın tamamlamak için çalışacağım çünkü cumartesi akşamı kendime verdiğim tek boşluk.
15 dk okuma
Yazılımın ilk 250 günü - Part 11. Gün. Bugün çok çok şey öğrendiğimi, en azından çalıştığımı düşünüyorum. Çalıştığım konuları, kısaca hafızamda kalan şekilleriyle sıralayabilirim: Binary sistem, bit ve byte konuları gibi, hakkında daha önce araştırdığım fakat çok da detayına girmediğim şeylere zaman ayırdım. Big endian,little endian kavramlarını öğrendim. Senkronize programlama ile farkını öğrendim. Asenkronize, “I will call you back” diye aklımda kalacak gibi görünüyor. Kısaca şu: kodlarımız içinde uzun sürebilecek bir işlem varken ya da engelleyebilecek bir durum varken, bekleyen diğer işleri yapmak ve o işleri bitirdikten sonra yapılmamış işleme geri dönmek asenkronize programlama diye geçiyor. Yani işlem sırasını düz bir çizgide yapmıyor ve o çizgi üstünde bir işlem hata verirse onu es geçip yoluna devam ediyor. Sonrasında tekrar oraya geri dönüyor. Senkronizeye göre daha hızlı çünkü olduğu konumda takılı kalmıyor. Thread sayılarının da bir önemi var tabii ki, bir thread yerine iki ya da üç thread le işlem çok daha hızlı sonlanabiliyor.
16 dk okuma