Çeviklik, Scrum ve Biz

Yazılım Mühendisliği

Çok komik. 🙂 Zaman zaman duyuyorum, IT yöneticilerinin “biz çevik sürece geçtik” ya da “artık çevik süreçler kullanıyoruz” gibisinden cümlelerini. Hemen şunu soruyorum ya da içimden geçiriyorum: “Daha önce neyi kullanıyordunuz ki???” 🙂 Öyle ya bildiğime göre taa Orta Asya’dan bu yana bizde kervan yolda düzülüyor. Yüzyıllardır zaten çevik hatta aşırı çevikiz. O kadar çok heyecanlıyız ve aklımız heyecanımıza o kadar çok yenik düşüyor ki birisinden bize bir iş yapmasını istediyip de bir süre sonra “düşünüyorum” cevabını alırsak çoğunlukla “düşünme yap” ya da “aptal mısın neyini düşünüyorsun?”  şeklinde laflar ediyoruz. İşin tuhafı, yazılım geliştirme gibi son derece soyut ve aşırı değişken çıktıları olan bir disiplinde de benzer şekilde kervanın yolda düzüldüğünü düşünmemiz. Tabi tüm bunlar birer kültür meselesi. Yazılım geliştiren ya da yöneten kişi, örneğin milli takımmızın Hollanda maçında bir mucize bekliyor. Zaten Çeklere karşı 3-2’lik mucizeyi de biz gerçekleştirmiştik. Olaylara bakışımız, toplumun hangi katmanından gelirsek gelelim aynı açıdan yani, sistematiklik yerine gelişi güzellik, takım yerine tek tek kişilerin kurtarma becerilerine odaklı, uzun vadede bir şeyleri yerleştirip başarmak yerine tamamen random, rastgele, ne zaman olacağı belli olmayan çıkışları beklemek. Yazılımı da bu şekilde ele alıyoruz genelde. Dolayısıyla diyorum ki bize sadece “çeviklik” değil “disiplin” de lazım. Bize “agility” değil “process-orientedness” lazım daha çok, yani kimin ne yapacağının belli olduğu, iyi tanımlandığı yazılım geliştirme süreçleri gerekli diye düşünüyorum.

Ne demek istediğimi bir örnekle anlatmaya çalışayım. 15 yılı aşkın süredir iş yazılımları geliştiren bir şirkete danışmanlık veriyorum. Zamanında bu şirketin yazılım müdürlüğünü de yaptığımdan 15 yılda nereden nereye geldiklerini çok iyi biliyorum. Ben şirketten ayrılırken 45-50 kişilerdi, şimdi ise 150’ye dayandılar sanırım. Sirketi zamanında kurup tırnaklarıyla kazıyarak bu noktaya getiren kişiler uzun süre haklı olarak programcılarının, müşterilerinin sorunlarını çözmekte sıklıkla yetersiz kaldıklarından şikayet eder ve problemi “proaktif olmamak” ya da en azından “inisiyatif almamak, alamamak” çekirdek davranışına indirgerlerdi. Tamamen haklılardı. Çünkü son derece çekirdekteki iş uygulamalarını geliştiren bu kurumun çalışanlarının müşterilerinin problemlerini çözmede “iki eli kanda olsa bile” şeklinde bir davranışa sahip olması, müşteri memnuniyeti açısından son derece önemliydi onlar için. Dolayısıyla “agile” davranarak işe başladılar. Simdi ise büyüdüler, “analist-programcı-proje yöneticisi-tester” düzeninden PMP sertifikasına sahip proje yöneticilerinden oluşan proje yönetim ofisine, yazılım mimari gibi rollere sahip bir development grubuna, 30 civarında analistin olduğu bir analiz grubuna, yeni oluşturulmakta olan ap-ayrı bir tester yapısına ve İK, Finans vb destek birimlerine sahip, ülkemiz standartlarında kocaman bir yazılım evi haline geldiler. Ve geldikleri noktada artık sistematik olmak zorundalar, kaliteye daha fazla önem veriyorlar, çünkü sektörlerinde bu ülkede lider oldukları gibi yurt dışına da açılmaya çalışıyorlar. Ve artık yöneticileri örneğin developerlarının müşteriden gelen bir hata bildirimine balıklama atlamalarını istemiyor. O hatanın kayıtlara geçmesini, gerçek sebebinin bulunmasını, gerekiyorsa analizinin yapılıp, etki ve maliyet gibi bilgilerin ortaya çıkmasını, o anı kurtarmak yerine daha sağlıklı bir çözüm üretilip, bu çözümün gerekiyorsa tüm müşterilerde yaygınlaştırılmasını hatta bir sonraki sürümün parçası olmasını ve en önemlisi de bu bilgilerin ilgili herkes tarafından bilinmesini istiyorlar. Bu yüzden developerin bu döngüye girmeden hatayı kendi başına halletmeye kalkmasının, nihayetinde, hata halledilse bile doğru bir davranış olmadığını, belki müşterisini memnun edeceğini ama şirketi açısından sürdürülemez bir davranış olacağını, yine müşteri odaklı ama daha sistematik bir çözüm döngüsü içinde olmak gerektiğini çalışanlarına anlatmaya çalışıyorlar. Çalışanlarının kariyer planları ve mutlu olmaları üzerine daha fazla kafa patlatıyorlar. Eskiden eğitim harcamaları ancak zorunluluk durumunda ve pek çok kısıtla yapılabilirken şimdi her sene San Francisco’ya JavaOne’a 4-5 çalışanını gönderiyorlar, çalışanlarını elde tutmak ve daha mutlu ve üretken kılmak için “yetenek yönetimi” çalişmaları yapıyorlar.  Çünkü artık çok daha zor bir yönetim problemiyle karşı karşıyalar. Sadece çevik olmak yerine sistematik çeviklik istiyorlar. Bu amaçla analiz olsun tasarım olsun ya da development olsun, nasıl bir sürece sahip olmaları gerektiği üzerine birlikte kafa yoruyoruz. Risk analizi, bütçe çalışmaları, yıllık eğitim planı vb. çalışmalar çok daha önemli hale geldi artık. Hala çevikler ama artık daha çok disiplinli bir çeviklik var.

Ote taraftan çevikliği yukarıda olduğu gibi kelime manasıyla almak yerine bir yönetim felsefesi ya da yazılım geliştirme paradigması olarak ele aldığımızda, yani “agile processes” ya da “çevik süreçleri” düşündüğümüzde, pek tabi olarak yukarıda kastettiğimiz çeviklikten farklı bir noktada durduğumuz aşikardır. Bunu da şöyle açıklayabiliriz: Çevik süreç kavramı bizim ülkemizde çıkmadığı gibi bu paradigma çerçevesinde oluşturulan metodolojilere bir katkımız da henüz olmadı. Çevik süreçlerin temeli, ozellikle ABD’de aşırı yapısal ve bürokratik, bundan dolayı hantal ve müşteriden uzak yazılım organizasyonları ve onların yazılım geliştirmeye yaklaşımlarına bir tepki olarak yayınlanmış Agile Manifesto‘ya dayanır. Tabi olarak bu manifesto bir günde yayınlanmadı. Eskiden bu yana yazılımın başarısızlık ve başarısının neye bağlı olduğu üzerine kafa yoran pek çok akademisyen ve uygulayıcı vardı. Bunların en iyi bilinenleri Barry Boehm ve onun spiral modeli ile Kent Beck’in Extreme Programming’idir. Benzer şekilde Jim Highsmith’in yazılarını, bu konudaki itirazları ve çözüm önerilerini okuduğumu hatırlıyorum. Bu anlamda 90lı yıllarda Unified Process gibi, yazılım projesini bir seferde bir big bang gibi kurmak yerine daha daha müşteri odaklı, mimariyi merkeze koyan ve riski önceleyen metodolojiler konuşulmaktaydı. Agile Manifesto da bu dünyanın babaları tarafından, ağır süreçler yerine insanları ve iletişimi, hantal ve okunmayan dokümanlar yerine yinelemeli ve artımlı (iterative, incremental) olarak geliştirilen, her an çalışır halde tutulan ve müşteri tarafından test edilebilen kod yapısını, müşteride analiz yapıp, “2 sene sonra kullanıcı kabul testinde görüşelim” diyen anlayış yerine, müşteriyle yakın ilişki içinde olan, onu da elini taşın altına koymanın en temel risk yönetimi olduğunu düşünen bir paradigmayı, proje planını kutsamak yerine değişimi nasıl yöneteceğini düşünen bir felsefeyi dünyaya duyurdu. Çok da iyi oldu, özellikle de bizim için. Neden? Çünkü bizim zaten genlerimizden, kültürümüzden, alışkanlıklarımızdan ve aşırı faydacı ve anlık yapımızdan dolayı çok daha uzunca bir müddet o hantal ve aşırı bürokratik yazılım geliştirme metodolojilerini uygulamamız mümkün değildi. Bu yüzden çevik süreçler, bu hantal süreçlere sahip yazılım evlerine dinamizm getiriken bize sistematiklik getirdi. Ne kadar sistematiklik? Tam olması gerektiği kadar bence? Fazlası değil, çünkü fazla sistematiklik bize göre değil. Bu anlamda çevik süreçler, bizim gibi bir kaç bin senedir çevik yaşayanlara disiplin sağlayor, ben de bu yüzden yukarıda “disiplinli çeviklik”i kullandım.

Agile Manifesto’ya imza atanlardan birisi de Jeff Sutherland aynı zamanda Scrum’ın da yaratıcısı. Yukarıda bahsettiğim o hantal yapıdan tamamen haberdar ve ona karşın daha çevik ama gerektiği kadar sistemli bir yazılım geliştirme yönetim metodoloji ortaya koymuş birisi. Scrum ülkemizde de yaygınlaşıyor ve ben buna çok seviniyorum. Bize disiplin getirirken damarlarımızda olan çevikliği ise övüyor ama onu sistematik olarak kullanmamıza imkan sağlıyor.

Bu blogun takipçilerinden olan bir dost ise bana gönderdiği bir emaille, Jeff Sutherland’in 16-17 Ocak 2014 tarihlerinde ülkemizde yapılacak Scrum Master eğitimi için İstanbul’da oalcağını hatırlattı. Scrum Turkey tarafından düzenlenen bu çalışmayla ilgili ayrıntılı bilgiye buradan ulaşabilirsiniz.

İçimizdeki çevikliğe zapt-u rapt vurmanın zamanı geldi de geçiyor bile 🙂

 

Toplam görüntülenme sayısı: 1227

Yazılım Projelerinde İhtiyaç Analizi – II

İş ve İhtiyaç Analizi, Yazılım Mühendisliği , ,

Bir önceki yazıda, “analiz” diye dilimize pelesenk ettğimiz kavram ve çalışmanın, aslında “iş analizi” ve “yazılım ihtiyaç analizi” diye bir ayırıma tabi tutulması gerektiğinden bahsedip, iş analizinin, bir yazılım sisteminden bağımsız olarak, işin sahibinin yani kurumun, işini süreç olarak sistematik bir şekilde bilmesi ve bunu formal olarak dokümanlarla ifade etmesidir demiştik. Var olan süreçlerin bu şekilde yakalanmasına “as is” analizi de denir. Sonrası iş süreçlerinin gittikçe daha verimli hale getirilmesi, yeniliklerin süreçlere dahil edilmesi gibi çalışmalardır. Verimli hale getirmekten kasıt da, iş sürecinde problemli olduğu düşünülen, hantallık yaratan vb. problem noktalarının bulunması ve bunların ya süreçten çıkarılması ya da iyileştirilmesi ve  sürecin gittikçe daha az kırtasiye üreten, yüksek performansta çalışan ve müşterilerini memnun eden hale getirilmesidir. İş süreçleri yönetimi (business process management) denen şey de temel olarak budur.

Dolayısıyla bir işin süreçlerinin sistemli olarak çözümlenmesine iş analizi (business analysis) denir. İş analizi, işin nasıl yapıldığına odaklanır ve

  • İş hedeflerini ve stratejilerini
  • İşin süreçlerini ve bu süreçlerdeki normal, alternatif ve sıra dışı akışları,
  • Bu akışları yönlendiren iş kurallarını, yani her türlü hesaplama, kısıtlama, tetikleme ve şart ifadelerini,
  • Süreçlerde bulunan insan rolleri ile bu rollerin sistem ile etkileşimini,
  • Süreçlerde iletişimde bulunulan yani entegre olunan diğer sistemleri, yani işin tüm insan olan ve olmayan tüm aktörlerini,

sistemli bir şekilde çözümler. Bu anlamda iş analizi, herhangi bir yazılım sisteminin varlığını zorunlu tutmaz, sadece işin yapılışına odaklanır

Eğer kurum, kendi süreçlerini bir yazılım sistemiyle daha etkin, hızlı vs. yapmak amacıyla otomatize etmek isterse, bu süreçler için bir yazılım alır, geliştirtir ya da kendisi geliştirir. Her halukarda, kurum, nasıl bir yazılım istediğini, süreçlerinin otomatize edilmesinden neyi kastettiğini detaylı olarak bir dokümanda belirlemelidir. Formal iş literatürüne RFP (request for proposal) olarak geçen bu doküman, yazılım ihtiyaçlarını son detaya kadar vermese bile ciddi bir seviyede yazılımdan beklenenleri, en azından özellik tabanında yakalamış olmalıdır.

Eğer bir kurum, kendi işini tanımlayamıyorsa, bu durumda ister satın alınsın ister geliştirilsin, işi otomatize edecek yazılım sisteminin, kullanıcılarının ihtiyaçlarına cevap verebilme şansı son derece düşük olacaktır. Bu yüzden genel olarak olan biten, böyle bir yazılım sistemi alınması ya da geliştirilmesi vesilesi ile bir miktar iş analizi yapılmasıdır. Tabiki bu çalışma, “iş analizi” niyetinden ziyade, bir yazılım sistemine yönelik olarak, o yazılım sisteminin ihtiyaçlarını anlamak niyetiyle yapılmaktadır. Bu durum çok tipiktir ve biz de bu durum üzerine, “hiç yoktan iyidir” diyerek sevinebiliriz.

Bazen de hakikatten bir iş süreci ya yoktur ya da çok ilkel ve kişiye bağımlı olarak vardır ve bir yazılım sistemiyle bu konunun otomatize edilmesi bekleniyordur. Dolayısıyla yukarıdakine benzer şekilde ama daha farklı bir durum olarak, sürecin kurgulanması da söz konusudur. Durum ne olursa olsun, yazılım projeleri çoğu zaman süreç kurgulamayı yani kuruma “bu işi artık böyle yapacaksın” demeyi de kendi içinde barındırıyor. Bu durumda risk, süreci kurgulayanların işe ne kadar hakim oldukları, kurumun stratejisini bilip bilmedikleri, biliyorlarsa bu stratejileri ne kadar sürece yansıttıkları gibi noktalara kayacaktır. Stratejiyi geçersek (önemsiz olduğundan değil ülkemizde böyle bir kavramın henüz çok da yerleşmemiş olmasından 🙁 ), süreci kurgulamanın ne kadar sağlıklı yapıldığından bahsetmek söz konusudur.

Doğru düzgün bir iş analizinin olmadığı ama buna rağmen bir yazılım sistemi geliştirmeye yönelik olarak yazılım ihtiyaç analizi yapmanın gerekli olduğu durumlarda, ilk ve en önemli olarak yapılacak şey, iş süreçlerini, akılda herhangi bir yazılım sistemi düşüncesi olmadan ele almak yani bulmak, detaylandırmak ve dokümante etmektir. “Akılda herhangi bir yazılım sistemi düşüncesi olmadan” sözünden de kasıt, ister veri tabanı ister kullanıcı arayüz detayları olsun, herhangi bir yazılım sisteminin varlığını düşünmeden, tamamen kullanıcı süreçlerine ve ihtiyaçlarına odaklı olarak, var olsun ya da henüz var olmayıp yeni kurgulanacak olsun, yazılım ile otomatize edilecek olan süreçlerin bilgisini yakalamaktır. Buradaki en riskli durum, iş analizi de bir yazılım sistemi geliştirme amacıyla yapıldığı için, geliştirilecek yazılımın detaylarına hızlıca girmek ve bundan dolayı var olan ya da tasarlanacak süreçleri yakalamada zorluk çekme riskidir. Bu da çok tipik bir durumdur. Odaklanılması gereken şey aslında, süreçlerin detaylarıdır, yani iş açısından “ne”yin olup bittiğidir. İşin akışı ve akıştaki adımlar, akışı yönlendiren iş kuralları, akışta üretilen, taşınan, işlenen ve saklanan veri, akışa müdahil olan roller, akışların birbirleriyle olan alış-verişi, öncelik-sonralık ilişkileri vb. noktalara odaklanıp, bunları doğru düzgün yakalamadan, yazılımın özellikle arayüzlerinin ve işlenen verinin tasarım ve gerçekleştirme detaylarına girmek çok sık rastlanan bir durumdur. Bu durum çok problemlidir çünkü aslolan işin nasıl olması gerektiğidir, kullanıcı arayüzü ve veri, ancak iş süreci tarafından belirlenebilir, tersinin olması, ya da belirlemenin tamamen arayüz ve veriden çıkılarak yapılması, süreçlerin sağlıklı yakalanamaması sonucunu doğuracaktır.  Böyle bir hedeften sapma aslında çok kolaydır, kolaycılıktır ve ortaya çıkacak yazılım sisteminin pek de fazla bir işe yaramayacağının da garantisidir.

Req. Ana. Humor

Ben gidip ne ihtiyaçları olduğuna bir bakayım, siz de bu arada kodlamaya başlayın!

 

Şimdi isterseniz yazılım ihtiyaç analizine biraz daha yakından bakalım. Benim yazılımı ilk öğrendiğim ABD’de ve uzun süredir yaptığım ülkemde, yazılım süreçleriyle ilgili en fazla ıskalanan, en fazla zorlanılan, kafa karışıklığının en fazla olduğunu düşündüğüm alan yazılım ihtiyaç analizi ya da daha kısa ifadeyle ihtiyaç analizidir. Proje yöneticileri, programcılar, sistem yöneticileri gibi rollerde çalışanlar, ne yaptıklarını daha formal bir şekilde ifade edebilirlerken, benim tecrübeme göre ihtiyaç analistlerinin yaptıklarını formal yollarla tanımlayabilenlerine pek az rastladım. Bir başka yazımda da anlattığım ve cok sık yaşadığım tecrübemi burada da tekrarlayayım:

İş görüşmelerinden bir sahne bu. Ben, “Yazılım İhtiyaç Analisti” ilanına başvuran, muhtemelen Endüstri Mühendisi, 10 küsür yıl analistlik tecrübesi olduğunu söyleyen kişiye soruyorum, “nasıl iş analizi yapıyorsunuz?” diye. Cevap veriyor: “İşte, müşterimiz iç müşteri oluyor her zaman. Onlardan istek geliyor. Gidip görüşüyorum onlarla, sonra görüşmeden çıkardıklarımdan bir Word dokümanı oluşturuyorum. Ayrıca PowerPoint’de ekran tasarımı yapıyorum.” “Peki” diyorum içimden ve soruyorum kendi kendime: Burada “analiz” nerede? PowerPoint ile yapılan şeyin analiz olmadığı kesin çünkü zaten adında “tasarım” var. Geriye kalıyor “Word dokümanı”. Oradan birşeyler çıkarmaya çalışıyorum, çünkü adayın anlatımından “Word dokümanına yazılan şey, iş analizidir” ya da “cümleleri, analitik yapan şey, onların bir Word dokümanına yazılmış olmasıdır” (!) şeklinde birşey çıkıyor. Soruyorum,” o Word dokümanındaki temel kısımlar, başlıklar nelerdir?” Ya da “herhangi bir diyagram çiziyor musunuz” diye, ama nafile. Tek derdim, “iş analisti” olarak çalışan arkadaşımızın zihninde “iş” ve “analiz” ile ilgili bir kırıntı var mı onu anlamak. Belli ki iş analisti olarak çalışan herkes kendine göre bir “analitik” 🙂 süreç izliyor. Ve Word dokümanına yazılan şeyler bir şekilde “analiz” oluyor ama dokümanda herhangi bir yapısallık bile yok. Çünkü aday, dokümandaki başlıklardan bile bahsederken sıkıntı çekiyor. Halbuki merak edip, 10 senedir yaptığı iş ile ilgili kendini geliştirmeye çalışsa, Internet’te tonla kitap, makale, şablon vs. bulabilir.

Hadi bu çok uç bir örnek diyelim ama yine de bu konuda konuşan kişilerin kullandıkları kelimelere bakarak bile sahip oldukları kafa karışıklığını anlayabilirsiniz. En temel kafa karışıklığı, bu ve bir önceki yazıda açıkladığım ayırımı ıskalamaktan kaynaklanıyor. İş analistliği başka yazılım ihtiyaç analistliği başkadır.  Bir başka kafa karışıklığı analiz ile tasarım arasındaki fakla ilgili. Analiz, “ne” sorusuna cevap arar, “ne istiyoruz?”, tasarım ise “nasıl” sorusuna cevap arar, “nasıl olmasını istiyoruz?”. Bunlar o kadar ayrı iki sorudur ki, birbirlerine karıştırılmasının bedeli pahalı olur.

Toplam görüntülenme sayısı: 3199

Java Persistence API

Java, Java EE

Java Persistence API ya da kısa adıyla JPA, Java EE’nin bir parçası olarak belki, EJB’lerden sonra JSF ile birlikte en ilgi çeken ve kullanılan parçası. Bunu genel olarak iki sebebi var: Ilki tabi olarak Java’nın yayılmasına paralel olarak gelişen nesne-ilişkisel eşleştirme (object-relational mapping, ORM) ihtiyacı. Diğeri ise Java EE 5’nin parçası olarak yayımlanan EJB 3.0’ın içinde yeni bir bileşen olarak çıkarılan JPA 1.0’ın, standart Java EE yapısı içerisinde nesne-ilişkisel eşleştirme problemini nihayetinde daha sancısız ve sağduyulu olarak çözmeye niyetlenmiş olması. Bu durumu, nesne-ilişkisel eşleştirme araçlarının kısa tarihi olarak burada ve burada anlatmıştım. JPA ile geç de olsa bu problemin hal yoluna konulmuş olması güzel bir gelişme.

Ben de JPA’yı sevdiğim için bu konuda bir kitap projesi başlattım. Kitabı yazdıkça www.jpabook.com adresinden, online olarak paylaşacağım. Sadece kitabın bölümlerini değil, aynı zamanda kod gibi ek malzemeleri de buradan paylaşacağım.

Bu kitap temelde benim ve çevremde bana yardımcı olan arkadaşların bir çalışması olarak ortaya çıkıyor. Ben yazıyorum, arkadaşlarım da okumaları, gerekli ekleme, düzeltme vs. yapıyorlar. Ayrıca kodları gözden geçiriyorlar, şeytanın avukatlığını yapıp, benim saçmalıklarıma itiraz ediyorlar 🙂 Dolayısıyla bir grup çalışması oluyor bu kitap. Bu ülkede pek görülen cinsten bir şey değil. Gerek ortaya çıkış şekli gerek ise kalitesi açısından çok farklı olacağına inanıyoruz.

Okumak, en azından eleştiri ve taktirlerinizi iletmek hatta katkıda bulunmak için sizi www.jpabook.com adresine davet ediyorum 🙂

 

Bol JPA’lı günler dilerim.

 

Toplam görüntülenme sayısı: 1475

Karasızlar İçin Mac Kılavuzu

Diğer , , ,

Sıklıkla “Macler nasıl?” ya da “yeni bir laptop almak istiyorum, Mac’e mi geçeyim?” hatta “Java developer olarak Mac kullanabilir miyim?” gibi sorulara muhatap oluyorum. Yine bir Javacıyla sohbette konu açılınca artık bu soruları bir yazıyla cevaplamak şart oldu.

Öncelikle ben kendi tecrübemi kısaca özetleyeyim: Ben 80’li yilların tam ortasında, dokunmatik yeşil ve küçük ekranlı HP makinalarda Fortran yazarak çalışmaya başladım. Daha sonra PCler gelişti ama ben gelişemedim 🙂 PClere tekrar dönmem 90’ların ortasını buldu. Çünkü o arada yoğun bir şekilde Sun ve HP makinlarda Unix ile çalıştım. C/ C++ ve hatta Java’yı bile ben bu makinalarda, Unix üzerinde öğrendim. PClerle tekrar çalışmaya başladığımda Windows’un 3.0-3.1 sürümleri vardı sanırım. Yurt dışında üniversitedeyken ödev-sunum vs. yapmak için de üniversitenin Mac lablarını kullanırdım. Daha sonra Windows’un hemen her sürümünü kullandım ama sanırım en rahat ettiğim XP idi.

Özellikle Türkiye’ye döndükten sonra, zaten Unix’de çalışma ortamı bulmak mümkün değildi ve geliştirme ortamı olarak devamlı Windows kullanırken, sıklıkla Linux severlerin tacizine uğruyordum 🙂 Bu ülke zaten benim gibi çok tutkulu bir ülke. Herkes beğendiği şeyi diğerlerine de kabul ettirmeden rahat etmiyor 🙂 Ama ben direndim Linux’e, çünkü vaktimin ciddi miktarını Linux’un ayar ve düzenlemeleriyle geçirmemeliydim. Cünkü ben bir yazılımcıydım ve hangi ortam sorunsuz olarak benim amaçlarıma hizmet  ediyorsa onu tercih ediyor ve alt yapıyla vakit kaybetmek istemiyordum.

Derken biraz iPhone biraz da Apple’in daha makul fiyat stratejisi izlemesi ve en çok da yurt dışında üniversiteye başlayan oğlumun kullandığı MacBook Pro’ya hayranlığından etkilenerek, 2011 yılında 13 inchlik bir MacBook Pro aldım. Intel i5 işlemci ve 4 GB’lık RAM’i ile ilk Mac’im başlarda beni çok yordu. Kısa yollara alışırken, ne bileyim örneğin print screeni nasıl yapacağımı ögrenirken kendimi spastik hissettirmesine rağmen, son derece eğlenceli parmak hareketleriyle kontrolleri beni eğlendirdi. Java nereye kuruluyor, classpathi nasıl ayarlarım gibisinden daha terminal tabanlı işlemler için bir miktar tırmalayıp, eski Unix bilgilerimi hatırlamam gerekti tabi ki ama çok uzun sürmedi, kısa sürede diğer yeni Mac kullananlara bir şeyler anlatırken buldum kendimi. Bu Mac üzerine Oracle’ın yazılımcılar için çıkardığı Linux paketlerinden birini de kurdum, dolayısıyla Oracle XE, WebLogic vb. yazılımları, Macimdeki Linux kurulumu üzerinde kullanır hale geldim. Yaklaşık 1 senelik 13 inchlik MacBook Pro deneyimimden sonra ABD’ye gittiğimde kendimi, 15 inchlik retina ekranlı, i7 işlemcili, 8 GB RAM’li ve CD sürücüsü ve hard diski olmayan, 512 GB SSD’li nefis bir Mac’e terfi ettirdim 🙂 Simdi 20 küsür senelik bütün bir Unix, Windows, Linux macerasından sonra Mac ve Mac OS bana nasıl geldi derseniz, “nefffiiissss” derim. Bir PC bu kadar mı kullanışlı olur, bir sistem bu kadar mı rahat olur, bir ortam bu kadar mı güvenilir olur? Windows’da sağ tık yaparak çıkan “New” listesi Mac’de yok, ilk başlarda beni deli etmedi değil. Ama hem alışma hem de bulduğum “New File” gibi ufak tefek yazılımlarla sıkıntımı giderdim açıkçası. En çok da sistemin performansı, tıkanma ve donmaların olmayışı, mesela çalıştırdığım yazılımların kaynakları emip bitirme problemini hemen hiç yaşamamış olmam gibi noktalar, yedekleme, ses ve görüntü kalitesi, kullanım rahatlığı açısından bana mükemmel bir tecrübe yaşattı. Yanlış hatırlamıyorsam iki seneye yaklaşan Mac tecrübemde sanırım bir ya da iki defa Mac’i shut down’a zorladım. Olay bu işte 🙂 Sorunsuz bir PC isteyenler bence Mac’i çok ciddi bir alternatif olarak düşünmeliler.

Peki Mac’i alternatif olarak düşünenlerin önündeki seçenekler nelerdir? Seçenek derken tabi olarak laptopları kastediyorum. Apple’ın şu anki Mac laptoplarında temelde 2 farklı serisi var: MacBook Air, MacBook Pro. MacBook Air, diğer seriye göre daha kısıtlı computing gücüne ihtiyaç duyanlar için birebir. Yani örneğin laptopunuzu temel yazım, sunum gibi doküman oluşturma ve okuma ile emailleşme, Internet’te gezme, müzik dinleme ve film izleme gibi daha genel amaçlar için kullanacaksanız MacBook Air bence birebir. 11 ve 13 inchlik seçeneklere sahip MacBook Air’in ufak modeli sadece 1 kilo ağırlığında. Batarya ömrü olarak zaten çok iyi rakamlara sahip olan Mac laptoplarından MacBook Air olanlar aynı zamanda 512 GB’a kadar flash depolamaya da sahipler. Hem i5 hem de i7 dual-core işlemci seçeneğine sahip olan bu tüy ağırlığındaki laptopların 1.3 GHz’lük i5 işlemcili, 4 GB RAMli ve ve 256 GBlık flash bellekli modellerinin ABD fiyatları, 11 inch ekranla $1199, 13 inchlik ekranla $1299. 13 inchlik MacBook Air’i, 1.7 GHz’lük i7 işlemci, 8 GB RAM ve 512 GB flash bellek ile donatırsanız fiyatı $1849 oluyor.

Daha güçlü Mac laptop isteyenler için MacBook Pro var. MacBook Pro daha güçlü çünkü hem RAM’i 16 GB’a kadar arttırılabiliyor, hem sadece dual-core değil aynı zamanda quad-core modelleri de var ve işlemci frekansı Mac Book Air’lere göre daha fazla. 13 ve 15 inchlik modelleri olan MacBook Pro’nun ekranı retina olan MacBook Pro Retina Display modelleri de var. 2.3 GHz’lük dual-core i7 işlemcili, 4 GB RAMli, 500 GB hard diskli 15 inchlik MacBook Pro, ABD’de $ 1799. Bu makinanın ekranını retina, işlemcisini 2,7 GHz’lük quad-core i7, RAMini 16 GB ve hard diskini de 512 GBlık flash SSD ile değiştirirseniz fiyatını $2799 yaparsınız 🙂 Bu modelin retina olan ekranı, 2880*1800 piksellik bir görünüm sağlıyor 🙂 Bu büyüklükteki bir laptopun ise sadece 2 kg olması ayrı bir avantaj. Bu model, computing açısından en güçlü Mac laptoptur.

Java ile programlama yapanlar açısından değerlendirmek gerekirse, MacBook Pro’da hemen her IDE çalışıyor. En fazla kullanılan Java geliştirme ortamlarından Eclipse, Netbeans, IntelliJ Idea benim makinamda kurulu örneğin. Mac üzerinde JDK’in en yeni 1.7 sürümü yanında eski sürümleri de kurulabilir. 64 bitlik HotSpot JVM ile gelen Mac JDK’sı, quad-core i7 işlemci üzerinde son derece hızlı çalışıyor. Java EE geliştirme yapmak isteyenler için Glassfish eski sürümleri yanında, Java EE 7 için en son 4 sürümüyle kullanımınıza hazır. Tomcat vb. pek çok web sunucusu da Mac üzerinde kullanılabilir. Arzu eden JBoss’u da Mac üzerinde kullanabilir. Ben daha önceki MacBook Pro laptopumda, Oracle’in hazır Linux paketini kurmuş ve üzerinde hem Oracle XE veri tabanını hem de WebLogic uygulama sunucusunu çalıştırmıştım. Isteyenler için Internet’te Mac üzerine hem WebLogic hem de Oracle XE veri tabanı kurmak için yol gösterenler var. Ben egitim amaçlı olarak üzerine Linux kurmadan Mac ile rahatlıkla çalışabiliyorum. Veri tabanı ihtiyacım için hem JDK 1.7 ile gelen Java DB ya da Apache Derby veri tabanı, hem de MySQL yeterli. Bu anlamda Mac laptopların, işte bir geliştirme ortamında çalışmak için ancak biraz üzerinde çalışma ile uygun hale gelecek olmasına karşın, evdeki bilgilenme, ufak-tefek proje geliştirme ve günlük kullanım için mükemmel olacağını düşünüyorum. Mac üzerinde WebLogic ya da Oracle DB gibi kurumsal yazılımlar çalıştırmak isterseniz temelde üç tane yolunuz var: Ilki, bu yazılımları Mac üzerinde kurmaya çalışmak. Bunun için webden yardım almanız gerekli. İkincisi, Mac üzerine kuracağınız Linux ile bu problemi çözebilirsiniz. Yukarıda ilgili linki vermiştim. Üçüncüsü ise bu yazılımlar yerine özellikle ögrenme amaçlı ise Glassfish, MySQL gibi alternatiflerini kullanmak. Yok zaten C/C++ geliştirme yapacaksanız zaten bu sıkıntılar pek olmayacaktır. Ya da iOS gibi ortamlar için Objective C ile geliştirme yapacaksanız zaten tek alternatifiniz Mac olacaktır.

Geliştirme yanında eğer benim gibi makinasıyla beraber yatıp kalkanlardansanız Mac size çok iyi gelecektir. Eğer müzik dinlemeye ve kaliteli sese meraklıysanız, fotoğraf, film vs. ile uğraşıyorsanız, hem Mac’in yetkinlikleri hem de eğer retina ekrana sahipseniz, nefis görüntü ve ses kalitesi size makinanın başında çok keyifli zaman geçirtecektir. Eğer iPhone kullanıcısı iseniz, çok entegre bir sistem oluşturduklarından, Mac kullanmanın faydası daha da artacaktır.

Toplam görüntülenme sayısı: 8197

«< 50 51 52 53 54 >»