Çevik modellemenin başlıca özelliği veri modelleri ve ara yüzü modelleri gibi modelleme tekniklerinin neler olduğunu ve bunların ayrıntılarını söylemek yerine bu tekniklerin nasıl uygulanması gerektiğini söylemesidir. Mesela; yapılan projelerin test edilmesi gerektiğini belirtse bile nasıl test hazırlanacağına değinmemesi gibi. O sadece bir yöntemler biçimidir ve bir projenin etkili,hızlı bir şekilde ortaya çıkarılmasında, müşterinin ihtiyaçlarını karşılamasında ve aynı zamanda da her türlü değişikliğe kolayca adapte olabilmesinde geliştiricilere yol gösterir.

Ayrıca  Hızlı bir geliştirme sürecine sahip, kaliteli ürünlerin ortaya çıkması için uygulanan bir geliştirme yöntemidir. Agile geliştirme yöntemlerinde en önemli sonuç kriteri müşteri memnuniyetidir. Asıl amaç müşteriyi memnun eden bir ürün ortaya koyabilmektir. Ortaya çıkan ürünün çalışan ve müşterinin ihtiyaçlarını tam olarak karşılayabilen bir ürün olması en temel amaçlardan biridir.

Hangi Durumlarda Kullanılabilir?Bu metotların kullanılmasının en uygun olduğu durumlar şunlardır:

•Projenin yazılım evresinde müşteriden gelebilecek talep değişikliklerinin tahmin edilemez olması

•Projenin parçalarının önce tasarlanıp ardından hemen geliştirilmesinin gerekmesi ve önceden ne yapılacağını, detaylı yol haritasını ve tasarımını tahmin etmenin çok güç olması

•Analiz, tasarım ve test etme süreçlerinin ne kadar zaman alacağının önceden bilinememesi

•Yazılım ekibinin birlikte çalışmak, hiyerarşiye önem vermemek, sağlam iletişim kurmak gibi özelliklere sahip olması

Elbette bazı durumlarda çevik programlamadan vazgeçilmesi gerekebilir. Örneğin; çok kişinin dahil olduğu projelerde çevik metotlar ile proje geliştirmek mümkün olmayabilir ya da aynı yerde bulunmayan takım arkadaşları ve hiyerarşik yapının her an hakim olduğu şirket ortamlarında klasik yöntemler daha uygun olabilir. Zaten, düşünülenin aksine, bu metotları kullanarak programlama ve modelleme yapılmasını öneren insanlar bu gibi durumlarda klasik yöntemlerin kullanılmasına karşı değildir.

Çevik programlama metotlarının özellikleri:

Çevik metotlar tam bir yazılım süreci değildir ama kapsamlı yazılım geliştirme yöntemlerini tamamlayıcı niteliktedir. Başlıca çevik süreç modelleri:

•Sınırsal programlama(Extreme Programming-XP)
•Çevik Birleştirilmiş Süreç (Agile Unified Process)
•Scrum
•Test Güdümlü Geliştirme (Test-driven Development)
•Çevik bilgi Metodu (Agile Data Method)
•Özellik güdümlü geliştirme (Feature-Driven Programming)

Çevik (Agile) Programlama Süreci

Çevik yazılım geliştirme, takım çalışmasını desteleyen liderlik vasıflarını, sorumluluk alabilme ve kendi kendini organize edebilme özelliklerini ve nitelikli ve yeterince hızlı yazılım geliştirmeye yarayan mühendislik uygulamalarını destekleyen proje yönetim sürecini kapsar. Bu yönetim süreci hem müşteri taleplerini hem de şirket amaçlarını düzenleyerek olumlu  bir geliştirme ortamı ve yaklaşım sunar.

Çevik modelleme işleri kısa vadeli planlar ve küçük gelişmeler halinde yapmayı uygun görür. Kısa vadeli planlar yineleme (iteration) olarak bilinir. Her yineleme sürecinde belli bir takım yazılım ya da modelle üzerinde çalışır ve bu süreç planlama, talep analizi, tasarım, kodlama, birim testi ve kabul testi gibi süreçleri kapsar. Yineleme süreci değişikliklere uyum sağlamayı kolaylaştırırken genel riski de azaltır. Tek bir yineleme bir ürünü piyasaya sürmek için ona yeterli işlevsellik katmayabilir ancak amaç her yineleme sonunda en az sorunla çalışan mevcut bir sürüm elde edebilmektir. Bir ürünü sürüm olarak piyasaya sürmek ve yeni özellikler eklemek için birden çok yineleme gerekir.

Çevik programlama ve modellemede dokümantasyon da yapılır. Ancak dokümantasyon ürünün kullanılabilirliği ve verimliliğinin önüne geçmez. Aksine dokümantasyon sadece gerekli görülen yerlerde yapılır. IBM ’de çalışan ve aynı zamanda da “Effective Practices for Modeling and Documentation” kitabının yazarı olan scott ambler’e göre; geliştiricilerin tahtada yazıp çizdikleri modeller uzun uzadıya yazılan dokümanlardan daha kullanışlıdır ve insanların aylarca dokümantasyon yapmasının önlenmesi gerekmektedir.

Çevik projedeki takım yapısı çoğunlukla iş değişimine dayanan ve kendi kendini organize eden bir yapıdır. Firma içindeki hiyerarşik durumlar takım içinde göz ardı edilir ve çalışmalar bu şekilde yürütülür.
Bir çok projeden insanlar daha ilerideki işler için önceden çalışmaya başlarlar. Örneğin; gelecekte yapılacak işler için karmaşık altyapılar geliştirmek ve modelleme yapmak. Bu durum çok büyük bir zaman kaybına yok açar ki, taleplerde bir değişiklik olması durumunda bu çalışan insanlara fazladan emek ve iş gücü olarak geri döner. Çevik modeller ihtiyaç olmadan herhangi bir şeyin yapılmasına ve boşa zaman kaybedilmesine karşıdır.

Proje aşamasında test süreci, önemli bir yer kaplar. Tüm testlerin son ana bırakılması yanlış anlaşılmaların projeyi çok farklı yerlere götürmesine sebep olabilir. Henüz yapım aşamasındayken, yapılan kısmı farklı kişilerin test edip geri bildirimde bulunması, bu açıdan hayati bir süreçtir. Bu sayede yanlış henüz yeni yapılmışken tespit edilip ortadan kaldırılır. Çevik programlama ve modelleme geliştiricilerin her an yan yana bulunarak bu iletişimde olmasını ve aynı zamanda da müşteri ile iletişim içinde bulunmasını öngörerek bu sorunu aşar. Kabul testleri ise müşteri tarafından en son aşamada yapılacak testlerdir. Burada geri dönülen hatalar yeniden modellemeye aktarılabilir. Çevik modellemede en son yapılan değişiklikler bile olumlu karşılanır.

Agile Yazılım Geliştirme’de, takım çalışması,güven,iletişim gibi insanlar ile olan etkileşim çok önemli. Sürekli bilgi alışverişi ve beyin fırtınalarına dayanan bir geliştirme süreçi olduğundan bu kavramların bilincinde olmak geliştirme sürecine artılar katabiliyor. Geliştirme sırasında ya da öncesindeki analiz kısımlarında sürekli yüz yüze bir iletişim ile gereksinim ve ihtiyaçların sürekli üzerinden geçilmesi daha sağlıklı sonuca ulaşmak için kaçınılmaz ihtiyaç.

Agile yazılım geliştirme süreçlerinde her zaman çalışan bir yazılım aranan bir kavram. Zaten soyut kavramlardan oluşan yazılım dünyası, bu dünyaya uzak olan müşteri için pek bir şey ifade etmeyecektir. Bu yüzden bazı şeyleri biraz daha somutlaştırmak adına çalışan bir yazılım her zaman aranan bir kavramdır. Uygulamaların nasıl çalışacağına ya da ne yapacağına dair uzun ve karışık dökümanlardan çok müşteriye çalışan bir uygulama göstermek her zaman daha faydalı olacaktır.

Agile’ın altını çizdiği bir başka husus da müşteri ilişikileri.Belli bir sözleşme yerine sürekli müşteri ile işbirlik halinde olunmasının daha faydalı olacağı manifestoda söylenen diğer bir şey. Müşterinin ihtiyaçlarını sürekli sorgulamak ve işi onunla beraber yapmak ortaya çıkacak ürünün kalitesi adına önemli bir nokta. Bu noktada, ihtiyaçların sürekli sorgulanmasından dolayı da ortaya çıkacak değişiklik taleplerine de açık olmak gerekmekte.Bu değişikliklerin yönetilmesi sayesinde ürünlerin canlılığı ve tam olarak ihtiyaca uygun olması sağlanabiliniyor.

Tarihçe

Uygulanabilir bir yazılım geliştirme süreci ilk önce 1974 te Edmonds tarafından kaleme alınmıştır. Bundan sonra daha çok yeni bir yöntem olan çevik yazılım geliştirme ve modelleme 1990ların ortasında diğer (“heavyweight”) zor uygulanan, aşırı kuralcı waterfall model tipi geliştirmeye tepki olarak ortaya çıkmıştır.  Bu tip bir gelişim modelinin usta yazılım geliştiricileri için fazlasıyla bürokratik, yavaş ve tutarsız olduğu düşünülmüştür. Bunun üzerine bu süreci hızlandırıp kolaylaştıracak çevik metotlar  hafif metotlar -“lightweight methods” olarak ortaya çıkmıştır. Daha sonra 2001’de, yazılımın önde gelen isimleri Snowbird Utah’ta buluşarak bu metotlara çevik metotlar -“agile mehtods” – ismini vermişlerdir. Aynı kişiler “Agile Alliance” diye kar amacı gütmeyen ve bu sistemin gelişmesine destek veren bir organizasyon kurmuşlardır.
En önemli çevik programlama süreçleri Clear, Exreme Programming (XP-1996), uyarlanabilir yazılım geliştirme, özellik bazlı gelişim ve DSDM’dir (1995). Bunlar çevik  yöntembilimleri olarak 2001’de yayınlanan Çevik Yazılım Yaklaşımı Manifestosu’nu yayımlamışladır.

Çevik program geliştirme alanındaki önde gelen 17 isim 2001 yılında Snowbird, Utah’ta buluşarak bir yazılımı nasıl daha hızlı, basit ve insan merkezli yaratabileceklerini tartışmışlar ve sonucunda imzaladıkları manifesto ile  bu süreci anlatmışlardır. Bu manifestoyu imzalayanlar Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas’tır.

Bundan sonra 2005 yılında ise Alistair Cockburn ve Jim Highsmith yönetim uzmanlarını toplayarak bu manifestoya bir ek yazmıştır. PM Decleration of Interdependence adı verilen bu manifesto 6 madde ile Çevik Yazılım Yaklaşımı Manifestosu’nu günümüze daha iyi uyarlanabilir hale getirmişlerdir.

Çevik Metotların Prensipleri:

Yukarıda isimleri geçen topluluk, manifestoda,  nasıl daha iyi bir yazılım geliştirdiklerini ve bunu yapmak isteyenlere yol gösterecek maddeler listelemişlerdir. Genel olarak kabul edilen yöntem 4 maddede sıralanabilir:

•Bireyler ve onlar arasındaki etkileşimi süreç ve araca tercih etmek
•Çalışan bir yazılımı detaylı bir dokümantasyona tercih etmek
•Müşteri ile işbirliğini, anlaşma görüşmelerine tercih etmek
•Değişikliklere istenildiği anda cevap verebilmeyi sınırları belirli bir plana tercih etmek

Agile manifestosunun ardındaki başlıca ilkeler ise:

•Hızlı, devamlı ve kullanışlı yazılım üreterek müşteri memnuniyeti sağlamak amaçlardandır.
•Çalışan yazılım gelişimin en önemli ölçüsüdür.
•Taleplerdeki geç değişikliklerin de memnuniyetle karşılanır.
•Yüz yüze görüşme iletişimin en güzel yoludur.
•Geliştiriciler ile iş adamları arasında günlük ve yakın işbirliği bulunmalıdır
•Basitlik önemlidir. (Yada sadellik güzelliktir)
•Kendi kendini organize eden takım yapısı gereklidir.

Çevik Metotların Diğer Metotlardan Farkı:

Çevik metotlar bazen planlı ve disiplinli olmaması ile eleştirilse de bu doğru değildir. Açıklamak gerekirse; bir projenin ortaya çıkarılmasında 2 tip metot kullanılabilir. Biri uyarlanabilir olan, bir diğeri de tahmin edilebilir olandır.  Değişime tepki verebilecek şekilde tasarlanmıştır. Mesela, projenin gereksinimleri değişirse, projenin takımı da bu değişikliğe ayak uydurur ve değişir. Bu takım bize 1 hafta sonra hangi işlerin yapılacağını söyleyebilir ancak 1 ay sonra ne yapacaklarını belirtemez. Yani  projede planlanan tarih ne kadar uzaksa o tarihte yapılacak işler de bir o kadar belirsizdir. Tahmin edilebilir olan metotların takımları projenin tamamlanma süresi içindeki tüm değişikliklerin ve gelişmelerin tarihini önceden bilir, bu plan çerçevesinde iş yapar. Değişiklik olduğunda tüm plan iptal olur ve yeni bir program yapılır. Yeni programda ise sadece en önemli olan değişikler seçilip projeye dahil edilir. Çevik metotlar uyarlanabilir olanlara dahildir. Yani değişime açıktır ve uyarlanabilirdir. Uyarlanabilir olduğu için bu kadar net bir şekilde planlanmayan proje müşterinin isteklerine göre şekil alır ve istenilen başarıyı gösterir.

Çevik metotların bir diğer özelliği de; diğer yinelemeli geliştirme metotlarında (iterative development methods) zaman dilimi ay olarak alınırken, çevik metotlarında bu süre haftaya kadar düşer. Bu kısa süre içinde küçük ilerlemeler şeklinde ve her adımda müşteriden geri bildirim alınarak yazılım ortaya çıkarılır.

Günümüzde kullanılan bir diğer model de Waterfall modelidir. Waterfall modeli 2008  yılında dahi geçerliliğini koruyan bir modeldir ve çevik modellemeden farklılık gösterir. Bu model yazılım projesini baştan sona planlar. Gelişim ise  sunulabilir işler açısından ölçülür: talep açıklamaları,tasarım dokümanları, test planları, kod incelemeleri vb. Bu durum belli aralıklara bölünmeye uygun değildir ve ilerideki değişikliklere uyum gösterilemez. Ancak çevik metotlar ise her şeyi küçük parçalar halinde yapıp haftalık olarak sunar ve gerekirse o parça üzerinde gerekli değişiklikleri rahatlıkla uygular.

Cowboy coding’in çevik modellemeden farkı metottan yoksun olmasıdır. Proje takımındakiler kendilerine nasıl uygun gelirse o şekilde çalışırlar. Çevik  programlamada yüz yüze görüşme ve her an iletişimde olmak ön plandadır. Ayrıca önceden belirlenmiş kısa bir süreç içinde çalışmalar yürütülür.

Sonuç olarak; bugün yazılım ve teknoloji dünyası büyük bir hızla gelişmekte ve yeni sistemler yeni talepler ortaya çıktıkça aynı zamanda yeni modellemelere de gereksinim duyulmaktadır. Bunun en açık göstergesi ise bilişim projelerinin ortalama 1 yılda bitiriliyor olmasıdır. Artık projelerin daha etkin ve hızlı bir şekilde bitirilmesi beklenmektedir. Bu amaca yönelik olarak ortaya çıkan çevik programlama modelleri modelleme ve programlama konusunda geliştiricilere yol göstermekte ve alternatif bir model oluşturmaktadır.

Kaynaklar
http://jamshidhashimi.com/2010/08/23/agilecevik-modelleme-ve-cevik-yazilim-gelistirme

http://en.wikipedia.org/wiki/Agile_Modeling

http://en.wikipedia.org/wiki/Agile_software_development

http://e-bergi.com/2008/Ekim/Cevik-Modelleme-ve-Cevik-Yazilim-Gelistirme

http://www.minepla.net/2008/10/agilecevik-yazylym-gelithtirme

Örneğin Oracle’de Kullanıcı isimli bir tablomuzun içindeki Kullanıcı_Id sütununu otomatik artan yapmak istediğimizi düşünürsek öncelikle aşağıdaki gibi bir Sequence yazmamız gerekir.

CREATE SEQUENCE SEQ_KULLANICIID

START WITH 1

INCREMENT BY 1;

SEQ_KULLANICIID isimli bir sequence oluşturduk. Bu sequence 1’den başlayacak ve birer birer artacak. Şimdi de aşağıdaki gibi bir trigger yani tetikleyici yazalım.

CREATE OR REPLACE TRIGGER TBI_KULLANICIID

BEFORE INSERT ON TBL_KULLANICI

FOR EACH ROW

BEGIN

SELECT SEQ_KULLANICIID.NEXTVAL INTO :NEW.KULLANICI_ID FROM DUAL;

END;

Oluşturmuş olduğum trigger’a TBI_KULLANICIID adını verdim. TBL_KULLANICI isimli tabloma bir kayıt eklemeden önce her bir satır için az once oluşturduğumuz sequence’yi çalıştırır.Her yeni kullanıcı_id için sequence yardımıyla değer bir artar. Bu şekilde oracle içinde otomatik artan bir sütun oluşturulmuş olur. Oracle ile uğraşmaya başlayacaklar için gerekli bir bilgi olduğunu düşündüğümden paylaşmak istedim. Bir sonraki makalemde görüşmek dileğiyle.

Yazar: Görkem Sezgin.

O kodu tam hatırlamıyorum ama yapmış olduğunuz configurasyon dosyasını test etmeniz için bir komut; Çalışan config dosyasını aktif ediyor ancak startup confige yazmıyor böylelikle sizin belirtiğiniz süre içinde reset atıp eski config dosyanıza geri dönmenizi sağlıyor. Hatırlayan olursa bi zahmet yazıversin bana Neyse konumuza geri dönelim kullandığımız script çok basit iptables’ı sıfırlıyor tabi cronjob a bunu atıyoruz çalışamaya başlamadan olurda kendimizi kilitlersek diye
#!/bin/bash
# Firewallumuzu olduğu gibi bırakmak için aşağıdaki durum değerini 0 bırakıyoruz.
# Firewallumuzu resetlemek istiyorsak durum degeri 1 olmalı ki döngüye girip firewallu sıfırlasın.
durum=1
# Centos Redhat ve Fedora sistemler dışındaki dağıtımlar için değerimiz "hayir" olucak
# Ben Centos kullandığım için benim değerim evet
sistem=evet
yol=/sbin/iptables
if [ "$durum" == "1" ];
then
if [ "$sistem" == "evet" ];
then
# Firewall'u durdurmak için
/etc/init.d/iptables stop
else
# Diğer linux distroları için aşağıdaki kodları kullanıyor.
$yol -F
$yol -X
$yol -Z
for tablo in $(/proc/net/ip_tables_names)
do
$yol -t $tablo -F
$yol -t $tablo -X
$yol -t $tablo -Z
done
$yol -P INPUT ACCEPT
$yol -P OUTPUT ACCEPT
$yol -P FORWARD ACCEPT

fi
else
:
fi
Çalıştırma izni için
chmod +x /root/sifirla.sh
Bu dosyamızı 5 dk da bir çalıştırmak için /etc/crontab altına
*/5 * * * * root /root/sifirla.sh satırını ekliyoruz.
Önemli nokta: Çalışmaya başlamadan önce yukarıdaki durumu dikkate alınız!!!

tcpdump -i venet0:0 port not 22

ile 22. port dışında trafiği izleyebiliriz. Ayrıca;

tcpdump -i venet0:0 port not 22 and port not 53

bir kaç portu izlemeyi engelleyebiliriz.

tcpdump -i venet0:0 port not 22 and host 1.2.3.4

ile host adresi de ekleyebiliriz.

Open Source kavramı bugüne kadar hep yazılım geliştirme süreci ile birlikte kullanılan bir kavram olarak karşımıza çıktı. Zaman zaman birileri bu kavramı karşımıza böyle çıkardı ve bizde karşımıza her sunulan şeyi kabullendiğimiz gibi bunu da hep bu şekilde kabullendik. Fakat gerçekte open source denen kavramı sadece yazılım geliştirme gibi bir alan ile sınırlandırmak bu fikirsel akıma tamamen haksızlık yapmak demektir.

Open source’ ün ne olduğuna geçmeden önce bugüne kadar bize anlatılanlardan bahsetmek gerekirse; en basit hali ile kaynak kodu açık bir şekilde yazılım geliştirme sürecidir diyebiliriz. İlk bakışta herhangi bir mantığa dayandıramadığımız bu süreç üzerine biraz düşününce aslında son derece iyi niyetli bir düşünce olduğunu anlıyoruz. Buraya kadar bir sorun yok zaten. Fakat sorun bu kavramı bu kadar sığ bir şekilde açıklayıp gerisini getirememekten kaynaklanıyor.

Bu durumu neden bir sorun olarak gördüğüme gelirsek eğer şunu söyleyebilirim ki;
bu kavramın içi sığ tutulduğu sürece, open source kavramı kendi ideolojisine tamamen zıt olan farklı ideolojilerin(örneğin kapitalizm gibi) kendi çıkarları doğrultusunda onu sömürmesi devam edecektir. Bu cümleden sonra biraz durup düşünmek gerekiyor sanırım. Çok ufak bir örnek vermek gerekirse, günümüz de tamamen kar elde etmeye odaklanmış ulusararası bir X firması , 2-3 tane open source projeye imza atıp, bakın biz de open source’ e destek veriyoruz imajı yaratarak programcıları kendi cephesine çekmeye çalışmaktadır. Üstelik bu çabalar özgür düşüncenin hakim olması gereken üniversite salonlarında gerçekleştirilmektedir. Farklı bir örnek daha vermek gerekirse benzer girişimler sanat alanında da görülebilmektedir. Bir çok küresel firma bir yandan çevreyi kirleterek Dünya’yı yaşanmaz bir hale getirirken bir yandan da sanata destek veriyoruz imajı yaratmaya çalışır. Peki bunu neden yaparlar? Bu sorunun cevabı tamamen ayrı bir yazı konusudur, dolayısıyla bu bölümü burada bitirerek open source’ ün bize anlatılmayan kısımlarına değinmek istiyorum.

Open source için öncelikle söylenmesi gereken ilk şey bence; asla ama asla sadece yazılım geliştirme süreci ile alakalı bir kavram olmadığıdır. Aksine open source’ ü hayatın her alanında görebiliriz. Yeter ki doğru açıdan bakalım.

Open source, insanların hayata bakış açıları ile örtüşen bir fikir akımıdır. Hayattan tek beklentisi sadece kendini kurtarmak olan ve öğrendiği herşeyi kendisine saklayan insanların sahip olamayacağı bir bakış açısıdır.

Open source, tüm insanlığı daha iyiye ve daha doğruya götürecek bir fikir akımıdır. Dolayısıyla paylaşımcı ve pozitif bir bakış açısıdır. Bir bilim adamının bir hastalığa karşı bulduğu bir ilacın formülünü diğer bilim adamları ile paylaşması da özünde bir open source ‘e destek hareketidir. Bir programcının geliştirdiği bir mimariyi insanlara anlatmasıda…

Open source’e bir programcı bakış açısıyla bakarsak eğer ilk olarak, sadece kaynak kodu açık bir şekilde yazılım geliştirmek demek değildir diyebiliriz. Bu durum sadece yapılması gereken adımlardan biridir. Önemli olan open source denen kavrama neden ve nasıl sadık kalmanız gerektiğidir. Örneğin open source olmayan araçlar ile open source’ e destek verilebilir mi ? Bu sorunun cevabının zaman zaman değişkenlik gösterebileceğine inandığım gibi genel olarak bence evet diyebilirim. Çünkü işin özünde insanlara bir fikir vermek, bir fikri paylaşmak vardır. Eğer yaptığınız işle insanlara bir fikir veremiyorsanız bunun sizden başka kimseye bir faydası yoktur. Bu da open source kavramına tamamen terstir.

Örnek vermek gerekirse bir içerik yönetim sistemini sadece açık kaynak kodlu şekilde geliştirirken insanlara bir fikir veremiyorsanız bunun hiç bir anlamı yoktur. Hatta bence bu tamamen bir zaman kaybıdır. Burada bence bakış açısı şu şekilde olmalıdır; siz veriye erişim için bir mimari geliştirmiş olabilirsiniz ve bunu bir içerik yönetim sistemine entegre şekilde örnekleyerek insanlara sunarsınız. İşte bunu yaptığınız zaman tüm programcılara bir fikir vermiş olursunuz. Burada ki amacınız içerik yönetim sistemi değil, veriye erişim mimarisidir. İçerik yönetim sistemide bu amacın anlatılmasını kolaylaştırmak için kullanılan bir araçtır sadece…

Bu anlattıklarımın hepsi bir yana open source ‘de gözden kaçan bir nokta daha vardır ki oda, geri bildirimdir. Geri bildirim sayesinde sizin paylaştığınız fikirler insanlar tarafından yorumlanır ve bir şekilde size geri döner. Bu sayede siz kendi fikirlerinizin ne kadar doğru veya ne kadar yanlış olduğunu çok net bir şekilde öğrenir ve kişisel gelişiminizi çok olumlu bir şekilde sürdürebilirsiniz. Kendi fikirlerini kimseyle paylaşmayan bir insan neyin doğru neyin yanlış olduğunu asla ama asla öğrenemez bence.

Tekrar etmek gerekirse, open source; sadece kaynak kodu açık bir şekilde yazılım geliştirme süreci demek değildir.Aksine open source’ ü hayatın her alanında görebiliriz. Yeter ki doğru açıdan bakalım.

Mehmet Aydın Ünlü
aydinunlu85@gmail.com
http://www.aydinunlu.blogspot.com