Flash ve Flex ortamlarının kendilerine özgü artıları ve eksileri olmakla birlikte şayet Flex framework’üne ihtiyaç duymayan bir proje için bu iki teknolojinin entegrasyonu ile daha sağlıklı bir geliştirme ortamı oluşturulabilir.  Proje ekibindeki görsel arayüz tasarımcılarının ve programcıların bu şekilde birbirlerinden kullandıkları ortamlar bakımından bağımsız çalışmaları mümkündür.

http://www.communitymx.com/content/article.cfm?cid=A2D85

NOSQL veri tabanı sistemleri günümüzde daha çok yüksek ölçeklenebilirlik ihtiyacı olan, dinamik içerikli Google, Facebook, Amazon, Twitter gibi web uygulamaları tarafından kullanılmaktadır. Yapılan pazar araştırmaları sonucu internet üzerindeki veri boyutu 2006 yılında 161 exabyte iken, 2010 yılında 6 kat büyüyerek 988 exabyte’a ulaşmıştır[13].  Yönetilen verinin bu kadar hızlı artması, veri üzerinde yapılan işlemlerin süresinin de artmasına sebep olur. Hedeflenen; yatay ölçeklenebilir, performansı yüksek, veri karmaşıklığı düşük ve yönetimi kolay bir veri tabanı sistemi ortaya koymaktır. NOSQL veri tabanı sistemleri tam olarak bu noktada özelleşmiş bu ihtiyaçlara çözüm üretmeyi amaçlar.

NOSQL veri tabanı sistemlerinden in-memory kategorisine dahil olan Memcached[14] veri tabanı sistemi dünyanın en çok ziyaret edilen üçüncü[15] web sitesi YouTube video barındırma sisteminde önbellek ihiytaçlarını karşılamak üzere kullanılmaktadır. Memcached’in kullanılması, YouTube firması için donanım maliyetlerinde %30 civarında düşüş, performansta ise %25’lik bir artış sağlamıştır. Memcahced dağıtık ve bellek tabanlı veri tabanı sistemini kullanan diğer uygulamalar için Wikipedia, WordPress, Sourceforge, Facebook, Zynga, Twitter, Joomla, Drupal firma ve web uygulamaları sıralanabilir.

NOSQL destekleyicilerinden ve NOSQL veri tabanı sistemlerinden Cassandra projesini ilk geliştiricilerinden dünyanın en büyük sosyal ağı olarak geçen Facebook, sistemindeki kullanıcılarına sunduğu site içi arama işlevini Cassandra veri tabanına dayandırmaktadır. 500 milyondan fazla kullanıcının sunduğu içerikte yapılan aramanın geri bildirim(response) zamanını düşürmek adına, kolay genişleyebilir özellikte tasarlanan Cassandra veri tabanı projesi 2009 yılından sonra Apache topluluğuna devredilmiştir.

     Apache topluluğuna ait HBase veri tabanı sistemi ise kolon tabanlı ve yapı olarak Google BigTable veri tabanı sistemine benzerlik gösteren, birçok uygulama alanı olan bir projedir. Ünlü web portallarından Yahoo, sisteminde barındırdığı her türlü dokümanın kendi aralarındaki benzerliği tespit eden, bir birini tekrar eden kopyaları ayıran yazılımında kullanmaktadır. Yine sosyal ağlar üzerinde reklamcılık ve medya işleriyle tanınan SocialMedia firması, reklam materyalleriyle kullanıclar arasındaki etkileşimleri ve hareketleri HBase tabanlı sisteminde saklamakta ve reklamcılık ile ilgili analiz işlemlerini bu veriler üzerinden gerçekleştirmektedir. Benzer kullanım alanları Adobe, Twitter gibi firmalarda da mevcuttur[16].

NOSQL sistemler genel olarak belirli bir amaca yönelik tasarlanmış ve kullanım alanları ilişkisel veri tabanı sistemlerinin aksine daraltılmıştır. Bu açıdan bakılacak olursa, NOSQL veri tabanı sistemleri ilişkisel veri tabanı sistemlerinin tümden yerine geçebilecek bir alternatif olarak değil, ilişkisel veri tabanları ile birlikte kullanılmasıyla heterojen sistemlerin ortaya çıkarılmasında yer alacak bir sistem parçasıdır. NOSQL’den maksimum fayda sağlayabilmenin ilk koşulu, kullanılması düşünülen sistem ile ne derece uygun olduğudur. NOSQL sistemlerin ne zaman, hangi koşullarda seçilmesi gerektiği hakkında standart kurallar olmamakla birlikte, farklı kaynaklardan edinilen bilgilerin derlemesi olarak şu şekilde sıralamak mümkündür[17][18][19]:

• Mevcut sistemde oldukça büyük veriler (terabyte seviyesinde) üzerinde işlemler yapılıyor ve performans yükseltme ihtiyacı öncelik taşıyorsa
• Mevcut ilişkisel modelin özellikle join sorgularında getirdiği karmaşıklıktan kaçınmak üzere de-normalization işleminin yapılması gerektiği düşünülüyorsa
• Mevcut sistem çoklu-nesne-hareketi(multi-object transaction) gerektirmeyen, daha çok her harekette bir nesne üzerinden işlem yapılıyorsa
• Sistemin gereksinimleri sürekli değişkenlik gösteriyor ve bu değişiklikleri ilişkisel model yansıtmak kayda değer kaynak maliyeti ortaya çıkarıyorsa
• Mevcut sistemde aynı kayıtlar üzerinden okuma işlemi sık olarak gerçekleştiriliyor ve önbellek mekanizmasına ihtiyaç duyuluyorsa
• Sistemde bulunan ve yapısal olmayan verilere ihtiyaç duyan, veri ambarı veya diğer uygulamalara sunulan verilerin saklanması için şema ve yapısal veri olgusu olmayan bir veritabanı ihtiyacı varsa
• Yüksek erişilebilirlik(high availability)  adına yapılan harcamaların getirdiği performans için gereğinden fazla olduğu düşünülüyorsa

NOSQL sistemlerinin kullanılması düşünülebilir.

Şekil 1

İlk üç formant frekansı genelde ünlüleri ayırt etmek için yeterlidir. Spektrumda ünlüler koyu renkli sıklıklarıyla kolayca fark edilebilmektedirler. Formant frekansları ses yolunun rezonans frekansları olarak algılandığında ses yolunun geometrisine göre bu frekansların gerek sayılarının gerekse değerlerinin değisiklik göstereceği açıktır. Aşağıda Türkçe’deki sesli harfler için ortalama F1, F2, F3 formant frekanslarının değerleri verilmiştir. (Yetişkin Erkekler için)

Formant değişiminin(vokal trakt) ses tellerinden çıkan sinyal üzerindeki etkisi Şekil-2 de gösterilmiştir

Şekil 2

Formant frekansların değeri yaşa, cinsiyete ve diğer fiziksel özelliklere bağlı olarak değişim gösterebilmektedir. Bir bakıma kişiye özeldir denebilmektedir.  Ünlü harflerin ses olarak üretilmesi aşamasında dilin yukarda veya aşağıda kalması, dudakların yuvarlanıp yuvarlanmaması gibi özellikler formant frekanslarının değerlerinden çıkarılabilmektedir. Örneğin F1 frekansı ünlü harfin yüksekliğini(dilin yukarda veya aşağıda olması) bulmakta kullanılabiliniyor. F1 frekansı ile ünlünün yüksekliği arasında ters orantı vardır. F1 frekansının büyük değerlerinde yükseklik azalırken, düşük değerleri için ise artmaktadır.

Şekil 3

F2 formant frekansı ise ünlü harfin üretilirken dilin öne(frontness) veya arkaya(backness) geçme durumunu tespit etmede kullanılabiliyor. Büyük f2 değerler için dil öne kayarken, düşük f2 değerlerinde arka tarafa kaymaktadır. Şekil-3’te bu durum ifade edilmek istenmiştir.

Bu çalışma F2 ve F1 frekansları arasındaki farkların Türkçedeki ünlüler için gösterilmesidir. Bu fark değerleri için beklenen sonuç, farkın arttığı ünlülerin frontness, azaldığı ünlülerin ise backness özellikte olmasıdır. Başka bir deyişle Kalın-İnce ünlü tespiti yapabilmek mümkün olacaktır. Ünlü, dil ağızda geriye doğru çekilerek(backness) çıkmışsa kalın ünlü adını alır. Bunlar “a, ı, o, u” ünlüleridir. Dil ağızda ileriye doğru itilerek çıkmışsa da ince ünlüdür.(e,i,ö,ü)

Uygulama

Çalışma kapsamında Matlab ortamında yazılan program ile ünlü harflerin F2-F1 değerlerine karşılık F1 değerinin grafiği bulunmuştur. Beklenildiği gibi kalın ünlüler için F2-F1 değerinin küçük olduğu görülmektedir.  Aynı zamanda ortalama F2-F1 değeri 665 bulunmuştur. Bu ortalama değerden küçük olan ünlülerin geniş ünlü, büyük olanların ise dar ünlü olduğu gözlemlenmiştir. Program doğrudan şu şekilde çalıştırılır:

formantOdev();

Şekil 4

1)      Spectral Centroid ve short-term energy öznitelikleri ses sinyalinden çıkarılır

2)      Her öznitelik için threshold T değeri devingen olarak hesaplanır

3)      T threshold değeri ses sinyali üzerinde uygulanır.

4)      Konuşmanın olduğu ve olmadığı kısımlar tespit edilir

Öznitelik Çıkarma (Feature Exraction)

Öznitelik çıkarma işleminden önce ses sinyali 50 ms genişliğinde window’lara bölünür. Her çerçeve için aşağıdaki öznitelikler hesaplanır:

• Short-term Energy  :  Konuşmanın olduğu kesimlerde daha fazla enerji vardır.
• Spectral Centroid: Konuşmanın olmadığı kesimlerde, çevreden kaynaklanan gürültüler düşük frekanslı olacağı için bu kısımlarda spectral centroid değeri düşük olacaktır.

Programı çalıştırmak için:

[segments, fs] = detectVoiced(‘ses.wav’,1);

İndir: Matlab Kodu

Sonar is an open platform to manage code quality.

Website

Demo (nemo)

• “Many client specific interfaces are better than one general purpose interface“
• “The dependency of one class to another one should depend on the smallest possible interface“
• “Make fine grained interfaces that are client specific.“
• “Clients should not be forced to depend upon interfaces that they don’t use. This principle deals with the disadvantages of fat interfaces. Fat interfaces are not cohesive. In other words the interfaces of classes should be broken into groups of member functions.“

Nesne Yönelimli Tasarım için tavsiye buyrulan prensiplerden biri de Interface Segregation Principle(ISP) ‘ dir. ISP, bir siniftan hizmet alan istemcilerin ilgi duymadiklari arayuzlerden soyutlanmasi, sadece ihtiyac duyduklari arayuzlere erisebilmesini saglamaktir. Bu sebeple her istemci için bütün metotlarin aynı arayüzde toplanması yanlış bir tasarımdır. Somut bir ornek vermek gerekirse; Insan günlük hayatında özel hayatıyla, iş hayatını beraber yürütür. Evinde uyuyup, yemek yer vb. İş yerinde ise çalışır, ücret kazanır. Kişi aynı kişidir ancak iş yerinde(mesela fabrika) bir Çalışan, bunun dışında bir Birey’dir. Bu senaryo için Fabrika istemcisi Insan varliginin Calisan arayuzlerini kullanmak isterken, Ev istemcisi onun Birey arayuzlerini kullanmak ister. Iyi bir tasarim olması açısından Fabrika istemcisini Birey arayuzunden, Ev istemcisini de Calisan arayuzunden soyutlamak gerekmektedir. Problem cozumu için Insan sınıfının gerceklestirecegi 2 tane arayuz(Calisan ve Birey) tanımlamak gerekir. Daha sonra Fabrika, Insan’a Calisan arayuzunden, Ev ise Birey arayuzunden baglanmalidir.

public interface Calisan {

public void calis();

public void maasHesapla();

}

public interface Birey {

public void uyu();

public void yemek();

}

public class Insan implements Calisan, Birey {

}

no segments* file found in org.apache.lucene.store.SimpleFSDirectory..

diye giden bir hata IndexWriter nesnesi yaratılırken ortaya cikabilir. Sebebi Lucene’e olusturacağı indexleri saklayacağı dizini verirken, dizinin zaten var olması ya da dizin var olsa bile icinde indexlerin tutuldugu ikili(binary) dosyaların mevcut olmamasıdır. Bunun icin asagidaki gibi bir cozum kullanılabilir:

// boolean false parametresi, her acilista var olan index’in ustune yazilmasini engeller.
boolean resetIndexes = true;
File indexFile = new File(indexDir);

if(indexFile.exists()){
resetIndexes = false;
}
FSDirectory dir = FSDirectory.open(new File(indexDir));
writer = new IndexWriter(dir, new StandardAnalyzer(Version.LUCENE_CURRENT),
resetIndexes, IndexWriter.MaxFieldLength.LIMITED);

Yukarıdaki çözümde, Lucene’e index klasoru varsa, varolan indexlerin üstüne yazmaması icin “resetIndexes” boolean degeri false verilir. Şayet sistemde index klasorumuz henüz yaratılmamışsa da “resetIndexes” degeri bu sefer true verilerek yeni baştan indexleri oluşturması sağlanır.