Cocuklar&Ebeveynler&Buyukler Icin Ucretsiz Java Kitabi

Java Gurusu ve aynı zamanda birçok Java kitabının yazarı Yakov Fain bir tane de çocuklar için, karikatürlerle renklendirdiği bir Java kitabı yazmış. Kitabın orijinal adı "Java Programming for kids, parents and grandparents" ve ücretsiz olarak pdf formatında (İngilizce ve Fransızca) piyasaya çıkmış. (İndirmek için tıklayınız)

Bu kitap ilk bakışta he ne kadar sadece çocuklara hitap ediyormuş gibi gözükse de aslında Java'ya yeni başlayan herkesin çok faydalanacağı bir başlangıç kitabı. Ayrıca Bilgisayar Eğitmenleri ve Öğretmenleri için de harika bir kaynak.

Kitap 3 sene evvel yazılmaya başlandığı için içerik biraz eski gibi gözükse de Java'nın temel ve pek değişmeyen kavramlarını anlattığı için gayet öğretici. Ayrıca tüm örnekler JDK 1.5 ve Eclipse baz alınarak anlatılmış.

Konu açılmışken Java'ya yeni başlayanların ve ilerletmek isteyenlerin çok faydalanacağını düşündüğüm bir kaynak daha mevcut. http://www.javapassion.com/ adresinde Sang Shin tarafından sunum şeklinde hazırlanmış, pdf formatında harika Java eğitimleri mevcut. Acemisinde, ustasına kadar her kesime hitap eden harika Java eğitimler hazırlamış Sang amcamız.

Özellikle Java Programming with Passion! ismindeki, Basic ve Advanced olmak üzere iki kısımdaki toplam 20 başlık altında topladığı eğitimler harika. Yeni başlayanların mutlaka bu linkteki eğitimlere bir göz atmasında fayda var.

Ustalar için ise aşağıdaki eğitimler gayet faydalı olacaktır,birçoğu benim zamanımda faydalandığım ve development konusunda katettiğim yollardan geçmemde faydası olan yaklaşımları hoş kaynaklar:
AJAX Programming with Passion!
Java EE Programming with Passion!
Java Programming with Passion!
Web Services Programming with Passion!
Distributed Programming using Jini and JavaSpaces Technology
XML
Basic Servlet and JSP programming
Advanced J2EE programming
J2EE programming(5-day)
Servlet programming
Struts programming
Web services programming
Web services programming
JavaServer Faces (JSF) programming
NetBeans IDE 5.0 1-day Workshop
J2SE 5.0 (Tiger) programming

Açık Kaynak Konusuna Bakışım

Açık Kaynak mı? Ücretsizdir kullanalım!?

Başlamadan önce Açık Kaynağın ne olduğunu anlamam ve anlatmam gerekiyor. Birincisi açık kaynak ücretsiz olmaktan öte özgürlük kavramı ile daha çok bağdaşır.Yani kod geliştirirken, dağıtırken veya kullanırken özgür olabilmek açık kaynağın getirdiği fırsatlardır. Bunun getirdiği bir sürü avantaj vardır ki, bunlar için ayrı ayrı bir sürü yazı yazılmıştır. Yani bu yazıyı okumaya devam etmeden önce kafanızdaki açık kaynak=bedava eşitliğini bir süreliğine bırakmanız veya kafanızda biraz gerilere itelemeniz gerekiyor.

Asla!! Açık Kaynak bu şirketin kapısından içeri adım atmayacak dedim sana!! :)
Biz MS destekli firmayız, en iyisini onlar bilirrrr ona göre!!

Zaman zaman etrafımızda, çalıştığımız yerde görürüz, Açık kaynak öcüymüş gibi bir tavır sergilenir.Bu tavır genellikle büyük ölçekli, kurumsal şirketlerde gösterilir. Ve en temelde iki sebebi (ya da öyle olduğu söylenir) vardır. İlki, güvenlik açıklarından dem vurulur.. İkincisi, destek ve dokümantasyon olmadığından yakınılır.

Öncelikle güvenlikten bahsedelim. Güvenlik açığı heryerde olabilir. Sisteminin mükemmel işlediğini düşünen bankalarda dahi güvenlik açıkları vardır. Her programda olduğu gibi açık kaynak uygulamalarda da güvenlik açıkları vardır. Ama uygulamada geliştirme/kullanma olarak katılımcı sayısı (ki bu açık kaynak topluluğu denen grupta gerçekten çok sayıda da insan var) fazla ise güvenlik açıkları zaman içerisinde bulunmuş ve düzeltilmiş/düzeltiliyordur. Eğer bundan yana çok şüphe duyuluyorsa kodlar nasıl olsa elimizde bakabiliriz değil mi? Bu noktada sanki kapalı kaynak kodlar biraz daha güvensiz gibi duruyor farkındayım.

Destek ve dokümantasyona gelirsek, açık kaynak uygulamalar ölçeklerine bağlı olarak ücret karşılığında destek ve dokümantasyon sağlarlar. Tabi açık kaynağı bedava olarak niteleyip, ardından "nereden çıktı bu masraf" denmemeli. Az önce de belirttiğim gibi açık kaynak her zaman bedava anlamına gelmez. JBoss lisans ücreti ödemezsiniz, ama JBoss ON için CPU başına bir lisans ücreti ödemek zorundasınızdır, dünyanın en büyük güvelik ve network firmaları bu yazılımı kullanıyor gözümle gördüm :)

Açık kaynak geliştiricileri kazanmıyor mu?

Açık kaynak uygulamalar Microsoft'un aksine lisans ücreti talep etmezler, bunun yerine dokümantasyon ve destek, zaman zaman da yardımcı entegre modüller asıl para getiren kısımlardır. Bununla ilgili Matt Asay'in Open Road'daki "Why Microsoft fears open source more than other proprietary vendors do" yazısı lisanslama ve dokümantasyon/destek arasındaki farkı ve bununla ilgili Microsoft ve Açık Kaynak arasındaki görüş farklılıklarını çok güzel anlatmış. Bir göz atmakta fayda var.

Açık kaynak kodu çok mu iyidir ? O halde neden herşey açık değil ?

Açık kaynak trendi özellikle Sun CEO'su Jonathan Schwartz'ın katkıları ve vizyonu ile önce OpenOffice, sonra OpenSolaris ve ardından OpenJDK ile ivme kazandı. Sun'ın bu çabasına yakın zamanda IBM de OpenOffice.org topluluğuna katıldığını açıklayarak bir anlamda destek oldu. Sonra sırası ile birçok geniş ölçekli program trend değiştirip kodlarını açma kararı aldılar. Bunun en son örneği ise VMWare oldu. RedHat Fransız Eğitim Bakanlığı ve İsveç'te büyük ölçekte bir ilaç portali olan Fass.se'nin tüm server'larını (IBM ve Solaris'ten) RedHat Linux'e geçirdi.

Yapılması Gerkenler:

Bu kadar yazıdan sonra etrafımdakilerden haraketle olaya nasıl baktığımın özeti:

1.Hala açık kaynak bir uygulama gördüğümüzde kalitesiz ve ucube muamelesi yapıyoruz (Ve hatta lisanslı ürünlerin web sayfalarını inceleyip, aynı ürünün açık kaynak bir şekilde yapılamayacağına kendimizi inandırıyoruz)
2.Açık kaynağın bedava olmaktan öte paylaşımcı, sürekli geliştiren ve öğretici bir topluluk olduğunu anlamakta zorlanıyoruz.
3.Biz geliştirdiğimiz uygulamaları sanki dünyada kimse yazamazmış gibi, kodları kapalı ve lisanslı satmaya çalışıyoruz. (Tamam bu biraz fazla oldu, ama öyle)

Yukarıda yazdığım sonuçlar ile kimseyi suçlamıyorum..Sadece dünyanın yöneldiği trendi hala görmemekte ısrar ediyoruz. Benim vurgulamak istediğim nokta bu, Turgut Uyar gibi insanlar olmadığı sürece açık kaynak kodunun amacı ve gerekliliği de ülkemizde yayılamıyacak gibi.

Hmm tabi bunları söyledikten sonra şunları da ekleyeyim, OpenOffice kullanıyorum, Sun Server'lar üzerine Solaris 9 yerine OpenSolaris veya RedHat kuralım diye her fırsatta iddalı insanlar görüyorum. Firefox favorim. NetBeans ve Eclipse'ten daha iyi IDE'ler tanımıyorum. Projelerine baktığım Kaynak Kodların çoğu Subversion'da (Starteam'den geçtik) tutuluyor. Server ve scripting işlemleri Hudson/CruiseControl ve Ant kullanılarak yapılıyor, yazlım konusundaki tecrübelerini yakından takip ettiğim Sun'da ANT Scriptleri kullanan büyük firmalardan :) ve daha birçoğu....

Son olarak Linux Torvalds (bkz: http://en.wikipedia.org/wiki/Linus_Torvalds) tam bir efsane insandır, dikkatle tüm hayatı ve yaptıkları en otobiyografik detayında incelenmelidir, ilgisi olanlara..

Algorithms Book (Memory remains from Course: Analysis of Algorithms)

I just finished a fantastic book called "Algorithms", by Sanjoy Dasgupta, Christos Papadimitriou and Umesh Vazirani. Even better: this book is free and can be downloaded in PDF form.

At 300+ pages, it's not lightweight either, but the authors have done a fantastic job at explaining the main foundations of essential algorithms in simple terms that even developer who don't have a CS degree will find easy to read and to absorb. You will see a few mathematics formulas and proofs here and there, but you can safely skip them if you are not comfortable with them and just take away the very natural and friendly wordings that the authors never omit to make when they are trying to get you to understand the overall idea behind an algorithm.

The book is very extensive and covers the most important algorithms you will ever come across in your life as a developer, starting with the introduction of the "big O" notation, and then progressively moving to more complex topics such as graphs, dynamic programming (nothing to do with dynamic languages), linear programming and culminating this area with the Simplex algorithm (I loved this section).

I would consider the chapters that follow as a "second part" of the book (even though it's not structured as such) since they cover more advanced (and sometimes, still not completely understood yet) problems such as NP completeness and quantum programming.

A must-read for any developer who never got a chance to understand how all these algorithms work or who simply want to get a refresher...

And hats off to Sanjoy, Christos and Umesh for making such a great contribution to the computing world!

XML: Performans Katili - Another Performance Killer

XML teknolojisi yazılım dünyasının işlerini bir çok noktada kolaylaştıran ama bir o kadar da zorlaştıran bir teknoloji. Özellikle Java ile uygulama geliştiriyorsanız XML'den olabildiğince uzak durmak gerekiyor. XML parsing & generating operasyonları sırasında çok fazla String işlemi olduğu için JVM memory ve CPU kullanımı korkunç artıyor. XML'e performans diye boşu boşuna dememişler.

Bu yazımın esas amacı aslında Java uygulamarında XML kullanmanın getirdiği maliyetleri ve Dennis Sosnoski amcamızın meşhur XML Model Benchmark Test'lerini tanıtmak.

XML'in performance killer 'dan nasıl proje katiline dönüşebileceğine bakmadan evvel öncelikle neden uygulamalarımızda XML kullanmak zorunda kaldığımıza bir bakalım.

XML kullanımı, özellikle Java dünyasında Web Service'lerin yaygınlaşması ile artmaya başladı. Web Service kullanımını arttıran da hepimizin yakından bildiği SOA (Service Oriented Architecture) oldu. 2000'li yılların başında SOA'nın moda olmaya başlamasıyla, dünyaca ünlü vendor'larımız her zaman yaptıkları gibi bu kavramı da hemen suistimal etmeye başladılar. Bir metodoloji çok tuttuğunda vendor'larımızın ilk yaptığı şey, satabilmek için ortaya zorlama bir ürün çıkarmaktır. SOA'nın bu ürünü de Web Servis implemantasyonları oldu. Web Service ailesi (XML-RPC , REST, SOAP) içinde de en fazla öne çıkarılan SOAP mesajları oldu.

Halbuki SOA'nın felsefisinde tüm servis hizmetlerinin web servisler aracılığı ile verilmesi diye bir zorunluluk yoktur. SOA'da bir servise dış veya iç sistemden erişim ihtiyacı varsa öncelikle servis hizmetini veren (server) ile alanın (client) ortamlarına bakmak gerekir.

1. Durum Servis hizmetini veren ve alanın aynı java container'ında olması.
2. Durum Servis hizmetini verenin ve alanın farklı java container'larında olması
3. Durum Servis hizmetini verenin java fakat alanın farklı bir dile (ASP,C#,vs.) ait container'da olması.

1. Durumda istemci ve sunucu aynı JVM'de olduğu için zaten web servis kullanmaya gerek yoktur. Fakat dikkat edilmesi gereken konu, SOA'nın şartlarından biri olan servisler arası bağımsızlığın (loose coupling) korunmasıdır. Spring Framework 'unun da kullandığı Inversion of Control diye adlandırılan patterni bu duruma güzel bir örnektir.

2. Durumda istemci ve sunucu farklı container'da olmasına rağmen iki taraf da java olduğu için yine web servis kullanmaya gerek yoktur. İlk bakışta servis çağırmak için RMI kullanmak en mantıklı çözüm gibi gözüksede, RMI teknolojisinin http protokolü kullanmaması nedeniyle firewall ve proxy'lerde problem yaşaması, farklı java versiyonları kullanan istemci/sunucu mimarilerinde sorun yaşanması gibi sebeplerden pek tercih edilmemektedir.

Bunun yerine en mantıklı çözüm serialized java objects kullanmaktır. Serializable java nesnelerini aynı web servis mantığı ile örnekteki gibi byte array'e çevirip container'lar arasında http üzerinden transfer edebilirsiniz. Objelerin serialVersionUID 'lerini değiştirmediğiniz sürece JDK 1.3 - 1.5 arasındaki container'lar arasında bile servis çağırabilirsiniz. Serialization&DeSerialization, XML parsing'e göre çok daha hızlı, daha az memory kullanan, binary olduğu için daha az data büyüklüğü oluşturan bir işlemdir. Vakti zamanında yaptığımız testlerde özellikle büyük datalarda 30 kata yakın performans elde etmiştik. Eğer bu konuda daha yetenekli, productionda kullanmaya hazır bir API'ye ihtiyaç duyarsanız JBoss Remoting 'e bir göz atabilirsiniz.

3. Durumda istemci java'dan başka bir container olduğunda web servis kullanmaktan başka bir çare yok. Fakat bu konuda da alınabilecek önlemler var. Eğer standart web servis implementasyonlarından herhangi birini seçme imkanınız var ise SOAP'dan kesinlike uzak durun derim. SOAP çok genel amaçlar için tasarlanmış ve sistem performansını en çok düşüren bir XML protokolüdür.

XML'in sisteminizin performansına olan etkisini belirleyen 3 önemli unsur vardır:

1. XML'in yapısı

Varsayalım elimizde 100KB. büyüklüğünde 2 farklı yapıda XML dosyası olsun. Birincisinin ağaç yapısında varsayalım:

XML teknolojisi yazılım dünyasının işlerini bir çok noktada kolaylaştıran ama bir o kadar da zorlaştıran bir teknoloji. Özellikle Java ile uygulama geliştiriyorsanız XML'den olabildiğince uzak durmak gerekiyor. XML parsing & generating operasyonları sırasında çok fazla String işlemi olduğu için JVM memory ve CPU kullanımı korkunç artıyor. XML'e performans diye boşu boşuna dememişler.

Bu yazımın esas amacı aslında Java uygulamarında XML kullanmanın getirdiği maliyetleri ve Dennis Sosnoski amcamızın meşhur XML Model Benchmark Test'lerini tanıtmak.

XML'in performance killer 'dan nasıl proje katiline dönüşebileceğine bakmadan evvel öncelikle neden uygulamalarımızda XML kullanmak zorunda kaldığımıza bir bakalım.

XML kullanımı, özellikle Java dünyasında Web Service'lerin yaygınlaşması ile artmaya başladı. Web Service kullanımını arttıran da hepimizin yakından bildiği SOA (Service Oriented Architecture) oldu. 2000'li yılların başında SOA'nın moda olmaya başlamasıyla, dünyaca ünlü vendor'larımız her zaman yaptıkları gibi bu kavramı da hemen suistimal etmeye başladılar. Bir metodoloji çok tuttuğunda vendor'larımızın ilk yaptığı şey, satabilmek için ortaya zorlama bir ürün çıkarmaktır. SOA'nın bu ürünü de Web Servis implemantasyonları oldu. Web Service ailesi (XML-RPC , REST, SOAP) içinde de en fazla öne çıkarılan SOAP mesajları oldu.

Halbuki SOA'nın felsefisinde tüm servis hizmetlerinin web servisler aracılığı ile verilmesi diye bir zorunluluk yoktur. SOA'da bir servise dış veya iç sistemden erişim ihtiyacı varsa öncelikle servis hizmetini veren (server) ile alanın (client) ortamlarına bakmak gerekir.

1. Durum Servis hizmetini veren ve alanın aynı java container'ında olması.
2. Durum Servis hizmetini verenin ve alanın farklı java container'larında olması
3. Durum Servis hizmetini verenin java fakat alanın farklı bir dile (ASP,C#,vs.) ait container'da olması.

1. Durumda istemci ve sunucu aynı JVM'de olduğu için zaten web servis kullanmaya gerek yoktur. Fakat dikkat edilmesi gereken konu, SOA'nın şartlarından biri olan servisler arası bağımsızlığın (loose coupling) korunmasıdır. Spring Framework 'unun da kullandığı Inversion of Control diye adlandırılan patterni bu duruma güzel bir örnektir.

2. Durumda istemci ve sunucu farklı container'da olmasına rağmen iki taraf da java olduğu için yine web servis kullanmaya gerek yoktur. İlk bakışta servis çağırmak için RMI kullanmak en mantıklı çözüm gibi gözüksede, RMI teknolojisinin http protokolü kullanmaması nedeniyle firewall ve proxy'lerde problem yaşaması, farklı java versiyonları kullanan istemci/sunucu mimarilerinde sorun yaşanması gibi sebeplerden pek tercih edilmemektedir.

Bunun yerine en mantıklı çözüm serialized java objects kullanmaktır. Serializable java nesnelerini aynı web servis mantığı ile örnekteki gibi byte array'e çevirip container'lar arasında http üzerinden transfer edebilirsiniz. Objelerin serialVersionUID 'lerini değiştirmediğiniz sürece JDK 1.3 - 1.5 arasındaki container'lar arasında bile servis çağırabilirsiniz. Serialization&DeSerialization, XML parsing'e göre çok daha hızlı, daha az memory kullanan, binary olduğu için daha az data büyüklüğü oluşturan bir işlemdir. Vakti zamanında yaptığımız testlerde özellikle büyük datalarda 30 kata yakın performans elde etmiştik. Eğer bu konuda daha yetenekli, productionda kullanmaya hazır bir API'ye ihtiyaç duyarsanız JBoss Remoting 'e bir göz atabilirsiniz.

3. Durumda istemci java'dan başka bir container olduğunda web servis kullanmaktan başka bir çare yok. Fakat bu konuda da alınabilecek önlemler var. Eğer standart web servis implementasyonlarından herhangi birini seçme imkanınız var ise SOAP'dan kesinlike uzak durun derim. SOAP çok genel amaçlar için tasarlanmış ve sistem performansını en çok düşüren bir XML protokolüdür.

XML'in sisteminizin performansına olan etkisini belirleyen 3 önemli unsur vardır:

1. XML'in yapısı

Varsayalım elimizde 100KB. büyüklüğünde 2 farklı yapıda XML dosyası olsun. Birincisinin ağaç yapısında olduğunu,ikincinin ise tek nod'dan oluştuğunu varsayalım:
Herhangi bir XML parser ile (DOM, SAX, PULL farketmez) yukarıdaki aynı büyüklükteki 2 farklı yapıdaki dosyayı parse ettiğinizde çok farklı sonuçlar (hız, cpu ve memory kullanımı) elde ettiğinizi göreceksiniz. Birazdan bahsedeceğimiz XML Parser'in seçimi ile XML'in yapısı arasında çok yakından bir ilişki vardır.

2. XML'in büyüklüğü

XML data'sı büyüdükçe sistem performansı doğal olarak düşer. Fakat XML verisinin büyüklüğü ile sistem performansı arasındaki oran logaritmiktir. Bunun sebebi ise XML'in daha evvel bahsettiğimiz gibi çok fazla memory ve cpu kullanmasıdır. Bir JVM'de aynı anda çok fazla XML parsing işlemi olduğunda CPU bu işlemleri sıraya koymaya başlıyacak, sırada bekleyen XML nesneleri çok fazla memory kullandığından heap'i doldurmaya başlıyacak, JVM heap'in dolduğunu görünce sık sık GC (Garbage Collector) çalıştırmaya başlıyacak, GC çalışırken çok fazla CPU kullandığı ve tüm sistemi çalıştığı sürece suspend ettiği için tüm sistem tabir yerinde ise ağır çekimde ilerleyecektir. Tabii bu durum son kullanıcıya program çöktü olarak yansıyacaktır.

3. XML Model

Buraya kadar anlattıklarımıza rağmen data alışverişlerinde hala XML kullanmaya kararlı iseniz o zaman yapmanız gereken doğru XML parseri seçmek. Aynı zamanda bir SOA danışmanı olan Dennis Sosnoski 'nin eski ama hala meşhur XML Model Benchmark sonuçlarını incelerseniz, farklı test tipleri için meşhur XML API'lerin nasıl değişik test sonuçları verdiğini görebilirsiniz.

Ben genelde parser olarak çok daha hızlı olan ve az memory kullanan PULL parser'ları tercih ediyorum. Bu konuda size de XPP3 'i önerebilirim. Fakat son yıllarda VTD-XML isminde XML datasını String olarak değilde byte olarak işleyen çok hızlı bir XML parser ön plana çıktı. (world's fastest XML processor benchmark results).

Sonuç

Buraya kadar anlattıklarımızı özetlersek çok çok mecbur kalmadıkça konfigürasyon dosyası dışında XML kullanmayın derim. (Bu konfigürasyon dosyalarını okumak için de lütfen kendiniz bir API yazmaya kalkmayın, Apache Commons Configuration'ı kullanın.) Diyelimki çok mecbur kaldınız o zaman aşağıdaki önerilere kulak asmanızda fayda var:

1) SOAP'tan uzak durun ve XML'in yapısını oldukça basit tutun. XML'in yapısı ne kadar basit ise o kadar hızlı işlenir.
2) Farklı yapılarda XML veriniz var ise hepsi için aynı XML Model'ini kullanmayan. Hatta process etmeden evvel, XML'in büyüklüğüne ve yapısına bakıp en uygun XML Model'ini seçen generic bir API bile yazabilirsiniz.
3) Veri büyüklüğünün üst sınırını bilemediğiniz servislerinizi XML ile sunmayın ya da limit koyun. Test ortamlarında ortalama 100Kb.'lık datalar ile çalışırken, production'da bir servis sonucu 10MB.'lık bir XML oluşursa çok ciddi üzülürsünüz :)
4) XML operasyonlarını servisi hazırladığınız veya karşıladığınız katmanda yapın ve XML objelerini hemen basit java objelerine çevirin. Business metodları içine XML objelerini geçirmeyin.
5) Vendorların her söylediğine hemen kanmayın (hatta şüphe ile yaklaşın). Unutmayın onların hedefi daha fazla ürün satmak, sizin hedefiniz ise projenin başarılı olması.

Bu aralar AJAX'ın çok moda olması nedeniyle XML konusunda bir hatırlatma daha yapmak istiyorum. Bildiğiniz gibi AJAX 'da client/server arasındaki data alışverişini mecburen XML ile yapıyor. Developer'lar AJAX kullanırken XML yüzünden sisteme binen yükün farkında değiller. Konu açılmışken AJAX'a henüz giriş yapmayanlar Sezer Yeşiltaş'ın AJAX konusundaki blog'una bir göz atabilirler

Performans katili, projelerimizin katili olmamalı! Önümüzdeki projelerde de buna dikkat etmeliyiz!

Konuyla ilgilenmek isteyen hem .NET'ciler hem de JAVA'cılar için birkaç link vermek istiyorum:

Comparing Web service perfomances(1):
http://msdn2.microsoft.com/en-us/vstudio/aa700840.aspx

Comparing Web Service performances (2):
http://www.sosnoski.com/presents/cleansoap/comparing.html

Checklist Web Service performances:
http://msdn2.microsoft.com/en-us/library/ms979173.aspx

Ve Sun 'ın olaya yanıtı:
http://java.sun.com/performance/reference/whitepapers/WS_Test-1_0.pdf

Adobe Acrobat: Please Die!! (Expirence during old AMVG Internship days)

Don’t get me wrong, Adobe makes some fine products. But for the life of me, I think their programmers are insane.

Up until six months or so ago, I used Adobe Acrobat to view, edit, create, etc. PDF files. And what happens every time you open Adobe Acrobat? It takes 5 minutes to load all of it’s fancy schmancy dlls and plugins just so that I can view a friggin PDF!

“No more!” said I six months ago, “this shall not continue!”

So I downloaded Foxit Reader to view my PDFs in. All well and good. You may ask why I’m posting this now, six months after the fact. because even though I can view PDFs in Foxit (without the 5 minute wait for Adobe), I can’t create or edit them. So, I have to keep Adobe installed for that purpose. Luckily, though, the need to create a customized PDF happens somewhat rarely, and most of the time I can just use the Bullzip PDF Printer from MS Word or Publisher or whatever. Sometimes though, I need the more advanced features of Adobe. Such an event occurred this very eve. I needed to make a PDF form…

So, I launch Adobe Acrobat, go make myself a cup of coffee while I wait, and proceed to create said PDF. Easy peasy, no fuss, etc. All done. Close Adobe and get a terse message that Adobe needs to download critical updates.

Now, having experienced the Adobe update routine before, I wasn’t too keen about it. I declined the request to update.

But Adobe wasn’t done yet.

Not by a long shot.

An hour goes by, the customer is happy with their PDF, and I decide to relax with a short game of Hacker Evolution. Midway through level 3, the game minimizes to the task bar (it runs full screen) and Adobe asks again to be updated.

“No!” I shout, worried about the progress of my game which was interrupted. Accordingly, I click the button to dismiss the dialog and go back to my game (which paused automatically, thank goodness). I successfully finish level 3 in record time!

Okay, back to work. Now I’m writing a letter to a past due customer, asking them if they would be so kind as to pay their friggin bill. But wait! Adobe needs to install it’s updates right now!!

Now I’m irritated. I fumble through the dialog looking for the “Don’t ever ask me again, you stupid cow!” button. I know there is one; not visible, perhaps. In frustration, I click the “Download and Install Now” button. Big mistake.

So here I am 6,348 reboots later with a fully updated Adobe. Big whoop.

I summary, here are some questions for the Adobe Acrobat team:

1. Why the heck do you need to load every single possible DLL and plugin that you can think of just to view a friggin PDF?! Why!?
2. Why is Acrobat the only program in existence that requires the entire computer be restarted after every single update?! Even Windows Updates don’t need that, and they’re patching the ***-da**ed operating system. Do they need to reboot after ever update? NO! They need only one, big reboot after installing as many updates as were needed. Come on! If you can’t figure out a way to patch an application without restarting the OS each time, then you need to change careers; there is no place for you in the programmers’ kingdom.
3. Why, oh why, do you feel it necessary to insert your bloatware into every possible orifice of an OS? I don’t want nor need your program to load with Windows, consuming resources and calling home every day in case their are any updates.

Useful Links:
Foxit Reader For Windows, an excellent free PDF viewer.

And i do not expect to get a reply message from Adobe Team encouraging me for development to do a better product, My answer is ready: G me the source, i'll give you the best :)

There, I feel better now.