Teknoloji Seçerken

Bu yazıyı Java bilgi işlem teknolojilerinden biri olan Entity Bean'lerin erken ölümü üzerine yazdık. Zamanında büyük şaşa ile ortaya çıkan bu teknoloji niye böyle erken tedavülden kalktı? Ayrıca bu tecrübeden ders çıkarmak bağlamında, ileride bu tür geleceği olmayan ve külfetli teknolojilerin kokusunu nasıl alabiliriz? Bu yazı bilgi işleme daha çok hitap eden bir yazıdır çünkü 3-4 senede bir yeni bir dehşet teknolojiyle çalkantılar yaratan grup bu olmaktadır. Bu dinamizm tabii ki iyidir fakat bilgi işlem müdürleri ve proje yöneticileri için bu teknoloji enflasyonunda bir seçici turnusol testi lazımdır. Aksi halde sonuç InfoWeek Dergisi Pazartesi Günü Sendromudur; (Masasındaki Infoweek dergisinin yeni sayısını pazartesi günü okuyan yönetici) "XML diye bir şey cıkmış bütün dertlere devaymış! Hemen kullanalım!" . [Proje teknik lideri burada somurtur].

http://www.bilgidata.com/yazi.jsp?dosya=a_ejb_postmortem.xml

Görüşler

bio
21 yıl önce

Tebrik ederim. Yazinin tamaminin altina imzami atarim. EJB 1.0 zamaninda entity bean'lerin calismasini anlatan bir egitmene "saka gibi bu" deyip gecmistim. Ama onsezimi bu yazidaki gibi "pattern" haline getiremezdim herhalde.

FZ
21 yıl önce

Ben de tebrik ve teşekkür ederim. Uzun zamandır okuduğum en ilginç ve özgün BT (Bilgi Teknolojileri) makalelerinden biri idi.

Her ne kadar ``Enterprise´´ ölçekte Java nedir ne değildir pek bilmesem de uğraşmasam da makalede anlatılanları üç beş gözümün önünde canlandırabildim.

Başarı öykülerinin yanısıra bu tür teknolojik başarısızlık ve hüsran analizlerinin de çok önemli olduğunu ve dersler çıkarılması gerektiğini düşünüyorum. Bununla birlikte maalesef Sun, IBM, Oracle vs. gibi firmalar bir konuya el attıklarında devasa kampanyalar ve büyük rüzgârlar söz konusu oluyor ve hangi rüzgârın doğru olduğunu bilmek de iş işten geçmeden önce kolay yapılabilecek bir iş değil. Post-mortem analizde analizi yapan kişinin çok büyük bir avantajı var, geçmişe doğru yorumlamak!

Hazır teknolojik projelerin analizi demişken son zamanlarda bu konuda okuduğum en enteresan kitaplardan biri olan Aramis´ten de bahsetmeden geçemeyeceğim:

http://ileriseviye.org/blog/index.php?p=95

bm
21 yıl önce

Malkocoglu eline saglik. Firsattan istifade tam uymasa bile ben de bir alinti ve link sokusturayim: http://www.paulgraham.com/avg.html [www.paulgraham.com]

Yazida bu konuya bagli olan ana fikir: kucuk sirketler zaten calissa bile buyuk sirketlerin secimlerini taklit etmeseler iyi olur. Fortune-500'un bilgisayarcilarina ile yepyeni fikirlerle tasarlanmis birseymis gibi pazarlanan ('enterprise' ya!) seye zaten ta basindan derin supheyle yaklasmak lazim. "J2EE" bilmenin nasil anlasilirsa anlasilsin marifet haline gelmesi bu tip birsey. Musterinin sistemleri oyleyse zaten yapacak birsey yok, ama J2EE en iyisiymis abi diye kendi islerini boyle yapanlar icin iyi olmamistir tabi. En azindan Graham'in iddiasini boyle bir hikaye ile buraya sokusturmak kabil.

Herneyse, Graham diyor ki:

The average big company grows at about ten percent a year. So if you're running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company-- that is, to grow about ten percent a year.

The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.

bm
21 yıl önce

Elinden kacti yaziyi kontrol etmeden yolladim kusura bakmayin. lInk soyle olacak: http://www.paulgraham.com/avg.html [www.paulgraham.com].

FZ
21 yıl önce

Mükemmel bir makale!

malkocoglu_2
21 yıl önce

bio, FZ, bm: Yaziyi begendiginize cok sevindim. Bu yazilari yazarken zaten tek istegimiz yararli olmalari ve begenilmeleridir. Iyi calismalar.

Görüş belirtmek için giriş yapın...

İlgili Yazılar

Free as in Freedom

FZ
24 Aralık 2002, 1 dakika okuma süresi

Sam Williams'ın GNU hareketi ve Richard Stallman üzerine, bu yılın Mart ayında kaleme aldığı "Free as in Freedom" adlı kitabın tamamına Internet üzerinden de erişebilirsiniz.

Kitabın belki de en zevkli bölümü 1. bölüm: Bu bölümde 80'li yılların başında MIT yapay zekâ laboratuvarında çalışan Stallman'ın bozuk bir XEROX yazıcının yazılımına düzeltmek için müdahale etmek istemesi ama XEROX'un kaynak kodunu vermemesi ve sonrasında gelişen olaylar anlatılıyor. Önce efendi ve nazik bir dille derdini anlatmaya çalışan Stallman, insanların "hadi len, biz burada ticari iş yapıyoruz, yok sana kaynak kod, mod, ne halin varsa gör!" demesi üzerine ufaktan bir şok geçiriyor ve "sizin allahınız, kitabınız var mı üleennn!" diye elini kolunu sıvıyor ve GNU isimli organizasyonu kuruyor. (Ve bugün çoğumuzun bu organizasyona ait olduğunu bilmeden, Linux ve benzeri sistemler üzerinde kullandığımız bir ton çok önemli yazılım geliştirilmeye başlanıyor.)

Diff ve Patch Kullanımına Giriş

Armish
27 Ocak 2004, 1 dakika okuma süresi

Bu araçlar programlama veya program kodları ile uğraşanlar için bazen hayat kurtarıcı olabilyor. diff ve patch'i kullanmak konusunda az da olsa bilgim olsun diyorsanız bu yazı size yardımcı olabilir.

Yeni bir E-dergi : pozi+if

boreas
9 Mart 2006, 1 dakika okuma süresi

E-lapis, penguence gibi ücretsiz dergilerin arasına yaklaşık üç ay önce yayına başlayan yeni bir e-dergi pozi+if eklendi. Programlama, özgür yazılımlar gibi konuların yanında donanım ve yazılım testi gibi konularada ağırlık veren bu dergi yaklaşık 200 sayfalık içeriğiyle umut vaad ediyor.

Adres : http://www.pozitifpc.com/

Yazılım Mühendisliğinde Çıkmaz Sokak Tarifleri: Anti-Patterns

FZ
21 Mart 2005, 1 dakika okuma süresi

Bilgisayar yazılımları geliştirmekle yıllardır uğraşılmakta. Son yarım yüzyılda ortaya çıkan bu alanda çeşitli paradigmalar (prosedürel, nesne tabanlı, fonksiyonel, vs) ve çeşitli modeller (code reuse, unit testing, component model, extreme programming, design patterns) ortaya atıldı. Daha çok "Özgür Yazılım'' ile birlikte dağıtık geliştirme yöntemleri gündeme geldi. Tasarım, uygulama ve test aşamalarını kapsayan geniş bir açıdan baktığımızda bize önerilen çeşitli "doğru'' geliştirme yöntemleri var.

Diğer her alanda olduğu gibi dengeli ve sağlıklı bir kavrayışa sahip olmak için doğruların yanında "yanlış'' yöntemler hakkında da bilgi sahibi olmak gereklidir. Bu konuda yaşanmış çok tecrübe olmakla birlikte, yazılı olarak birkaç kaynak dışında ciddi bir eksiklik bulunmaktaydı. Bu makale, ağırlıklı olarak yazılım mühendisliği ile ilgili birkaç Internet sitesinden derlenmiş, daha çok özgür yazılım alanını ilgilendiren bu tür çıkmaz yolları tanıtmaktadır. Ortak noktaları:

* Çoğu bir problemi çözmek isterken ortaya çıkar
* İlk bakışta harika bir fikir gibi gözükebilirler
* En çok tasarım aşamasında görülürler
* Sizden çok daha üretken ve başarılı grupları batırmışlardır!

Gürer Özen'in Anti-Patterns çevirisinin devamını burada okuyabilirsiniz.

Nasıl Programcı Olunur

yalcink01
2 Ağustos 2003, 1 dakika okuma süresi

Robert L. READ tarafından yazılmış olan ve ESR'nin "Nasıl Hacker Olunur?" kılavuzunda da bahsi geçen "How to be a programmer" kılavuzunun "acemiler" için olan kısmının çevirisi bitti. Hem çevrilen kısmın imla, yazım, mantık ve bilumum hatalarının kontrolü için hem de programlamaya merak saran acemi vatandaşlara yol yordam göstersin diye bu kısmı yayınlamaya karar verdik. Çevrilmiş kısım hakkındaki fikir ve eleştirilerinizi bekliyorum. Hata ayıklama konusundaki yardımlarınız için şimdiden teşekkürler.

Saygılarımla,

Yalçın KOLUKISA
yanmasın diye kaz çevirmeye giden adam