Forem: Barış Bideratan

API Endpoint Tasarımında Küçük Bir Detay, Büyük Bir Fark

Barış Bideratan — Mon, 11 May 2026 12:37:21 +0000

Geçenlerde X’te gezinirken bir gönderiye denk geldim. Bir junior geliştiricinin tasarladığı iki endpoint paylaşılmıştı ve buradaki tasarım hatasının ne olduğu soruluyordu.

Endpoint’ler şunlardı:

GET /api/v1/followers/verified

GET /api/v1/followers/unverified

İlk bakışta çalışır gibi görünüyor. Hatta ne yapmak istediği de gayet anlaşılır: doğrulanmış takipçileri getir, doğrulanmamış takipçileri getir.

Ama API tasarımında mesele sadece “anlaşılıyor mu?” değil. Asıl mesele, doğru modellenmiş mi?

Buradaki problem şu: verified ve unverified, sanki followers altında ayrı birer kaynakmış gibi davranıyor. Oysa burada gerçek kaynak followers. verified ise bu kaynağın bir özelliği, yani filtreleme kriteri.

Daha temiz yaklaşım şu olurdu:

GET /api/v1/followers?verified=true

GET /api/v1/followers?verified=false

Burada ayrım çok daha net.

Path bize hangi kaynağa eriştiğimizi söylüyor: followers.

Query parametre ise bu kaynağı nasıl filtreleyeceğimizi söylüyor: verified=true veya verified=false.

Bence iyi API tasarımında en kritik ayrımlardan biri bu:

Path resource’u anlatır, query parametre filtreyi anlatır.

Bu ayrım küçük gibi görünüyor ama proje büyüdükçe ciddi fark yaratıyor.

Bugün sadece iki durum olabilir: verified ve unverified. Ama yarın işin içine pending, blocked, suspended, muted gibi başka durumlar da girebilir. Eğer her durumu ayrı endpoint olarak tasarlarsak API bir süre sonra şuna döner:

/followers/verified

/followers/unverified

/followers/pending

/followers/blocked

/followers/suspended

Bu yapı hem gereksiz endpoint kalabalığı oluşturur hem de aynı listeleme mantığını farklı route’lara dağıtır. Halbuki tek bir listeleme endpoint’i üzerinden bunu çok daha temiz yönetebiliriz:

GET /api/v1/followers?status=verified

GET /api/v1/followers?status=unverified

GET /api/v1/followers?status=pending

GET /api/v1/followers?status=blocked

Burada status kullanmak, özellikle ileride farklı durumlar eklenecekse daha esnek bir tercih olur. Eğer sistem gerçekten sadece doğrulanmış/doğrulanmamış bilgisinden ibaretse verified=true/false yeterli olabilir. Ama domain büyüyecekse status daha sağlıklı modelleme sağlar.

Bu örnek bana şunu tekrar hatırlattı: API tasarımı sadece route yazmak değil, aynı zamanda domain’i doğru okumak işi.

“Ben burada neyi kaynak olarak görüyorum, neyi filtre olarak görüyorum?” sorusunu doğru sormak gerekiyor.

Çünkü yanlış modelleme ilk başta çok sorun çıkarmayabilir. Endpoint çalışır, frontend veriyi alır, herkes yoluna devam eder. Ama birkaç ay sonra yeni filtreler, yeni durumlar, yeni listeleme ihtiyaçları geldikçe tasarımın zayıf tarafları ortaya çıkar.

Ben olsam bu örnekte endpoint’i şöyle tasarlardım:

GET /api/v1/followers?verified=true

veya daha geniş düşünüyorsam:

GET /api/v1/followers?status=verified

Aynı endpoint üzerine sayfalama, sıralama ve arama da rahatça eklenebilir:

GET /api/v1/followers?status=verified&page=2

GET /api/v1/followers?status=verified&sort=created_at

GET /api/v1/followers?status=verified&search=baris

Böylece hem endpoint sayısı artmaz hem de API’nin davranışı daha tahmin edilebilir olur.

Kısacası, /followers/verified çalışabilir ama iyi modellenmiş bir endpoint değildir. Çünkü verified burada ayrı bir kaynak değil, followers listesinin filtresidir.

Özetle:

Resource path’te durur. Filtre query parametrede durur.

Laravel’de Backed Enum Nedir? Pure Enum ile Farkı Ne?

Barış Bideratan — Sat, 09 May 2026 15:52:58 +0000

Laravel’de enum kullanmaya başlayınca ilk karşılaşılan kavramlardan biri şu oluyor:

Backed enum ne demek?

İlk bakışta biraz “fazla akademik” gibi duran bir terim. Ama aslında olay oldukça basit:

Backed enum, her enum case’inin arkasında gerçek bir string veya int değer taşıdığı enum türüdür.

Yani enum sadece PHP tarafında sembolik bir isimden ibaret değildir; aynı zamanda veritabanına yazılabilecek, request’ten gelebilecek veya API response’unda kullanılabilecek gerçek bir değere sahiptir.

Bu yazıda Laravel üzerinden backed enum mantığını, pure enum’dan farkını ve günlük projelerde nasıl kullanılacağını anlatacağım.

Enum nedir?

Enum, belirli bir alanın alabileceği değerleri kontrollü hale getiren bir yapıdır.

Mesela bir kullanıcı rolü düşünelim:

admin
editor
user

Normalde bunları string olarak kullanabiliriz:

if ($user->role === 'admin') {
    // ...
}

Ama bu kullanımın birkaç problemi var:

Yazım hatalarına açık.
Her yerde string tekrar ediyor.
IDE desteği zayıf.
Refactor yapmak zorlaşıyor.
Sistemde hangi roller var, tek bir yerden anlaşılmıyor.

Enum ile bu değerleri tek bir yerde toplarız:

namespace App\Enums;

enum UserRole: string
{
    case Admin = 'admin';
    case Editor = 'editor';
    case User = 'user';
}

Artık rol kontrolünü şöyle yapabiliriz:

if ($user->role === UserRole::Admin) {
    // ...
}

Bu hem daha okunabilir hem de daha güvenli.

Pure Enum ve Backed Enum farkı

PHP’de temel olarak iki enum türü var:

Pure enum
Backed enum

Laravel’de de aslında bu PHP enum’larını kullanıyoruz. Laravel burada enum’ları model cast, validation ve request işlemlerinde daha pratik hale getiriyor.

Pure Enum nedir?

Pure enum, case’lerin arkasında herhangi bir değer taşımadığı enum türüdür.

enum UserRole
{
    case Admin;
    case Editor;
    case User;
}

Burada Admin, Editor ve User sadece enum case’leridir.

Şunu yapabiliriz:

$role = UserRole::Admin;

Ama şunu yapamayız:

UserRole::Admin->value;

Çünkü pure enum’da value yoktur.

Sadece name vardır:

UserRole::Admin->name; // "Admin"

Pure enum daha çok uygulama içinde sembolik durumları belirtmek için kullanılabilir. Fakat veritabanına değer yazmak istediğimiz senaryolarda genellikle yeterli olmaz.

Backed Enum nedir?

Backed enum’da her case’in arkasında gerçek bir değer bulunur.

Bu değer yalnızca iki tür olabilir:

string
int

Örneğin:

namespace App\Enums;

enum UserRole: string
{
    case Admin = 'admin';
    case Editor = 'editor';
    case User = 'user';
}

Burada enum case’i şudur:

UserRole::Admin

Bu case’in arkasındaki gerçek değer ise şudur:

UserRole::Admin->value; // "admin"

Yani:

case Admin = 'admin';

satırında iki farklı şey var:

UserRole::Admin->name;  // "Admin"
UserRole::Admin->value; // "admin"

name, PHP tarafındaki case adıdır.
value, dış dünyaya veya veritabanına yazılacak gerçek değerdir.

Backed enum neden Laravel’de daha çok kullanılır?

Çünkü Laravel projelerinde enum kullandığımız alanların çoğu veritabanıyla ilişkilidir.

Örneğin:

role
status
type
payment_status
order_status
notification_channel
provider

Bu alanların veritabanında bir karşılığı vardır.

Mesela users tablosunda şöyle bir değer tutmak isteriz:

role = admin

Ama PHP tarafında bu değeri düz string olarak kontrol etmek yerine enum olarak kullanmak isteriz:

$user->role === UserRole::Admin

İşte backed enum burada çok işe yarar.

Laravel’de enum dosyası oluşturmak

Laravel’de enum oluşturmak için Artisan komutu kullanılabilir:

php artisan make:enum Enums/UserRole

Bu komutla enum dosyasını app/Enums/UserRole.php altında tutabiliriz.

Örnek enum:

namespace App\Enums;

enum UserRole: string
{
    case Admin = 'admin';
    case Editor = 'editor';
    case User = 'user';
}

Ben genelde enum’ları app/Enums klasörü altında tutmayı daha düzenli buluyorum. Çünkü proje büyüdükçe enum sayısı artıyor ve bunların app dizininin altında dağınık durması pek hoş olmuyor.

Laravel model cast ile kullanım

Enum’un en güzel taraflarından biri, Laravel model cast ile çok temiz çalışmasıdır.

Örneğin users tablosunda role alanımız olsun.

Migration tarafında bunu basit bir string kolon olarak tutabiliriz:

$table->string('role')->default(UserRole::User->value);

Modelde ise cast tanımlarız:

use App\Enums\UserRole;

protected function casts(): array
{
    return [
        'role' => UserRole::class,
    ];
}

Bundan sonra Laravel, veritabanındaki string değeri otomatik olarak enum’a çevirir.

Yani veritabanında şu varsa:

role = admin

Modelde şunu elde ederiz:

$user->role; // UserRole::Admin

Artık kontrolü şöyle yapabiliriz:

if ($user->role === UserRole::Admin) {
    // Admin işlemleri
}

Kaydetmek de oldukça temizdir:

$user->role = UserRole::Editor;
$user->save();

Laravel bunu veritabanına otomatik olarak şöyle yazar:

editor

Burada bizim manuel olarak ->value vermemize gerek kalmaz. Laravel enum cast sayesinde bunu bizim yerimize halleder.

Form request ve validation tarafı

Backed enum’ları request doğrulamada da kullanabiliriz.

use App\Enums\UserRole;
use Illuminate\Validation\Rule;

$request->validate([
    'role' => ['required', Rule::enum(UserRole::class)],
]);

Bu sayede role alanı sadece enum içinde tanımlı değerlerden biri olabilir.

Yani şunlar geçerlidir:

admin
editor
user

Ama şu geçerli olmaz:

super_admin

Bu küçük gibi görünen şey aslında büyük projelerde ciddi fayda sağlar. Çünkü veri daha sisteme girerken kontrol altına alınır.

`from()` ve `tryFrom()` farkı

Backed enum’ların güzel özelliklerinden biri de string veya int değerden enum case’i oluşturabilmemizdir.

$role = UserRole::from('admin');

Bu bize şunu döndürür:

UserRole::Admin

Ama dikkat etmek gerekir. Eğer geçersiz bir değer verirsek:

UserRole::from('wrong-role');

PHP hata fırlatır.

Daha güvenli kullanım için tryFrom() tercih edilebilir:

$role = UserRole::tryFrom('admin');

Geçerli değer varsa enum case’i döner:

UserRole::Admin

Geçersiz değer varsa null döner:

$role = UserRole::tryFrom('wrong-role'); // null

Ben genelde dışarıdan gelen, güvenmediğim verilerde tryFrom() kullanmayı daha doğru buluyorum.

Enum içine yardımcı metotlar eklemek

Enum’lar sadece sabit değer listesi olmak zorunda değil. İçlerine metot da ekleyebiliriz.

Mesela kullanıcı rollerine ekranda gösterilecek label değerleri ekleyelim:

namespace App\Enums;

enum UserRole: string
{
    case Admin = 'admin';
    case Editor = 'editor';
    case User = 'user';

    public function label(): string
    {
        return match ($this) {
            self::Admin => 'Yönetici',
            self::Editor => 'Editör',
            self::User => 'Kullanıcı',
        };
    }
}

Kullanım:

$user->role->label();

Bu şekilde enum sadece teknik değer tutmaz, aynı zamanda o değere ait davranışı da taşıyabilir.

Bu özellikle admin panel, select input, filtreleme ve raporlama gibi alanlarda çok işe yarar.

Select input için options üretmek

Enum’dan select option üretmek de güzel bir kullanım örneğidir.

public static function options(): array
{
    return collect(self::cases())
        ->mapWithKeys(fn (self $role) => [
            $role->value => $role->label(),
        ])
        ->toArray();
}

Artık şunu yapabiliriz:

UserRole::options();

Çıktı:

[
    'admin' => 'Yönetici',
    'editor' => 'Editör',
    'user' => 'Kullanıcı',
]

Bu yaklaşım sayesinde hem backend hem frontend tarafında aynı değerleri daha kontrollü kullanabiliriz.

Veritabanında SQL enum mu, string kolon mu?

Burada önemli bir tercih var.

MySQL tarafında gerçekten enum kolon tipi kullanabiliriz. Ama ben çoğu Laravel projesinde string kolon kullanmayı daha esnek buluyorum.

Örneğin:

$table->string('status');

Neden?

Çünkü enum değerleri zamanla değişebilir. Yeni bir status eklemek isteyebiliriz. SQL enum kullanırsak veritabanı şemasını değiştirmek gerekir. String kolon kullanıp uygulama tarafında PHP enum ile kontrol sağlamak genelde daha rahat bir yaklaşımdır.

Yani kontrolü database seviyesinde değil, uygulama seviyesinde enum ile sağlamış oluruz.

Bu her zaman tek doğru demek değil. Ama Laravel projelerinde çoğu senaryo için pratik ve sürdürülebilir bir tercih olduğunu düşünüyorum.

Ne zaman backed enum kullanmalıyız?

Şu tarz alanlarda backed enum oldukça mantıklıdır:

role
status
type
category
payment_status
order_status
provider
channel
visibility
priority

Mesela:

enum OrderStatus: string
{
    case Pending = 'pending';
    case Paid = 'paid';
    case Shipped = 'shipped';
    case Cancelled = 'cancelled';
}

Ya da:

enum PaymentStatus: string
{
    case Waiting = 'waiting';
    case Successful = 'successful';
    case Failed = 'failed';
}

Bu tarz alanlarda backed enum kullanmak, magic string kullanımını ciddi ölçüde azaltır.

Ne zaman pure enum kullanılır?

Pure enum’u ise daha çok veritabanına yazılmayacak, sadece uygulama içinde anlam taşıyan durumlarda düşünebiliriz.

Örneğin:

enum ModalState
{
    case Open;
    case Closed;
}

Ama açık konuşmak gerekirse Laravel projelerinde benim elim çoğu zaman backed enum’a gidiyor. Çünkü genelde bu değerler bir yerden geliyor, bir yere yazılıyor veya API ile dış dünyaya açılıyor.

Kötü kullanım örneği

Şöyle bir kod düşünelim:

if ($user->role === 'admin') {
    //
}

if ($user->role === 'editor') {
    //
}

if ($user->role === 'user') {
    //
}

Bu kod çalışır. Ama uzun vadede çok güven vermiyor.

Daha sonra biri yanlışlıkla şöyle yazabilir:

if ($user->role === 'admn') {
    //
}

PHP buna kızmaz. Çünkü sonuçta bu da bir string.

Ama enum kullandığımızda:

if ($user->role === UserRole::Admin) {
    //
}

IDE bizi destekler. Refactor kolaylaşır. Yanlış değer kullanma ihtimali azalır. Kodun niyeti daha açık hale gelir.

Bence enum’un asıl değeri de burada:
Sadece daha “modern” göründüğü için değil, kodun anlamını netleştirdiği için kullanılır.

Kısa özet

Backed enum, arkasında gerçek bir string veya int değer taşıyan enum türüdür.

Pure enum:

enum UserRole
{
    case Admin;
}

Backed enum:

enum UserRole: string
{
    case Admin = 'admin';
}

Laravel projelerinde backed enum özellikle veritabanı, request, validation ve API response gibi alanlarda çok kullanışlıdır.

Benim genel yaklaşımım şu:

Veritabanına yazılacaksa backed enum
Request’ten gelecekse backed enum
API’de dönecekse backed enum
Sadece uygulama içi sembolik bir durumsa pure enum düşünülebilir

Enum kullanmak küçük projede bile kodu daha okunabilir yapar. Büyük projede ise magic string karmaşasını azaltır, refactor sürecini kolaylaştırır ve domain’i daha anlaşılır hale getirir.

Kısacası, Laravel’de role, status, type gibi alanlarda hâlâ düz string’lerle ilerliyorsak, backed enum’a geçmek çoğu zaman daha temiz bir adımdır.

Laravel’de Neden Kod İçinde env() Kullanılmamalı?

Barış Bideratan — Mon, 27 Apr 2026 12:34:09 +0000

Laravel projelerinde sık gördüğümüz bir kullanım var:

$apiKey = env('SMS_API_KEY');

veya

if (env('PAYMENT_PROVIDER') === 'iyzico') {
    // ...
}

Local ortamda bu kod çoğu zaman çalışır. Bu yüzden ilk bakışta yanlış gibi görünmez. Ama Laravel’de genel kural şudur:

env() sadece config dosyalarında kullanılmalı, uygulama kodunda config() tercih edilmelidir.

Yani controller, service, job, command, middleware veya model içinde doğrudan env() kullanmak iyi bir pratik değildir.

Doğru akış

Laravel’de ideal akış şudur:

.env -> config/*.php -> config()

Örneğin .env dosyasında şöyle değerler olsun:

SMS_API_KEY=example-key
SMS_API_SECRET=example-secret
SMS_SENDER=MYAPP

Bu değerleri doğrudan uygulama kodunda okumak yerine config dosyasına taşımalıyız:

// config/services.php

return [
    'sms' => [
        'api_key' => env('SMS_API_KEY'),
        'api_secret' => env('SMS_API_SECRET'),
        'sender' => env('SMS_SENDER', 'APP'),
    ],
];

Sonra uygulama içinde şöyle kullanmalıyız:

$apiKey = config('services.sms.api_key');

Bu küçük fark, özellikle production ortamında önem kazanır.

Asıl sebep: config cache

Production ortamında Laravel projelerinde genellikle şu komut çalıştırılır:

php artisan config:cache

Bu komut, tüm config dosyalarını tek bir cache dosyasında toplar. Böylece Laravel her request’te config dosyalarını tekrar tekrar okumaz.

Ama bunun önemli bir sonucu vardır:

Config cache aktifken .env dosyası doğrudan okunmayabilir.

Bu yüzden uygulama kodunda şu kullanım risklidir:

env('SMS_API_KEY');

Çünkü production’da beklediğin değeri alamayabilirsin.

Ama şu kullanım güvenlidir:

config('services.sms.api_key');

Çünkü bu değer config cache içine zaten alınmıştır.

Yanlış kullanım

namespace App\Services;

final class SmsService
{
    public function send(string $phone, string $message): void
    {
        $apiKey = env('SMS_API_KEY');

        // SMS gönder...
    }
}

Bu kod localde çalışıp production’da sorun çıkarabilir. Çünkü localde genellikle config cache yoktur, production’da ise vardır.

Doğru kullanım

// config/services.php

return [
    'sms' => [
        'api_key' => env('SMS_API_KEY'),
        'api_secret' => env('SMS_API_SECRET'),
        'sender' => env('SMS_SENDER', 'APP'),
    ],
];

namespace App\Services;

final class SmsService
{
    public function send(string $phone, string $message): void
    {
        $apiKey = config('services.sms.api_key');
        $apiSecret = config('services.sms.api_secret');
        $sender = config('services.sms.sender');

        // SMS gönder...
    }
}

Burada servis artık .env dosyasına doğrudan bağımlı değildir. Laravel’in config sistemi üzerinden çalışır.

Büyük servislerde ayrı config dosyası daha iyi olabilir

Eğer ayarlar büyüyorsa config/services.php içine her şeyi koymak yerine ayrı bir dosya oluşturmak daha okunabilir olur.

Örneğin:

// config/sms.php

return [
    'provider' => env('SMS_PROVIDER', 'netgsm'),
    'api_key' => env('SMS_API_KEY'),
    'api_secret' => env('SMS_API_SECRET'),
    'sender' => env('SMS_SENDER', 'APP'),
    'timeout' => (int) env('SMS_TIMEOUT', 10),
];

Kullanım:

$provider = config('sms.provider');
$timeout = config('sms.timeout');

Bu yapı özellikle SMS, ödeme, yapay zeka, takvim, WhatsApp veya dış servis entegrasyonlarında daha düzenli olur.

Test yazarken de config daha kullanışlıdır

Doğrudan env() kullanırsan testlerde değer değiştirmek zahmetli hale gelir.

Ama config kullanıyorsan test içinde kolayca override edebilirsin:

config()->set('sms.provider', 'fake');

Örneğin:

public function test_it_uses_fake_sms_provider(): void
{
    config()->set('sms.provider', 'fake');

    // test...
}

Bu, testleri daha kontrollü ve temiz hale getirir.

Bir adım ileri: typed config object

Daha büyük projelerde config değerlerini sürekli string key ile çağırmak da dağınıklık oluşturabilir:

config('sms.api_key');
config('sms.api_secret');
config('sms.sender');
config('sms.timeout');

Bu durumda küçük bir config object kullanılabilir:

final readonly class SmsConfig
{
    public function __construct(
        public string $apiKey,
        public string $apiSecret,
        public string $sender,
        public int $timeout,
    ) {}
}

Service provider içinde bağlanabilir:

$this->app->singleton(SmsConfig::class, function () {
    return new SmsConfig(
        apiKey: config('sms.api_key'),
        apiSecret: config('sms.api_secret'),
        sender: config('sms.sender'),
        timeout: config('sms.timeout'),
    );
});

Sonra servis içinde:

final readonly class SmsService
{
    public function __construct(
        private SmsConfig $config,
    ) {}

    public function send(string $phone, string $message): void
    {
        // $this->config->apiKey
    }
}

Bu Laravel’in zorunlu standardı değildir. Her config için object yazmak da gereksizdir. Ama kritik ve büyüyen entegrasyonlarda tip güvenliği, IDE desteği ve test edilebilirlik açısından temiz bir mimari tercih olabilir.

env() config dosyalarında, config() uygulama kodunda kullanılır.

Bu basit alışkanlık, localde çalışan ama production’da sorun çıkaran birçok hatanın önüne geçer.

PHP’de Global Function Resolution: strlen() mi, \strlen() mi?

Barış Bideratan — Mon, 27 Apr 2026 10:53:55 +0000

PHP’de bazen şöyle kodlar görürüz:

strlen($name);

Bazı projelerde ise aynı fonksiyon şöyle yazılır:

\strlen($name);

İlk bakışta gereksiz bir detay gibi görünebilir. Sonuçta ikisi de string uzunluğu hesaplıyor, değil mi?

Evet, çoğu zaman sonuç aynı olur. Ama PHP’nin namespace içindeki fonksiyon çözümleme davranışını bilirsek, bu küçük farkın neden ortaya çıktığını daha iyi anlarız.

Bu konu özellikle framework, package, library veya performans hassasiyeti olan kodlar yazarken önem kazanır.

Kısa cevap

PHP’de namespaced bir dosya içindeysen:

namespace App\Services;

strlen($value);

PHP önce şu fonksiyonu arar:

App\Services\strlen()

Eğer bulamazsa global namespace’e düşer ve şunu çalıştırır:

strlen()

Ama şöyle yazarsan:

\strlen($value);

PHP doğrudan global namespace’teki strlen fonksiyonunu çağırır.

Yani:

strlen()

ile

\strlen()

çoğu durumda aynı sonucu üretir, fakat çözümleme yolları farklıdır.

Namespace içinde fonksiyon çağırmak

Şu örneğe bakalım:

<?php

namespace App\Support;

function example(string $text): int
{
    return strlen($text);
}

Buradaki strlen() çağrısı global PHP fonksiyonu gibi görünür. Ama PHP bunu doğrudan global strlen() olarak okumaz.

Önce mevcut namespace içinde fonksiyon arar:

App\Support\strlen()

Eğer böyle bir fonksiyon yoksa, PHP fallback yapar ve global fonksiyonu çağırır:

strlen()

Bu yüzden kod çalışır.

Peki `\strlen()` ne yapar?

Başına \ koyduğumuzda PHP’ye şunu söylemiş oluruz:

Bu fonksiyonu mevcut namespace içinde arama. Direkt global namespace’ten çağır.

Örnek:

namespace App\Support;

function example(string $text): int
{
    return \strlen($text);
}

Burada PHP doğrudan global strlen() fonksiyonuna gider.

Yani namespace fallback mekanizmasına hiç girmez.

Farkı daha net görelim

Şöyle bir kod düşünelim:

<?php

namespace App\Support;

function strlen(string $value): int
{
    return 999;
}

function test(): void
{
    echo strlen('Barış');
}

Çıktı:

Çünkü strlen() çağrısı önce mevcut namespace içinde aranır ve App\Support\strlen() bulunduğu için o çalışır.

Ama şöyle yazarsak:

<?php

namespace App\Support;

function strlen(string $value): int
{
    return 999;
}

function test(): void
{
    echo \strlen('Barış');
}

Çıktı:

Çünkü \strlen() doğrudan global PHP fonksiyonunu çağırır.

Buradaki 6, "Barış" string’inin byte uzunluğudur. Türkçe karakterlerden dolayı karakter sayısı ile byte sayısı farklı olabilir. Karakter sayısı gerekiyorsa mb_strlen() kullanmak daha doğru olur.

Bu davranış sadece fonksiyonlarda mı var?

PHP’de namespace çözümleme davranışı fonksiyonlar, sabitler ve class’lar için farklı çalışır.

Fonksiyonlarda fallback vardır:

namespace App;

strlen('test');

PHP önce App\strlen() arar, bulamazsa global strlen() fonksiyonuna gider.

Sabitlerde de benzer fallback davranışı vardır:

namespace App;

echo PHP_VERSION;

PHP önce App\PHP_VERSION arayabilir, sonra global PHP_VERSION sabitine düşebilir.

Ama class’larda durum farklıdır.

namespace App;

$date = new DateTime();

Bu kod global DateTime sınıfını otomatik bulmaz. PHP bunu şöyle yorumlar:

App\DateTime

Bu yüzden doğru kullanım şudur:

$date = new \DateTime();

veya:

use DateTime;

$date = new DateTime();

Bu ayrım önemli. Fonksiyonlarda global fallback varken, class’larda aynı rahatlık yoktur.

Neden bazı projeler `\strlen()` kullanır?

Bunun birkaç sebebi var.

1. Açık niyet

\strlen($value);

şunu açıkça söyler:

Ben PHP’nin global built-in fonksiyonunu çağırıyorum.

Bu özellikle framework, SDK veya package geliştirirken güzel bir sinyaldir.

Mesela:

namespace Vendor\Package;

final class StringHelper
{
    public static function length(string $value): int
    {
        return \strlen($value);
    }
}

Burada \strlen() kullanmak, kodu okuyan kişiye “bu global PHP fonksiyonu” mesajını net verir.

2. Namespace içinde aynı isimli fonksiyonlardan etkilenmemek

Bir namespace içinde aynı isimde fonksiyon tanımlanmış olabilir:

namespace App\Support;

function time(): int
{
    return 123456;
}

Bu durumda:

time();

çağrısı App\Support\time() fonksiyonunu çalıştırır.

Ama:

\time();

global PHP time() fonksiyonunu çağırır.

Bu, özellikle testlerde veya özel helper fonksiyonlarında fark yaratabilir.

3. Çok küçük performans farkı

Geçmişte \strlen() gibi fully-qualified global function çağrılarının daha doğrudan çözümlendiği için küçük performans avantajı sağlayabileceği konuşulurdu.

Modern PHP sürümlerinde OPcache ve engine optimizasyonları sayesinde bu fark çoğu uygulamada pratik olarak önemsizdir.

Yani normal bir Laravel projesinde:

strlen($name);

yerine her yerde:

\strlen($name);

yazmak büyük bir performans mucizesi yaratmaz.

Ama düşük seviyeli bir package, yüksek frekanslı bir parser, serializer, validator veya framework core kodu yazıyorsan \strlen(), \is_array(), \count(), \sprintf() gibi kullanımlar tercih edilebilir.

`use function` alternatifi

PHP’de fonksiyonları import etmek de mümkündür.

namespace App\Support;

use function strlen;
use function array_filter;

function example(array $items, string $name): array
{
    $length = strlen($name);

    return array_filter($items);
}

Bu kullanım da niyeti açık hale getirir.

Daha okunabilir bir örnek:

namespace App\Support;

use function is_string;
use function trim;
use function strlen;

final class UsernameValidator
{
    public function validate(mixed $value): bool
    {
        return is_string($value)
            && strlen(trim($value)) >= 3;
    }
}

Burada fonksiyonların global PHP fonksiyonları olduğu üstte açıkça belirtilmiş olur.

Ama pratikte çoğu PHP/Laravel projesinde bu kadar detaylı import kullanılmaz. Daha çok package veya library seviyesinde karşımıza çıkar.

Laravel projelerinde ne yapmalı?

Laravel tarafında günlük uygulama kodunda şu kullanım gayet normaldir:

if (strlen($request->name) < 3) {
    // ...
}

Bunu illa şöyle yazmak zorunda değilsin:

if (\strlen($request->name) < 3) {
    // ...
}

Benim pratik önerim şu olur:

Basit application code içinde okunabilirliği bozmayacak şekilde normal kullanım yeterlidir:

count($items);
is_array($value);
trim($name);

Ama reusable package, framework-level helper, performans hassas kod veya namespace çakışması ihtimali olan bir yerde fully-qualified kullanım daha temiz olabilir:

\count($items);
\is_array($value);
\trim($name);

Yani mesele “her zaman böyle yaz” değil; kodun bağlamına göre doğru seçimi yapmak.

Testlerde bu davranış işe yarayabilir

Namespace function resolution bazen testlerde bilinçli olarak kullanılabilir.

Örneğin production kodunda şöyle bir kullanım var diyelim:

namespace App\Services;

final class TokenGenerator
{
    public function generate(): string
    {
        return bin2hex(random_bytes(16));
    }
}

Burada random_bytes() unqualified çağrılmıştır.

Test ortamında aynı namespace altında özel bir fonksiyon tanımlayarak bu davranışı kontrol etmek teorik olarak mümkündür:

namespace App\Services;

function random_bytes(int $length): string
{
    return str_repeat('a', $length);
}

Bu durumda App\Services namespace’i içindeki random_bytes() çağrısı önce bu fonksiyona bakabilir.

Ama production kodunda şöyle yazılmış olsaydı:

return \bin2hex(\random_bytes(16));

artık namespace içindeki override devreye girmezdi. Çünkü çağrı doğrudan global fonksiyona giderdi.

Bu teknik her projede önerilecek bir yöntem değildir, ama PHP’nin fonksiyon çözümleme mantığını anlamak açısından güzel bir örnektir.

Laravel'de Real-Time Facades Nedir? Nasıl Çalışır?

Barış Bideratan — Sun, 09 Nov 2025 11:40:50 +0000

Laravel, servis container yapısıyla dependency injection (bağımlılık enjeksiyonu) kullanımını kolaylaştırır. Ancak bazı durumlarda her servisi container üzerinden almak ya da özel bir Facade sınıfı oluşturmak gereksiz gelebilir. İşte Real-Time Facades bu noktada devreye giriyor.

Kısaca özetlemek gerekirse:

Real-Time Facades, herhangi bir sınıfı veya interface'i, özel bir Facade sınıfı yazmadan Facade gibi kullanmanı sağlar.

Facade Nedir?

Laravel’de Facade, container içindeki bir servise statik gibi görünen bir arabirim sunar.
Örneğin Cache::get() ya da Log::info() çağrıları aslında arka planda container içinden çözümlenir.

Ama her Facade için ayrı bir sınıf yazmak gerekir.
Örneğin App\Facades\MyService gibi.
Real-Time Facades ise bu işi senin yerine yapar.

Normal Kullanım vs Real-Time Facade

Önce klasik bir örnek üzerinden gidelim.

Klasik yöntem:

namespace App\Models;

use App\Services\Publisher;
use Illuminate\Database\Eloquent\Model;

class Podcast extends Model
{
    public function publish(Publisher $publisher)
    {
        $this->update(['published_at' => now()]);

        $publisher->publish($this);
    }
}

Burada Publisher sınıfını method parametresi olarak alıyoruz.
Gayet güzel ama her çağrıda bu parametreyi geçirmek gerekiyor.

Real-Time Facade ile:

namespace App\Models;

use Facades\App\Services\Publisher;
use Illuminate\Database\Eloquent\Model;

class Podcast extends Model
{
    public function publish()
    {
        $this->update(['published_at' => now()]);

        Publisher::publish($this);
    }
}

Bak farkı fark ettin mi?

Artık Publisher servisini parametre olarak geçmedik.
use Facades\App\Services\Publisher; yazarak Laravel’e “bu sınıfı facade gibi kullan” dedik.
Yani Publisher::publish() dediğimizde Laravel container’dan otomatik olarak App\Services\Publisher örneğini çözüp metodu çalıştırıyor.

Gerçekten “Statik” mi Çalışıyor?

Hayır.
Publisher::publish() statik gibi görünse de aslında container’dan dinamik olarak çözülüyor.
Bu sayede test ederken mock oluşturabiliyorsun:

Publisher::shouldReceive('publish')
    ->once()
    ->with($podcast);

Yani hem facade rahatlığını hem test edilebilirliği koruyorsun.

Gerçek Hayattan Bir Örnek

Diyelim ki bir Notifier servisin var:

namespace App\Services;

class Notifier
{
    public function sendEmail($to, $subject)
    {
        // E-posta gönderme işlemi
    }
}

Klasik kullanım:

$notifier = app(\App\Services\Notifier::class);
$notifier->sendEmail('test@example.com', 'Merhaba!');

Real-Time Facade ile:

use Facades\App\Services\Notifier;

Notifier::sendEmail('test@example.com', 'Merhaba!');

Tek satırla aynı işi yaptık.
Kod hem okunabilir hem sade.

Ne Zaman Kullanmalı?

Real-Time Facades harika bir kolaylık ama her yerde kullanmak doğru değil.

Kullan:
✅ Basit servis çağrılarında
✅ Model içindeki küçük yardımcı işlemlerde
✅ Hızlı prototip geliştirme aşamalarında

Kullanma:
❌ Büyük veya karmaşık servislerde
❌ Kodun bağımlılıklarını açık görmek istiyorsan
❌ Fazla mock işlemiyle test yazıyorsan

Kısacası, tıpkı kahve gibi:
Azı lezzet, fazlası çarpıntı. ☕

Özet

use Facades\ ile başlayan bir import yaptığında Laravel otomatik olarak Real-Time Facade oluşturur.
Arka planda container çözümlemesi yapılır, yani dependency injection hâlâ geçerlidir.
Testlerde shouldReceive() kullanarak mock oluşturabilirsin.
Kodun sadeleşir ama “nereden geliyor bu servis?” sorusu bazen bulanıklaşabilir.

APK Dosyalarını Düzenleme ve Yeniden İmzalama: Adım Adım Kılavuz

Barış Bideratan — Tue, 04 Feb 2025 07:08:58 +0000

Selamlar,

Bu makalede, bir Android APK dosyasını nasıl decompile edip, kodları inceleyip düzenleyebileceğinizi, ardından yeniden build, optimize ve imzalama işlemleriyle crack hazırlığınızı nasıl tamamlayacağınızı adım adım anlatacağım. Her bir adımı dikkatle uygulayarak süreci başarıyla tamamlayabilirsiniz. Bir sonraki makalemde de Frida ile javascript kullanarak neler yapabileceğinizi anlatacağım :)

1. APK Dosyasını Çıkarın (Extract)

İlk adımda, apktool kullanarak APK dosyasını extract etmeniz gerekiyor. Bu işlem, APK içeriğini smali dosyalarına ve kaynak dosyalara ayırarak düzenleme yapmanızı sağlar.

apktool d <path>

Burada <path> kısmına düzenlemek istediğiniz APK dosyasının yolunu yazmalısınız.

2. Kodları İnceleyin

Extract işleminin ardından, jadx aracı ile APK dosyasını açıp kodları inceleyin. Jadx, byte kodu okunabilir Java koduna çevirerek uygulamanın mantığını anlamanızı sağlar.

İpucu: Hangi kodlarda değişiklik yapmanız gerektiğine karar verirken, bu aracı kullanarak detaylı bir analiz yapabilirsiniz.

3. Smali Kodlarda Gerekli Değişiklikleri Yapın

Jadx ile incelediğiniz kodlarda emin olduğunuz kısımları belirleyin. Ardından, apktool ile extract ettiğiniz smali dosyaları arasında bu kod satırlarını bulun ve gerekli değişiklikleri uygulayın.

Dikkat: Smali kodlar üzerinde yapacağınız değişiklikler, uygulamanın çalışma mantığını etkileyebileceğinden, dikkatli ve özenli olun.

4. Değişikliklerden Sonra Build İşlemi

Yaptığınız düzenlemeler sonrasında, extract ettiğiniz dosyaların root dizininde iken yeniden build almanız gerekmektedir. Bunun için apktool’un build komutunu kullanın:

apktool b

Bu komut, düzenlenmiş dosyalarınızı yeniden derleyerek yeni bir APK oluşturur.

5. İmzalama İçin Key Oluşturun

Yeni build aldığınız APK’yı imzalayabilmek için öncelikle bir imzalama key’ine ihtiyacınız var. Bunun için keytool kullanarak aşağıdaki komutla key oluşturabilirsiniz:

keytool -genkey -v -keystore DOSYAADI.keystore -alias alias_name -keyalg RSA -keysize 2048 -validity 10000

Açıklama:
- DOSYAADI.keystore: Oluşturulacak keystore dosyasının adı.
- alias_name: Key’in alias adı.
- -keyalg RSA -keysize 2048: RSA algoritması ile 2048 bit büyüklüğünde key oluşturma.
- -validity 10000: Key’in geçerlilik süresi (gün olarak).

6. APK Dosyasını Zipalign ile Optimize Edin

Build işleminden sonra, APK dosyasını zipalign aracı ile optimize ederek hizalamaları düzenleyin. Bu işlem, APK performansını artırır ve yükleme sırasında hata olasılığını azaltır.

zipalign -v 4 original.apk original_zipaligned.apk

Not:
- original.apk: Orijinal build edilmiş APK dosyası.
- original_zipaligned.apk: Zipalign işlemi sonrası oluşacak optimize edilmiş APK dosyası.

7. APK Dosyasını İmzalama

Son adım olarak, uber-apk-signer aracını kullanarak APK dosyasını imzalayın. İmzalama, uygulamanın güvenliği açısından önemlidir ve imzasız APK’lar yüklenmeyebilir.

java -jar uber-apk-signer-1.3.0.jar --skipZipAlign --apks ./

Açıklama:
- --skipZipAlign: Zaten zipalign işlemini tamamladıysanız, tekrar yapmamak için bu parametreyi kullanabilirsiniz.
- --apks ./: İmzalanacak APK dosyasının bulunduğu dizini belirtir.

Sonuç

Yukarıdaki adımları sırasıyla takip ederek APK dosyasını extract ettiniz, kodları incelediniz, gerekli düzenlemeleri yaptınız, yeniden build aldınız, optimize ettiniz ve son olarak imzaladınız. Artık crack işleminiz için hazırlıklar tamam; hayırlı olsun, crack hazır :)

Unutmayın, bu tür işlemler sadece eğitim amaçlıdır. Gerçek bir ürün üzerinde asla denemeyin!

~/Android/Sdk

$ ---- apktool b && cd dist && zipalign -p -f 4 Obsidian-V1.3.objection.apk Obsidian-V1.3.objection_zipaligned.apk && java -jar uber-apk-signer-1.3.0.jar --skipZipAlign --apks ./

PHP’de Early Return: Kodunuzu Temizleyen Basit Bir Yaklaşım

Barış Bideratan — Thu, 09 Jan 2025 09:15:14 +0000

Merhaba Arkadaşlar!

Bugün sizlere yazdığımız kodları daha temiz ve okunabilir hale getiren bir yaklaşımdan bahsedeceğim: Early Return (Erken Dönüş). PHP'de bu yaklaşımı kullanarak hem kod yazma deneyiminizi iyileştirebilir hem de projelerinizin daha bakımı kolay bir hale gelmesini sağlayabilirsiniz.

Early Return Nedir?

Early return, fonksiyonların başında belirli bir koşul karşılandığında veya karşılanmadığında fonksiyonu erken sonlandırmak için kullandığımız bir tekniktir. Bu yöntem, kod içinde gereksiz iç içe bloklardan kurtulmamıza yardımcı olur ve yazım sürecini daha akıcı hale getirir.

Kısaca, bir “guard clause” olarak da adlandırılan bu teknik, “Eğer bu durum karşılanmıyorsa, şu anda dön” mantığıyla çalışır.

Neden Early Return Kullanmalıyız?

Kod yazarken hepimizin amacı daha okunabilir, anlaşılır ve bakımı kolay yapılar oluşturmaktır. Early return tam olarak bunu sağlar:

Okunabilirlik Artar: Kodunuz, gereksiz iç içe bloklardan kurtulduğu için daha temiz ve kolay anlaşılabilir hale gelir.
Hata Kontrolü Daha Kolay Olur: Hata durumlarını hemen kontrol edip ele almak, kodun ilerleyen kısımlarında yanlışların birikmesini önler.
Bakım Kolaylığı: Projenize yeni biri katıldığında veya siz bir süre sonra kodunuza geri döndünüzde, early return kullanan yapılar daha kolay çözülür.
Performans: Gereksiz şekilde fonksiyonun ilerleyen kısımlarını çalıştırmak yerine, önceden dönülerek zamandan tasarruf edilir.

Early Return Nasıl Kullanılır?

Hadi bir senaryo üzerinden early return'i inceleyelim.

Klasik Yaklaşım

Bir kullanıcının yaşını kontrol ettiğimizi düşünelim:

function checkAge($age) {
    if ($age >= 18) {
        echo "Giriş yapabilirsiniz.";
    } else {
        echo "Yaş sınırına uygun değilsiniz.";
    }
}

Bu kod işlevsel gibi görünse de, bir "else" bloğu barındırdığı için okunabilirliği bir miktar düşürebilir. Kod ilerledikçe iç içe geçen blokların arttığını hayal edin.

Early Return ile

Aynı senaryoyu early return kullanarak yazalım:

function checkAge($age) {
    if ($age < 18) {
        echo "Yaş sınırına uygun değilsiniz.";
        return;
    }

    echo "Giriş yapabilirsiniz.";
}

Şimdi bu kodun farklılıklarına bakalım:

Hata durumunu başta kontrol ettik ve hemen geri döndük.
Fonksiyonun geri kalanı yalın ve anlaşılır oldu.
else bloğunu ortadan kaldırdık.

Daha Karmaşık Bir Örnek

Bir kullanıcının sisteme giriş yapması gereken bir senaryoyu düşünelim:

function loginUser($user) {
    if (!$user) {
        echo "Kullanıcı bulunamadı.";
        return;
    }

    if (!$user->isActive) {
        echo "Kullanıcı aktif değil.";
        return;
    }

    echo "Hoş geldiniz, {$user->name}!";
}

Burada farklı durumları teker teker kontrol edip her durumda fonksiyondan erken çıkıyoruz. Bu, iç içe bloklardan kurtulmamıza yardımcı oluyor. Özellikle fonksiyonlarınızda birden fazla kontrol noktaları varsa, bu yaklaşımı kullanmanızı şiddetle tavsiye ederim.

Unutmayın, kod yazarken amacımız sadece çalışan bir sistem değil, aynı zamanda kolay anlaşılabilir bir sistem oluşturmaktır. Siz de early return'i projelerinizde denemeyi unutmayın!

Görüşlerinizi yorumlarda bekliyorum! 😊

PHP'de Metotlar Arası Takip: Hangi Metottan Geldim?

Barış Bideratan — Thu, 19 Dec 2024 07:52:08 +0000

Herkese selamlar! 👋

PHP projelerimizde bazen bir metottan başka bir metodu çağırırken, çağrıyı yapan metodu öğrenmek isteyebiliriz. "Ama neden?" diye sorabilirsiniz. Gelin önce böyle bir duruma neden ihtiyaç duyabileceğimizden bahsedelim.

Neden Hangi Metottan Geldiğini Bilmek İsteyelim?

Diyelim ki bir web uygulaması geliştiriyorsunuz ve birden fazla metot, aynı işlevi yerine getiren ortak bir metodu çağırıyor. Ancak bu ortak metodun davranışını, çağıran metoda göre farklılaştırmak istiyorsunuz. Mesela bir loglama işlemi yapacaksınız ve hangi metottan çağrıldığını bilmek, loglarınıza anlam katacak. Ancak, ek parametreler göndermek istemiyorsunuz; kodunuz sade ve temiz kalsın istiyorsunuz.

İşte tam bu noktada PHP'nin güçlü araçlarından biri olan debug_backtrace yardımımıza koşuyor.

Gerçek Bir Örnek Üzerinden Anlatım

Haydi bir senaryo üzerinden bu işi nasıl yapabileceğimizi görelim. Elimizde şöyle bir Laravel controller'ı olsun:

namespace App\Http\Controllers;

use Illuminate\Http\Request;

class ExampleController extends Controller
{
    public function a()
    {
        return $this->c();
    }

    public function b()
    {
        return $this->c();
    }

    public function c()
    {
        // Çağrının geldiği metodu tespit et
        $trace = debug_backtrace();
        $caller = $trace[1]['function']; // Bir önceki çağrıyı al

        return response()->json([
            'called_from' => $caller,
        ]);
    }
}

Kodun Açıklaması

a() ve b() metotları, ortak olan c() metodunu çağırıyor.
c() metodunda debug_backtrace() fonksiyonunu kullanıyoruz.
debug_backtrace()[1] ile bir önceki çağrının detaylarını alıyoruz.
['function'] anahtarı, çağrıyı yapan metot adını döndürüyor.

Çalışma Sonucu

Eğer tarayıcıda a() metodunu çağırırsanız:

{
  "called_from": "a"
}

b() metodunu çağırırsanız:

{
  "called_from": "b"
}

Bu kadar basit ve etkili! 👌

Nerelerde Kullanabiliriz?

Loglama: Çağrıyı hangi metottan yaptığınızı bilmek, loglarınızı anlamlı hale getirebilir.
Dinamik Davranışlar: Aynı metodu farklı davranışlar sergilemesi için özelleştirmek istediğinizde, çağıran metodu bilmek işinizi kolaylaştırır.
Hata Ayıklama: Uygulama içinde metotların çağrı yığınını görmek, hataları daha hızlı çözmenizi sağlar.

Dikkat Edilmesi Gerekenler

debug_backtrace her ne kadar güçlü bir araç olsa da, bazı durumlarda performans üzerinde etkisi olabilir. Çok sık çağrılan metotlarda kullanıyorsanız dikkatli olun. Ayrıca, bu yöntemi yalnızca gerçekten gerekli olduğunda tercih edin. Aksi halde kodunuz gereksiz karmaşık hale gelebilir.

Sonuç

Metotlar arası takip yapmak gerektiğinde, debug_backtrace tam bir hayat kurtarıcıdır. Ekstra parametrelerle kodu şişirmeden, temiz ve sade bir şekilde çözüm sunar.

Umarım bu yazı sizin için faydalı olmuştur! Eklemek istedikleriniz varsa, yorumlarda buluşalım. 😊

🚀

Laravel'de .env Dosyasında Bir Değişkeni Diğerine Referans Verme

Barış Bideratan — Fri, 27 Sep 2024 20:35:34 +0000

Laravel projelerinde yapılandırma ayarları genellikle .env dosyasında tanımlanır. Çoğu zaman, bu dosya içerisinde bir değişkeni diğer bir değişkene referans etmek isteyebilirsiniz. Bu gibi durumlarda Laravel, ${} string şablonunu kullanmanıza olanak tanır. Böylece önceden tanımladığınız bir değişkeni başka bir değişken içerisinde çağırabilirsiniz.

Nasıl Yapılır?

.env dosyasında bir değişkeni diğerine referans vermek için şu yöntemi kullanabilirsiniz:

APP_NAME=Netsper
DASHBOARD_TITLE="${APP_NAME} Dashboard"

Bu yapılandırma ile, DASHBOARD_TITLE değişkeni artık "Netsper Dashboard" değerine sahip olacaktır. İlk değişken olan APP_NAME değerini doğrudan kullanarak yeni bir string oluşturmuş oldunuz.

Bu basit ancak etkili yöntemi projelerinizde rahatlıkla kullanabilirsiniz!

Laravel Migration: Metin Veri Tipleri Arasındaki Farklar

Barış Bideratan — Wed, 12 Jun 2024 10:17:47 +0000

Herkese selamlar! Bu makalede text, longText, mediumText, ve tinyText veri tiplerini ve bunların kullanımını inceleyeceğiz.

Laravel'de text, longText, mediumText ve tinyText veri tiplerinin farklarını anlamak, veritabanı tasarımınızı optimize etmenize ve doğru veri tipini seçerek performansı artırmanıza yardımcı olur.

Text Veri Tipleri

1. `text`

text veri tipi, orta boyutlu metin verilerini saklamak için kullanılır. 65,535 karaktere kadar veri saklayabilir.

Schema::create('posts', function (Blueprint $table) {
    $table->id();
    $table->text('content');
    $table->timestamps();
});

Bu tip genellikle blog yazıları, açıklamalar veya kullanıcı girdileri gibi orta boyutlu metinler için uygundur.

2. `longText`

longText, büyük miktarda metin verisi saklamak için kullanılır ve 4,294,967,295 karaktere kadar veri saklayabilir.

Schema::create('articles', function (Blueprint $table) {
    $table->id();
    $table->longText('body');
    $table->timestamps();
});

Bu tip, büyük belgeler, uzun makaleler veya HTML içeriklerinin saklanması için idealdir.

3. `mediumText`

mediumText veri tipi, text ve longText arasında bir yerdedir ve 16,777,215 karaktere kadar veri saklayabilir.

Schema::create('comments', function (Blueprint $table) {
    $table->id();
    $table->mediumText('message');
    $table->timestamps();
});

Bu tip, orta boyutlu ile büyük boyutlu metinler arasında yer alan veriler için uygundur, örneğin kullanıcı yorumları veya detaylı açıklamalar.

4. `tinyText`

tinyText veri tipi, çok küçük boyutlu metin verilerini saklamak için kullanılır ve 255 karaktere kadar veri saklayabilir.

Schema::create('tags', function (Blueprint $table) {
    $table->id();
    $table->tinyText('name');
    $table->timestamps();
});

Bu tip, kısa etiketler, açıklamalar veya çok kısa metinler için uygundur.

Metin Veri Tiplerinin Seçimi

Hangi veri tipini kullanmanız gerektiğine karar verirken, saklayacağınız metin verisinin boyutunu ve kullanım amacını göz önünde bulundurmalısınız:

text: Orta boyutlu metinler (blog yazıları, açıklamalar).
longText: Çok büyük metinler (büyük belgeler, HTML içerikleri).
mediumText: Orta ile büyük boyutlu metinler (detaylı kullanıcı yorumları).
tinyText: Çok küçük metinler (etiketler, kısa açıklamalar).

Laravel'de Carbon Kütüphanesini Yerelleştirme

Barış Bideratan — Tue, 11 Jun 2024 08:38:44 +0000

Carbon, yerelleştirme için setLocale metodunu kullanır. Uygulamanızın servis sağlayıcısında veya bir middleware içinde bu ayarı yapabilirsiniz.

AppServiceProvider içine yerleştirerek Carbon'un yerelleştirme ayarlarını yapabilirsiniz:

namespace App\Providers;

use Illuminate\Support\ServiceProvider;
use Carbon\Carbon;

class AppServiceProvider extends ServiceProvider
{
    public function boot()
    {
        Carbon::setLocale(config('app.locale'));
    }
}

Bu örnekte, Laravel'in varsayılan dil ayarı olan app.locale değeri kullanılarak Carbon'un dili ayarlanır. config/app.php dosyasında locale ayarının tr olarak ayarlandığından emin olun:

'locale' => 'tr',

Yerelleştirilmiş Tarih ve Saat Formatlarını Kullanma

Carbon, yerelleştirilmiş formatlarda tarih ve saat görüntülemek için çeşitli metodlar sunar:

$now = Carbon::now();
echo $now->isoFormat('LLLL'); // Örneğin, "Çarşamba, 15 Haziran 2024 14:23" gibi bir çıktı verir.

veya

$now = Carbon::now();
echo $now->translatedFormat('m/d/Y h:i a');

Gördüğünüz gibi Laravel'de Carbon kütüphanesini yerelleştirmek oldukça basit. AppServiceProvider içinde Carbon'un dilini ayarlayarak ve Laravel'in yerelleştirme dosyalarını yapılandırarak tarih ve saat bilgilerini istediğiniz dilde görüntüleyebilirsiniz. Bu sayede, uygulamanızın kullanıcıları kendi dillerinde daha anlaşılır ve kullanıcı dostu bir deneyim yaşarlar.

PHP 8.1 ile Gelen Enum'lar: Kodunuzu Daha Güvenli ve Anlaşılır Hale Getirin

Barış Bideratan — Tue, 11 Jun 2024 07:19:19 +0000

PHP 8.1'in tanıtılmasıyla birlikte birçok yeni özellik ve iyileştirme geldi. Bu özelliklerden biri de enum'lar. Bu yazıda, enum'ların ne olduğunu, PHP'de nasıl kullanıldığını ve yazılım geliştirme sürecinizde neden bu kadar önemli olduklarını detaylı bir şekilde inceleyeceğiz.

Enum Nedir?

Enum (enumeration), belirli bir sabit değerler kümesini tanımlayan bir veri türüdür. Enum'lar, özellikle bir değişkenin belirli, sabit bir grup değerden birini alması gerektiğinde kullanılır. Bu, kodun okunabilirliğini ve bakımını kolaylaştırır ve hataları azaltır.

PHP'de Enum'lar

PHP 8.1 ile birlikte gelen enum'lar, aşağıdaki şekilde tanımlanabilir:

<?php
enum Status {
    case Pending;
    case Approved;
    case Rejected;
}

// Kullanım
$status = Status::Pending;

if ($status === Status::Approved) {
    echo "Status is approved.";
}
?>

Enum'ların Temel Amacı Nedir?

Enum'ların temel amacı, belirli bir grup değeri daha güvenli ve anlaşılır bir şekilde yönetmektir. Bu, kodun okunabilirliğini ve bakımını kolaylaştırır ve hataları azaltır. Özellikle belirli bir değişkenin sadece belirli değerler alması gerektiğinde kullanışlıdır.

Enum Kullanım Senaryoları

Durum Yönetimi: Sipariş durumları, kullanıcı hesap durumları gibi.
Hata Kodları: Belirli hata türlerini tanımlamak için.
Rol Yönetimi: Kullanıcı rolleri (Admin, User, Guest) gibi.
Ödeme Yöntemleri: Kredi kartı, banka havalesi, PayPal gibi ödeme yöntemlerini tanımlamak için.

Enum Tanımlamadığımızda Olabilecek Problemler

Enum'lar kullanılmadığında, belirli bir grup sabit değeri yönetmek için genellikle sabitler veya stringler kullanılır. Bu, aşağıdaki problemlere yol açabilir:

Hata Yapma Riski: Bir string ya da sabit yanlış yazıldığında (örneğin, 'approved' yerine 'aproved'), hata ayıklamak zor olabilir.
Kod Okunabilirliği: Sabitler veya stringler kullanıldığında, kodun okunabilirliği ve anlaşılabilirliği azalabilir.
Bakım Zorluğu: Değerlerde bir değişiklik gerektiğinde (örneğin, 'pending' yerine 'awaiting'), tüm kod tabanını güncellemek zor olabilir.

PHP'de Enum İle İlgili İleri Düzey Özellikler

PHP'de enum'lar, sadece sabit değerlerin bir koleksiyonunu tanımlamakla kalmaz, aynı zamanda enum sınıflarına metotlar da ekleyebilirsiniz:

<?php
enum Status {
    case Pending;
    case Approved;
    case Rejected;

    public function getLabel(): string {
        return match($this) {
            self::Pending => 'Pending',
            self::Approved => 'Approved',
            self::Rejected => 'Rejected',
        };
    }
}

// Kullanım
$status = Status::Pending;
echo $status->getLabel(); // Output: Pending
?>

Enum'ların Avantajları

Güvenlik: Hataları ve yanlış değerleri önler.
Okunabilirlik: Kodun daha anlaşılır ve okunabilir olmasını sağlar.
Bakım Kolaylığı: Değerlerin yönetimini ve güncellenmesini kolaylaştırır.
Tutarlılık: Değerlerin tutarlı bir şekilde kullanılmasını sağlar.

Özetleyelim

PHP 8.1 ile birlikte gelen enum'lar, kodunuzun güvenliğini, okunabilirliğini ve bakımını büyük ölçüde artırır. Belirli sabit değerlerin kullanıldığı her yerde enum'ları tercih ederek kodunuzu daha sağlam ve anlaşılır hale getirebilirsiniz. Özellikle durum yönetimi, hata kodları ve rol yönetimi gibi alanlarda enum'ların gücünden faydalanmak, yazılım geliştirme sürecinizi daha verimli hale getirecektir.

Forem: Barış Bideratan

API Endpoint Tasarımında Küçük Bir Detay, Büyük Bir Fark

Laravel’de Backed Enum Nedir? Pure Enum ile Farkı Ne?

Enum nedir?

Pure Enum ve Backed Enum farkı

Pure Enum nedir?

Backed Enum nedir?

Backed enum neden Laravel’de daha çok kullanılır?

Laravel’de enum dosyası oluşturmak

Laravel model cast ile kullanım

Form request ve validation tarafı

from() ve tryFrom() farkı

Enum içine yardımcı metotlar eklemek

Select input için options üretmek

Veritabanında SQL enum mu, string kolon mu?

Ne zaman backed enum kullanmalıyız?

Ne zaman pure enum kullanılır?

Kötü kullanım örneği

Kısa özet

Laravel’de Neden Kod İçinde env() Kullanılmamalı?

Doğru akış

Asıl sebep: config cache

Yanlış kullanım

Doğru kullanım

Büyük servislerde ayrı config dosyası daha iyi olabilir

Test yazarken de config daha kullanışlıdır

Bir adım ileri: typed config object

PHP’de Global Function Resolution: strlen() mi, \strlen() mi?

Kısa cevap

Namespace içinde fonksiyon çağırmak

Peki \strlen() ne yapar?

Farkı daha net görelim

Bu davranış sadece fonksiyonlarda mı var?

Neden bazı projeler \strlen() kullanır?

1. Açık niyet

2. Namespace içinde aynı isimli fonksiyonlardan etkilenmemek

3. Çok küçük performans farkı

use function alternatifi

Laravel projelerinde ne yapmalı?

Testlerde bu davranış işe yarayabilir

Laravel'de Real-Time Facades Nedir? Nasıl Çalışır?

Facade Nedir?

Normal Kullanım vs Real-Time Facade

Klasik yöntem:

Real-Time Facade ile:

Gerçekten “Statik” mi Çalışıyor?

Gerçek Hayattan Bir Örnek

Klasik kullanım:

Real-Time Facade ile:

Ne Zaman Kullanmalı?

Özet

APK Dosyalarını Düzenleme ve Yeniden İmzalama: Adım Adım Kılavuz

1. APK Dosyasını Çıkarın (Extract)

2. Kodları İnceleyin

3. Smali Kodlarda Gerekli Değişiklikleri Yapın

4. Değişikliklerden Sonra Build İşlemi

5. İmzalama İçin Key Oluşturun

6. APK Dosyasını Zipalign ile Optimize Edin

7. APK Dosyasını İmzalama

Sonuç

PHP’de Early Return: Kodunuzu Temizleyen Basit Bir Yaklaşım

Early Return Nedir?

Neden Early Return Kullanmalıyız?

Early Return Nasıl Kullanılır?

Klasik Yaklaşım

Early Return ile

Daha Karmaşık Bir Örnek

PHP'de Metotlar Arası Takip: Hangi Metottan Geldim?

Neden Hangi Metottan Geldiğini Bilmek İsteyelim?

Gerçek Bir Örnek Üzerinden Anlatım

Kodun Açıklaması

Çalışma Sonucu

Nerelerde Kullanabiliriz?

Dikkat Edilmesi Gerekenler

Sonuç

Laravel'de .env Dosyasında Bir Değişkeni Diğerine Referans Verme

Nasıl Yapılır?

Laravel Migration: Metin Veri Tipleri Arasındaki Farklar

Text Veri Tipleri

1. text

`from()` ve `tryFrom()` farkı

Peki `\strlen()` ne yapar?

Neden bazı projeler `\strlen()` kullanır?

`use function` alternatifi

1. `text`

2. `longText`

3. `mediumText`

4. `tinyText`