Hatalı ve Yanlış girişleri engellemek ve Reguler Expressions

Müşteri ilişkilerini önemseyen bir firmada müşteri telefonları ve e posta adresleri büyük önem taşır.

Ve tablolarımızda kullandığımız ilgili alanların sadece zorunlu olması kullanıcılarımızı doğru bilgi girmesini sağlamaya yetmez.

Özellikle anlamsız bilgi girenler için ayrı bir paragraf açmalıyız çünkü bu konuda gerçekten yaratıcı bir millet olduğumuzu ifade etmeliyim. Bir müşterimizde CRM modülündeki telefon numaralarının ortalama olarak %30’u aynı numaralardan oluştuğuna şahit olmuştum. Muhtemelen e posta adresleri için de durum pek iç açıcı değildir. Ayrıca Türkiye’nin öne gelen kargo firmalarından birinde her kargo göndermemde TC kimlik numarası alanının varsayılan bir değer ile doldurulduğunu görüyorum. Bu tür girişler konumuzun biraz dışında, devam edelim…

Hatalı girişleri engellemek adına, daha kontrollü girişler sağlamak, daha doğru bilgi elde etmemizi sağlayabilir. Bu işlem için de Reguler Expressions ya da kısa adıyla Regex kullanmak çok faydalı olabilir. Regex, özetle bir alana girilecek olan olası bilgilerin formatını belirlemek için kullanılabilir. Buna terminolojide genellikle “maskeleme” denmektedir. Daha detaylı bilgi için tıklayınız.

konumuza dönersek; örneğin için Türkiye’deki sabit telefon numaraları için şehirler arası kodlar 02, 03 ya da 04 ile başlamaktdır. Batı illeri 02, orta kısım 03, doğu ise 04 olarak kodlanmıştır. Bunun haricinde tüm Türkiyede telefon numaraları toplam 11 hanedir. Şimdi bu bilgileri kontrol etmek için nasıl bir Regex kullanabiliriz?

Okumaya devam et

Kullanıcı arayüzlerinde amaca uygunluk ve olası hataları engelleme yaklaşımı

Merhaba.

Bir önceki yazımda fonksiyonalite ve basitleştirme yaklaşımı ile ilgili fikirlerimi paylaşmıştım. Okuyan arkadaşlarımdan olumlu yorumlar aldım, hepsine teşekkür ederek bir diğer konuyu paylaşmak istiyorum.

Yıllar önce ilk kişisel bilgisayarlarımızı aldığımızda Windows 95 kullanmaktaydık. Ve Windows 95 kurmak için disket kullanılmakta idi. Genç arkadaşlar muhtemelen inanamayacaklar ama her birisi sadece 1.44 MB kapasiteye sahip 40 (yazıyla kırk ! ) kadar disket kullanarak işletim sistemi yükleniyordu. Nostalji için Microsoft’un internet sitesinden Windows 95’in gereksinimlerini inceleyebilirsiniz.  Ayrıca Windows 95 nasıl birşeydi diye merak ediyorsanız şu resmi bir inceleyebilirsiniz:

Windows95

Şimdi sıkı durun; Windows 95’i kurmak için öncelike bilgisayarı başlatacak MS-DOS disketi oluşturmak, bu disketle bilgisayarı açmak (boot etmek), ilk Windows diskini takıp bu diskteki setup dosyasını bulmak, bulunan bu dosyayı çalıştırmak (run), sonraki adımlarda doğru sıra ile doğru disketleri takmak ve en sonunda da yine disketleri kullanarak tek tek driverları (ekran, anakart, eternet vb) yüklemek gerekiyordu. Tabi son işlem hariç tüm işlemler DOS ekranında (şu siyah ekran var ya, işte o) yapılyordu. Dolayısı ile Windows 95 kurmak sadece işletim sistemini kurmaktan çok daha fazlasını gerektiriyordu. Yani tam bir “bilgisayarcı çocuk” olmanız gerekmekte idi.

Bilgisayarcı çocuk (temsili resim)

Computer-Addict-copy

Okumaya devam et

Yazılım geliştirmede fonksiyonalite ve basitleştirme yaklaşımı

Hemen her konuda fonksiyonalite ile basitlik arasında bir ters orantı olduğunu söylemek mümkündür.

Örneğin çok amaçlı bir tornavida setinin karmaşıklığı tek bir iş yapan tornavidadan çok daha fazladır.

Karmaşıklık ise genellikle kullanım zorluğu ile eşgüdümlüdür. Dolayısı ile karmaşık bir aygıtın (tool) kullanılması da zordur.

multiScrew

Peki bir taraftan çok fonksiyonluluk bizim için gerekli iken kullanım kolaylığı da gerekiyorsa ne yapmalıyız? Sadece bu konuya yönelik çalışmalar yapan firmalar olduğunu elbette biliyoruz. İsviçre çakıları bu konudaki en iyi örneklerdendir. Ama yine de çok amaçlı bir İsviçre çakısının tüm fonksiyonlarını çok kolay gerçekleştirdiğini söylemek mümkün değildir.

Okumaya devam et

Numara serileri Ax 2012

Daha önceki makalede numara serileri ile ilgili temel konulara değinmiştik ama sistem standartlarına göre kullanmayı ikinci bir yazıya bırakmıştık. Bu arada köprünün altından çok sular aktı ve Ax 2012 yayınlandı. Her ne kadar temel felsefe aynı kalsa da bazı değişiklikler olduğunu söylemeliyiz. Dolayısı ile değişen ya da yenilenen tarafları ile konuyu yeninden ele almak gerekti. Geçen sefer çok uzun olmasın diye kısa kesmiştim ama bu sefer tamamını yazdım.

Öncelikle eski versiyonlar ile AX 2012 arasındaki en temel farkları sıralayacak olursak

  1. EDT tanımlarında bazı farklılıklar var.
  2. Tablo özelliklerinde bazı farklılıklar var.
  3. Yerleşik metodlarda farklılıklar var.
  4. Kullanılan classların isimlendirmesi değişmiş.
  5. Load module metodu aynı kalsa da parametreler değişmiş.
  6. Numara serileri şirketler arası, mali yıla bağlı ya da normal (eskisi gibi) tanımlanabiliyor.
  7. Sihirbazın yeni numara serisini görmesi için bir job çalıştırılması gerekiyor.
  8. Numara serilerini asıl yöneten kodlar form yerine classa taşınmış. (Bence daha iyi olmuş)

Önceki yazıdan hatırlatma babından bir alıntı :
Numara serileri Dynamics Ax içindeki en temel konulardan birisidir. Numara serisi tanımlanmış bir formda her yeni kayıt oluşturulduğunda (kuruluma bağlı olarak) yeni bir numara verilir. Bu numara adından zannedileceği gibi integer değil, string alandır.

Numara serisi tanımlarken kendi modülümüz mü yoksa varolan bir modül mü kullanıldığı önemlidir. Kolay anlaşılması için varolan bir modül olduğunu kabul edelim ve bu modül örneğimiz için Alacak hesapları olsun. Anlaşılacağı üzere numara serileri ile Modüller sıkı bağlıdır.

Şimdi kolları sıvama vakti. Yapmamız gereken işlemler sırası ile alttadır. Her aşamadan önce kaydetmek işinizi kolaylaştıracaktır. Ayrıca Eşitleme isteği gelirse evet demelisiniz. Haydi kolay gelsin 🙂

Okumaya devam et

Tiplerin kullanımı (Use the Type System) tasarım deseni

Microsoft Dynamics AX içinde kullandığımız X++ dili bir strong type dildir. (Strong type için bakınız). Kod geliştirirken Microsoft Dynamics AX Tiplerinin kullanılması her zaman tavsiye edilir.

Bununla birlikte AX içinde genel tipler (str gibi) ve ana classlar (common, object gibi) da mevcuttur.

Genel tipler daha az kontrollü olduklarından tehlikeli olabilir. Ana classlar da kullanıldığı yere göre runtime hata verebilir.

Bu nedenle genel tipler yerine mümkün olan her zaman tam olarak istenen spesifik nesneler kullanılmalıdır.

Ancak ana classların kullanılması tavsiyesini polimorfizm ile karıştırmamaya dikkat edelim.

Polimorfizm uygulamayı runtime’da esnekleştiren bir yöntemdir ve kaçınılması gerekmez.

Polimorfizm ile ilgili konuları başka bir yazıya bırakarak devam edelim.

Okumaya devam et

Microsoft Dynamics AX Design Patterns

Design Patterns (Tasarım Desenleri) kelimesinin birebir Türkçe karşılığı konusunda henüz bir anlaşmaya varılamamıştır. Genel anlamda; sık kullanılan geliştirme yapılarının çözümünde kullanılacak olan standart yapılara tasarım desenleri adı verilir. Tasarım densenleri ile ilgili daha detaylı bilgi için http://www.tasarimdesenleri.com/  sitesini ziyaret edebilirsiniz.

Yazılım dünyasında farklı tasarım desenleri var olmakla birlikte, Dynamics AX’a özel tasarım desenleri altta listelenmiştir. Bu listedeki her bir konu, Dynamics AX içinde sıkça karşılaşılan sorunları çözmeye yönelik standart yaklaşımları izah etmektedir. Fırsat buldukça herbiri ile ilgili  birer yazı yazacağım.

Okumaya devam et

Enumun değerleri ve Reflection

BaseEnum (enum ya da enumarated values şeklinde de ifade edilebilir) hiç değişmeyen değer kümelerini (örneğin : Yılın ayları, haftanın günleri vb.)

ya da sık değişmeyen değer kümelerini (örneğin : sipariş durumu, işlem tipi vb. ) ifade etmek için kullanılır.

En önemli sınırlaması yeni bir değerin kullanıcı tarafından değil, ancak yazılımcı (developer) tarafından eklenebilir olmasıdır.

Buna karşılık Enum’lar veri tabanınnda bir tamsayı değeri ile ifade edildiğinden hem az yer kaplar, hem de sık değişmediğinden bu değerlere göre kodlar yazılabilir.

Not : Yazıyı geçen hafta yayınlamıştım ancak kod kısmında hata oluşmuş, tekrar inceleyebilirsiniz.

Okumaya devam et

Best Practice derleyicisi ve Kod Review

Daha önceki yazılarımızda, Dynamics AX projesi yaparken nelere dikkat edilmesi gerektiğini parçalar halinde paylaşmıştım.

Bunlardan bazıları tecrübe, bazıları ise Microsoft tarafından doğrudan tavsiye edilen konulardan oluşmakta idi.

Örneğin Dynamics AX geliştirmesi yaparken dikkat edilmesi gereken konular başlıklı yazıyı inceleyebilirsiniz.

Bu konudaki en kritik detaylardan biri Microsoft tarafından tavsiye edilen kriterlere uygun geliştirme yapmaktır. Bunun için Best Practice Guide (Özeti için burayıtamamı için burayı tıklayın.) mutlaka incelenmeli, geliştirme yapılırken bu kurallar gözardı edilmemelidir.

Peki hali hazırda yapılmış bir geliştirmeyi nasıl değerlendirebiliriz?

Okumaya devam et

Pack – Unpack Tasarım Deseni (Pack – Unpack Design Pattern)

Bir nesnenin en son durumunu (parametrelerini, değerlerini vb : saved state) kaydederek daha sonra tekrar kullanmak gerektiğinde Pack – Unpack yapısı kullanılmalıdır. Böylece aynı nesne aynı değerlerle tekrar oluşturulabilir.

Ayrıca nesnenin katmanlararası (istemci – sunucu : client – server) geçişi sözkonusu ise değerlerin transferi için yine Pack – Unpack yapısı gereklidir.

Dynamcis AX’ta debug yaparken değişkenlerin birden sıfırlandığına şahit olduysanız, ya da dialog metodu ile kullanıcıdan aldığınız değerlerin bir türlü işleme dahil olmadığını görüyorsanız sorun pack – unpack yapısının kullanılmamış olmasıdır. Çünkü nesne katmanlar aarası taşınırken değerleri taşınamaz.

Nesne sınıf ayrımı için ilgili makaleyi inceleyiniz.

Nesnelerin o anki istenen değerlerini kaydetmek için (save state) pack metodu kullanılır. Bu metod belirtilen değerleri bir container’e yazar ve kaydeder. Kaydedilmiş değerleri alıp kullanmak için ise Unpcak metodu kullanılmalıdır.

Okumaya devam et