Previous
Next

Yaz saati uygulaması ve tzupdater ile java güncellemesi yapılması

by Cem Kefeli 10. Ekim 2016 22:09

Yaz saati uygulaması Türkiye'de 1972 yılından 2016 yılına kadar doğrudan enerji tasarrufu amaçlı olarak gün ışığından daha fazla faydalanabilmek amacıyla uygulanmıştır. Bu uygulama ile birlikte ilkbahar aylarının başlangıcında saatler bir saat ileri alınır ve Türkiye saati UTC+3 olur. Sonbahar aylarının sonuna doğru ise saatler bir saat geri alınarak ülke zaman dilimi UTC+2'ye geri döner ve yaz saati uygulaması ise son bulmuş olur. Yani aslında Türkiye'nin gerçek zaman dilimi UTC+2 olarak belirlenmiştir. UTC+3 ise yaz saati uygulaması için geçici bir süreliğine geçilen bir zaman dilimidir.

2016 ekim ayı itibari ile ise Bakanlar Kurulu'nun 2013'de almış olduğu ama 2016'ya kadar uygulanmayan karar (Resmi gazete 2016/9154) doğrultusunda saatlerin geri alınması uygulamasına son verilmiştir. Yani artık tüm yıl boyunca yaz saati uygulanmasının kullanılması ya da kış saati uygulamasının ülke genelinde son bulması kararlaştırılmıştır.

Özellikle bankacılık ve iletişim sektörü için bu durumdan nasıl etkilenileceği, olumsuz etkilerinin neler olacağının tartışıldığı bir ortamda bilişim sistemleri de kendisini yeni karara adapte etmeye çalışıyor. Binlerce ve hatta çok büyük olasılıkla on binlerce sistem bu karar için elden geçiriliyor... İşletim sistemlerine yamalar yükleniyor, veritabanlarına yamalar yükleniyor, vb... Bu bağlamda kurumsal birçok yazılımın vazgeçilmezi olan Java için de yeni koşullara ayak uydurabilmenin bazı şartları bulunuyor.

iana.org üzerinden indirebileceğiniz bir time zone (tz) güncellemesi ile Java kurulumunuzu Türkiye için yeni time zone'a uygun hale getirebilirsiniz. Aşağıda yüklemenin nasıl yapılacağını göstermeye çalışacağım fakat bununla birlikte bu güncellemenin etkilerinin de neler olacağını görebilmek, analiz edebilmek için birkaç satırdan oluşan bir test kodu yazdım ve yaşadıklarımı aşağıdaki gibi aktarmaya çalışıyorum;

Java test kodumuz aşağıdaki gibi;

Time Zone test uygulaması  |  Gizle  |  Göster
package datetimeapp;

import java.text.SimpleDateFormat;
import java.time.LocalDateTime;
import java.time.ZoneId;
import java.time.ZonedDateTime;
import java.util.Date;

/**
 *
 * @author cem.kefeli
 */
public class DatetimeApp {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) {
        SimpleDateFormat simpleDateFormat = new SimpleDateFormat("dd.MM.yyy HH:mm:ss.SSS");
        
        ZonedDateTime zonedDateTime_Local = ZonedDateTime.now();
        Date dateTime_ZonedLocal = Date.from(zonedDateTime_Local.toInstant());        
        System.out.println("dateTime_ZonedLocal: "+simpleDateFormat.format(dateTime_ZonedLocal));
        
        ZoneId zoneId_Turkey = ZoneId.of("Europe/Istanbul"); // Europe/Istanbul +02:00/+03:00
        ZonedDateTime zonedDateTime_Turkey = ZonedDateTime.of(LocalDateTime.now(), zoneId_Turkey);
        Date dateTime_ZonedTurkey = Date.from(zonedDateTime_Turkey.toInstant());        
        System.out.println("dateTime_ZonedTurkey: "+simpleDateFormat.format(dateTime_ZonedTurkey));
        
        ZoneId zoneId_Any = ZoneId.of("Asia/Baku"); // Asia/Baku +04:00
        ZonedDateTime zonedDateTime_Any = ZonedDateTime.of(LocalDateTime.now(), zoneId_Any);
        Date dateTime_ZonedAny = Date.from(zonedDateTime_Any.toInstant());        
        System.out.println("dateTime_ZonedAny: "+simpleDateFormat.format(dateTime_ZonedAny));
    }
}

Eğer bu kodu derleyerek çalıştıracak olursanız aşağıdaki gibi bir çıktı ile karşılaşıyor olacaksınız. Şu anda yaz saati modunda ve UTC+3 zaman diliminde olduğumuz için Bakü yerel zaman dilimi ile aramızdaki zaman farkı bir saat olarak görülecektir. Sistem zamanı ve java zamanı ise aynı görülüyor.Fazlası...

Java Server Faces (JSF) nedir?

by Cem Kefeli 17. Mayıs 2016 05:49

Tüm java makalelerime buradan ulaşabilirsiniz...Java

Java Server Faces (JSF) kavramını anlatabilmek için ilk önce Java'nın bu güne kadar sunmuş olduğu önyüz/arayüz dinamik yapılarını incelemek gerekir diye düşünüyorum.

En başa java servlet'ler yerleşir ki java servlet'ler 1990'lı yıllardan ve de JDK 1.0'dan bu yana hayatımızdadırlar. Güncel versiyonu 4.0'dır ve en son J2EE 8 ile birlikte duyurulmuştur. Temel olarak sunucuya gelen HTTP isteğini keser, ilgili kod parçacığını çalıştırarak yorumlar, ve de istemciye bir cevap dönerler. Servlet'ler içerisinde java kodları bulunur ve istemciye gönderilecek HTML çıktılar bu kodların içerisinde barındırılırlar. Yani servlet teknolojisinde Java kodu içerisine HTML kodları gömülebilir.

İkinci sırada Java Server Pages (JSP) teknolojisi gelmektedir ki aslında JSP'ler de çalışma mantığı olarak yine servlet'ler üzerine kuruludurlar. Arka planda çalışan aslında bir servlet'tir. Fakat uygulamayı yazan kişi bu arka plandaki durumu görmez. Farkı ise JSP'lerin kodlama mantığının HTML üzerine kurulu olmasıdır. Nasıl ki yukarıda bahsettiğim gibi servlet'lerde java kodları arasında HTML kullanılıyorsa, JSP'lerde de HTML içerisine java kod parçacıkları gömülebilmektedir. HTML öğeleri örneğin formlar, tablolar, imajlar doğrudan JSP içerisindeyer alırlar. JSP'ler, servletlere göre görselliği daha ön plana çıkaran yapılar sunar.

Java Servlet, JSP, JSF Historyt

Şimdi asıl konu olan JSF'lere dönelim. Servler'ler ilk ortaya çıktığı gün, günün ihtiyaçlarını karşılıyorlardı. Bir süre sonra görselliği ön plana alan JSP teknolojisi ortaya çıkıverdi. JSP bir nebze olsun görsellik konusunu ileriye taşıdı ama aranan kan halen bulunamamıştı aslında. JSF'nin duyurulması ile birlikte hem kod katmanına hem de görsel katmana hitap eden bir yapı ortaya çıktı. C#, C++ ya da java gibi dillerle masaüstü uygulaması geliştirenler bilirler, form üzerine yerleştirdiğiniz nesnelere aksiyonlar atayabilirsiniz. Örneğin forma bir buton yeteştirdiniz üzerine çift tıklarsanız butona tıklandığında çalışacak olan listener'a ulaşmış olursunuz. Bu listener, kod bloğu, içerisine buton tıklandığında yapılması istenen işlere ait dilediğiniz gibi kod yazabilirsiniz. İşte JSF ile birlikte masaüstü programlamanın bu güzel görsel yapısı bir nebze olsun WEB ile de buluşmuş oldu. JSF ile birlikte artık hem HTML kod tarafında bir kaynak kodumuz, hem de pure java tarafında bir kaynak kodumuz bulunuyor, ve de framework sayesinde bu ikisi arasında bir etkileşim de mevcut.
Fazlası...

RESTFUL ve SOAP web servisleri

by Cem Kefeli 26. Şubat 2016 01:16

SOAP vs. RESTFULMüşterilere sunulan her bir servisin teknolojik karşılığı olan iş yapan uygulama parçacıklarını da birer servis olarak düşünme fikri hayatımızda daha da yer edinmeye başladıkça artık mimari yapılar da buna göre şekillenmeye başlıyor. Servis temelli mimari yaklışım ile ilgili bahsettiğim konsepti anlatan bir yazıma buradaki linkten (Service Oriented Architecture - SOA) ulaşabilirsiniz.

Bu yazının konusu olan RESTFUL ve SOAP web servisler de servis temelli yaklaşıma hizmet eden çok gözde ve üzerinde yoğunlaşılan yapılar. Her ikisinin de temelde hedefleri aynı. Kendisini çağıran kişinin isteğine uygun işi yapmak, ve yine kendisini çağıran kişiye bir cevap dönmek. İşte bu aşamada ikisi arasındaki farktan söz etmeye başlayabiliriz artık, çünkü birbirinden farklı şekilde cevaplar dönüyor bu iki servis yapısı. Ve tabiki birbirinden farklı şekillerde kabul ediyorlar istekleri.

REST (Representational State Transfer), RESTFUL web servislerin sahip olduğu mimariye verilen isimdir. Yani aslına bakacak olursak SOAP (Simple Object Access Protocol) kavramına illaki bir denklik düşünmek istersek bu denkliğin adı REST değil de RESTFUL olmalıdır. Çünkü REST mimari ile ilgili bir kavram, RESTFULL ise REST mimarisine uygun servisler gibi düşünülmelidir.

RESTFUL servisler HTTP protokolü üzerinden konuşurlar ve SOAP servislere göre daha hızlıdırlar. Yapıları daha hafif ve basittir. Zaten de en cazip yönleri bu servislerin sahip olduğu hafif ve kolay kullanılabilir özellikleridir. Çıktılarını XML ya da JSON olarak istemciye ulaştırırlar. Genel olarak bant genişliği yönünden de avantajlıdırlar çünkü istemciye dönen cevap içerisinde yalnızca içerik ile ilgili tag'lar bulunur, yapı ile ilgili tag'lar bulunmaz. REST stateless'dır, durum bilgisi barındırmadığı için de HTTP header'larda ilave bir bilgi taşınmaz. Fazlası...

Java Memory Yönetimi

by Cem Kefeli 3. Şubat 2016 02:39

En sıkıntılı konulardan birisidir bir uygulamayı geliştirirken ve de canlıya alınması sonrasında karışılaşılan memory problemleri. Eğer geliştirme aşamasında tecrübelerinizden de faydalanarak olası memory problemlerini öngörebilirseniz canlıya çıkış sonrası oluşabilecek problemleri azaltabilirsiniz. Ya da daha geliştime ve test aşamasında bir memory problemi ile karşılaşırsanız, ki genelde uygulama gerçek yük altında çalışmaya başladığında açığa çıkarlar, fix etme imkanınız olur ve şanlısınız demektir.

C/C++ ile uygulama geliştirdiyseniz bilirsiniz ki bellek yönetimini tamamen geliştiriciye bırakır. Geliştirici istediği adresteki istediği bellek gözüne kadar herşeye hakimdir. Örneğin işaretçiler yardımıyla bellek gözlerini dilediği gibi yönetebilirler. Bu durum iyi kodlanmış yazılımlar için daha optimal memory kullanımlarını birlikte getirir. Düşünsenize tasarladığınız yazılımın her bir byte seviyesinde her bir bellek gözüne hakimsiniz ve nerede ne var tamamen biliyorsunuz, işlerinizi ona göre planlıyorsunuz. Ama ya iyi kodlanmamış bir yazılım varsa elinizde? Belki de iyi bir uygulama geliştirici değilsinizdir... Bellek yönetiminin esnekliği yerini bir anda bir kaos ortamına bırakıverir. Belki erişmemeniz gereken, sizin olmayan bir bellek gözlerine erişirmişsiniz ve hata alırsınız. Belki de ayırdığınız bellek alanlarının dışına çıkarsınız çalışma anında ve de yine hata alırsınız...

Bununla birlikte eğer nesle yönelimli (Object Oriented Programming - OOP) bir yazılım dili kullanarak uygulama geliştiriyorsanız sevindirici haberler de vardır. OOP konsepti herşeyi birer nesne olarak ele almak istediği için, nesnelerin varlığından ve de yokluğundan haberdar olmak isterler. Nesneleri doğduğu andan öleceği ana kadar takip ederler. Nesne doğduğu anda ona bir yuvacık sunarlar. Biraz ergenleştiği zaman onu yuvacıktan alıp yeni bir yuvaya nakleder ki yeni doğanlara yer açılsın. Nihayetinde zaman gelip de nesnenin ömrü dolduğunda kalıcı olarak yuvayı bozarlar ve nesne de artık yok olur. Bu yuva ve yuvacıkları bellek bölümleri olarak düşünebilirsiniz. Yuvaların tahsisi konusunu yöneten bir birim de vardır tabiki ve örneğin java için bu işi üstenen Garbage Collector (GC)'dür. GC, neslerin ömrü boyunca bellek işlerinden sorumlu müdürlüktür. Yeri geldiğinde kullanılmayan nesneleri de temizleyerek ilgili belleğin tekrar kullanılabilmesi amacıyla geliştiricinin hizmetine sunar. Geliştirici bu konseptte bellek işleri ile ilgilenmez.

Java Memory Management
Fazlası...

Hakkımda...

Cem KEFELİ

Electronics and
Telecommunication Eng.
devamı...


Son yapılan yorumlar...

Comment RSS

Yasal bir uyarı...

Disclaimer"Bu web sitesinde görmüş olduğunuz bilgilerin, dokümanların ve diğer materyallerin kullanılmasından doğabilecek hiç bir sorumluluktan site sahibi sorumlu tutulamaz. Web sitesi içerisinde yer alan yazılar, yorumlar, resimler ve diğer tüm içerikler yalnızca sahibinin görüşünü yansıtmakta olup içeriğin sahibi kişilerin çalıştığı kurumları bağlayıcı hiç bir nitelik taşımamaktadır. Yapılan tüm alıntılar mutlaka kaynak gösterilerek verilmeye çalışılmaktadır. Web sitesi içerisinde bulunan ilgili materyaller, ilgili yasal kurumlar tarafından uygun görülmemesi durumda kaldırılacaktır."
General