24 Temmuz 2017 Pazartesi

Negatif Mutlak Değer Olur Mu?

Java'da mutlak değer metodunun negatif sayı dönebileceğini biliyor muydunuz?



Mesela random pozitif integer değer almaya çalışırken beklenmedik bir negatif sayı sistemi alt üst edebilir. Bu sorun sadece bir exception fırlatmakla kalmaz bazen milyon dolarlık zararlara da yol açabilir.

23 Temmuz 2017 Pazar

Stok Takip Programı Hakkında Sıkça Sorulan Sorular

Merhabalar. Bu yazımızda PMobile Android Barkod & Karekod Sistemi hakkında sizden gelen soruları cevaplandıracağız.

1- Satın almak için istenen ücret bir aylık mı, yıllık mı, veya süreli mi yoksa sınırsız kullanım için mi?
- Sınırsız kullanım için tek bir defa ödeme yapıyorsunuz. Başka bir ödeme yapmadan, güncellemeleri de takip edebiliyorsunuz.

2- Telefonu değiştirdiğimde veya telefon bozulduğunda verilerimi de kaybetmiş olacak mıyım?
- Hayır, uygulamada bulunan içe aktar/dışa aktar mekanizmasını kullanarak verilerinizi koruyabilirsiniz. Verileriniz güncellendikçe "Dışa Aktar" tuşu ile veritabanınızı dosyaya aktarın. Bu dosyayı güvenli bir yerde yedekleyin. Telefon değiştirdiğinizde ilgili klasöre bu dosyayı koyarak "İçe Aktar" tuşunu kullanarak verilerinize kavuşmuş olacaksınız. Hangi klasöre atmanız gerektiği "İçe Aktar" sayfasında yazıyor. Telefonda böyle bir klasör yoksa oluşturun ve dosyayı içine atın.

3- Demo sürümde bulunan kayıt sınırı PRO sürümde de var mı?
- Hayır, PRO sürümde sınırsız kayıt yapabilirsiniz.

4- Pro sürümüyle stok sayımı yapabilirmiyim?
- Evet. Barkodunu okutup kaydettiğiniz ürünlerin stok sayısını "Stok Takibi" sayfasında yapabilirsiniz. Stok girişi/Stok çıkışı işlemleri ile stok sayısını güncelleyebilirsiniz. "Stok Raporu" sayfasında geçmişe dönük günlük-haftalık-aylık hareket dökümünü görebilirsiniz.

5- Uygulamayı nasıl satın alacağız?
- Google Hesabınızdaki ödeme yöntemlerini kullanarak Google Play'den uygulama ve dijital içerik satın alabilirsiniz. Bu ilk alışverişinizse ödeme yönteminiz Google Hesabınıza eklenir. Ödeme yöntemlerini nasıl ekleyeceğinizi ve değiştireceğinizi öğrenmek için ödeme yöntemlerini ekleme ve değiştirme sayfasına göz atın.

Hesabınıza aşağıdaki kredi/banka kartlarını ekleyebilirsiniz:
American Express
MasterCard
Visa
Discover (sadece ABD)
JCB (sadece Japonya ve ABD)
Visa Electron (sadece ABD dışında)
Elo kredi kartları (yalnızca Brezilya)

Google Play üzerinden kabul edilen kartların türü, bulunduğunuz konuma göre değişiklik gösterebilir.


Doğrudan Operatör Faturalandırması


Bazı mobil cihazlar ve hizmet planlarında, uygulama ve dijital içerik satın alma işlemlerinin ücretini operatör faturanız üzerinden ödeyebilirsiniz. Bir uygulama satın aldığınızda, 15 dakika sonra operatörünüzün faturasında bir ödeme görürsünüz.

Türkiye'de şu anda Türk Telekom(Avea), ve Turkcell ile bakiyenizden ödeme yapabiliyorsunuz.

Not: Doğrudan operatör faturalandırmasına kaydolduğunuzda telefonunuzda "DCB_Association" ifadesiyle başlayan bir SMS (kısa mesaj) görebilirsiniz. DCB_Association mesajı, Google Play hesabınız için doğrudan operatör faturalandırması kaydını tamamlamak üzere otomatik olarak oluşturulur ve gönderilir.


Desteklenmeyen Ödeme Türleri


Google Play'de aşağıdakiler kullanılamaz:
Banka havalesi
EFT
Western Union
Money Gram
Sanal Kredi Kartları (VCC)
Sağlık Tasarruf Hesabı (HSA)
Toplu taşıma kartları
Bloke tutar türündeki herhangi bir ödeme




10 Temmuz 2017 Pazartesi

Clean Code Notlarım - (Temiz Koda Doğru)

Robert C. Martin'den Clean Code kitabı bizim yazılım sektöründe oldukça popüler. Yazılım geliştiricilere kodun sadece çalışmasının yetmeyeceğini, aynı zamanda anlaşılır, sürdürülebilir, test edilebilir, genişletilebilir vb. olması gerektiğini ve bunun hangi yöntemlerle yapılabileceğini örneklerle anlatan kitabı tüm meslektaşlarıma öneriyorum. Sunum haline getirdiğim kendimce çıkardığım notları şuradan indirebilirsiniz.



Sunum PDF dosyası indirilemiyorsa içerik aşağıdaki gibidir.

Clean Code Notları
Murat ÖKSÜZER
http://muratoksuzer.com

Robert C. Martin

Temiz kodun özellikleri
Verimli
Okunabilir
Test edilebilir
Sürdürülebilir
Yalın
Tekrar (dublication) içermeyen 
Anlamlı isimlendirmeli

Amaç:
Kodu bulduumuzdan temiz bırakmamızı salayacak duyarlılıı kazanmak

simlendirme
simlendirme niyeti belli etmelidir. 
Yanlıbilgilendirmemelidir. 
Telaffuzu mümkün olmalıdır. 
Aranabilmelidir.
Kodlamadan kaçınılmalıdır.
Aynı konsepten bahsederken aynı isim kullanılmalıdır.
Aynı isim farklı konseptler için kullanılmamalıdır.
Zeki olmaya çalı
ılmamalı, sade herkesin anlayacaı isim kullanılmalıdır.


simlendirme
simleri deitirmekten korkmamalı. Gerekli yerlerde refactor yapılmalıdır.
Helper, Manager vb. genel isimler sınıfın hereyi içeren torbaya döndüüne iaret ediyor olabilir.

Fonksiyonlar
Küçük olmalıdır. dealde en fazla 20 satır olmalıdır.
Nested yapılar 2 seviyeden fazla olmamalıdır. If, else, while gibi blokların içi metoda alınarak tek satıra düürülebilir.
Metod tek bir iyapmalıdır. Tek sorumluluu olmalıdır. (Single Responsibility Principle)

Fonksiyonlar
Switch blokları doası gerei n tane iyaparlar. Mümkün olduunca kaçınmalıdır.
Polimorfizm kullanarak switch blokları refactor edilebilir. (Abstract factory vb.)
Fonksiyonun ismi açıklayıcı olmalıdır. 
Yaptıı ianlaılmalıdır.

Fonksiyonlar
Fonksiyonların argüman sayısı en aza indirgenmelidir. Mümkünse sıfır, en kötü üç argüman almalıdır.
Argüman sayısı artıyorsa, argüman objesi oluturmalı, argümanlar bu sınıf ile geçirilmelidir.
Output argümanlar ekstra dikkat gerektireceinden mümkün olduunca kaçınılmalıdır.

Fonksiyonlar
Boolean flag argüman alan fonksiyon büyük olasılıkla birden fazla iyapıyordur. Fonksiyon ayrılarak flag argümanından kurtulunmalıdır.
Fonksiyonun yan etkisi olmamalıdır. Var ise, fonksiyon isminde belirtilmelidir. (Unutmayın, fonksiyon bir iyapmalıydı)

Fonksiyonlar
Bir fonksiyon ya nesnenin durumunu deitirmeli ya da nesneyle alakalı bilgi dönmelidir. kisini aynı anda yapmamalıdır.
Örnein;
public boolean set(String attribute, String value); if (set("username", “unclebob"))...

Set metodu birden fazla iyapıyor...

Fonksiyonlar
Fonksiyondan hata kodu dönmektense exception fırlatmak tercih edilmelidir.
Try/Catch blokları fonksiyonlara dönütürülmeli, blok sadeletirilmelidir.

Fonksiyonlar
Single-entry, single-exit kuralı uzun fonksiyonlar için mantıklıydı. Metodlarımızı kısa tutacaımız için birden fazla return, break kullanılabilir, hatta daha açıklayıcı bile olabilir.

Yorumlar
Kötü koda açıklama yazmakla uraılmamalı, kodu tekrar yazmalıdır.
Kod açıklamaya gerek kalmayacak kadar okunur ve anlaılır olmalıdır. 
Derdimizi kodla anlatmalıyız.

Yorumlar
Yorumun gerekli olduu yerler de vardır.
Yasal zorunluluklar. Lisans bilgilerini içeren yorumlar.

Koddaki bir tasarımsal kararın arkasındaki neden yorum olarak eklenebilir.

Yorumlar
Gelitiriciyi çalıtırılacak kodun sonuçlarına karı uyarmak gerektiinde yorum kullanılabilir.
TODO yorumları unutulmamak artıyla faydalıdır. Javadoc yorumları dökümantasyon için faydalıdır.

Yorumlar
Kodu okuyarak anlayabileceimiz eyler için yorum yazılmamalıdır. Gereksiz kalabalık yaparlar.
Yanlıbilgi içeren, yanlıyönlendiren yorumlar tehlikelidir. Bir an önce kurtulunmalıdır.
Yoruma alınmıkod bırakılmamalıdır, silinmelidir. Siz silmezseniz, birinin iine yarayacak düüncesiyle kimse silmeye cesaret edemez.

Formatlama
Kodun çalıır olması kadar okunabilir olması da önemlidir.
Kod listesi okurken gazete okuyor hissi vermeli, yukarıdan aaıya genelden özele doru bir yapı oluturulmalıdır.

Formatlama
Alakalı metodlar birbirine yakın yerletirilmelidir.
Deikenler kullanıldıı yere mümkün olan en yakın yerde tanımlanmalıdır.
Yatay satır uzunluu, sayfada saa doru scrola gerek bırakmamalıdır.

Formatlama
Takımca formatlamanın nasıl olacaına karar vermeli ve tüm gelitiriciler bu kurallara uymalıdır.

Hataları Yönetme
Hata kodu dönmektense Exception kullanılmalıdır. Böylece çaıran kod hata kodu kontrol etmekten kurtulur ve esas ii yapan kod, hata handling kodundan ayrıldıı için daha temiz olur.

Hataları Yönetme
Unchecked exception tercih edilmelidir. Checked exception fırlatan bir metodun catch’i 3 seviye yukardaysa, exceptiondaki bir deiiklik tüm seviyelerin deimesine ve yeniden compile-deploy edilmesine sebep olmaktadır.
Checked exception olmadan da salam yazılım yapılabilir. Örnein; C#, C++, Python ve Ruby dillerinde Checked exception yoktur.

Hataları Yönetme
Exception içine hata ile alakalı içeriksel bilgiler de konulmalıdır. Ne yapmaya çalıırken hata olutuu bilgisi debug yaparken yardımcı olacaktır.

Hataları Yönetme
Duruma özel nesne ile çözülebilecek exceptional case’ler, try/catch ile deil, bu nesne ile çözülmelidir. (SPECIAL CASE PATTERN [FOWLER]

Hataları Yönetme
try {
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());

  m_total += expenses.getTotal();
} catch(MealExpensesNotFound e) {
m_total += getMealPerDiem();
}
// yerine
MealExpenses expenses = expenseReportDAO.getMeals(employee.getID());
  m_total += expenses.getTotal();
// Special Case obejesi
public class PerDiemMealExpenses implements MealExpenses {
  public int getTotal() {
// return the per diem default }
}


Hataları Yönetme
Metodlardan null dönmek hatalara davetiye çıkarır. Null dönmemeli, Exception fırlatmalı veya SPECIAL CASE nesnesi kullanılmalıdır.
Metodlara null parametre geçirmek, null dönmekten daha kötüdür. Null parametre geçirmekten sakınmalıdır. 

Birim Testleri
TDD (Test Driven Development) pratiinin üç temel yasası vardır. 
1- Fail eden bir test yazmadan production kodu yazma
2- Fail etmeye yetecek kadardan fazla test yazmaya devam etme.
3- Fail eden testi geçecek kadardan fazla production kod yazma. Testi geçecek kadar gelitirmen yeterli.

Birim Testleri
Bu sayede fail edecek test yaz - kodu gelitir - fail edecek test yaz eklinde bir döngüye girilir.
Böylece production kodu testlerle beraber üretilir.

Birim Testleri
Test sınıfları da production kod kalitesinde temiz tutulmalıdır. kinci sınıf vatandamuamelesi görmemelidir.
Testler temiz tutulmadıında sürdürülemez ve bir süre sonra production kod testsiz kalma tehlikesiyle karı karıya kalır.
Testsiz kalan production kodda deiiklik yapmaya cesaret etmek zordur. Nerenin bozulduu anlaılamaz

Birim Testleri
Test metodlarındaki assert sayısı en aza indirgenmelidir. Testler çalıtırıldıında fail eden bir assert yüzünde onun altında kalan assertlerin sonuçları muamma olmaktadır.
One assert per method en idealidir.
Test metodu sadece bir konuyu test etmelidir. 
Birden fazla durum için farklı test metodları yazılmalıdır.

F.I.R.S.T. kuralı
Testler F.I.R.S.T. kuralına uymalıdır:
Fast: Testler hızlı çalımalıdır. Yavaçalıan testi kimse çalıtırmak istemez, hatalar tespit edilemez.
Independent: Testler birbirinden baımsız çalıabilmelidir.

F.I.R.S.T. kuralı
Repeatable: Testler her ortamda tekrarlanabilmelidir.
Self-validating: Test sonucunu anlamak için fazla düünmeye gerek olmalıdır. Test ya geçmeli ya fail etmelidir. Durumu anlamak için çıktıları incelemek vs. gerekmemelidir.
Timely: Testler zamanında yazılmalıdır. Production kodla beraber gelitirilmelidir.

Sınıflar
Yukarıdan aaıya statik deikenler (önce publicler sonra private statikler), sonra instance deikenleri (public, private sırasında) daha sonra public metodlar ve private metodlar gelmelidir.
Sınıfı okurken gazete okuyor hissi vermelidir.

Sınıflar
Sınıflar olabildiince küçük olmalıdır. Sorumluluklar olabildiince küçük parçalara bölünmelidir.
Sınıfa isim vermekte zorlanıyorsanız, sınıfın olması gerektiinden büyük olduu anlaılabilir.
Single Responsibility Principle der ki, bir sınıfın deimesi için sadece bir neden olmalıdır.


Sınıflar
Sınıfın sorumluluu arttıkça, deiime urama olasılıı o kadar artmaktadır.
Sınıfın manipüle ettii deiken sayısına bakarak bu deikenlerden yeni sınıflar üretilebilir mi diye sorgulamalıdır.