Yeni Kayıt
Konudaki Resimler
önceki
|
Hızlı 
Bildirim
c++ için kitap tavsiyesi (3. sayfa)
Sıcak Fırsatlarda Tıklananlar
Editörün Seçtiği Fırsatlar
Orret Home Dijital Mutfak Terazisi, Paslanmaz Çelik Yüzeyli Hassas Tartı, Dara İşlevi, LCD Ekran,Piller Dahil 5 Birim Dönüştürme, Otomatik Kapanma Özellikli, 5 kg Kapasite : Amazon.com.tr: Mutfak
https://www.amazon.com.tr/Orret-Home-Paslanmaz-D%C3%B6n%C3%BC%C5%9Ft%C3%BCrme-%C3%96zellikli/dp/B0D62XF3SC/ref=zg_m_mg_g_56453957031_m_sccl_2/262-9977704-9917659?psc=1
18 sa. önce paylaşıldı
Bu Konudaki Kullanıcılar:
2 Misafir - 2 Masaüstü
Giriş
Mesaj
-
-
quote:
:) bunu ispatlamaniz gerekir. C ile uygulama geliştirenlerin aylık maliyeti 5000 in ustunde ve haftada ortalama 2 fonksyion yazarken görsel dillerde yazan (fark etmez karalayan da diyebilirim) aylık 1500 e yazıyor ve hafta 10 fonksiyon geliştirebiliyor.
Eğer o C ile uygulama geliştiren durumu bu şekilde ise, burada bir sorun vardır: Yanlış tercih yapmış olmak. S57 kodu yazan yanımdaki arkadaş, C ile dediğiniz duruma düşmemek için oturup kodunun içine bir prolog implementasyonu yapmıştı mesela.
Bu noktada asıl sorun şu: O ortalama 2 fonksiyon ile diğer 10 fonksiyonu aynı kefeye nasıl koyabiliriz? Bu pek ölçüt değil. Ve bir diğer hususta şu. Aylık 1500'e yazan varken, aylık 5000'e yazanlarda var olabiliyorsa, demekki o parayı verip o adamı kullanmadan o amaca ulaşamıyorsunuz. Bu açıkca C ve C programcısının daha iyi olduğunu göstermez mi?
quote:
dikkatinizi cekerim eski kodlara destegi (application lifecycle) wrapper yazarak veremezsiniz. bu bir anlamda hayat dongusunu yamaya baglamak olur. kaldi her kod parcaciginin reusable olabilecegini kabul etmek te ayri bir varsayim.
Bunu şöyle düşünün. O kodları yeni bir dile taşımak, demekki daha masraflı. Yeni dilin getireceği ve verebileceği bir şey yok. Eğer öyle olmasa, başta bu yöntem gibi bir şeyler ile bu kolayca aşılabilirdi. Yada eğer o "görsel" programlama bir dokunuşta uygulama yapıyor olsaydı, neden bu uygulamayı alıp taşımasınlar ki?
quote:
dogru ama bununla nereye varmaya calisiyorsunuz? bir dilin derin ve guclu olmasini o dilin kullanildiginde iyi ticari is yapacagi anlamina getirmektesiniz?
Ne alaka? Bir şeyi ne ile yazdığınız değil, nasıl yazdığınızdır önemli olan. Burada geliştirme ve işletme maliyeti elbette en önemli unsur olacaktır. Projenin "karmaşıklığı" arttıkça, hazır nesneler arası uyumsuzluklar artmaya başlar. Eldeki mevcut komponentlerin pek çoğunda basitçe yeni nesne türetmeyle aşılması zor olan püsüratlar ortaya çıkmaya başlar. İşte bu kırılma noktasını iyibir programcı (elbette onun yöneticiside) önceden görebilmelidir. İşte bu noktada, C gibi bir dilin gücü kendini hissettirir.
Fakat bu "karmaşık" terimi, genelde pek kolay anlaşılmaz. Nedir karmaşık olan? Bilinen multitier vs. çözümlerinin sınırları ne zaman birbirine girmeye başlar? Bulanık sahalar, kaynak erişimi problemleri vs. ne zaman sorun olur? İşte bu noktaları görebilmek, gerçekten ciddi bir öngörü gerektirir. Pek çok zaman, bu öngörü doğru yapılamaz ve o batağa girmemek için uzun, zahmetli yol seçilir, C ile vs. başlanır. Bu gibi örnekler pek çoktur.
Gerçi, bugünün yazılım siparişlerine baktığımızda son derece standart kalıplar görüyoruz. Programlama pratiği açısından yüzeysel uygulamalar. Velakin, bunun şöyle bir soruna yolaçtığını görüyoruz: İmplementasyondaki temel problemlerin çözümünde, gerekleri doğru tespit edemeyen, bu gereklere asıl çözümleri getiremeyen uygulamalar ortalığa yayılıp gidiyor. İşte SSK'nın X milyon dolarlık rezaleti. Ben ne zaman eczaneye gitsem, sistemleri çökük oluyor SGK'nın. Elbette bununla kalmıyor, bakıyoruz, kullanıcısını bir amuda kaldırmadığı kalan uygulamalar.
İşte asıl mesele burada. C sizi bu konularda daha disipliner olmaya zorlar. C, atladığınız bir şeyi çok kötü başınıza geçirir. O yüzden ufak hataları vs. gözardı etmemek gerektiğini öğrenirsiniz. Bu disipline sahip olan, uygulamayı hangi dille gerçeklerse gerçeklesin, aynı prensipleri olabildiğince kollayacaktır. İşte bu topikte benim üzerinde durmak istediğim konu bu.
quote:
maalesef 12 yillik bir proje yoneticisi olarak, dil tercihinde developer maliyetine bakiyorum (butcelendirmede benim bilmedigim ve yekune en cok etki eden baska bir olcek varsa ogrenmek isterim). ve bu en onemli tercih mevzuu. perkande pazarda bulunan donanim gucu karsisinda dillerin birbirinde pek bir farki yok. ama maliyet tablosunda 200bin in ve zaman planında 4 ayin ciddi bir degeri var.
Zatne terslikte burada. Budur denebilecke bir developerin bu şekilde o dili bilir, bu dili bilir gibi bir ölçüte tabi tutulması bana son derece abes geliyor. Projede diğer arkadaşlar python diyor, olur diyoruz. Ve aynı gün işe girişip, python ile bir dil geliştiriyoruz. Python'da ilk yazdığımız şey bir parser, virtual machine ve devamı.
Tüm diller en nihayetinde döngüler, referanslar ve komutlardan oluşan bir yapı. Ve işletim sistemlerinin API olarak verdikleri belli. Hangi dile giderseniz gidin, socket gene socket hepsinde örneğin kabaca. Kısaca, zaten programlama pratiğine hakimseniz, dillerin sizin için bir farkı kalmıyor. Daha doğrusu, her dile kolayca intibak edebiliyorsunuz. Bu noktada, yapacağınız iş için envanterinizdeki dillerden en uygun olanı kolayca çekip ortaya koyabiliyorsunuz. İşte asıl o zaman maliyetleri vs. efektif olarak uygun hale getirebiliyorsunuz.
quote:
zannediyorum bunda 15 yil oncesine ait terimler kullaniyorsunuz. artik gorsel gelistiriciler icin scripting nerede basliyor, sql nerede bitiyor, bll nerede kimse bunu ayirt etmiyor. bunu maalesef korukle destekleyenler var. karsi degilim yoksa bugun uygulama yazilimlarinin en dusugunun ticari degeri bir kac pc bedeline esit olurdu. su an perakende de 30 milyon satiri 199 ile alabiliyorsaniz, bunu istemesenizde gorsel dillere borclusunuz.
Ben bunun kötü bir tarafını göremiyorum. Ama bu noktada, aynı verimi sağlayan C içinde gayet gelişmiş RAD toollarının var olduğunu söylüyorum. Pek iyi ifade edemediğimi kabul edeyim gerçi. Ama o bahsettiğim karmaşıklık noktasında, işte o SQL ile başka bir şeyin uyumsuzluğu vs. ortaya çıkmaya başladığında, artık size daha güçlü, daha doğrusu tam olarak sizin dediğinizi yapacak şeyler gerekiyor.
Fakat bundan sanki C açılır bir konsol, vi yada emacs ile yazılırda yazılır gibi bir anlam çıkıyor. Hoş, vi ve emacs ile gayet güzel kod yazılır ama C artık bu değil. Bugünün C geliştirme ortamı, diğerlerinden geri kalır değil, hatta, pek çok noktada çok daha ileri olduğu da kesin. Fakat, 199 dolara 30 milyon satırın, çin malı ucuz olta iğnesi gibi cazibesi genelde öne çıkıyor. Tamam, vuran 10 balığın 6'sı kaçıyor ama, 4 balık bizi doyuruyor oluyor.
Velhasıl işin birde diğer tarafı var. Burada bir öğrenci, hayatını kazanmak için kod yazmayı öğrenmek istiyor. Ve o okuldan çıktığında 30 değil 100 milyon satır 100 dolara düşmüş olacak. Karnını doyurmak için, artık o yüz milyon satırın veremeyeceği bir şeyleri yapabiliyor olması gerekecek. İşte o zaman şu anda C'ye yapacağı yatırımın geri dönüşünü alabilecek. İşte asıl meselede bu.
Diğer yanda? Alet yapıyoruz. Süper çalışıyor. Ama sonuçları grafik olarak ekrana dökecek "mühendis" bulamıyoruz. Balık bulucu yapıyoruz, balıkları karada gösteriyor. Elimizdekiler şuradaki kurstan bir sertifika alıp gelen insanlar değil, İTÜ bölüm birincisi filan. Üflüyor, püflüyor, bir kaç rus "programcıya" 15 bin dolar verip 10 günde yazdırıyoruz sonra UI'yi.. Sizce bu bir ayıp değil mi?
Bu hayali bir örnek, ama inanın yaptığımız işlerde aynen böyle durumlar yaşıyoruz. İşte bunun sebebi ne acaba? Programlamanın iki üç komponenti sağdan alıp sürükleyip bırakmakla bittiğini sanmak olabilir mi?
-
quote:
Orijinalden alıntı: AlperXp
quote:
Orijinalden alıntı: AlperXp
En basit incelenecek açık kaynak program tipi nedir ? Text Editorler mi ? C++ için open source kaynak arıyorum headerları incelemek gerektiğini daha yeni anladım...
Öhöm öhöm ?? Tamam kaptırdık gidiyoruz ama sorulara da yanıt versek hani bilgilerinizi bunda da kullansanız zaten yazdıklarınızın %1 ini anlıyorum anca -_-"
Yazı mı görünmüyor yoksa bende mi bi sorun var ? -
quote:
Orijinalden alıntı: AlperXp
quote:
Orijinalden alıntı: AlperXp
En basit incelenecek açık kaynak program tipi nedir ? Text Editorler mi ? C++ için open source kaynak arıyorum headerları incelemek gerektiğini daha yeni anladım...
Öhöm öhöm ?? Tamam kaptırdık gidiyoruz ama sorulara da yanıt versek hani bilgilerinizi bunda da kullansanız zaten yazdıklarınızın %1 ini anlıyorum anca -_-"
eger reverse engineering ile bir seyler ogrenme yoluna gidecek iseniz temel olarak network uygulamalarindan baslamanizi tavsiye edebilirim.
network uygulamalari (router, firewall, proxy gibi ) hem olgundur hem de uygulama domain ini -neredeyse- eksiksiz kapsayan bir analize sahiptir.
uygulama gelistirdiginiz sistemin yapisini (open/closed), bu yapinin uygulama modelinize etkisini, state lerin neler oldugunu, exception in nerede yakalanacagini, performans ihtiyacini, cache i en dogru zannediyorum network uygulamalarinda gorebilirsiniz. esasinda temel algoritmalara ne kadar yaklasirsaniz o kadar tumevarimci bir yontem izlersiniz. tumevarim bence ice dogmadan sonra en iyi ogrenme metodudur.
bakmaniz gereken en son yer ise veri tabani uygulamalaridir :) . kimse iki ayakli, acik, tutarsiz bir sistemin ve bu sistemin kendisinin gelistirdigi diger basarisiz sistemlerin (ornegin ekonomi) ihtiyaclarini ongorup, cozum gelistirmeye yonelmek istemese gerek.
-
Tavsiyem, C++ ile değil, C ile başlamanızdır. C++ gereksiz yere fazla karışıktır, yeni başlayan için anlaması, kavraması güçtür.
Nerden başlayacaksınız? Bunun çok fazla önemi yok. Önemli olan nasıl başlayacağınız.
Bu açıdan en makul olanı kullanıcı ile bir kaç interaksiyon yapan bir koda gözatmak olabilir. Peki bu amaçla bakılabilecek en iyi başlangıç noktası neresidir?
Open source yazılımlar gerçekten iyi bir başlangıçtır fakat dökümantasyonu zayıftır. Ama şöyle bir avantajları vardır, tüm geliştirme süreçlerini takip edebilir, yazanlarla iletişime geçme imkanına sahip olabilirsiniz.
Bunun yanında nerden, nasıl başlamalı? En iyi yol, çeşitli programlama API'lerini vs. incelemektir. Bunların içinde genelde bolca açıklama bulunur. Örneğin, GTK kaynak kodlarını indirirseniz, bolca örnek program ele geçirmiş olursunuz. Bunlarla başlamak iyi olur.
http://freshmeat.net
Buradan kendinize bir başlangıç kodu seçin. hiç bir şey bilmiyorsunuz, sudan çıkmış balıksınız. Açın kodu, bakın ne oluyor? Bir sürü karman çorman şey. Bunun içinden nasıl çıkılır?
Cevabı basit, buraya sorarsınız mesela. Kod kod dendi, aha bulduk kodu, tabi yanında papazı da. Bu nedir, nasıl iştir? Nerden başlayacağız bu kamyon yükü pirinci ayıklamaya?
Her şeyin bir başlangıcı olduğu gibi, bu programında bir başlangıcı olması lazım. Nedir acaba bu? Bu soruyu araştırmak, sizi main() fonksiyonuna götürecek. Tüm mesele şu. Önünüze çıkan şey neyse, inatla onu kavramaya, aşmaya çalışacaksınız. Kolay olacak demiyorum, buna özellikle dikkat edin. Bir şeyi çözmek, kavramak istediğinizde önünüze başka bir şey çıkacak. böyle yaparken yaparken derinlere girmiş olacaksınız. Merka etmeyin, nefesiniz yeter, boğulmazsınız, yeterki kendiniz bırakmayın. O derinlerde bir şeyler netleşmeye başladıkça, daha önce anlamakta zorlandığınız şeyler netleşmeye başlayacak. Size neleri öğretecek, neleri gösterecek bir dökümana, bir kitaba vs. ihtiyacınız olduğunu kendiniz kavrayacaksınız.
BU kolay değil, ama zor hiç değil. Önemli olan, önünüzdeki pirincin taşını ayıklamayı öğrenmek zaten. Size kitap yasak, şu yasak bu yasak demiyorum, dikkat edin. Her yer kitap dolu, açın okuyun, öğrenmeniz gereken şeyi biliyorsunuz. Açın öğrenin. zaten olayın bam telide burasıdır. Siz kitabın vs. yönlendirmesi ile değil, sizin o kitabı vs. kullanmanızla bu işi öğreneceksiniz. Patron siz olacaksınız, kitaplar değil diyelim kabaca. Bilmediğiniz şeyi, en fazla saatler içinde internette bulursunuz, hiç merak etmeyin.
Kısaca, ne öğrenmek istediğinize siz karar vereceksiniz. Tahminen uzun süre hiç bir şey anlamayacaksınız. Sebebi, ne öğrenmek istediğinizi öğrenmenin yolunu önce öğrenmeniz, sonra da size gereken bu bilgiyi en iyi nasıl bulacağınızı öğrenmeniz gerektiği. Kitaplar, man sayfaları, internet vs. bir numaralı dostunuzdur, ama onlar sadece referanstır, öğretici değil.
-
quote:
C ve C programcısının daha iyi olduğunu göstermez mi?
bir genellemeye yonelirsek evet, hatta ne kadar low level yaziyor ise o kadar daha iyidir de denilebilir.
quote:
Bunu şöyle düşünün. O kodları yeni bir dile taşımak, demekki daha masraflı. Yeni dilin getireceği ve verebileceği bir şey yok. Eğer öyle olmasa, başta bu yöntem gibi bir şeyler ile bu kolayca aşılabilirdi. Yada eğer o "görsel" programlama bir dokunuşta uygulama yapıyor olsaydı, neden bu uygulamayı alıp taşımasınlar ki?
bunu ilk yazimda soylemistim, eski muhendisler veya kod gelistirenler maaslarinda feragat etmekten cekinmiyorlar. bu nedenle eski kodlarla calisilmaya devam ediliyor. taki ticari anlamda bir mecburiyet olana kadar. bir cok surum de bundan 20 yil once yaptigi dil secimini surduruyor. eski kodlar oldukca olgun ve basarili, yeni fonksiyonlar uygulamalara yeni kutuphaneler ile ekleniyor. ancak yeni kutuphalerde C ile yazilmaya devam ediyor. bunda yadirganacak ya da gocunacak bir durum yok. ticari tercih, her zaman kollamak lazim.
quote:
Projenin "karmaşıklığı" arttıkça, hazır nesneler arası uyumsuzluklar artmaya başlar. Eldeki mevcut komponentlerin pek çoğunda basitçe yeni nesne türetmeyle aşılması zor olan püsüratlar ortaya çıkmaya başlar. İşte bu kırılma noktasını iyibir programcı (elbette onun yöneticiside) önceden görebilmelidir. İşte bu noktada, C gibi bir dilin gücü kendini hissettirir. Fakat bu "karmaşık" terimi, genelde pek kolay anlaşılmaz. Nedir karmaşık olan? Bilinen multitier vs. çözümlerinin sınırları ne zaman birbirine girmeye başlar? Bulanık sahalar, kaynak erişimi problemleri vs. ne zaman sorun olur? İşte bu noktaları görebilmek, gerçekten ciddi bir öngörü gerektirir. Pek çok zaman, bu öngörü doğru yapılamaz ve o batağa girmemek için uzun, zahmetli yol seçilir, C ile vs. başlanır. Bu gibi örnekler pek çoktur.
bunu bir analizci gorebilir. ve sistem mimari da uygun tedbirleri alir. benim karmasikligi azaltmak adina en cok yoneldigim tercih sistem mimarindan gereksinim izlenebilirligi istemek oluyor. bir cok projede sistem karmasikliginin alt sistemler arasi etkilesimden kaynakli oldugunu ve bu etkilesiminde hatali protokol tanimlarindan geldigini gordum. pratikte c coderlarinin analizde icsel bir ongorulerinin oldugunu sezmek mumkun. bu bazen dezavantaj da olabiliyor. mesela siz proje yoneticisi olarak urunu bir an once olgunlastirmak uzere sureci baskilarken, developer/coder cok ta elzem olmayan bir gereksinime ya da ancak 3 yil icinde karsilasmanin mumkun olacaginiz bir implementasyona kendini kaptiriyor. bu arkadasin saatinin 50 dolar oldugunu ve 20 saatini bu ise ayridigini gorunce elbette irkiliyorsunuz. toplam koda enjekte ettigi 50-100 satir kod 2 class ta cabasi.
quote:
Gerçi, bugünün yazılım siparişlerine baktığımızda son derece standart kalıplar görüyoruz.
kendini ispatlamis demek daha dogru olur.
quote:
programlama pratiği açısından yüzeysel uygulamalar. Velakin, bunun şöyle bir soruna yolaçtığını görüyoruz: İmplementasyondaki temel problemlerin çözümünde, gerekleri doğru tespit edemeyen, bu gereklere asıl çözümleri getiremeyen uygulamalar ortalığa yayılıp gidiyor. İşte SSK'nın X milyon dolarlık rezaleti. Ben ne zaman eczaneye gitsem, sistemleri çökük oluyor SGK'nın. Elbette bununla kalmıyor, bakıyoruz, kullanıcısını bir amuda kaldırmadığı kalan uygulamalar.
bu elestiriniz haksiz olmus. o kodlar yazilirken analizlerde sosyal guvenlik kurumunun her hastaneye, hastanenin muhasebesine, eczaneye, doktora hastaya, kamu kurumuna, sigortaliya erisecegini kimse ongormuyordu. sgk ve uyap su an en cok kapsama alanina sahip iki dev. yuzbinlerce nesne tanimi, onbinlerce protokol, binlerce fonksiyon var.
ulke hizli bir degisim icinde gerek gercek dunya sistemleri gerekse elektronik sistemler bu degisimi yakalamakta zorlaniyor. kimse de abi bu kanunu 5 yil tutun ben bir program yazacagim diyebilecek halde degil. herkesin tempoyu yukseltmesi lazim. bazen elektronik sistemler de yeterli olgunluga sahip olmasa da hizmete alniyor. ticari bir isletim sistemine bile eklenen yamanin haddi hesabi yok. gunde 3 yama yayinlaniyor.
İşte asıl mesele burada. C sizi bu konularda daha disipliner olmaya zorlar. C, atladığınız bir şeyi çok kötü başınıza geçirir. O yüzden ufak hataları vs. gözardı etmemek gerektiğini öğrenirsiniz. Bu disipline sahip olan, uygulamayı hangi dille gerçeklerse gerçeklesin, aynı prensipleri olabildiğince kollayacaktır. İşte bu topikte benim üzerinde durmak istediğim konu bu.
quote:
Fakat bundan sanki C açılır bir konsol, vi yada emacs ile yazılırda yazılır gibi bir anlam çıkıyor. Hoş, vi ve emacs ile gayet güzel kod yazılır ama C artık bu değil. Bugünün C geliştirme ortamı, diğerlerinden geri kalır değil, hatta, pek çok noktada çok daha ileri olduğu da kesin. Fakat, 199 dolara 30 milyon satırın, çin malı ucuz olta iğnesi gibi cazibesi genelde öne çıkıyor. Tamam, vuran 10 balığın 6'sı kaçıyor ama, 4 balık bizi doyuruyor oluyor.
buna mecbursunuz. dunyadaki her eve bir bilgisayar sokamadiginiz taktirde, agir aksak isleyen bir e-devlet sistemi kuramadiginizda insanlarin dunya duzenine, rejiminize baglayacak bir bag kuramamissiniz demektir. olgun olmasa da optimum u yakaladiginizda hizmet vermeye basliyorsunuz. artik kimse bir donatello, rafael, ya da da vinci degil. bu isi sanat icin yaparsak hepimiz ac kaliriz.
quote:
Diğer yanda? Alet yapıyoruz. Süper çalışıyor. Ama sonuçları grafik olarak ekrana dökecek "mühendis" bulamıyoruz. Balık bulucu yapıyoruz, balıkları karada gösteriyor. Elimizdekiler şuradaki kurstan bir sertifika alıp gelen insanlar değil, İTÜ bölüm birincisi filan. Üflüyor, püflüyor, bir kaç rus "programcıya" 15 bin dolar verip 10 günde yazdırıyoruz sonra UI'yi.. Sizce bu bir ayıp değil mi?
bence ayip degil. eger bu balik bulucuyu bir rusa, bolivyaliya, pengune ya da marsliya satacak iseniz, global dunyanin imkanlarindan faydalanmak zorundasiniz. ya da kendinize bir community olusturup kaynaklarinizi kendiniz uretmelisiniz, belki de bunu microsoft gibi parayla yapip (msdn), urunlerinizi satip, ayrica g*tunuzden uydurdugunu dilde uygulama yazabilmeleri icin vereceginiz egitim programindan bile server elde edebilirsiniz. soylemesi ayip bu arkadaslar para ile aldiginiz urunlerini gelistirmek uzere vercekleri danismanlik destegini ulkenizdeki 5 aylik asgari ucrete esdeger rakam ile gunluk olarak fatura edebilirler. kaba rakamlar ile 72 gun calisip asgari ucretlinin 30 yillik emeginin karsiligini isteyebilir.
quote:
İşte bunun sebebi ne acaba? Programlamanın iki üç komponenti sağdan alıp sürükleyip bırakmakla bittiğini sanmak olabilir mi?
bence bunun sebebi stratejik ongorulerin olmayisi, gunubirlik yapilan isler, merdiven alti (kayitsiz, sendikasiz, egitimsiz) isletmeler/girisimler, halen bilisim derneginden baska sosyal orgutlenmenin olmayisi, connected calisama, girisimciligin desteklenmemesi, melek yatirimcilarin olmayisi.
edit:gorsel
< Bu mesaj bu kişi tarafından değiştirildi kuduk -- 2 Şubat 2010; 23:20:26 >
-
atlamayayim. sourceforge -
quote:
quote:
Gerçi, bugünün yazılım siparişlerine baktığımızda son derece standart kalıplar görüyoruz.
kendini ispatlamis demek daha dogru olur.
Sanırım burada bir yanlış anlama olmuş. Söz konusu olan, ürün kalıpları değil, sipariş kalıpları. Yani sizden istenen üründe listelenen beklentiler, bir klişe gibi nerdeyse. Elbette aynı temel gereklere sahip bir ürünün aynı inşa bloklarına sahip olması ve RAD işi için biçilmiş kaftan olması şaşırtıcı olmayacaktır.
Diğer yandan SGK mevzusunda size katılmadığımı belirteyim. Benim indimde, uygulamada bir şey ya bir tanedir, yada çoktur, 3, 5, 15 değil, sınırı yoktur. Yani örnek olarak, bir index ya unique olur, yada olmaz. Bu açıdan bu gibi bir uygulamanın sistemni gelişmesi ile paralel büyüebilir olmasının sağlanması, o gerekler listesinin en başında olması gereken bir husustu. Basitçe, buradaki sorun, dikey ve yata partisyonların doğru tespit edilememiş olması, çok sıkı bağlanmış modil/nesneler arasına bir şeyler eklemenin zorluğu sorunu. Gevşek kuplaj, nesneleri birbirinden tam bağımsız yapabilme öngörülerinin olmayışı. Nasılsa ORACLE var, yüklen, su götürür, getir itfaiye hortumunu gibi bir anlayış.
İşin daha kötüsü ise şu. Kanıksanmışlık. bu şekilde aksyana, topallayan ve doğuştan kör sistemlerin sanki bu işin doğasıymış gibi görülmesi. İşin kalbinin uygulamada, beyinde değil de, vücutta attığının sanılması. Yani, aman ne olacak, yarın şu clustere bir düzine daha makina ekleniverir canım gibi anlayışlarla, uygulamada yapılması gerekenlerin altyapıya havale edilmesi gibi.
Bunun asıl ilginç olan yansıması ise, uygulama geliştirme sürecinde gözleniyor. Dilin bir altyapısı var, ahada burda var ya, bunu kullanayım, kullanırım, kısa yoldan köşe dönerim zihniyeti hasıl oluyor. Basitçe örnek vermek gerekirse, aslında basit bir hash-table gereken yere gidip SQL sunucu konmaya çalışılıyor. Elinde logo bilgileri var arkadaşın, birde rtf textbox. Hah, göstermek için budur, alırım, koyarım gibi bir yaklaşıma giriyor. Kısaca, kullanacağı komponenti, textbox olsun, SQL sunucu olsun, dil olsun, ihtiyaca göre düşünmüyor, elind eolanı o ihtiyaca yamamaya çalışıyor. Ve sonuçta işte bu durumlar oluşuyor. İstenmeyen diyemiyorum, zira artık kanıksanmış. Benim evimde 3 bilgisayar mevcut. Yaklaşık 5 yıldır ne format atıldı, ne bir bakım vs. gerekti. ama duyuyorum, "DeepFreeze kur, sonra 6 ayda bir format attırırsın.." Komik geliyor, ama buradaki acı gerçek şu. Bir uygulamanın doğru dürüst çalışmaması, bir noktada gelip böyle milleti kapılarda bekletmesi kanıksanmış. ama bir hayli yıllardan beri bu işin içinde olan ben, bunun böyle olması gerekmediğini çok iyi biliyorum.
Peki neden? Basit bir log bilgisi göstermek için RTF penceresi düşünen arkadaş var, elbette. Fakat şu göz ardı ediliyor, burada o RTF widget'in getirileri gerçekten gerekiyor mu? Öncelikle ne oluyor, o widget'i yazan, herkesin böyle ufak tefek isteklerine cevap vermek için ufak tefek bir sürü şey ekliyor. Ama şu kullanıcının o şeylere ihtiyacı yok. Fakat, geliştirici alıp o bileşeni oraya tıkıştırınca, farkında olmadan amaç için gereksiz olan bir sürü satırı, özelliği vs. oraya tıkıştırmış oluyor. Pek çok geliştirici, bu durumda ne yaptığından habersiz. Olayı atomik bir işlem sanıyor.
Basit bir log gösterme işi yaptım sanıyor ama, o işlemin mesela gereksiz yere bir sürü CPU zamanı harcadığından haberi olmuyor. Ve işin kötüsü, bir tek RTF box yokki, daha bir sürü şey var ve geliştirici aslında 50 satır gereken kodunun işletilirken efektif olarak milyon satıra çıktığını kavrayamıyor. Asıl daha da kötüsü şu. O kodlar gökten zembille inmiyor. Böyle olunca da, hataları da beraberinde getiriyor. Sonuçta, 50 satırının ne yaptığını bildiği ama geri kalan 999.950 satırdan bi haber bir geliştirici oluyor elimizde. Hesap basit, 1 milyon satırdaki bir hata, işte böyle çöken sistem olarak geri dönüveriyor.
Hata denince genelde son derece fatal hususlar, hemen görünüveren syntax error'umsu şeyler düşünülüyor. Ama hata bu kadar basit bir olgu değil. Tıkır tıkır çalışan pek çok kod olmadık yerde hatalar barındırıyor. Bunlar da bir gün geliyor, bir şekilde patlıyor.
Peki, C ile yazmak bu sorunu giderir mi? Tam tersine, çoğaltır. Bu noktada asıl mesele, işi bilen bir C programcısının bunu acı tecrübelerle öğrenmiş olacağı ve adımını daha doğru atacak olması sadece. Fakat, bu tecrübesi olmayan kullanıcı; ne yaptığının farkında olmuyor. Zira, nasılsa, sürekleyip bırakıp araya 3-5 event handler yazdığı kod çalışıyor.
-
quote:
Orijinalden alıntı: skoylu
Sanırım burada bir yanlış anlama olmuş. Söz konusu olan, ürün kalıpları değil, sipariş kalıpları. Yani sizden istenen üründe listelenen beklentiler, bir klişe gibi nerdeyse. Elbette aynı temel gereklere sahip bir ürünün aynı inşa bloklarına sahip olması ve RAD işi için biçilmiş kaftan olması şaşırtıcı olmayacaktır.....
Basitçe, buradaki sorun, dikey ve yata partisyonların doğru tespit edilememiş olması, çok sıkı bağlanmış modil/nesneler arasına bir şeyler eklemenin zorluğu sorunu. Gevşek kuplaj, nesneleri birbirinden tam bağımsız yapabilme öngörülerinin olmayışı. Nasılsa ORACLE var, yüklen, su götürür, getir itfaiye hortumunu gibi bir anlayış.
İşin daha kötüsü ise şu. Kanıksanmışlık. bu şekilde aksyana, topallayan ve doğuştan kör sistemlerin sanki bu işin doğasıymış gibi görülmesi. İşin kalbinin uygulamada, beyinde değil de, vücutta attığının sanılması. Yani, aman ne olacak, yarın şu clustere bir düzine daha makina ekleniverir canım gibi anlayışlarla, uygulamada yapılması gerekenlerin altyapıya havale edilmesi gibi.
Öncelikle ne oluyor, o widget'i yazan, herkesin böyle ufak tefek isteklerine cevap vermek için ufak tefek bir sürü şey ekliyor. Ama şu kullanıcının o şeylere ihtiyacı yok. Fakat, geliştirici alıp o bileşeni oraya tıkıştırınca, farkında olmadan amaç için gereksiz olan bir sürü satırı, özelliği vs. oraya tıkıştırmış oluyor. Pek çok geliştirici, bu durumda ne yaptığından habersiz. Olayı atomik bir işlem sanıyor.
Ve işin kötüsü, bir tek RTF box yokki, daha bir sürü şey var ve geliştirici aslında 50 satır gereken kodunun işletilirken efektif olarak milyon satıra çıktığını kavrayamıyor. Asıl daha da kötüsü şu. O kodlar gökten zembille inmiyor. Böyle olunca da, hataları da beraberinde getiriyor. Sonuçta, 50 satırının ne yaptığını bildiği ama geri kalan 999.950 satırdan bi haber bir geliştirici oluyor elimizde. Hesap basit, 1 milyon satırdaki bir hata, işte böyle çöken sistem olarak geri dönüveriyor.
Hata denince genelde son derece fatal hususlar, hemen görünüveren syntax error'umsu şeyler düşünülüyor. Ama hata bu kadar basit bir olgu değil. Tıkır tıkır çalışan pek çok kod olmadık yerde hatalar barındırıyor. Bunlar da bir gün geliyor, bir şekilde patlıyor.
Peki, C ile yazmak bu sorunu giderir mi? Tam tersine, çoğaltır. Bu noktada asıl mesele, işi bilen bir C programcısının bunu acı tecrübelerle öğrenmiş olacağı ve adımını daha doğru atacak olması sadece. Fakat, bu tecrübesi olmayan kullanıcı; ne yaptığının farkında olmuyor. Zira, nasılsa, sürekleyip bırakıp araya 3-5 event handler yazdığı kod çalışıyor.
güzel bir fikir alışverişi oldu. teşekkür ederim.
-
Cidden güzel bir fikir alışverişi olmuş. Sonuna kadar okudum bazı şeyleri anlamasamda ufkumu actıgını soyleyebilirim. -
Serdar Hocam, uzun zamandir nerelerde oldugunuzu merak eder dururdum. Meger dogru durust bakmamisim. Sizden bir ricam var. Lutfen yazmayi birakmayin, hep devam edin. Zaten gordugum kadariyla eski formunuzdan bir sey kaybetmemissiniz. Ayni Eksi Sozluk'te yazildigi gibi, patatesli pogacadan bile bahsetseniz, okunur, dinlenir.
Ip işlemleri
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
Bu mesaj IP'si ile atılan mesajları ara Bu kullanıcının son IP'si ile atılan mesajları ara Bu mesaj IP'si ile kullanıcı ara Bu kullanıcının son IP'si ile kullanıcı ara
KAPAT X
