Jump to page: 1 2
Thread overview
Dosya yolu sonu
Dec 13, 2016
zafer
Dec 14, 2016
erdem
Dec 15, 2016
zafer
Dec 15, 2016
zafer
Dec 17, 2016
zafer
Dec 18, 2016
zafer
December 13, 2016

Biraz tuhaf bir başlık oldu ama başka bir şey bulamadım. Resimlerle bir takım işler yapmak için bir boyutlandırma işlevi hazırlıyordum. Ancak daha sonra başka bir takım işlevlerede ihtiyaç duyacağım için bu işlevide içine alan bir sınıf geliştirmeye karar verdim. Sınıf yapısını oluşturan kodlar aşağıdaki gibi, burada da eksik ve hatalarım olabilir. Önerilere açığım. :-D

Benim esas sorum. buradaki klasör adreslerinin sonuna "/" işareti koyup koymamakla ilgili. Bu durum için genel bir kullanım var mıdır? Yani böyle bir temel adres belirtilirken sona bir ayraç koymak mı yoksa koymamak mı daha doğrudur. Yoksa bu tamamen kişisel bir tercihmidir? Fikirlerinizi öğrenebilir miyim?

module resim;

import std.process: spawnProcess;
import std.path: extension, baseName;
import std.conv: to;
import std.string: format;

class Resim
{
   // ./upload
   private string resimKlasoru;
   private string depoKlasoru;

   public this()
   {
       this.resimKlasoru = "/media/depo/Projeler/genel/imagek-test/public/upload/";
       this.depoKlasoru = "/media/depo/Projeler/genel/imagek-test/public/upload/cache/";
   }

   public string boyutlandir(string dosya, int en, int boy)
   {
       string kaynak = resimKlasoru ~ dosya;
       string uzanti = extension(dosya);
       string adi = baseName(dosya, uzanti);

       string boyut = to!string(en) ~"x"~ to!string(boy);
       string hedef =  format("%s%s_%s.%s", depoKlasoru, adi, boyut, uzanti);

       spawnProcess(["convert", kaynak, "-resize", boyut, hedef]);

       return hedef;
   }
}

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 14, 2016

Eğer dizin ismiyse *nix için burada anlatıldığına göre (http://unix.stackexchange.com/questions/216267/what-is-the-difference-between-a-directory-name-that-ends-with-a-slash-and-one-t) en sona / koymak daha mantıklı gözüküyor.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 14, 2016

Böylece adında klasör bulunan değişkenlerin ayraçla sonlandığına da güvenmiş olursun ve denemek gerekmez.

Bu arada, kod çok temiz görünüyor. :)

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 15, 2016

Teşekkürler, doğrusu daha önce hangisi denk gelirse o şeklide kullanıyordum ama bazı şeyler için bir düzen belirlemek daha doğru olur diye düşündüm. Aslında çalıştığım bir çok kütüphanede sonda "/" olmuyor. Sanırım bu yine bir tehcih meselesi.

Alıntı (acehreli):

>

Bu arada, kod çok temiz görünüyor. :)

Umarım bunu iyi anlamda söyledin :) Elimden geldiğince güzel ve akıcı yazmaya çalışıyorum. Kötü ses nasıl kulakları tırmalıyorsa çarpık çurpuk kodlarda bence gözleri tırmalıyor. Özellikle format() gerçekten çok yardımcı oluyor. Birde senin gibi şu map(), filter() kullanımına geçsem daha güzel olacak :-D

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 15, 2016

Eksik kalmasın: std.path.buildPath, ayraç olsun olmasın doğru çalışır:

https://dlang.org/phobos/std_path.html#.buildPath

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 15, 2016

Alıntı (acehreli):

>

Eksik kalmasın: std.path.buildPath, ayraç olsun olmasın doğru çalışır:

Bu gerçekten güzel oldu. Hem daha temiz bir kodlama sağlıyor hemde ayraç karmaşasını önlüyor. D'nin böyle kilit noktalara eklediği özellikler gerçekten çok güzel.

Bende hemen buildPath olanağını kodlarıma kattım :) Bununla birlikte birazda deneysel olarak D dilinin alias ve UFCS (http://ddili.org/ders/d/ufcs.html) özelliklerinden faydalanarak kodları biraz daha geliştirdim.

Ayrıca başta aklımda olan ancak bir önceki koda yetişmeyen önbellek sisteminide Resim sınıfına ekledim. Bu sistem dosyayı önce cache isimli bir klasörde arıyor bulursa direk bunu gönderiyor eğer bulamazsa dosyayı oluşturup yine bu klasöre kaydediyor ve bunu gönderiyor. Basit bir önbellek sistemi kurmaya çalıştım.

module resim;

import std.path: extension, baseName, buildPath;
import std.process: spawnProcess;
import std.string: format;
import std.uuid: md5UUID;
import std.file: exists;
import std.conv: to;

// to!string yerine str
alias str = to!string;

class Resim
{
   // ./upload
   private string resimKlasoru;
   private string depoKlasoru;

   public this()
   {
       this.resimKlasoru = "/media/depo/Projeler/genel/imagek-test/public/upload/";
       this.depoKlasoru = "/media/depo/Projeler/genel/imagek-test/public/upload/cache/";
   }

   public string boyutlandir(string dosya, int en, int boy)
   {
       string kaynak = buildPath(resimKlasoru, dosya);
       string uzanti = extension(dosya);
       string isim = baseName(dosya, uzanti);

       string adi = md5UUID(isim ~"."~ en.str ~"."~ boy.str).str;
       string boyut = en.str ~"x"~ boy.str;
       string hedef = buildPath(depoKlasoru, format("%s_%s%s", adi, boyut, uzanti));

       if (!exists(hedef))
       {
           spawnProcess(["convert", kaynak, "-resize", boyut, hedef]);
       }

       return hedef;
   }
}

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 15, 2016

Bu sınıfın gelişeceğini söylediğin için sözü bile edilmemeli ama bir kaç noktanın üzerinde durulabilir:

  • Klasörlerin her Resim nesnesinde ayrı kopyaları olmasına gerek yok. Her ikisi de modül düzeyinde enum string olabilirler.

  • O zaman boyutlandır'ın en azından şimdiki haliyle sınıf üyesi olmaya ihtiyacı kalmaz ve o da serbest bir işlev olabilir. Eğer ileride sınıf üyesi olacaksa, 'dosya' parametresi de kurucuya verilebilir ve Resim'in bir üye değişkeni olur.

  • Dizgileri ~ işleci ile birleştirmek yerine format() daha iyi olabilir çünkü format() tek dizgi üretir ama her ~ işleci farklı bir dizgi üretmek zorundadır. Örneğin, a~b~c dendiğinde önce a ile b'nin birleşiminden bir dizgi üretilir, sonra ona c'nin eklenmesinden başka bir dizgi üretilir. Küçük ve çoğu durumda önemsiz bir konu ama bazı özel durumlarda bilinmesi gerekebilir.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 17, 2016

Alıntı (acehreli:1481872279):

>
  • Klasörlerin her Resim nesnesinde ayrı kopyaları olmasına gerek yok. Her ikisi de modül düzeyinde enum string olabilirler.

Söylediğinde kesinlikle haklısın. Aslında bunu bende düşündüm ama bildiğim kadarıyla enum değeri derleme zamanında bilinmeli. Bense bu adres için dinamik bir yapı kurmak istiyorum örneğin çalıştırılabilir dosyanın adresini baz alacak bir yol yapısı gibi. Bu durumda enum kullanmak mümkün mü?

Alıntı (acehreli:1481872279):

>
  • O zaman boyutlandır'ın en azından şimdiki haliyle sınıf üyesi olmaya ihtiyacı kalmaz ve o da serbest bir işlev olabilir. Eğer ileride sınıf üyesi olacaksa, 'dosya' parametresi de kurucuya verilebilir ve Resim'in bir üye değişkeni olur.

Bu noktada önemli. Ben bilinçli olarak dosya parametresini kurucuya vermiyorum. Bilmem bu noktada doğru mu yapıyorum. Düşüncem şöyle kullanıcı (yani ben :)) Bir tane Resim nesnesi örneği oluşturup onun üzerinden bir çok defa boyutlandır metodunu çağırabileyim. Aksi taktirde her boyutlandıma işleminden önce Resim sınıfının bir örneğini oluşturmak gerekir diye düşünüyorum. Ancak bu konuda önerilere açığım.

Alıntı (acehreli:1481872279):

>
  • Dizgileri ~ işleci ile birleştirmek yerine format() daha iyi olabilir çünkü format() tek dizgi üretir ama her ~ işleci farklı bir dizgi üretmek zorundadır. Örneğin, a~b~c dendiğinde önce a ile b'nin birleşiminden bir dizgi üretilir, sonra ona c'nin eklenmesinden başka bir dizgi üretilir. Küçük ve çoğu durumda önemsiz bir konu ama bazı özel durumlarda bilinmesi gerekebilir.

Birleştirme ~ işlecinin bu özelliğinden haberim yoktu. Eğer durum buysa imkan olduğu sürece format() kullanmak daha doğru olur.

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 17, 2016

Dosya yolu konusunda haklısın; çalışma zamanında olacaksa enum olamaz. Resmin tam yolunu tutmak yeterli olacaktır.

boyutlandır() gibi işlevler konusunda ben hep şöyle düşünüyorum: Eğer işlemleri sırasında nesne üyelerine ihtiyacı olmayacaksa, yani tamamen parametreleri ile işleyebiliyorsa, üye işlev olmasına gerek yok. Yani, eğer tam dosya yolunu alsa serbest işlev olabilir. Öte yandan, belirli bir resim nesnesine "kendini boyutlandır" demek istiyorsak o zaman dosya yolunu parametre olarak vermeyiz. Neyse... Bunları biliyorsun zaten. :) Ama özetlersek, ben de başka bir çok saygı duyduğum programcı gibi önce serbest işlev düşünüyorum.

Evet, ~ işleci ne yazık ki en yavaş birleştirme olanaklarından birisi. Öte yandan, derleme zamanında hiçbir sakıncası yok ve format() gibi ek olanakları gerektirmediğinden daha kullanışlı oluyor.

Ali

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

December 18, 2016

Alıntı (acehreli:1482020571):

>

boyutlandır() gibi işlevler konusunda ben hep şöyle düşünüyorum: Eğer işlemleri sırasında nesne üyelerine ihtiyacı olmayacaksa, yani tamamen parametreleri ile işleyebiliyorsa, üye işlev olmasına gerek yok. Yani, eğer tam dosya yolunu alsa serbest işlev olabilir. Öte yandan, belirli bir resim nesnesine "kendini boyutlandır" demek istiyorsak o zaman dosya yolunu parametre olarak vermeyiz. Neyse... Bunları biliyorsun zaten. :) Ama özetlersek, ben de başka bir çok saygı duyduğum programcı gibi önce serbest işlev düşünüyorum.

"Bildiğim tek şey hiçbir şey bilmediğimdir." sözünü hatırladım bir an, bende aslında bunları bilmiyorum :)

Yazdıklarına katılıyorum. boyutlandır() işlevi şu hali ile zaten tüm işi tek başına yapıyor. Bunu serbest bir işlev olarak resim modülü içine eklemek hem daha pratik hemde daha kullanışlı olur.

Resim sınıfının amacı boyutlandır() işlevi için gerek olan resim adresi işlevinide içerecek olması. Kodlarda sadece adres olarak görünsede benim amacım bu adresi oluşturan bir işlevide Resim sınıfı içine eklemekti. Böylece kullanıcı sadece elinde bulunan resim adını girecek ve arka planda resim yolu hakkında hiçbir bilgisi olmadan veya işletim sistemi farklılıkları ile uğraşmadan sistemi kullanabilecek.

Ancak bunu resim modülü içindeki iki serbest işlev ilede yapmak mümkün aslında. Peki burada seçim nasıl olmalı?

--
[ Bu gönderi, http://ddili.org/forum'dan dönüştürülmüştür. ]

« First   ‹ Prev
1 2