feat: add new blog posts, associated images, and automation scripts for content management
@@ -140,26 +140,11 @@ export function BlogDetailContent({ post }: BlogDetailContentProps) {
|
|||||||
|
|
||||||
<header className="space-y-3">
|
<header className="space-y-3">
|
||||||
<Badge className="rounded-sm">{post.category}</Badge>
|
<Badge className="rounded-sm">{post.category}</Badge>
|
||||||
<Typography variant="h2" className="leading-tight">
|
<Typography variant="small" className="block text-muted-foreground">
|
||||||
{post.title}
|
|
||||||
</Typography>
|
|
||||||
<Typography variant="small" className="text-muted-foreground">
|
|
||||||
{post.author} · {post.date} · {post.readTime}
|
{post.author} · {post.date} · {post.readTime}
|
||||||
</Typography>
|
</Typography>
|
||||||
<Typography variant="p" className="text-muted-foreground">
|
|
||||||
{post.excerpt}
|
|
||||||
</Typography>
|
|
||||||
</header>
|
</header>
|
||||||
|
|
||||||
<Card className="relative aspect-16/8 overflow-hidden rounded-sm border-border">
|
|
||||||
<img
|
|
||||||
src={post.coverImage}
|
|
||||||
alt={post.title}
|
|
||||||
sizes="(max-width: 768px) 100vw, 50vw"
|
|
||||||
className="object-cover"
|
|
||||||
/>
|
|
||||||
</Card>
|
|
||||||
|
|
||||||
<section className="space-y-5">
|
<section className="space-y-5">
|
||||||
<ReactMarkdown
|
<ReactMarkdown
|
||||||
remarkPlugins={[remarkGfm]}
|
remarkPlugins={[remarkGfm]}
|
||||||
|
|||||||
@@ -0,0 +1,287 @@
|
|||||||
|
---
|
||||||
|
title: "Clean Architecture Frontend’e Nasıl Uyarlanır?"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-12-02"
|
||||||
|
readTime: "10 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "clean-architecture-frontende-nas-l-uyarlan-r"
|
||||||
|
excerpt: "Clean Architecture Frontend’e Nasıl Uyarlanır? İçerik Giriş Frontend’de neden mimariye ihtiyaç duyuyoruz? Clean Architecture’ın temel fikri Clean Architecture frontend’e uygulanabilir …"
|
||||||
|
coverImage: "/blog/images/clean-architecture-frontende-nas-l-uyarlan-r-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/clean-architecture-frontende-nas%C4%B1l-uyarlan%C4%B1r-2db91f7e7c97"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Clean Architecture Frontend’e Nasıl Uyarlanır?
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## İçerik
|
||||||
|
|
||||||
|
* Giriş
|
||||||
|
* Frontend’de neden mimariye ihtiyaç duyuyoruz?
|
||||||
|
* Clean Architecture’ın temel fikri
|
||||||
|
* Clean Architecture frontend’e uygulanabilir mi?
|
||||||
|
* Katmanların tanımı
|
||||||
|
* Bağımlılık yönü ve soyutlama mantığı
|
||||||
|
* Kod organizasyonu ve best practices
|
||||||
|
* Todo örneği ile uygulama
|
||||||
|
* Sonuç ve değerlendirme
|
||||||
|
|
||||||
|
## TL;DR
|
||||||
|
|
||||||
|
Frontend’de Clean Architecture, tüm projeyi “UI + Application + Domain + Infrastructure” olarak zihinde ayrıştırmayı önerir. Domain kurallarını component’lere karıştırmak yerine, React bileşenlerini sadece sunum aracı olarak ele alırız. API çağrılarını bileşenlerde değil, infrastructure tarafında tutarız. Her katman sadece iç katmanlara bağlı olur. Bu yaklaşım küçük örneklerde ekstra soyutlama gibi görünse de proje büyüdükçe okunabilirliği, test edilebilirliği ve sürdürülebilirliği artırır. Yazıda, Todo örneği üzerinden katmanların nasıl ayrıldığını ve React ile nasıl uygulanabileceğini gösteriyoruz.
|
||||||
|
|
||||||
|
## Giriş
|
||||||
|
|
||||||
|
Frontend projeleri küçükken her şey yolunda görünür; API çağrısı component’in içinde olur, state orada tutulur, UI da orada şekillenir. Ancak proje büyümeye başladığında bu yaklaşım hızla karmaşaya dönüşür. İş mantığı, sunum ve veri erişimi birbirine karışır: kodu okumak, test etmek ve genişletmek zorlaşır.
|
||||||
|
|
||||||
|
Clean Architecture tam da bu noktada devreye giriyor arkadaşlar. Genelde backend dünyasına ait gibi görünse de, aslında React (Ben uzun süredir React üzerine çalıştığım için buradan örnekler vereceğim ama Angular, Vue gibi teknolojilerde dahil tabii ki buraya) gibi UI odaklı projelerde de büyük bir fayda sağlıyor. Bu yazımda Clean Architecture’ı frontend açısından sade bir dille ele alacağız ve basit bir Todo örneği ile nasıl uygulanabileceğini göstereceğiz.
|
||||||
|
|
||||||
|
Amaç; soyut teoriler değil, günlük geliştirme deneyimini daha düzenli bir hale getirmek.
|
||||||
|
|
||||||
|
## Frontend’de neden mimariye ihtiyaç duyuyoruz?
|
||||||
|
|
||||||
|
Bir React projesini açıp hızlıca bir şeyler inşa etmeye başlamak çoğu zaman oldukça rahatlatıcıdır. Bir component oluştururuz, API çağrısını içine koyarız, state’i kah burada kah orada tutarız, sonra UI’yı da o component’te render ederiz. Başlangıçta her şey basit görünür çünkü uygulama küçüktür. Ama bu yaklaşım büyüdükçe sorunlar doğurur.
|
||||||
|
|
||||||
|
Örneğin küçük bir Todo uygulaması düşünelim. Başta tek bir liste, bir input ve bir butonumuz vardır. Her şey App.js içinde olabilir ve işler yürür. Şimdi uygulamaya filtre ekleyelim, sonra kullanıcı giriş sistemi ekleyelim, sonra kategori desteği ve offline kullanım derken App.js bir anda 500 satır olur. Tüm bu iş mantığı bir noktada “Burada ne vardı?” diye kendimize sormaya başlatır.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Asıl problem, frontend’in sadece arayüz çizmekten ibaret olmamasıdır. **Veri yönetimi, doğrulama, iş kuralları, kullanıcı davranışı, performans, erişilebilirlik ve dış servislerle entegrasyon** gibi konular aslında işin merkezindedir. Bu yüzden her şeyi component seviyesinde çözmeye çalıştığımızda, büyüdükçe iç içe geçmiş bir kod yığınına dönüşür.
|
||||||
|
|
||||||
|
Bir diğer örnek: API’den gelen veriyi component içinde doğrudan kullanmak ilk günlerde sorun yaratmaz. Ama bir ay sonra başka bir component aynı veriyi işlemeye ihtiyaç duyduğunda aynı işi tekrar yazmak zorunda kalırız. Test etmek zorlaşır, hataları izole etmek imkansız hale gelir ve yeni biri projeye dahil olduğunda “Bu logic neden burada çalışıyor?” diye sürekli soru sormaya başlar.
|
||||||
|
|
||||||
|
İşte mimarinin amacı bu karmaşayı önlemektir. Küçük bir uygulamada bile mantığı katmanlara ayırmak, projeyi büyütmek istediğimizde işimizi kolaylaştırır. Başta fazladan zahmetmiş gibi görünse de, aynı Todoyu bir yıl sonrasına devrettiğinizde kendinizden memnun kalırsınız. Mimarinin önemi aslında “bugün değil, yarın” için hazırlanma fikrinden doğar. Güzel bir fikir değil mi?
|
||||||
|
|
||||||
|
## Clean Architecture’ın temel fikri
|
||||||
|
|
||||||
|
Clean Architecture kabaca şunu söyler: Uygulamanın merkezindeki kurallar dış etkilerden bağımsız olmalı. Yani iş mantığı, UI’dan, veri kaynağından, framework’ten ya da teknolojisel tercihlerden etkilenmemeli.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Bunu günlük hayattan bir örnekle düşünelim. Bir restoranın mutfağında yemek pişirme kuralları vardır: etin nasıl marine edildiği, sosların nasıl hazırlandığı, pişirme süresi gibi şeyler. Bu kurallar müşteri içeride oturuyor mu, paket servis mi istiyor, yoksa drive-thru’dan mı geliyor fark etmez. Siparişin nasıl iletildiği sürecin detayını değiştirir ama yemeğin tarifini değiştirmez.
|
||||||
|
|
||||||
|
Clean Architecture’ın temel fikri de buna benzer. Uygulamanın “mutfağı”, yani domain ve iş kuralları sabit kalır. Kullanıcı ister web üzerinden ister mobil uygulamadan gelsin; ister API yerelde çalışsın ister uzak bir sunucuda olsun; hatta UI framework’ü React yerine Svelte olsun fark etmez. Uygulamanın özünü oluşturan kurallar değişmez.
|
||||||
|
|
||||||
|
Bu yaklaşım üç kilit düşünce üzerine oturur:
|
||||||
|
|
||||||
|
* Bağımlılıkları merkeze değil dışarıya doğru konumlandırmak
|
||||||
|
* İç katmanların dış katmanlardan habersiz olması
|
||||||
|
* **Teknolojilerin birer detay ve değişken unsur olarak görülmesi — Bu bence çok önemli —**
|
||||||
|
|
||||||
|
Bu yüzden Clean Architecture projeyi katmanlara böler; kapalı bir çekirdek (domain) ve onun etrafında onu destekleyen halkalar oluşturur. Böylece değişen teknolojiye rağmen kurallar sabit kalır.
|
||||||
|
|
||||||
|
Bu fikir ilk bakışta fazla soyut gibi görünebilir. Ancak amacı çok basittir: İş mantığını korumak, değişimi kolaylaştırmak ve her şeyin yerini belli kılan bir düzen oluşturmak. Asıl değer, projeyi büyütmeye çalıştığımızda ortaya çıkar. Çünkü artık “Bu kod nereye gelmeli?” sorusunun net bir cevabı vardır.
|
||||||
|
|
||||||
|
## Clean Architecture frontend’e uygulanabilir mi?
|
||||||
|
|
||||||
|
Bu soru genelde ilk tepki olarak gelir çünkü Clean Architecture çoğunlukla backend dünyasında konuşulur. Servisler, domain katmanı, repository’ler derken sanki yalnızca API tarafına aitmiş gibi bir hava oluşur. Oysa frontend de artık sadece HTML render eden bir yüzey değil. Karmaşık iş akışları, offline senaryolar, cache stratejileri, authentication yönetimi, veri senkronizasyonu ve hatta **state persistence** gibi backend’e yakın sorumluluklar taşıyor.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Bu yüzden cevap: Evet, Clean Architecture frontend’e hem uygulanabilir hem de faydalıdır.
|
||||||
|
|
||||||
|
İlginç olan şu: Frontend’de zaten farkında olmadan bu fikirlere yakın hareket ediyoruz. UI bileşenlerini ayırıyoruz, service dosyaları açıyoruz, veri yönetimi için context veya store kullanıyoruz. Clean Architecture aslında bunu biraz daha bilinçli ve yapılandırılmış hale getiriyor.
|
||||||
|
|
||||||
|
React ile düşündüğümüzde:
|
||||||
|
|
||||||
|
* UI layer zaten component yapısıyla doğal bir sınır oluşturuyor.
|
||||||
|
* State yönetim araçları bir nevi application layer gibi konumlanıyor.
|
||||||
|
* Hooks ve custom logic’ler use case gibi davranabiliyor.
|
||||||
|
* API fetcher’ları infrastructure katmanını temsil ediyor.
|
||||||
|
|
||||||
|
Yani React bize Clean Architecture’ı uygulamak için kötü bir zemin sağlamıyor, tam tersine doğal bir başlangıç noktası sunuyor. Tek ihtiyaç, bu parçaların bilinçli bir şekilde ayrılması ve birbirlerine bağımlılıklarının doğru yönde kurulması.
|
||||||
|
|
||||||
|
Frontend’de Clean Architecture’ın asıl kazanımı, büyüyen projenin kontrol edilebilir ve test edilebilir kalmasıdır. UI değiştirilebilir, framework değişebilir, veri kaynağı farklılaşabilir. Ancak domain ve uygulama mantığı aynı kalır. İşin güzelliği de burada: Yarın React yerine başka bir UI kütüphanesi kullanmak isterseniz, iş mantığınızın yüzde sekseni taşınabilir durumda olur.
|
||||||
|
|
||||||
|
Bu yüzden “frontend’de mimari gereksiz yük” algısı yerine, “küçük bir yatırım ile uzun vadede rahatlık” yaklaşımı daha gerçekçi bir bakış açısıdır.
|
||||||
|
|
||||||
|
## Katmanların tanımı
|
||||||
|
|
||||||
|
Clean Architecture’ın en bilinen tarafı katman kavramıdır. “**Layer**” kelimesi kulağa teorik gelebilir ama aslında yapılmaya çalışılan şey çok basittir: Kodun hangi amaca hizmet ettiğini belirlemek ve o kodu doğru yere koymak.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Frontend’de bunu şu dört ana başlık üzerinden düşünebiliriz:
|
||||||
|
|
||||||
|
**1\. UI (Presentation) Katmanı**
|
||||||
|
Bu katman kullanıcıyla temas eden yüzdür. React component’leri, butonlar, formlar, sayfalar, animasyonlar ve görsel davranış burada yer alır. Buradaki kodun tek görevi, veriyi ekrana taşımak ve kullanıcı etkileşimlerini yakalamaktır. İş mantığı burada olmamalıdır. UI katmanı “ne” olacağını değil, “nasıl görüneceğini” temsil eder.
|
||||||
|
|
||||||
|
**2\. Application Katmanı**
|
||||||
|
Bu katman, uygulamanın davranışını yöneten yerdir. State yönetimi, use case’lerin orkestrasyonu, doğrulama akışları, UI ile domain arasında köprü görevini üstlenen logic burada bulunur. Bir işi başlatır, domain’i çalıştırır, sonuçları UI’ya geri iletir.
|
||||||
|
|
||||||
|
**3\. Domain (Core) Katmanı**
|
||||||
|
Bu uygulamanın en iç halkasıdır. İş kuralları, modeller, entity yapılandırmaları, use case fonksiyonları ve domain’e özgü doğrulamalar burada yer alır. Domain hiçbir teknolojiye bağımlı olmamalıdır. API çağrısı yapmaz, UI ile ilgilenmez, sadece işin nasıl çalışması gerektiğini tanımlar.
|
||||||
|
|
||||||
|
**4\. Infrastructure (External Services) Katmanı**
|
||||||
|
Burada teknoloji detayları yer alır. API çağrıları, fetch işlemleri, localStorage, indexedDB, third-party entegrasyonları, veri adaptörleri vs. Bu katman domain’in ihtiyaçlarını karşılar ama domain’in kendisini bilmez. Domain sadece bir abstract interface’e güvenip concrete implementasyonun burada olduğundan habersiz olur.
|
||||||
|
|
||||||
|
Bu katmanları ayrıştırmanın en büyük faydası şudur: Her şeyin nerede var olması gerektiğini biliyoruz. UI’da domain logic’i görmeye başladığımızda yanlış bir şeyler yaptığımızı anlarız. Infrastructure detaylarının component’e karıştığını gördüğümüzde “Bu servis UI’da ne arıyor?” diyebiliriz.
|
||||||
|
|
||||||
|
Katmanlar, frontend’in doğal karmaşasını isimlendirmemizi ve yönetmemizi sağlayan zihinsel bir çerçevedir. Bu ayrım zamanla otomatikleşir ve “Bu kod nereye gitmeli?” sorusunun tek seferde cevaplanmasını sağlar.
|
||||||
|
|
||||||
|
## Bağımlılık yönü ve soyutlama mantığı
|
||||||
|
|
||||||
|
Clean Architecture’ın belki de en kritik noktası bağımlılık yönüdür. Bu fikri anlamak, katmanları sadece dosya yapısı olarak değil, davranış modeli olarak kavramamızı sağlar.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Temel kural şudur:
|
||||||
|
İç katmanlar dış katmanlara asla bağımlı olmamalıdır. Bağımlılık her zaman dıştan içe doğru ilerler.
|
||||||
|
|
||||||
|
Başka bir ifadeyle, domain UI’yı tanımaz, API’yı bilmez, React ile ilgilenmez. Domain sadece kendisine ne söylenirse onu yapar. Bu yaklaşım domain’i uzun ömürlü ve taşınabilir kılar.
|
||||||
|
|
||||||
|
Bunu şöyle düşünebiliriz:
|
||||||
|
|
||||||
|
Bir fabrika düşünün. Ürün üretim hattı içerde yer alır. Dışarıdaki sevkiyat araçları, müşteriyle iletişim şekli veya kapının rengi üretim bandının nasıl çalıştığını değiştirmez. Üretim bandı dış etkilerden bağımsızdır. Clean Architecture’ın bağımlılık yönü de tam olarak bunu söyler.
|
||||||
|
|
||||||
|
Bu yön nasıl sağlanır?
|
||||||
|
İşte burada soyutlama devreye girer. Domain’in API’yı doğrudan çağırmak yerine bir interface’e, yani bir sözleşmeye güvenmesi gerekir. Domain “illa fetch kullan” demez, sadece “bana todo’ları getir” der. O işi nasıl yapacağımız infrastructure katmanına kalmıştır.
|
||||||
|
|
||||||
|
Bu soyutlama sayesinde:
|
||||||
|
|
||||||
|
* Domain test edilebilir hale gelir
|
||||||
|
* API değiştiğinde domain kodu değişmez
|
||||||
|
* UI değiştiğinde iş mantığı sabit kalır
|
||||||
|
* Proje büyüdükçe yollar karmaşıklaşmaz
|
||||||
|
|
||||||
|
React tarafında bu fikrin karşılığı şudur: Component içinde API almak yerine bir servis veya adapter üzerinden almak. Bu, component’i UI rolüne sadık bırakır, domain ise framework bağımsız kalır.
|
||||||
|
|
||||||
|
|
||||||
|
Bağımlılık yönü asla “UI domain’i yönetir” şeklinde değil, “domain ihtiyaçları yönetir, dış dünya bunu karşılar” şeklindedir. Temelde amaç, kodun kararlarını iş kurallarının belirlemesi ve teknolojilerin sadece bir ayrıntı olarak davranmasıdır.
|
||||||
|
|
||||||
|
## Kod organizasyonu ve best practices
|
||||||
|
|
||||||
|
Clean Architecture’ı frontend’de uygularken ilk temas noktamız genelde klasör yapısı oluyor. Dosya yapısı tek başına mimariyi garanti etmez ama zihnimizi doğru yönde çalıştırmamıza yardımcı olur.
|
||||||
|
|
||||||
|
Basitleştirilmiş bir örnek düşünelim:
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Burada amaç her dosyanın niyetini netleştirmek. Örneğin:
|
||||||
|
|
||||||
|
* `domain/todo` sadece todo’nun iş kuralları ile ilgilenir. “Todo nedir, hangi alanlara sahiptir, hangi durumlar geçerlidir?” gibi soruları yanıtlar.
|
||||||
|
* `application/todo` domain’i kullanarak UI’ya veri sağlayan hook’lar veya servisler içerir.
|
||||||
|
* `infrastructure/todo` API, localStorage veya başka bir kaynağa erişmek için gerekli adaptörleri bulundurur.
|
||||||
|
* `ui` tarafı ise tamamen React component’lerinden oluşur.
|
||||||
|
|
||||||
|
Buradaki önemli best practice şu:
|
||||||
|
**Dosyaları “teknolojiye göre” değil, “anlama göre” gruplayalım.**
|
||||||
|
|
||||||
|
Yani `components`, `hooks`, `services` gibi yatay ayrımlar yerine, feature odaklı ve katman bilinçli bir yapı daha uzun ömürlü olur. Örneğin:
|
||||||
|
|
||||||
|
* `todo` bir feature’dır; domain, application ve infrastructure içinde kendi alanı vardır.
|
||||||
|
* `ui/todo` altında da bu feature’a ait component’leri tutabiliriz.
|
||||||
|
|
||||||
|
İkinci kritik nokta: Component’lerin görevini sınırlı tutmak.
|
||||||
|
|
||||||
|
React tarafında sık yapılan hata, tek component içinde hem UI hem fetch hem de domain kararlarını vermek. Bunun yerine:
|
||||||
|
|
||||||
|
* UI component: Sadece props alıp render yapan “dumb” component.
|
||||||
|
* Container / Page component: Application layer’daki hook’ları kullanarak veriyi UI’ya taşıyan bileşen.
|
||||||
|
* Hook / service: Use case’leri ve domain’i bilen, UI’dan bağımsız mantık katmanı.
|
||||||
|
|
||||||
|
Mesela şöyle bir yapı gayet sağlıklı:
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
`useTodoList` ise domain ve infrastructure ile konuşur, UI ile değil. Bu sayede:
|
||||||
|
|
||||||
|
* Domain’i test ederken React’i ayağa kaldırmak zorunda kalmayız.
|
||||||
|
* Todo listesini başka bir UI (örneğin mobil veya farklı bir web framework) ile de kullanabiliriz.
|
||||||
|
* Refactor yaparken “bu logic’i nereden çekmeliyim?” sorusu azalır.
|
||||||
|
|
||||||
|
Bir diğer best practice de isimlendirmede tutarlılıktır.
|
||||||
|
|
||||||
|
Örneğin:
|
||||||
|
|
||||||
|
* Domain tarafında `Todo`, `TodoId`, `TodoStatus` gibi net isimler kullanmak,
|
||||||
|
* Application tarafında `useTodoList`, `createTodo`, `toggleTodoStatus` gibi eylem odaklı isimler seçmek,
|
||||||
|
* Infrastructure tarafında `TodoApi`, `TodoRepository`, `TodoStorage` gibi veri kaynaklarını vurgulayan isimler vermek, projenin okunabilirliğini ciddi anlamda artırır.
|
||||||
|
|
||||||
|
Son olarak: Her soyutlamayı gerçekten ihtiyaç oldukça eklemek önemli. Küçük bir projede bir anda 10 farklı layer açmak yerine, problem ortaya çıktıkça ve tekrar eden desenleri gördükçe bu yapıyı genişletmek daha doğal bir yol. Yani hedefimiz “kitaba uygun dosya yapısı” değil, “ekipçe rahatça anlayabildiğimiz ve büyüyebilen” bir yapı kurmak olmalı.
|
||||||
|
|
||||||
|
Bir sonraki adımda, bu prensipleri somutlaştırmak için todo domain’ini konuşup, ardından basit bir örnek üzerinden gideceğiz.
|
||||||
|
|
||||||
|
## Todo örneği ile uygulama
|
||||||
|
|
||||||
|
Clean Architecture’ı anlamanın en iyi yolu, küçük bir Todo örneğini katmanlara bölerek görmek. Aşağıda minimal ama fikir veren bir yapı var:
|
||||||
|
|
||||||
|
Klasör Yapım:
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Bu yapı şunu söylüyor:
|
||||||
|
|
||||||
|
* domain: Todo’nun tanımı ve kuralları
|
||||||
|
* infrastructure: Todo verisini nasıl sakladığımız
|
||||||
|
* application: Bu veriyi ve kuralları UI ile nasıl konuşturduğumuz
|
||||||
|
* ui: Kullanıcıya gösterdiğimiz React bileşenleri
|
||||||
|
|
||||||
|
### 1) Domain: Todo tanımı ve kuralları
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Domain şu an hiçbir şey bilmiyor: React yok, localStorage yok, fetch yok.
|
||||||
|
|
||||||
|
### 2) Infrastructure: localStorage implementasyonu
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Burada domain’in tanıdığı tek şey `TodoRepository` interface’i. LocalStorage tamamen detay.
|
||||||
|
|
||||||
|
### 3) Application: useTodoList hook’u
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Bu hook:
|
||||||
|
|
||||||
|
* UI’den istek alıyor
|
||||||
|
* Domain fonksiyonlarını kullanıyor (`createTodo`, `toggleTodo`)
|
||||||
|
* Infrastructure ile konuşuyor (`todoRepository`)
|
||||||
|
* Kendisi React’e bağımlı ama domain’e UI detayı taşımıyor.
|
||||||
|
|
||||||
|
### 4) UI: Sayfa ve görünüm bileşenleri
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Burada:
|
||||||
|
|
||||||
|
* `TodoListPage` application katmanıyla konuşan container bileşeni
|
||||||
|
* `TodoListView` sadece render yapan, “saf” UI bileşeni
|
||||||
|
|
||||||
|
Bu haliyle proje hala çok basit, ama önemli olan fikir:
|
||||||
|
|
||||||
|
* Domain: Kurallar ve model
|
||||||
|
* Application: Akış ve state
|
||||||
|
* Infrastructure: Veri kaynağı detayları
|
||||||
|
* UI: Sunum
|
||||||
|
|
||||||
|
Yarın localStorage yerine gerçek bir API kullanmak istersen sadece `todoRepository` implementasyonunu değiştiriyorsun; domain aynı, application aynı, UI aynı kalıyor. Clean Architecture’ın önemi tam burada ortaya çıkıyor.
|
||||||
|
|
||||||
|
## Sonuç ve değerlendirme
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Clean Architecture’ı frontend’de uygulamak ilk bakışta fazla yapılandırılmış gelebilir; özellikle küçük projelerde “Buna gerek var mı?” sorusu akla düşer. Ancak mesele dosya dizinleri veya katman isimleri değil, zihinsel düzen kazanmaktır. Todo örneğinde gördüğümüz gibi, domain mantığını UI’dan ayırmak, veri erişimini bir detay olarak ele almak ve davranışları uygulama katmanında tutmak projeyi okunabilir, genişletilebilir ve test edilebilir kılıyor.
|
||||||
|
|
||||||
|
Bu yaklaşım büyüyen projelerde rahatlatıcı bir etki yaratıyor. API değiştiğinde domain aynı kalıyor, UI yenilendiğinde iş mantığı taşınabiliyor. Asıl kazanım mimari değil; değişime dayanıklı bir kod alışkanlığı edinmek. Clean Architecture’ı “ideal dosya yapısı” olarak değil, doğru soruları sormayı öğreten bir düşünme biçimi olarak görmek belki de en iyi başlangıç noktasıdır.
|
||||||
@@ -1,91 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Yazılım Projelerinde Düzen ve Verimlilik İçin: Conventional Commits Nedir?"
|
|
||||||
category: "Yazilim"
|
|
||||||
date: "2026-02-01"
|
|
||||||
readTime: "8 min read"
|
|
||||||
author: "Poyraz Avsever"
|
|
||||||
excerpt: "Yazılım geliştirme sürecinde yalnızca kod yazmıyoruz; aynı zamanda takım iletişimini ve proje geçmişini...."
|
|
||||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/1*WQOgajPE2m4aYuVC3SZoFQ.jpeg"
|
|
||||||
---
|
|
||||||
|
|
||||||
# Yazılım Projelerinde Düzen ve Verimlilik İçin: **Conventional Commits Nedir?**
|
|
||||||
|
|
||||||
Yazılım geliştirme sürecinde, kod yazmanın ötesinde pek çok detayla uğraşıyoruz. Commit mesajları da bu sürecin kritik bir parçası tabii ki. Ancak commit mesajları, bazen dağınık, anlaşılmaz ve düzensiz olabiliyor. İşte bu noktada **“Conventional Commits”** devreye giriyor.
|
|
||||||
|
|
||||||
## Conventional Commits **Nedir?**
|
|
||||||
|
|
||||||
Conventional Commits, commit mesajlarınızı belirli bir formata oturtan bir yazılım standardı. Amaç, her commit’in ne yaptığını net bir şekilde ifade etmek ve proje geçmişini daha anlaşılır hale getirmek. Commit mesajlarınızı bu standarda göre yazmak, projeyi daha düzenli, takip edilebilir ve sürdürülebilir kılar. Gelin şimdi beraber inceleyelim.
|
|
||||||
|
|
||||||
## Neden Conventional Commits **Kullanmalıyız?**
|
|
||||||
|
|
||||||
### 1. **Anlaşılabilirlik**
|
|
||||||
|
|
||||||
Commit geçmişinin anlaşılabilir olması hepimiz için önemli. Bu standart, projede yapılan değişikliklerin kolayca takip edilmesini sağlıyor. Büyük projelerde, hangi commit’in hangi sorunu çözdüğünü veya hangi yeni özelliği eklediğini anlamak zaman zaman zorlaştığı için bu gibi standartları kullanmak yazılımcıların işini kolaylaştırıyor.
|
|
||||||
|
|
||||||
### 2. İzlenebilirlik ve **Şeffaflık**
|
|
||||||
|
|
||||||
Commit mesajlarımızı tutarlı ve net hale getirmek, proje geçmişimizde yapılan değişikliklerin izlenmesini kolaylaştırıyor. Özellikle geriye dönük uyumluluğu bozan değişikliklerde, bu düzenlemeler büyük bir avantaj sağlıyor.
|
|
||||||
|
|
||||||
## Peki Bu Commit Mesajları **Nasıl Yazılıyor?**
|
|
||||||
|
|
||||||
Conventional Commits’e göre, her commit mesajı üç ana bölümden oluşur:
|
|
||||||
|
|
||||||
- **Başlık (Summary):** Mesajın türünü ve kısaca ne yaptığını belirtir.
|
|
||||||
- **Gövde (Body):** Değişikliğin detaylarını açıklar. Neden yapıldığını ve nasıl yapıldığını anlatır.
|
|
||||||
- **Altbilgi (Footer):** Breaking changes gibi uyumluluğu bozan değişiklikler veya kapatılan sorunlar burada belirtilir.
|
|
||||||
|
|
||||||
## Commit **Türleri**
|
|
||||||
|
|
||||||
Commit mesajları belirli türlerle başlar. İşte en yaygın kullanılan türler: [Daha detaylı commit türlerini incelemek için tıklayın.](https://www.conventionalcommits.org/en/v1.0.0/)
|
|
||||||
|
|
||||||
- **feat:** Yeni bir özellik eklenmesi.
|
|
||||||
- **fix:** Bir hatanın düzeltilmesi.
|
|
||||||
- **docs:** Sadece dokümantasyonla ilgili değişiklikler.
|
|
||||||
- **style:** Kodun işleyişini değiştirmeyen biçimlendirme (boşluklar, noktalı virgüller vb.).
|
|
||||||
- **refactor:** Kodda, işlevini değiştirmeyen yeniden düzenleme.
|
|
||||||
|
|
||||||
### Gelin beraber örnek bir **Commit Mesajını** inceleyelim:
|
|
||||||
|
|
||||||
```text
|
|
||||||
feat(login): add JWT authentication
|
|
||||||
|
|
||||||
Added JWT authentication to the login process to enhance security.
|
|
||||||
This change involves updating the login controller and modifying the user model.
|
|
||||||
|
|
||||||
BREAKING CHANGE: The user model now requires a JWT token for all login operations.
|
|
||||||
```
|
|
||||||
|
|
||||||
#### 1. Başlık **(Summary)**
|
|
||||||
|
|
||||||
- **feat:**
|
|
||||||
Commit türünü belirtir. Burada feat (feature) türü kullanılmış, bu da commit'in projeye yeni bir özellik eklediğini gösterir. Başka türler de kullanılabilir, örneğin fix (bir hatayı düzeltmek), docs (dokümantasyon güncellemeleri) gibi.
|
|
||||||
- **(login):**
|
|
||||||
Parantez içinde belirtilen bölüm, bu özelliğin veya değişikliğin hangi modülü veya bölümü etkilediğini gösterir. Burada login kullanılmış, yani yapılan değişiklik, login (giriş) süreciyle ilgilidir.
|
|
||||||
- **add JWT authentication:**
|
|
||||||
Bu, commit'in yaptığı spesifik değişikliği kısa ve öz bir şekilde açıklar. Burada, JWT (JSON Web Token) ile kimlik doğrulamanın login sürecine eklendiği belirtiliyor.
|
|
||||||
|
|
||||||
#### 2. Gövde **(Body)**
|
|
||||||
|
|
||||||
- **İlk Cümle:**
|
|
||||||
“Added JWT authentication to the login process to enhance security.”
|
|
||||||
Bu cümle, yapılan değişikliğin amacını ve sonucunu açıklar. Burada, JWT kimlik doğrulamasının login sürecine eklendiği ve bunun güvenliği artırmak amacıyla yapıldığı belirtiliyor.
|
|
||||||
- **İkinci Cümle:**
|
|
||||||
“This change involves updating the login controller and modifying the user model.”
|
|
||||||
Bu cümle, değişikliğin hangi dosya veya modülleri etkilediğini daha detaylı açıklar. Burada, login controller’ın güncellendiği ve user model’in değiştirildiği belirtiliyor.
|
|
||||||
|
|
||||||
#### 3. Altbilgi **(Footer)**
|
|
||||||
|
|
||||||
- **BREAKING CHANGE:**
|
|
||||||
Bu ifade, uyumluluğu bozan bir değişiklik olduğunu gösterir. Eğer bir commit, mevcut kodun çalışmasını bozacak bir değişiklik yapıyorsa, bu mutlaka belirtilmelidir. Bu, diğer geliştiricilerin bu değişiklikten haberdar olmasını sağlar.
|
|
||||||
- **Detay:**
|
|
||||||
“The user model now requires a JWT token for all login operations.”
|
|
||||||
Bu açıklama, uyumluluğu bozan değişikliğin ne olduğunu detaylandırır. Burada, kullanıcı modelinin artık tüm giriş işlemleri için bir JWT token gerektirdiği belirtiliyor. Bu, diğer geliştiricilerin bu değişiklikleri uygularken dikkatli olmaları gerektiğini ifade eder.
|
|
||||||
|
|
||||||
## Sonuç **olarak**
|
|
||||||
|
|
||||||
Conventional Commits, yazılım geliştirme sürecimizi daha düzenli, anlaşılır ve verimli hale getirdi. Commit mesajlarımızı belirli bir yapıya oturtarak, proje yönetimimizi daha sürdürülebilir ve izlenebilir bir hale getirdik.
|
|
||||||
|
|
||||||
## **Kaynak**
|
|
||||||
|
|
||||||
- [Conventional Commits v1.0.0](https://www.conventionalcommits.org/en/v1.0.0/)
|
|
||||||
- [3 Reasons Why You Should Use Conventional Commits](https://developer.vonage.com/en/blog/3-reasons-why-you-should-use-conventional-commits)
|
|
||||||
@@ -0,0 +1,236 @@
|
|||||||
|
---
|
||||||
|
title: "CSS Frameworkleri Tanıyoruz | 1. Bölüm: Bootstrap"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-04-27"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "css-frameworkleri-tan-yoruz-1-b-l-m-bootstrap"
|
||||||
|
excerpt: "CSS Frameworkleri Tanıyoruz | 1. Bölüm: Bootstrap CSS Frameworkleri, artık modern web geliştirme süreçlerinde hayat kurtarıcı oluyor. Kendi css dosyalarımızı sıfırdan yazmak yerine …"
|
||||||
|
coverImage: "/blog/images/css-frameworkleri-tan-yoruz-1-b-l-m-bootstrap-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-1-b%C3%B6l%C3%BCm-bootstrap-232619268cc8"
|
||||||
|
---
|
||||||
|
|
||||||
|
# CSS Frameworkleri Tanıyoruz | 1. Bölüm: Bootstrap
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
CSS Frameworkleri, artık modern web geliştirme süreçlerinde hayat kurtarıcı oluyor. Kendi css dosyalarımızı sıfırdan yazmak yerine, önceden hazırlanmış, optimize edilmiş ve test edilmiş kodlardan faydalanabiliyoruz. Bu yazı serisi boyunca, en popüler frameworkleri adım adım birlikte öğreneceğiz. Serimizin ilk konuğu: **Bootstrap**!
|
||||||
|
|
||||||
|
## Bootstrap Nedir?
|
||||||
|
|
||||||
|
Bootstrap, Twitter mühendisleri tarafından geliştirilen, açık kaynaklı bir CSS frameworküdür. Temel amacı, hızlı ve uyumlu (responsive) web siteleri oluşturmayı kolaylaştırmaktır.
|
||||||
|
|
||||||
|
* **İlk Çıkış Yılı:** 2011
|
||||||
|
* **Geliştiriciler:** Mark Otto ve Jacob Thornton
|
||||||
|
* **Ana Özellikleri:** Responsive grid sistemi, hazır UI bileşenleri, JavaScript pluginleri ve hızlı prototipleme imkanı.
|
||||||
|
|
||||||
|
## Neden Bootstrap?
|
||||||
|
|
||||||
|
Günümüzde hangi kurumdan, videodan ya da dökümantasyonlardan front-end öğrenmeye çalışıyorsanız karşınıza kesinlikle “Bootstrap” çıkmıştır çünkü:
|
||||||
|
|
||||||
|
* **Kolay Başlangıç:** CDN üzerinden birkaç satır kodla hızlıca çalışmaya başlayabilirsin.
|
||||||
|
* **Mobil Öncelikli:** Tüm tasarımlar mobil uyumlu düşünülerek geliştirilmiştir.
|
||||||
|
* **Topluluk Desteği:** Sorun yaşadığında veya geliştirmek istediğinde çok geniş bir kaynak ve topluluk seni bekliyor.
|
||||||
|
* **Kapsamlı Bileşenler:** Düğmeler, formlar, modallar, navigasyon barları ve daha fazlası hazır halde gelir.
|
||||||
|
|
||||||
|
## Nasıl Başlıyoruz?
|
||||||
|
|
||||||
|
1. **Yöntem: CDN ile En Hızlı Başlangıç**
|
||||||
|
|
||||||
|
HTML dosyana sadece şu satırları eklemen yeterli:
|
||||||
|
|
||||||
|
<link href\="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel\="stylesheet"\>
|
||||||
|
<script src\="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/js/bootstrap.bundle.min.js"\></script\>
|
||||||
|
|
||||||
|
**2\. Yöntem: NPM Üzerinden Kurulum**
|
||||||
|
|
||||||
|
|
||||||
|
Projeni biraz daha büyük ölçekli yönetmek istersen:
|
||||||
|
|
||||||
|
npm install bootstrap
|
||||||
|
|
||||||
|
## İlk Bootstrap Deneyimimiz: Basit Bir Sayfa
|
||||||
|
|
||||||
|
Şimdi Bootstrap’ı küçük bir örnekle kullanalım:
|
||||||
|
|
||||||
|
<!DOCTYPE html\>
|
||||||
|
<html lang\="tr"\>
|
||||||
|
<head\>
|
||||||
|
<meta charset\="UTF-8"\>
|
||||||
|
<meta name\="viewport" content\="width=device-width, initial-scale=1.0"\>
|
||||||
|
<title\>Bootstrap Başlangıç</title\>
|
||||||
|
<link href\="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel\="stylesheet"\>
|
||||||
|
</head\>
|
||||||
|
<body\>
|
||||||
|
<div class\="container mt-5"\>
|
||||||
|
<h1 class\="text-center"\>Merhaba Bootstrap!</h1\>
|
||||||
|
<p class\="lead text-center"\>CSS frameworkleri serimizin ilk adımındasınız 🎉</p\>
|
||||||
|
<button class\="btn btn-primary d-block mx-auto"\>Bana Tıkla!</button\>
|
||||||
|
</div\>
|
||||||
|
</body\>
|
||||||
|
</html\>
|
||||||
|
|
||||||
|
Ve işte bu kadar.
|
||||||
|
|
||||||
|
## 1\. Bootstrap’ın Temel Yapısı
|
||||||
|
|
||||||
|
Bootstrap projeleri, genellikle şu 3 temel yapı üzerine kuruludur:
|
||||||
|
|
||||||
|
* **Container:** İçerikleri sınırlamak ve hizalamak için kullanılır.
|
||||||
|
* **Row:** Satır oluşturur. Grid sisteminin temel taşıdır.
|
||||||
|
* **Col:** Sütunları ifade eder. Responsive tasarımın kalbidir.
|
||||||
|
|
||||||
|
## Container Nedir?
|
||||||
|
|
||||||
|
`container` sınıfı, içerikleri ortalamak ve belirli bir genişlikte tutmak için kullanılır.
|
||||||
|
|
||||||
|
<div class\="container"\>
|
||||||
|
İçerik burada yer alacak.
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
İstersen tam genişlikte bir container da kullanabilirsin:
|
||||||
|
|
||||||
|
<div class\="container-fluid"\>
|
||||||
|
Bu container ekranın tamamını kaplar.
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
## 2\. Bootstrap Grid Sistemi
|
||||||
|
|
||||||
|
Bootstrap’ın en güçlü özelliklerinden biri: **12 kolonlu grid sistemi**. Bu sistemle her cihaz boyutuna göre düzenlemeler yapabiliyoruz.
|
||||||
|
|
||||||
|
### Basit Grid Kullanımı
|
||||||
|
|
||||||
|
<div class\="container"\>
|
||||||
|
<div class\="row"\>
|
||||||
|
<div class\="col"\>Sütun 1</div\>
|
||||||
|
<div class\="col"\>Sütun 2</div\>
|
||||||
|
<div class\="col"\>Sütun 3</div\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
Yukarıdaki kod 3 eşit genişlikte sütun oluşturuyor.
|
||||||
|
|
||||||
|
### Özel Genişlik Belirleme
|
||||||
|
|
||||||
|
İstersen sütunlara özel genişlikler de verebilirsin:
|
||||||
|
|
||||||
|
<div class\="row"\>
|
||||||
|
<div class\="col-6"\>%50 genişlik</div\>
|
||||||
|
<div class\="col-3"\>%25 genişlik</div\>
|
||||||
|
<div class\="col-3"\>%25 genişlik</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
### Responsive Grid
|
||||||
|
|
||||||
|
Farklı ekran boyutlarına göre farklı genişlikler ayarlayabilirsin:
|
||||||
|
|
||||||
|
<div class\="row"\>
|
||||||
|
<div class\="col-12 col-md-8"\>Büyük ekranlarda 8 birim</div\>
|
||||||
|
<div class\="col-6 col-md-4"\>Büyük ekranlarda 4 birim</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
* `col-12`: Küçük ekranlarda tüm satırı kapla.
|
||||||
|
* `col-md-8`: Orta ve daha büyük ekranlarda 8 kolon kapla.
|
||||||
|
|
||||||
|
## 3\. Bootstrap Bileşenleri
|
||||||
|
|
||||||
|
Bootstrap, tonlarca hazır bileşen sunuyor. Birkaç önemli bileşene beraber bakabilirz:
|
||||||
|
|
||||||
|
### Düğmeler (Buttons)
|
||||||
|
|
||||||
|
<button class\="btn btn-primary"\>Primary Düğme</button\>
|
||||||
|
<button class\="btn btn-success"\>Success Düğme</button\>
|
||||||
|
<button class\="btn btn-danger"\>Danger Düğme</button\>
|
||||||
|
|
||||||
|
Renk kodları ile istediğin tarzı seçebilirsin.
|
||||||
|
|
||||||
|
### Kartlar (Cards)
|
||||||
|
|
||||||
|
<div class\="card" style="width: 18rem;"\>
|
||||||
|
<img src\="https://via.placeholder.com/150" class\="card-img-top" alt\="..."\>
|
||||||
|
<div class\="card-body"\>
|
||||||
|
<h5 class\="card-title"\>Kart Başlığı</h5\>
|
||||||
|
<p class\="card-text"\>Bu bir Bootstrap kart bileşenidir.</p\>
|
||||||
|
<a href\="#" class\="btn btn-primary"\>Bir yere git</a\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
Kartlar, görsel + içerik kombinasyonları için çok ideal.
|
||||||
|
|
||||||
|
### Navigasyon Bar (Navbar)
|
||||||
|
|
||||||
|
<nav class\="navbar navbar-expand-lg navbar-light bg-light"\>
|
||||||
|
<a class\="navbar-brand" href\="#"\>Logo</a\>
|
||||||
|
<button class\="navbar-toggler" type\="button" data-bs-toggle\="collapse" data-bs-target\="#navbarNav"\>
|
||||||
|
<span class\="navbar-toggler-icon"\></span\>
|
||||||
|
</button\>
|
||||||
|
<div class\="collapse navbar-collapse" id\="navbarNav"\>
|
||||||
|
<ul class\="navbar-nav"\>
|
||||||
|
<li class\="nav-item"\>
|
||||||
|
<a class\="nav-link active" href\="#"\>Ana Sayfa</a\>
|
||||||
|
</li\>
|
||||||
|
<li class\="nav-item"\>
|
||||||
|
<a class\="nav-link" href\="#"\>Hakkında</a\>
|
||||||
|
</li\>
|
||||||
|
</ul\>
|
||||||
|
</div\>
|
||||||
|
</nav\>
|
||||||
|
|
||||||
|
## Mini Proje: Bootstrap ile Basit Bir İletişim Sayfası
|
||||||
|
|
||||||
|
Öğrendiklerimizi pekiştirmek için birlikte küçük bir iletişim sayfası tasarlayalım.
|
||||||
|
|
||||||
|
<!DOCTYPE html\>
|
||||||
|
<html lang\="tr"\>
|
||||||
|
<head\>
|
||||||
|
<meta charset\="UTF-8"\>
|
||||||
|
<meta name\="viewport" content\="width=device-width, initial-scale=1"\>
|
||||||
|
<title\>İletişim Formu</title\>
|
||||||
|
<link href\="https://cdn.jsdelivr.net/npm/bootstrap@5.3.0/dist/css/bootstrap.min.css" rel\="stylesheet"\>
|
||||||
|
</head\>
|
||||||
|
<body\>
|
||||||
|
|
||||||
|
<div class\="container py-5"\>
|
||||||
|
<h2 class\="text-center mb-4"\>Bize Ulaşın</h2\>
|
||||||
|
|
||||||
|
<form class\="mx-auto" style\="max-width: 600px;"\>
|
||||||
|
<div class\="mb-3"\>
|
||||||
|
<label for\="name" class\="form-label"\>Adınız</label\>
|
||||||
|
<input type\="text" class\="form-control" id\="name" placeholder\="Adınızı girin"\>
|
||||||
|
</div\>
|
||||||
|
<div class\="mb-3"\>
|
||||||
|
<label for\="email" class\="form-label"\>E-posta Adresiniz</label\>
|
||||||
|
<input type\="email" class\="form-control" id\="email" placeholder\="E-posta adresinizi girin"\>
|
||||||
|
</div\>
|
||||||
|
<div class\="mb-3"\>
|
||||||
|
<label for\="message" class\="form-label"\>Mesajınız</label\>
|
||||||
|
<textarea class\="form-control" id\="message" rows\="4" placeholder\="Mesajınızı yazın"\></textarea\>
|
||||||
|
</div\>
|
||||||
|
<button type\="submit" class\="btn btn-primary w-100"\>Gönder</button\>
|
||||||
|
</form\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
</body\>
|
||||||
|
</html\>
|
||||||
|
|
||||||
|
### Bu Mini Projede Neler Öğrendik?
|
||||||
|
|
||||||
|
* Container ve grid yapısını kullanarak belli bir düzen oluşturduk.
|
||||||
|
* Form elemanlarını Bootstrap ile daha şık hale getirdik.
|
||||||
|
* Button ve spacing (boşluk) classlarını (py-5, mb-3, w-100) kullandık.
|
||||||
|
|
||||||
|
Bu küçük örnek, Bootstrap ile bir tasarımın ne kadar hızlı oluşturabileceğinizi gösteriyor. Yukarıdaki kodları inceleyerek bir çok noktayı anlayabilirsiniz.
|
||||||
|
|
||||||
|
## Bootstrap’ı Daha İyi Öğrenmek İçin Ne Yapabilirsin?
|
||||||
|
|
||||||
|
* **Bootstrap Resmi Dokümantasyonu** sürekli güncelleniyor ve harika örneklerle dolu, inceleyebilirsiniz. ([https://getbootstrap.com/](https://getbootstrap.com/))
|
||||||
|
* **Kendi Küçük Projelerini Yap:** Mini portföyler, basit blog tasarımları, admin panelleri denemek çok öğretici olur.
|
||||||
|
* **Responsive Tasarımlar Üzerinde Çalış:** Farklı ekran boyutlarına uyum sağlamak için grid ve flex yapılarını bol bol kullan. Bunları ne kadar çok kullanırsan aşinalığın o kadar artacak.
|
||||||
|
* **Bootstrap Temalarına Göz At:** Ücretsiz tema sitelerinden ilham alabilirsin, kodlarını incele ve kendin tekrar kurmaya çalış. (Örneğin: [https://startbootstrap.com/](https://startbootstrap.com/))
|
||||||
|
* **Ekstra Bileşenleri Kullanmayı Öğren:** Modals, Toasts, Offcanvas gibi daha ileri seviye bileşenleri projelerinde deneyerek Bootstrap bilgin kat kat artar.
|
||||||
|
|
||||||
|
## Kapanış
|
||||||
|
|
||||||
|
Bu bölümde Bootstrap’ın temel yapı taşlarını ve ilk bileşenlerini tanıdık.
|
||||||
|
Bir sonraki yazımda Foundation ile tanışmaya gideceğiz. Daha fazla framework tanımak için takipte kalın, hoşçakalın.
|
||||||
@@ -0,0 +1,177 @@
|
|||||||
|
---
|
||||||
|
title: "CSS Frameworkleri Tanıyoruz | 2. Bölüm: Foundation"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-04-27"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "css-frameworkleri-tan-yoruz-2-b-l-m-foundation"
|
||||||
|
excerpt: "CSS Frameworkleri Tanıyoruz | 2. Bölüm: Foundation Merhaba arkadaşlar, bugün yeni konuğumuz “Foundation”. Gelin hep beraber tanışalım. Foundation Nedir? Foundation, ZURB tarafından …"
|
||||||
|
coverImage: "/blog/images/css-frameworkleri-tan-yoruz-2-b-l-m-foundation-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-2-b%C3%B6l%C3%BCm-foundation-68b08997cea3"
|
||||||
|
---
|
||||||
|
|
||||||
|
# CSS Frameworkleri Tanıyoruz | 2. Bölüm: Foundation
|
||||||
|
|
||||||
|
|
||||||
|
Merhaba arkadaşlar, bugün yeni konuğumuz “Foundation”. Gelin hep beraber tanışalım.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Foundation Nedir?
|
||||||
|
|
||||||
|
**Foundation**, ZURB tarafından geliştirilmiş, responsive web tasarımını ön planda tutan bir CSS framework’üdür. Modern web tasarımları için güçlü bir altyapı sanan ve projenizin hızlıca şekillendirilmesini sağlayan bir framework ‘tür.
|
||||||
|
|
||||||
|
* **Responsive Design**: Mobil uyumlu, masaüstü uyumlu web siteleri oluşturur.
|
||||||
|
* **Flexbox ve Grid Sistemleri**: Kullanımı kolay grid ve flexbox destekleri sunar.
|
||||||
|
* **Özelleştirilebilir Bileşenler**: Kendi tasarımınızı oluşturabileceğiniz hazır bileşenlerle gelir.
|
||||||
|
|
||||||
|
## 1\. Foundation’ın Temel Yapısı
|
||||||
|
|
||||||
|
Foundation ile bir sayfa tasarlarken, diğer framework’lerde olduğu gibi **grid sistemini** kullanacağız. Ancak Foundation, çok daha esnek yapıları destekleyebiliyor.
|
||||||
|
|
||||||
|
### Grid Sistemi
|
||||||
|
|
||||||
|
Örneğin bir sayfada 2 sütunlu bir düzen oluşturmak için:
|
||||||
|
|
||||||
|
<div class\="grid-x"\>
|
||||||
|
<div class\="cell small-12 medium-6"\>Sütun 1</div\>
|
||||||
|
<div class\="cell small-12 medium-6"\>Sütun 2</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
Burada;
|
||||||
|
|
||||||
|
* `grid-x`: Grid sistemini x ekseninde başlatır.
|
||||||
|
* `cell`: Her bir hücreyi tanımlar.
|
||||||
|
* `small-12`: Mobilde 12 sütun kullan, tam genişlik ver anlamına geliyor.
|
||||||
|
* `medium-6`: Masaüstünde 6 sütun, yani 2 sütunlu bir yapı anlamına geliyor.
|
||||||
|
|
||||||
|
Daha detaylı incelemek için [Foundation Framework Doc](https://get.foundation/sites/docs/index.html) sayfasından dökümantasyonu inceleyebilirsin.
|
||||||
|
|
||||||
|
## 2\. Foundation Kurulumu
|
||||||
|
|
||||||
|
### Hızlı Başlangıç (CDN ile)
|
||||||
|
|
||||||
|
Eğer hemen başlamak istiyorsan:
|
||||||
|
|
||||||
|
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/foundation-sites/dist/css/foundation.min.css"\>
|
||||||
|
|
||||||
|
Ardından HTML dosyanda Foundation class’larını kullanmaya başlayabilirsin.
|
||||||
|
|
||||||
|
### Daha Kapsamlı Projeler İçin Kurulum
|
||||||
|
|
||||||
|
Daha kapsamlı projelerde `npm` ile kurulumunu öneririm:
|
||||||
|
|
||||||
|
npm install foundation-sites
|
||||||
|
|
||||||
|
Sonrasında:
|
||||||
|
|
||||||
|
npx foundation new
|
||||||
|
|
||||||
|
Bu komutla, sana temel bir Foundation projesi kurabilirsin.
|
||||||
|
|
||||||
|
## 3\. Foundation İle Mini Bir Proje: Duyuru Kutusu Tasarlayalım
|
||||||
|
|
||||||
|
Bu kısımda, Foundation’ın sunduğu **callout** bileşenini kullanarak **duyuru kutusu** tasarımı yapacağız. Bu basit proje, Foundation’ın bileşenlerini nasıl kullanabileceğimizi ve responsive (duyarlı) bir tasarım nasıl oluşturulacağını göstermek için bence çok ideal.
|
||||||
|
|
||||||
|
### Adım 1: Duyuru Kutusu Bileşenini Oluşturma
|
||||||
|
|
||||||
|
Foundation’da duyuru, uyarı ya da önemli bilgileri vurgulamak için **callout** bileşeni kullanılabiliriz. **Callout** bileşeni, dikkat çekici bir stil sunarak mesajları öne çıkarır. Hadi hemen bir örnek üzerinden başlayalım:
|
||||||
|
|
||||||
|
<!DOCTYPE html\>
|
||||||
|
<html lang\="tr"\>
|
||||||
|
<head\>
|
||||||
|
<meta charset\="UTF-8"\>
|
||||||
|
<meta name\="viewport" content\="width=device-width, initial-scale=1.0"\>
|
||||||
|
<title\>Foundation Duyuru Kutusu</title\>
|
||||||
|
<link rel\="stylesheet" href\="https://cdn.jsdelivr.net/npm/foundation-sites/dist/css/foundation.min.css"\>
|
||||||
|
</head\>
|
||||||
|
<body\>
|
||||||
|
<!-- Duyuru Kutusu -->
|
||||||
|
<div class\="callout primary"\>
|
||||||
|
<h5\>Yeni Özellik Duyurusu!</h5\>
|
||||||
|
<p\>Web sitemizde yeni özellikler eklendi. Hızlıca göz atın ve denemek için tıklayın!</p\>
|
||||||
|
<a href\="#" class\="button"\>Özellikleri Keşfedin</a\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
<!-- Foundation Scripts -->
|
||||||
|
<script src\="https://cdn.jsdelivr.net/npm/foundation-sites/dist/js/foundation.min.js"\></script\>
|
||||||
|
</body\>
|
||||||
|
</html\>
|
||||||
|
|
||||||
|
### Açıklamalar:
|
||||||
|
|
||||||
|
* `**callout primary**`: `callout` bileşeni ile duyuru kutusunun stilini tanımlıyoruz. `primary` sınıfı ise kutunun rengini belirler (genellikle mavi tonlarında oluyor.).
|
||||||
|
|
||||||
|
### Adım 2: Duyuru Kutusunu Responsive Yapma
|
||||||
|
|
||||||
|
Bu proje, mobil uyumlu bir duyuru kutusu oluşturmayı da içeriyor. Foundation, **grid sistemi** ve **responsive utilities** ile sayfanın farklı ekran boyutlarına göre nasıl uyumlu hale getirileceğini gayet kolaylaştırır.
|
||||||
|
|
||||||
|
|
||||||
|
Örneğin, duyuru kutusunun genişliğini ekran boyutuna göre değiştirebiliriz:
|
||||||
|
|
||||||
|
<div class\="callout primary grid-container"\>
|
||||||
|
<div class\="grid-x grid-padding-x"\>
|
||||||
|
<div class\="cell small-12 medium-8 large-6"\>
|
||||||
|
<h5\>Yeni Özellik Duyurusu!</h5\>
|
||||||
|
<p\>Web sitemizde yeni özellikler eklendi. Hızlıca göz atın ve denemek için tıklayın!</p\>
|
||||||
|
<a href\="#" class\="button"\>Özellikleri Keşfedin</a\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
### Açıklamalar:
|
||||||
|
|
||||||
|
* `**grid-container**`: Container sınıfı, grid sisteminin düzenli çalışmasını sağlar.
|
||||||
|
* `**grid-x grid-padding-x**`: `grid-x` tüm satırı tanımlar, `grid-padding-x` ise yatay boşluk ekler.
|
||||||
|
* `**cell small-12 medium-8 large-6**`: Burada, duyuru kutusunun küçük ekranlarda tam genişlikte (12 sütun), orta boy ekranlarda 8 sütun ve büyük ekranlarda ise 6 sütun genişliğinde olmasını sağlıyoruz.
|
||||||
|
|
||||||
|
Bu düzen sayesinde duyuru kutusu, ekran boyutuna göre daha rahat yerleşim alacak ve kullanıcının her cihazda düzgün görüntülenmesini sağlayacaktır.
|
||||||
|
|
||||||
|
### Adım 3: Stil ve Renklendirme
|
||||||
|
|
||||||
|
Foundation, **temalar** ve **renkler** konusunda da özelleştirme imkanı sunar. `callout` bileşeninin varsayılan olarak gelen renkleri değiştirmek için, sınıflara renkler ekleyebilirsiniz.
|
||||||
|
|
||||||
|
Örneğin:
|
||||||
|
|
||||||
|
<div class\="callout alert"\>
|
||||||
|
<h5\>Önemli Uyarı!</h5\>
|
||||||
|
<p\>Web sitemiz geçici olarak bakıma alındı. Lütfen daha sonra tekrar deneyin.</p\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
* `**alert**`: Bu sınıf, **kırmızı** bir arka plan rengini ifade eder ve genellikle uyarılar için kullanılır.
|
||||||
|
* `**secondary**`: Duyuru kutusunun renk paletini değiştirir, farklı bir ton verir.
|
||||||
|
|
||||||
|
### Adım 4: İnteraktif Özellikler Eklemek
|
||||||
|
|
||||||
|
Foundation ile basit **modal pencereler** ve **accordion** gibi interaktif özellikler de ekleyebilirsiniz. Örneğin, kullanıcı butona tıkladığında bir **modal pencere** açılmasını sağlayabiliriz:
|
||||||
|
|
||||||
|
<!-- Button to trigger modal -->
|
||||||
|
<a href\="#" class\="button" data-open\="duyuruModal"\>Daha Fazla Bilgi</a\>
|
||||||
|
|
||||||
|
<!-- Modal -->
|
||||||
|
<div class\="reveal" id\="duyuruModal" data-reveal\>
|
||||||
|
<h2\>Detaylı Özellikler</h2\>
|
||||||
|
<p\>Bu özellikler hakkında daha fazla bilgi almak için web sitemizi inceleyebilirsiniz.</p\>
|
||||||
|
<button class\="close-button" data-close aria-label\="Close reveal" type\="button"\>
|
||||||
|
<span aria-hidden\="true"\>×</span\>
|
||||||
|
</button\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
<!-- Foundation Scripts -->
|
||||||
|
<script src\="https://cdn.jsdelivr.net/npm/foundation-sites/dist/js/foundation.min.js"\></script\>
|
||||||
|
<script\> $(document).foundation();</script\>
|
||||||
|
|
||||||
|
Burada reveal sınıfını kullanarak bir modal pencere oluşturuyoruz. data-open özelliği ile, butona tıklandığında ilgili modal pencerenin açılmasını sağlıyoruz.
|
||||||
|
|
||||||
|
## 4\. Foundation Öğrenmek İçin İpuçları
|
||||||
|
|
||||||
|
* **Resmi Dokümantasyon:** [https://get.foundation/](https://get.foundation/)
|
||||||
|
* **Flexbox Kullanımı:** Flexbox ile düzenleme yapmayı öğrenmelesin, Foundation ile çok güçlü düzenler oluşturabilirsin.
|
||||||
|
* **Proje Bileşenleri:** Formlar, butonlar, modal pencereler gibi bileşenleri kullanarak projeni hızlıca inşa et. Kendine bir tasarım, bir proje belirle ve onu foundation ile inşa et.
|
||||||
|
* **Responsive Tasarımlar Yap:** Foundation’ın responsive özelliklerini keşfederek, sitenizin tüm cihazlarla uyumlu olmasını sağlayın. Ne kadar çok pratik yaparsanız o kadar hızlanır ve aşina olursunuz.
|
||||||
|
* **Özelleştirme Yap:** Foundation’un css dosyalarını özelleştirerek, projene özel bir tema oluştur. Dosyaları kurcalamak foundation’ı çok daha iyi anlamana sebep olacaktır.
|
||||||
|
|
||||||
|
## Kapanış
|
||||||
|
|
||||||
|
Bu bölümde Foundation’ın temel yapı taşlarını ve ilk bileşenlerini tanıdık.
|
||||||
|
Bir sonraki yazımda **Bulma** ile tanışmaya gideceğiz. Benim favorilerimden biri kendisi. Daha fazla framework tanımak için takipte kalın, hoşçakalın.
|
||||||
@@ -0,0 +1,216 @@
|
|||||||
|
---
|
||||||
|
title: "CSS Frameworkleri Tanıyoruz | 3. Bölüm: Bulma"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-05-02"
|
||||||
|
readTime: "5 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "css-frameworkleri-tan-yoruz-3-b-l-m-bulma"
|
||||||
|
excerpt: "CSS Frameworkleri Tanıyoruz | 3. Bölüm: Bulma Bu seride amacımız, popüler CSS framework’lerini sade bir dille tanıtmak, nasıl kullanılacaklarını göstermek ve küçük projelerle …"
|
||||||
|
coverImage: "/blog/images/css-frameworkleri-tan-yoruz-3-b-l-m-bulma-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-3-b%C3%B6l%C3%BCm-bulma-7576b893d449"
|
||||||
|
---
|
||||||
|
|
||||||
|
# CSS Frameworkleri Tanıyoruz | 3. Bölüm: Bulma
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Bu seride amacımız, popüler CSS framework’lerini sade bir dille tanıtmak, nasıl kullanılacaklarını göstermek ve küçük projelerle öğrenmeyi desteklemek. İlk iki bölümde **Bootstrap** ve **Foundation** ile temel yapıları öğrendik. Şimdi sırada, sadeliği ve esnekliğiyle öne çıkan **Bulma** var. Açıkçası ben uzun zamandır **Bulma’yı** incelemek istiyordum. Bugüne nasip oldu.
|
||||||
|
|
||||||
|
Bulma, Flexbox temelli yapısı ve anlaşılır sınıf isimlendirmesiyle hem yeni başlayanlar hem de tecrübeli geliştiriciler için oldukça pratik bir seçenek. Hem hızlı prototipleme hem de üretim için kullanabileceğiniz güçlü bir araç.
|
||||||
|
|
||||||
|
Hazırsan, birlikte Bulma’nın dünyasına kısa bir yolculuğa çıkalım
|
||||||
|
|
||||||
|
## 1\. Bulma Nedir?
|
||||||
|
|
||||||
|
**Bulma**, modern web arayüzleri tasarlamak için geliştirilmiş, **yalnızca CSS içeren** ve %100 **Flexbox** tabanlı bir frontend framework’tür. JavaScript içermez; bu da onu, sade ve kontrolü tamamen geliştiriciye bırakan bir yapı haline getirir. Özellikle kendi sayfalarında da “Javascript” içermediğine sürekli vurgu yapılıyor.
|
||||||
|
|
||||||
|
Bulma’nın temel felsefesi, “**kodu anlamak kolay olmalı**” yaklaşımıdır. Açıkçası bu yaklaşıma oldukça katılıyorum. Sınıf isimlendirmeleri oldukça sezgiseldir ve HTML yazarken tasarımı aynı anda oluşturmak mümkündür. Bu yüzden özellikle **hızlı prototipleme** için çok tercih edilir.
|
||||||
|
|
||||||
|
## Öne Çıkan Özellikleri
|
||||||
|
|
||||||
|
### 1.1 - %100 Flexbox Tabanlı Olması
|
||||||
|
|
||||||
|
Bulma’nın layout sistemi tamamen Flexbox üzerine kuruludur. Bu sayede hem yatay hem de dikey hizalama işlemleri oldukça esnektir. Karmaşık grid yapıları bile birkaç satır sınıf ile kolayca oluşturulabilir.
|
||||||
|
|
||||||
|
<div class\="columns"\>
|
||||||
|
<div class\="column"\>İçerik 1</div\>
|
||||||
|
<div class\="column"\>İçerik 2</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
### 1.2 - Kolay Öğrenilebilir Sınıf Sistemi
|
||||||
|
|
||||||
|
Sınıf isimleri açık ve anlamlıdır:
|
||||||
|
|
||||||
|
* `is-primary`, `is-success`, `is-warning` gibi görsel sınıflar, bir bakışta ne işe yaradığını belli eder.
|
||||||
|
* `has-text-centered`, `is-fullwidth`, `is-size-4` gibi yapılar, stil vermek için CSS yazmadan işleri halletmenizi sağlar.
|
||||||
|
|
||||||
|
### 1.3 - Responsive Tasarımlarda Büyük Kolaylık
|
||||||
|
|
||||||
|
Mobil öncelikli yaklaşımı benimseyen Bulma, farklı ekran boyutları için özelleştirme yapmayı oldukça kolaylaştırır. Örneğin:
|
||||||
|
|
||||||
|
<div class\="column is-full-mobile is-half-tablet is-one-third-desktop"\>
|
||||||
|
|
||||||
|
Bu yapı, mobilde tam genişlik, tablette yarım, masaüstünde üçte bir genişlik anlamına gelir.
|
||||||
|
|
||||||
|
### 1.4 - JavaScript Bağımlılığı Yok
|
||||||
|
|
||||||
|
Bulma yalnızca CSS içerir. Yani framework içerisinde herhangi bir JS bileşeni bulunmaz. Bu da onu Vue, React, Angular gibi modern frameworklerle **kolay entegre edilebilir** hale getirir. Dilersen kendi JS kodlarını yazarak veya üçüncü taraf kütüphanelerle destekleyebilirsin.
|
||||||
|
|
||||||
|
### 1.5 - Zengin Hazır Bileşen Desteği
|
||||||
|
|
||||||
|
Buton, kart, form, navbar, mesaj kutuları, breadcrumb gibi birçok arayüz bileşeni varsayılan olarak gelir. Örneğin:
|
||||||
|
|
||||||
|
## 2\. Bulma Nasıl Kurulur?
|
||||||
|
|
||||||
|
Bulma’yı kullanmaya başlamak için birkaç farklı yöntem mevcut. İster bir CDN üzerinden hızlıca yükleyebilir, ister projene npm ile kurulum yaparak daha kontrollü bir entegrasyon gerçekleştirebilirsin.
|
||||||
|
|
||||||
|
### 2.1- CDN ile Hızlı Kurulum
|
||||||
|
|
||||||
|
Bulma’yı en hızlı şekilde projene dahil etmek için **CDN** (Content Delivery Network) kullanabilirsin. Bu yöntem, projene herhangi bir dosya indirmen gerekmeden doğrudan Bulma’nın sunucularından stil dosyalarını yükler.
|
||||||
|
|
||||||
|
İhtiyacın olan tek şey HTML dosyanıza şu satırı eklemek:
|
||||||
|
|
||||||
|
<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/bulma@0.9.3/css/bulma.min.css"\>
|
||||||
|
|
||||||
|
### 2.2- npm ile Kurulum
|
||||||
|
|
||||||
|
Projenin bir Node.js tabanlı yapısı varsa, npm ile Bulma’yı projenize dahil edebilirsin. Bu, özellikle projeyi daha profesyonel şekilde yönetmek isteyenler için iyi bir seçenek. Adımlar:
|
||||||
|
|
||||||
|
|
||||||
|
1 — Projende npm’i başlat:
|
||||||
|
|
||||||
|
npm init -y
|
||||||
|
|
||||||
|
2 — Bulma’yı kur:
|
||||||
|
|
||||||
|
npm install bulma
|
||||||
|
|
||||||
|
3 — `node_modules` klasöründen Bulma stil dosyasını projene import et:
|
||||||
|
|
||||||
|
@import 'node\_modules/bulma/css/bulma.min.css';
|
||||||
|
|
||||||
|
Bu yöntemle, projenin gereksinimlerine göre daha esnek bir kurulum yapmış olursun. Ayrıca, Bulma’nın özelleştirilmiş sürümleri için Sass kullanabilirsin.
|
||||||
|
|
||||||
|
### 2.3- Sass ile Özelleştirme (İleri Seviye)
|
||||||
|
|
||||||
|
Bulma, Sass ile özelleştirilebilirsin. Özellikle tasarımın bazı kısımlarını değiştirmek istiyorsan, Bulma’nın Sass dosyasını projene dahil edip, kendi özel tasarımını oluşturabilirsin. Bulma’nın Sass dosyasına erişmek için npm kurulumunu kullanman gerekecek.
|
||||||
|
|
||||||
|
1- Sass dosyasını import et:
|
||||||
|
|
||||||
|
@import 'node\_modules/bulma/bulma';
|
||||||
|
|
||||||
|
2- Bulma’nın sunduğu değişkenleri ve mixin’leri kullanarak renk, yazı tipi, buton boyutları gibi tasarım öğelerini özelleştirebilirsin. Örneğin:
|
||||||
|
|
||||||
|
$primary: #ff6347;
|
||||||
|
|
||||||
|
Böylece, global tema renklerinizi değiştirmiş olursunuz.
|
||||||
|
|
||||||
|
Harika! Şimdi **Bulma ile Basit Bir Proje** yapalım. Bu projede, Bulma’nın sunduğu temel bileşenleri kullanarak basit bir **landing page** (karşılama sayfası) tasarımı oluşturacağız. Aslında ne kadar basit ve anlaşılır olduğunu göreceksiniz. Dilerseniz başlayalım.
|
||||||
|
|
||||||
|
## Basit Bir Proje: Landing Page Tasarımı
|
||||||
|
|
||||||
|
Bu projede, temel HTML yapısını kullanarak Bulma framework’ü ile şık bir karşılama sayfası hazırlayacağız. İşte adım adım nasıl yapacağımız:
|
||||||
|
|
||||||
|
### 1\. HTML Yapısını Oluşturma
|
||||||
|
|
||||||
|
Öncelikle, temel HTML yapısını oluşturalım. Bulma’nın sunduğu `hero` sınıfını kullanarak bir başlık bölümü ekleyeceğiz ve altında birkaç kart bileşeni olacak.
|
||||||
|
|
||||||
|
<!DOCTYPE html\>
|
||||||
|
<html lang\="en"\>
|
||||||
|
<head\>
|
||||||
|
<meta charset\="UTF-8"\>
|
||||||
|
<meta name\="viewport" content\="width=device-width, initial-scale=1.0"\>
|
||||||
|
<title\>Bulma Landing Page</title\>
|
||||||
|
<link rel\="stylesheet" href\="https://cdn.jsdelivr.net/npm/bulma@0.9.3/css/bulma.min.css"\>
|
||||||
|
</head\>
|
||||||
|
<body\>
|
||||||
|
|
||||||
|
<!-- Hero Section -->
|
||||||
|
<section class\="hero is-primary is-fullheight"\>
|
||||||
|
<div class\="hero-body"\>
|
||||||
|
<div class\="container"\>
|
||||||
|
<h1 class\="title"\>
|
||||||
|
Hoş Geldiniz
|
||||||
|
</h1\>
|
||||||
|
<h2 class\="subtitle"\>
|
||||||
|
Bulma ile Basit Bir Landing Page Tasarımı
|
||||||
|
</h2\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
</section\>
|
||||||
|
|
||||||
|
<!-- Feature Section -->
|
||||||
|
<section class\="section"\>
|
||||||
|
<div class\="container"\>
|
||||||
|
<div class\="columns is-multiline"\>
|
||||||
|
<div class\="column is-4"\>
|
||||||
|
<div class\="card"\>
|
||||||
|
<div class\="card-content"\>
|
||||||
|
<h3 class\="title is-4"\>Özellik 1</h3\>
|
||||||
|
<p\>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
<div class\="column is-4"\>
|
||||||
|
<div class\="card"\>
|
||||||
|
<div class\="card-content"\>
|
||||||
|
<h3 class\="title is-4"\>Özellik 2</h3\>
|
||||||
|
<p\>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
<div class\="column is-4"\>
|
||||||
|
<div class\="card"\>
|
||||||
|
<div class\="card-content"\>
|
||||||
|
<h3 class\="title is-4"\>Özellik 3</h3\>
|
||||||
|
<p\>Lorem ipsum dolor sit amet, consectetur adipiscing elit.</p\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
</section\>
|
||||||
|
|
||||||
|
<!-- Footer Section -->
|
||||||
|
<footer class\="footer"\>
|
||||||
|
<div class\="content has-text-centered"\>
|
||||||
|
<p\>
|
||||||
|
<strong\>Bulma Landing Page</strong\> by <a href\="https://github.com/yourusername"\>Your Name</a\>.
|
||||||
|
</p\>
|
||||||
|
</div\>
|
||||||
|
</footer\>
|
||||||
|
|
||||||
|
</body\>
|
||||||
|
</html\>
|
||||||
|
|
||||||
|
### 2\. Açıklamalar
|
||||||
|
|
||||||
|
* **Hero Section**: Bulma’nın `hero` sınıfı ile ekranın tamamını kaplayan bir başlık bölümümüz var. Burada `is-primary` sınıfı, başlık kısmına ana renk tonunu verir
|
||||||
|
* **Feature Section**: Bu bölümde üç adet kart kullanıyoruz. Her kart, bir özellik tanıtımı yapacak şekilde tasarlandı. `columns` sınıfı ile kartları hizalıyoruz.
|
||||||
|
* **Footer Section**: Sayfanın alt kısmında, sayfa hakkında kısa bir bilgi veren basit bir footer bulunuyor.
|
||||||
|
|
||||||
|
### 3\. CSS Özelleştirmeleri (isteğe bağlı)
|
||||||
|
|
||||||
|
Eğer özelleştirmek istersen, Bulma’nın sunduğu renkleri veya tasarım ögelerini değiştirebilirsin. Örneğin, `hero` kısmının rengini değiştirebilir veya kartların stilini özelleştirebilirsin.
|
||||||
|
|
||||||
|
<section class\="hero is-link is-fullheight"\>
|
||||||
|
|
||||||
|
### 4\. Responsive Tasarım
|
||||||
|
|
||||||
|
Bulma, mobil öncelikli tasarım sunar. Bu nedenle tasarım, mobil cihazlarda düzgün bir şekilde görüntülenir. `columns` sınıfı ve `is-multiline` sayesinde, ekran boyutuna göre kartlar düzgün bir şekilde yerleşir. Küçük ekranlarda her kart bir satıra düşer, büyük ekranlarda ise yan yana yer alırlar.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Sonuç
|
||||||
|
|
||||||
|
Bu projede, Bulma’nın **kolay kullanımı**, **responsive özellikleri** ve **hazır bileşenleri** sayesinde hızlı bir şekilde profesyonel görünümlü bir sayfa oluşturduk. Artık, Bulma’yı kullanarak daha büyük projeler geliştirebilirsin.
|
||||||
|
|
||||||
|
### Daha İleri Gitmek İçin
|
||||||
|
|
||||||
|
* Bulma’nın **belgelerini** ([bulma.io](https://www.bulma.io)) inceleyerek daha fazla bileşen ve özelleştirme hakkında bilgi edinebilirsin.
|
||||||
|
* Bulma’yı projende Sass ile kullanarak stil dosyalarını daha detaylı şekilde yönetebilirsin.
|
||||||
@@ -0,0 +1,223 @@
|
|||||||
|
---
|
||||||
|
title: "CSS Frameworkleri Tanıyoruz | 4. Bölüm: Chakra UI"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-05-04"
|
||||||
|
readTime: "3 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "css-frameworkleri-tan-yoruz-4-b-l-m-chakra-ui"
|
||||||
|
excerpt: "CSS Frameworkleri Tanıyoruz | 4. Bölüm: Chakra UI Modern React uygulamaları için sade, güçlü ve erişilebilir bir çözüm mü arıyorsunuz? O zaman Chakra UI sizin için biçilmiş kaftan …"
|
||||||
|
coverImage: "/blog/images/css-frameworkleri-tan-yoruz-4-b-l-m-chakra-ui-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-4-b%C3%B6l%C3%BCm-chakra-ui-529192099789"
|
||||||
|
---
|
||||||
|
|
||||||
|
# CSS Frameworkleri Tanıyoruz | 4. Bölüm: Chakra UI
|
||||||
|
|
||||||
|
|
||||||
|
**Modern React uygulamaları için sade, güçlü ve erişilebilir bir çözüm mü arıyorsunuz?** O zaman Chakra UI sizin için biçilmiş kaftan olabilir.
|
||||||
|
|
||||||
|
|
||||||
|
Biliyorsunuz bu seride css frameworkleri ile tanışıyoruz. Bu bölümde, özellikle React geliştiricilerinin sıklıkla tercih ettiği, bileşen tabanlı ve esnek yapısıyla dikkat çeken **Chakra UI**’yi tanıyoruz. Dilerseniz başlayalım.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 1\. Chakra UI Nedir?
|
||||||
|
|
||||||
|
**Chakra UI**, React uygulamaları için modern, erişilebilir ve yeniden kullanılabilir bileşenler sağlayan bir **component-based UI library**’dir. Özellikle geliştiricilere yani size hızlı ve tutarlı tasarımlar yapabilmeleri için basitlik ve tema desteği sunar.
|
||||||
|
|
||||||
|
### Öne çıkan özellikleri:
|
||||||
|
|
||||||
|
* **React tabanlı** modern bileşenler
|
||||||
|
* **Tema desteği** ve kolay özelleştirme
|
||||||
|
* **Erişilebilirlik (Accessibility)** ön planda
|
||||||
|
* **Styled System** tabanlı stil verme yaklaşımı
|
||||||
|
* Koyu/açık mod desteği varsayılan olarak gelir
|
||||||
|
|
||||||
|
## 2\. Kurulum ve Başlangıç
|
||||||
|
|
||||||
|
Chakra UI, yalnızca **React** projeleriyle çalışır. Bu nedenle, öncelikle bir React projesine ihtiyacınız olacak. Eğer bir projen yoksa `Vite` ya da `Create React App` kullanarak hızlıca başlayabilirsin.
|
||||||
|
|
||||||
|
### 2.1. React projesi oluştur (Vite ile öneriyorum)
|
||||||
|
|
||||||
|
npm create vite@latest my\-chakra-app -- --template react
|
||||||
|
cd my\-chakra-app
|
||||||
|
npm install
|
||||||
|
|
||||||
|
veya
|
||||||
|
|
||||||
|
npx create-react-app my\-chakra-app
|
||||||
|
cd my\-chakra-app
|
||||||
|
|
||||||
|
### 2.2. Chakra UI’yi yükle
|
||||||
|
|
||||||
|
npm install @chakra-ui/react @emotion/react @emotion/styled framer-motion
|
||||||
|
|
||||||
|
Burada yüklediğimiz framer-motion doc ‘da zorunlu koşulmuyor fakat tavsiye ediyorum.
|
||||||
|
|
||||||
|
### 3.3. Uygulamayı ChakraProvider ile sarmala
|
||||||
|
|
||||||
|
`main.jsx` (veya `index.js`) dosyanı şu şekilde güncelle:
|
||||||
|
|
||||||
|
import React from 'react'
|
||||||
|
import ReactDOM from 'react-dom/client'
|
||||||
|
import { ChakraProvider } from '@chakra-ui/react'
|
||||||
|
import App from './App'
|
||||||
|
|
||||||
|
ReactDOM.createRoot(document.getElementById('root')).render(
|
||||||
|
<React.StrictMode\>
|
||||||
|
<ChakraProvider\>
|
||||||
|
<App />
|
||||||
|
</ChakraProvider\>
|
||||||
|
</React.StrictMode\>
|
||||||
|
)
|
||||||
|
|
||||||
|
### Artık hazırsın!
|
||||||
|
|
||||||
|
Chakra UI bileşenlerini kullanmaya başlayabilirsin. Örnek:
|
||||||
|
|
||||||
|
import { Button } from '@chakra-ui/react'
|
||||||
|
|
||||||
|
function MyButton() {
|
||||||
|
return <Button colorScheme\="teal"\>Merhaba Chakra!</Button\>
|
||||||
|
}
|
||||||
|
|
||||||
|
Bunun çalışıp çalışmadığını kontrol et. Eğer çalışıyorsa sağlıklı bir şekilde yüklemişsindir.
|
||||||
|
|
||||||
|
## 3\. Mini Proje: Basit Bir Profil Kartı
|
||||||
|
|
||||||
|
Bu küçük projede, Chakra UI bileşenleriyle şık ve responsive bir **profil kartı** tasarlayacağız. Projede kullanacağımız bileşenler:
|
||||||
|
|
||||||
|
* `Box`, `Image`, `Text`, `Stack`, `Button`, `Flex`, `Avatar`
|
||||||
|
* Chakra UI’nin **temaya dayalı renk sistemi** ve **spacing sistemini** kullanacağız.
|
||||||
|
|
||||||
|
import {
|
||||||
|
Box,
|
||||||
|
Flex,
|
||||||
|
Avatar,
|
||||||
|
Text,
|
||||||
|
Stack,
|
||||||
|
Button,
|
||||||
|
useColorModeValue,
|
||||||
|
} from "@chakra-ui/react";
|
||||||
|
|
||||||
|
function ProfileCard() {
|
||||||
|
return (
|
||||||
|
<Flex align\="center" justify\="center" minH\="100vh" bg\={useColorModeValue("gray.100", "gray.900")}>
|
||||||
|
<Box
|
||||||
|
maxW\="sm"
|
||||||
|
w\="full"
|
||||||
|
bg\={useColorModeValue("white", "gray.800")}
|
||||||
|
boxShadow\="lg"
|
||||||
|
rounded\="lg"
|
||||||
|
p\={6}
|
||||||
|
textAlign\="center"
|
||||||
|
>
|
||||||
|
<Avatar size\="xl" src\="https://i.pravatar.cc/300" mb\={4} />
|
||||||
|
<Text fontSize\="2xl" fontWeight\="bold"\>
|
||||||
|
Ayşe Yılmaz
|
||||||
|
</Text\>
|
||||||
|
<Text fontSize\="sm" color\="gray.500" mb\={4}\>
|
||||||
|
Frontend Developer | İstanbul
|
||||||
|
</Text\>
|
||||||
|
<Stack direction\="row" spacing\={4} justify\="center"\>
|
||||||
|
<Button colorScheme\="teal" variant\="solid"\>
|
||||||
|
Takip Et
|
||||||
|
</Button\>
|
||||||
|
<Button colorScheme\="teal" variant\="outline"\>
|
||||||
|
Mesaj Gönder
|
||||||
|
</Button\>
|
||||||
|
</Stack\>
|
||||||
|
</Box\>
|
||||||
|
</Flex\>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
|
||||||
|
export default ProfileCard;
|
||||||
|
|
||||||
|
### 1\. `Flex`
|
||||||
|
|
||||||
|
<Flex align\="center" justify\="center" minH\="100vh" bg\={...}\>
|
||||||
|
|
||||||
|
Sayfanın tamamında kartı **ortalamak** için kullanılıyoruz.
|
||||||
|
|
||||||
|
* `align="center"` → Dikey hizalama için
|
||||||
|
* `justify="center"` → Yatay hizalama için
|
||||||
|
* `minH="100vh"` → Sayfanın tamamını kapsaması için yükseklik
|
||||||
|
* `bg={...}` → Arka plan rengini açık/koyu moda göre ayarlıyoruz (`useColorModeValue` ile)
|
||||||
|
|
||||||
|
### 2\. `Box`
|
||||||
|
|
||||||
|
<Box
|
||||||
|
maxW\="sm"
|
||||||
|
w\="full"
|
||||||
|
bg\={...}
|
||||||
|
boxShadow\="lg"
|
||||||
|
rounded\="lg"
|
||||||
|
p\={6}
|
||||||
|
textAlign\="center"
|
||||||
|
\>
|
||||||
|
|
||||||
|
Tüm profil kartının çerçevesini oluşturuyor bu eleman. Atr ‘ları ise:
|
||||||
|
|
||||||
|
* `maxW="sm"` → Genişliği sınırlar (small boyut)
|
||||||
|
* `w="full"` → Mobilde tam genişlik
|
||||||
|
* `boxShadow="lg"` → Gölgelendirme efekti
|
||||||
|
* `rounded="lg"` → Köşeleri yumuşatır
|
||||||
|
* `p={6}` → İç boşluk (padding)
|
||||||
|
* `textAlign="center"` → Kart içindeki tüm yazıları ortalıyor.
|
||||||
|
|
||||||
|
### 3\. `Avatar`
|
||||||
|
|
||||||
|
<Avatar size\="xl" src\="https://i.pravatar.cc/300" mb\={4} />
|
||||||
|
|
||||||
|
Adından da anlaşılacağı üzere kullanıcının fotoğrafını gösteriyor.
|
||||||
|
|
||||||
|
* `size="xl"` → Büyük boy avatar
|
||||||
|
* `src="..."` → Avatar resmi (örnek olarak rastgele bir avatar servisi)
|
||||||
|
* `mb={4}` → Alt boşluk (margin bottom)
|
||||||
|
|
||||||
|
### 4\. `Stack` + `Button`
|
||||||
|
|
||||||
|
<Stack direction\="row" spacing\={4} justify\="center"\>
|
||||||
|
<Button colorScheme\="teal" variant\="solid"\>
|
||||||
|
Takip Et
|
||||||
|
</Button\>
|
||||||
|
<Button colorScheme\="teal" variant\="outline"\>
|
||||||
|
Mesaj Gönder
|
||||||
|
</Button\>
|
||||||
|
</Stack\>
|
||||||
|
|
||||||
|
`Stack`: Chakra’nın **dikey veya yatay sıralama** komponentidir.
|
||||||
|
|
||||||
|
* `direction="row"` → Butonları yatay sıralar
|
||||||
|
* `spacing={4}` → Aralarındaki boşluk
|
||||||
|
* `Button`: Chakra’nın hazır buton bileşeni
|
||||||
|
* `colorScheme="teal"` → Temadaki teal rengini kullanır
|
||||||
|
* `variant="solid"` vs. `variant="outline"` → Dolu ya da çerçeveli buton stilleri
|
||||||
|
|
||||||
|
Aslında genel mantık çok basit, dolayısıyla dökümantasyonda biraz zaman geçirdikten sonra projelerinizi hızlıca yapmaya başlayabilirsiniz.
|
||||||
|
|
||||||
|
## Chakra UI ‘ı daha detaylı öğrenmek için
|
||||||
|
|
||||||
|
### Resmî Dokümantasyon
|
||||||
|
|
||||||
|
Chakra UI’nin dökümantasyonu oldukça anlaşılır ve örneklerle doludur, incelemenizi tavsiye ederim.
|
||||||
|
🔗 [https://chakra-ui.com/docs](https://chakra-ui.com/docs)
|
||||||
|
|
||||||
|
### Öneridiğim Konular
|
||||||
|
|
||||||
|
Daha detaya inmek istersen şu konulara göz atmanı öneririm:
|
||||||
|
|
||||||
|
* **Theme Customization**: Renkler, fontlar, spacing’ler nasıl özelleştirilir?
|
||||||
|
* **Responsive Design**: Chakra ile mobil uyumluluğu yönetme
|
||||||
|
* **Dark Mode**: Chakra’nın dark mode desteği nasıl yapılandırılır?
|
||||||
|
* **Component Composition**: Kendi özel bileşenlerini Chakra tabanlı nasıl oluşturursun?
|
||||||
|
* **Hooks**: `useDisclosure`, `useMediaQuery`, `useColorMode` gibi özel hook’ların gücü
|
||||||
|
|
||||||
|
## Proje Fikirleri
|
||||||
|
|
||||||
|
* Blog kartları
|
||||||
|
* Dashboard bileşenleri
|
||||||
|
* E-ticaret ürün kartları
|
||||||
|
* Karanlık mod destekli portfolyo sayfası
|
||||||
|
|
||||||
|
**Unutma:** Chakra UI’nin asıl gücü, tekrar kullanılabilirlik ve sade komponent mimarisinde. Kendi projelerinde Chakra kullanarak hızlı ve sürdürülebilir arayüzler geliştirebilirsin. Buraya kadar okuduğun için teşekkür ederim, serinin bir sonraki yazısında görüşmek üzere.
|
||||||
@@ -0,0 +1,254 @@
|
|||||||
|
---
|
||||||
|
title: "CSS Frameworkleri Tanıyoruz | 5. Bölüm: Materialize"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-05-18"
|
||||||
|
readTime: "6 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "css-frameworkleri-tan-yoruz-5-b-l-m-materialize"
|
||||||
|
excerpt: "CSS Frameworkleri Tanıyoruz | 5. Bölüm: Materialize Merhaba arkadaşlar, bugün 5.bölümde sizlerle “Materialize” ile tanışıyoruz. Dilerseniz başlayalım. Google’ın Material Design …"
|
||||||
|
coverImage: "/blog/images/css-frameworkleri-tan-yoruz-5-b-l-m-materialize-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-5-b%C3%B6l%C3%BCm-materialize-5fd3c99862c2"
|
||||||
|
---
|
||||||
|
|
||||||
|
# CSS Frameworkleri Tanıyoruz | 5. Bölüm: Materialize
|
||||||
|
|
||||||
|
|
||||||
|
Merhaba arkadaşlar, bugün 5.bölümde sizlerle “Materialize” ile tanışıyoruz. Dilerseniz başlayalım.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Google’ın Material Design felsefesinden ilham alan Materialize, modern, duyarlı ve estetik kullanıcı arayüzleri oluşturmayı kolaylaştıran bir CSS frameworküdür. Bu yazıda, Materialize’ın temel özelliklerine, bileşen yapısına ve projelerde nasıl kullanılabileceğine yakından bakıyoruz.
|
||||||
|
|
||||||
|
## Material Design Nedir?
|
||||||
|
|
||||||
|
Material Design, 2014 yılında Google tarafından duyurulan modern bir tasarım dili. Bu sistemin temel amacı; fiziksel dünyanın kurallarını dijital ortama taşıyarak, sezgisel ve tutarlı kullanıcı deneyimleri oluşturmak. Yani butonlar, kartlar, gölgeler ya da animasyonlar rastgele değil; gerçek hayattaki fiziksel etkileşimleri taklit ederek tasarlanıyor. Bence gayet havalı bir başlangıç.
|
||||||
|
|
||||||
|
## Material Design’ın Temel İlkeleri:
|
||||||
|
|
||||||
|
* **Derinlik ve Katman**: Öğeler birbirinden gölge ve konumlandırma ile ayrılır. Bu, kullanıcıya hiyerarşi ve önem hissi verir.
|
||||||
|
* **Canlı Renkler**: Materyal tasarım, cesur ve doygun renkleri sever. Bu renkler genellikle marka kimliğini vurgulamak için kullanılır.
|
||||||
|
* **Animasyon ve Geçişler**: Kullanıcı etkileşimleri akıcı geçişlerle desteklenir. Bu da kullanıcıya her şeyin bilinçli olarak gerçekleştiğini hissettirir.
|
||||||
|
* **Tutarlılık**: Tüm platformlarda aynı görsel dilin korunmasına dikkat edilir.
|
||||||
|
|
||||||
|
Materialize CSS framework’ü de bu felsefeyi temel alarak geliştirildiği için, bileşenlerinden arayüz davranışına kadar her detayda bu prensipleri görebilirsin.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Materialize, sadece şık görünüm sunmakla kalmaz; aynı zamanda geliştiricilere zaman kazandıran birçok yerleşik özellik sunar. İşte öne çıkan temel bileşen ve özellikleri:
|
||||||
|
|
||||||
|
## 1\. Grid Sistemi (Izgara Yapısı)
|
||||||
|
|
||||||
|
Materialize, 12 sütunlu, esnek ve mobil uyumlu bir grid sistemi sunar. Bu yapı sayesinde sayfa düzenleri kolayca planlanabilir ve responsive tasarımlar rahatlıkla oluşturulabilir.
|
||||||
|
|
||||||
|
<div class\="row"\>
|
||||||
|
<div class\="col s6"\>Sütun 1</div\>
|
||||||
|
<div class\="col s6"\>Sütun 2</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
## 2\. Hazır UI Bileşenleri
|
||||||
|
|
||||||
|
Materialize, Material Design felsefesiyle uyumlu birçok hazır bileşen içerir:
|
||||||
|
|
||||||
|
* **Button**
|
||||||
|
* **Card**
|
||||||
|
* **Navbar**
|
||||||
|
* **Modal**
|
||||||
|
* **Tooltip**
|
||||||
|
* **Dropdown**
|
||||||
|
|
||||||
|
Bu bileşenler hem şık görünür hem de kolayca özelleştirilebilir.
|
||||||
|
|
||||||
|
## 3\. Formlar ve Doğrulama
|
||||||
|
|
||||||
|
Form tasarımı ve doğrulama konusunda da oldukça güçlüdür. Giriş kutuları, radio/checkbox elemanları, dropdown menüler ve daha fazlası Materialize ile oldukça estetik ve işlevsel görünür.
|
||||||
|
|
||||||
|
## 4\. JavaScript Destekli Bileşenler
|
||||||
|
|
||||||
|
Materialize, bazı bileşenleri interaktif hale getirmek için JavaScript tabanlı yapı sunar. Örneğin:
|
||||||
|
|
||||||
|
* **Slider**
|
||||||
|
* **Parallax**
|
||||||
|
* **Sidenav**
|
||||||
|
* **Toast mesajlar**
|
||||||
|
|
||||||
|
Bunlar sadece HTML yapısıyla değil, JS üzerinden de kolayca yönetilebilir.
|
||||||
|
|
||||||
|
## 5\. İkon Seti Desteği
|
||||||
|
|
||||||
|
Materialize, Google’ın Material Icons kütüphanesini doğal olarak destekler. Böylece ekstra bir ikon kütüphanesi aramadan projene kolayca ikon ekleyebilirsin.
|
||||||
|
|
||||||
|
<i class\="material-icons"\>home</i\>
|
||||||
|
|
||||||
|
Materialize’ın sunduğu bu temel özellikler, hızlı ve etkileyici kullanıcı arayüzleri geliştirmek isteyenler için büyük kolaylık sağlar. Özellikle yeni başlayanlar için kurulum ve kullanım açısından oldukça kullanıcı dostudur.
|
||||||
|
|
||||||
|
## Kurulum ve Kullanım
|
||||||
|
|
||||||
|
Materialize’ı projene entegre etmek oldukça basit. İster hızlıca denemek için CDN üzerinden, ister daha kapsamlı projelerde NPM gibi paket yöneticileriyle kullanabilirsin. İşte iki yaygın kurulum yöntemi:
|
||||||
|
|
||||||
|
### Hızlı Başlangıç (CDN ile)
|
||||||
|
|
||||||
|
Sadece birkaç satır HTML koduyla Materialize’ı projenize entegre edebilirsiniz:
|
||||||
|
|
||||||
|
<!-- Materialize CSS -->
|
||||||
|
<link rel\="stylesheet" href\="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/css/materialize.min.css"\>
|
||||||
|
|
||||||
|
<!-- Materialize JS -->
|
||||||
|
<script src\="https://cdnjs.cloudflare.com/ajax/libs/materialize/1.0.0/js/materialize.min.js"\></script\>
|
||||||
|
|
||||||
|
Bu yöntem, özellikle küçük çaplı projeler ve hızlı prototipleme için oldukça idealdir.
|
||||||
|
|
||||||
|
### Paket Yöneticisi ile (NPM)
|
||||||
|
|
||||||
|
Daha profesyonel bir yapı kurmak istersen, Materialize’ı NPM aracılığıyla kurabilirsin:
|
||||||
|
|
||||||
|
npm install materialize-css
|
||||||
|
|
||||||
|
Ardından `import` komutlarıyla projenin ilgili dosyalarında kullanabilirsin:
|
||||||
|
|
||||||
|
import "materialize-css/dist/css/materialize.min.css";
|
||||||
|
import "materialize-css/dist/js/materialize.min.js";
|
||||||
|
|
||||||
|
### Örnek Kullanım
|
||||||
|
|
||||||
|
<a class\="waves-effect waves-light btn"\>Tıkla</a\>
|
||||||
|
|
||||||
|
Materialize’ın `waves-effect` sınıfı sayesinde butona tıklama efekti otomatik olarak eklenir. Küçük ama etkili detaylar ile kullanıcı deneyimi artırılır.
|
||||||
|
|
||||||
|
|
||||||
|
Materialize’ın kurulumu ve kullanımı bu kadar basit. Az kodla çok şey elde etmek isteyen geliştiriciler için oldukça kullanıcı dostu bir yapı sunuyor.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Materialize CSS’in güçlü yönlerinden biri, sade yapısı ve örneklerle hızlı sonuç alınabilmesidir. Bu bölümde, framework’ün bazı temel özelliklerini küçük kod parçacıklarıyla tanıyalım.
|
||||||
|
|
||||||
|
## Grid Sistemi (Sütun Yapısı)
|
||||||
|
|
||||||
|
Responsive tasarımlar için kullanılan sütun yapısı oldukça esnektir:
|
||||||
|
|
||||||
|
<div class\="row"\>
|
||||||
|
<div class\="col s6"\>Sol Alan</div\>
|
||||||
|
<div class\="col s6"\>Sağ Alan</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
* `s6` sınıfı, küçük ekranlarda 12 sütunluk yapının yarısını kaplayacak şekilde ayarlanır.
|
||||||
|
* `row` sınıfı satır başlatır, `col` ise sütunu temsil eder.
|
||||||
|
|
||||||
|
## Kart Bileşeni (Card)
|
||||||
|
|
||||||
|
Kullanıcıya içerik sunmak için oldukça şık bir bileşen:
|
||||||
|
|
||||||
|
<div class\="card"\>
|
||||||
|
<div class\="card-content"\>
|
||||||
|
<span class\="card-title"\>Başlık</span\>
|
||||||
|
<p\>Bu bir kart açıklamasıdır.</p\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
## Butonlar
|
||||||
|
|
||||||
|
Basit ama şık butonlar tek satırda oluşturulabilir:
|
||||||
|
|
||||||
|
<a class\="waves-effect waves-light btn"\>Tıkla</a\>
|
||||||
|
|
||||||
|
`waves-effect` ve `waves-light` sınıfları sayesinde tıklama animasyonu eklenir.
|
||||||
|
|
||||||
|
## Modal
|
||||||
|
|
||||||
|
<!-- Tetikleyici -->
|
||||||
|
<a class\="waves-effect waves-light btn modal-trigger" href\="#demoModal"\>Aç</a\>
|
||||||
|
|
||||||
|
<!-- Modal -->
|
||||||
|
<div id\="demoModal" class\="modal"\>
|
||||||
|
<div class\="modal-content"\>
|
||||||
|
<h4\>Merhaba!</h4\>
|
||||||
|
<p\>Bu bir modal içeriktir.</p\>
|
||||||
|
</div\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
Modal’ın çalışması için JS dosyalarının yüklü olması ve `M.Modal.init()` ile başlatılması gerekir.
|
||||||
|
|
||||||
|
Bu örneklerle Materialize CSS’in kullanımının ne kadar basit olduğunu görebilirsin. Minimum kodla maksimum estetik hedeflenmiş durumda.
|
||||||
|
|
||||||
|
## Avantajlar & Dezavantajlar
|
||||||
|
|
||||||
|
Her framework gibi Materialize’ın da güçlü yönleri olduğu kadar bazı sınırlamaları da mevcut. Bu bölümde hem öne çıkan avantajlara hem de dikkat edilmesi gereken dezavantajlara göz atalım.
|
||||||
|
|
||||||
|
## ✅ Avantajlar
|
||||||
|
|
||||||
|
### 1\. Material Design Uyumu
|
||||||
|
|
||||||
|
Google’ın Material Design prensiplerini temel aldığı için arayüzler oldukça modern ve tanıdık bir kullanıcı deneyimi sunar.
|
||||||
|
|
||||||
|
### 2\. Hazır Bileşenler
|
||||||
|
|
||||||
|
Buton, navbar, kart, modal gibi UI bileşenleri önceden tasarlanmış halde gelir. Bu da geliştirme sürecini hızlandırır.
|
||||||
|
|
||||||
|
### 3\. Kolay Öğrenilebilirlik
|
||||||
|
|
||||||
|
Özellikle yeni başlayanlar için oldukça sade bir sözdizimine sahip. Hızlıca projeye dahil edilip kullanılabilir.
|
||||||
|
|
||||||
|
### 4\. Responsive Tasarım Desteği
|
||||||
|
|
||||||
|
Mobil uyumlu grid sistemi sayesinde cihazlar arası geçişlerde görsel bütünlük korunur.
|
||||||
|
|
||||||
|
### 5\. CDN ile Anında Kullanım
|
||||||
|
|
||||||
|
Kurulum süreci çok kolaydır; sadece iki satırla projeye entegre edilebilir.
|
||||||
|
|
||||||
|
## ❌ Dezavantajlar
|
||||||
|
|
||||||
|
### 1\. Topluluk Desteği Sınırlı
|
||||||
|
|
||||||
|
Bootstrap ya da Tailwind gibi büyük bir topluluğa sahip değildir. Kaynak bulmak zaman zaman zor olabilir.
|
||||||
|
|
||||||
|
### 2\. Özelleştirme Zorluğu
|
||||||
|
|
||||||
|
Hazır bileşen yapısı, daha fazla kontrol isteyen geliştiriciler için sınırlandırıcı olabilir. Her şeyin “hazır” olması bazen esnekliği kısıtlayabilir.
|
||||||
|
|
||||||
|
### 3\. Geliştirme Hızı Düşük
|
||||||
|
|
||||||
|
Son dönemde güncellemeleri yavaşlamış durumda. Bu da sürdürülebilirlik konusunda bazı soru işaretleri oluşturabilir.
|
||||||
|
|
||||||
|
Materialize, hızlı ve şık prototipler geliştirmek için harika bir araç olsa da büyük ölçekli projeler veya çok özel UI ihtiyaçları için sınırlayıcı olabilir. Bu yüzden projene başlamadan önce ihtiyaçlarını net belirlemen çok önemli.
|
||||||
|
|
||||||
|
## Materialize ile Yapılmış Projeler
|
||||||
|
|
||||||
|
Materialize, hızlı prototipleme ve modern görünümlü arayüzler oluşturmak isteyen geliştiriciler için oldukça cazip bir seçenek. Peki bu framework gerçek dünyada nasıl kullanılmış? İşte ilham verebilecek bazı örnekler:
|
||||||
|
|
||||||
|
### 1\. Admin Dashboard Arayüzleri
|
||||||
|
|
||||||
|
Materialize, özellikle basit kontrol panelleri ve yönetici arayüzleri için tercih edilir.
|
||||||
|
|
||||||
|
### 2\. Kişisel Portfolyo Siteleri
|
||||||
|
|
||||||
|
Frontend geliştiriciler veya tasarımcılar, portfolyo sitelerini hızlıca oluşturmak için Materialize’ı tercih eder. Renk uyumu ve hazır bileşenler sayesinde profesyonel bir görünüm elde edilir.
|
||||||
|
|
||||||
|
### 3\. Bloglar ve Tanıtım Siteleri
|
||||||
|
|
||||||
|
Materialize ile responsive, sade ve kullanıcı dostu blog temaları kolayca geliştirilebilir.
|
||||||
|
|
||||||
|
## Örnek Projeler ve Kaynaklar
|
||||||
|
|
||||||
|
### 1\. Materialize Showcase Sayfası
|
||||||
|
|
||||||
|
Materialize CSS’in resmi web sitesinde, framework kullanılarak oluşturulmuş çeşitli projelerin sergilendiği bir bölüm bulunmaktadır. Bu sayfada, farklı sektörlerden ve amaçlardan projeleri inceleyebilir, ilham alabilirsiniz.
|
||||||
|
🔗 [Materialize Showcase](https://materializecss.com/showcase.html)
|
||||||
|
|
||||||
|
### 2\. GitHub Üzerinde Açık Kaynak Projeler
|
||||||
|
|
||||||
|
GitHub’da, Materialize CSS kullanılarak geliştirilmiş birçok açık kaynak proje mevcuttur. Bu projeler, farklı kullanım senaryoları ve bileşen entegrasyonları hakkında fikir edinmenizi sağlar. Örneğin:
|
||||||
|
🔗 [Materialize CSS Template — GitHub](https://github.com/Erickmateli/materialize-css-template)
|
||||||
|
|
||||||
|
### 3\. Materialize CSS Temaları
|
||||||
|
|
||||||
|
Materialize CSS’in resmi web sitesinde, farklı kullanım senaryolarına uygun temalar sunulmaktadır. Bu temalar, projelerinize hızlı bir başlangıç yapmanız için faydalı olabilir.
|
||||||
|
🔗 [Materialize Temaları](https://materializecss.com/themes.html)
|
||||||
|
|
||||||
|
## Kapanış & Değerlendirme
|
||||||
|
|
||||||
|
Materialize CSS, sade yapısı ve Google’ın Material Design ilkelerine olan sadakatiyle, özellikle görsel olarak güçlü ve modern arayüzler oluşturmak isteyen geliştiriciler için büyük bir kolaylık sağlar. Hazır bileşenleri, responsive grid sistemi ve basit sözdizimi sayesinde hem yeni başlayanlar hem de hızlı prototipleme yapmak isteyen deneyimli geliştiriciler tarafından tercih edilebilir.
|
||||||
|
|
||||||
|
Ancak framework’ün büyük projelerdeki sınırlılıkları, özelleştirme konusundaki kısıtlamaları ve topluluk desteğinin sınırlı oluşu gibi dezavantajlarını da göz ardı etmemek gerekir. Eğer sade, hızlı ve estetik bir çözüm arıyorsan, Materialize CSS tam sana göre olabilir.
|
||||||
@@ -0,0 +1,201 @@
|
|||||||
|
---
|
||||||
|
title: "Deneyimlemeden Öğrenmeniz Gereken Güvenlik Açıkları"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-07-31"
|
||||||
|
readTime: "5 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "deneyimlemeden-renmeniz-gereken-g-venlik-a-klar"
|
||||||
|
excerpt: "Deneyimlemeden Öğrenmeniz Gereken Güvenlik Açıkları Yazılım geliştirme sürecinde ben dahil bir çoğumuz, kodun çalışmasına ve kullanıcı deneyiminin sorunsuz ilerlemesine …"
|
||||||
|
coverImage: "/blog/images/deneyimlemeden-renmeniz-gereken-g-venlik-a-klar-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/deneyimlemeden-%C3%B6%C4%9Frenmeniz-gereken-g%C3%BCvenlik-a%C3%A7%C4%B1klar%C4%B1-55c31f58c2b2"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Deneyimlemeden Öğrenmeniz Gereken Güvenlik Açıkları
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Yazılım geliştirme sürecinde ben dahil bir çoğumuz, kodun çalışmasına ve kullanıcı deneyiminin sorunsuz ilerlemesine odaklanıyoruz. Ancak bir proje ne kadar işlevsel görünürse görünsün, **arka planda kalan güvenlik önlemleri** yeterince düşünülmediğinde büyük sorunlara yol açabilir.
|
||||||
|
|
||||||
|
Yakın zamanda yaşadığım bir olay, bu gerçeğin var olduğunu bana güzelce hatırlattı.
|
||||||
|
|
||||||
|
Freelance olarak geliştirdiğim bir **blog uygulaması** vardı. Modern teknolojilerle **(Nextjs, Firebase, Express.js, MongoDB…)**, kullanıcı dostu bir arayüzle ve performans öncelikli geliştirilen bu uygulamayı, çalıştığım firmadaki deneyimli bir yazılımcı **abime** sadece fikir alışverişi için gösterdim. Ancak daha uygulamayı incelemesinin üzerinden birkaç dakika geçmişti ki ciddi bir güvenlik açığını (açıklarını) fark etti.
|
||||||
|
|
||||||
|
Bu durum benim için bir dönüm noktası oldu. Çünkü proje **çalışıyordu**. Hatta kullanıcı kayıt, içerik yönetimi gibi birçok özellik eksiksizdi. SEO 100 alıyordu, site aşırı hızlıydı. Ama güvenlik konusuna yeterince eğilmediğimi açıkça gösteriyordu sağolsun **abim**. Hemen ardından şu sorularla baş başa kaldım:
|
||||||
|
|
||||||
|
\- Next.js gibi modern bir framework kullanırken bile ne tür güvenlik açıkları doğabilir?
|
||||||
|
\- Sık yapılan hatalar neler?
|
||||||
|
\- Projeyi yayına almadan önce hangi kontroller mutlaka yapılmalı?
|
||||||
|
\- Uygulama içi kontroller, istemci ve sunucu tarafında nasıl ayrılmalı?
|
||||||
|
|
||||||
|
Bu yazıda, hem kendi deneyimimi hem de bu olaydan sonra yaptığım kapsamlı araştırmaları bir araya getirerek, **web geliştirmede karşılaşılabilecek güvenlik açıkları** ve **bunlardan korunma yöntemlerini** detaylı şekilde paylaşacağım.
|
||||||
|
|
||||||
|
İster benim gibi junior bir geliştirici olun ister senior, bu yazıdaki bilgilerin projelerinizde ciddi fark yaratacağına inanıyorum.
|
||||||
|
|
||||||
|
## Yaşadığım Güvenlik Açığı Neydi?
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Geliştirdiğim projede, admin paneline yalnızca yetkili kullanıcıların erişebilmesini sağlamak için bir doğrulama mekanizması kurmuştum. Ancak kurduğum bu mekanizma, düşündüğüm kadar sağlam değilmiş.
|
||||||
|
|
||||||
|
Admin paneline yönlendirme şu şekilde çalışıyordu:
|
||||||
|
|
||||||
|
1. Kullanıcı admin paneline ait bir route’a erişiyordu (`/admin` gibi),
|
||||||
|
2. Sayfa yüklendikten sonra `useEffect` içinde auth kontrolü yapılıyordu,
|
||||||
|
3. Eğer kullanıcı admin değilse, sayfa içinden bir `router.push("/")` ile yönlendirme yapılıyordu.
|
||||||
|
|
||||||
|
Kağıt üzerinde işe yarıyor gibi görünse de, pratikte büyük bir güvenlik açığı barındırıyormuş, bu genç kardeşiniz nereden bilsin.
|
||||||
|
|
||||||
|
Projeyi sadece fikir alışverişi amacıyla gösterdiğim yazılımcı **abim**, bu yönlendirme yapılmadan önce tarayıcıda admin panelinin içeriğini görüntülemeyi başardı. Yani kullanıcı admin olmasa bile, auth kontrolü yapılmadan önce bileşenler render edilmişti.
|
||||||
|
|
||||||
|
### Bu Neden Tehlikeli?
|
||||||
|
|
||||||
|
* Sayfa yüklenir yüklenmez içeriğin render edilmesi, aslında yetkisi olmayan kullanıcının **gizli verileri görmesine** (çokta gizli değil ama) neden olabiliyor.
|
||||||
|
* Üstelik bu sayfada form bileşenleri, istatistikler, hatta belki de yönetimsel aksiyon butonları varsa (ki vardı), saldırgan bu endpoint’lere doğrudan istek göndererek sistemi istismar edebilir.
|
||||||
|
|
||||||
|
Bu noktada temel problem şuydu: **Yetki kontrolü istemci tarafında yapılıyordu.**
|
||||||
|
|
||||||
|
Bu, kilitli(?) bir kapının önüne not koymaya benzer: “Bu odaya sadece yetkililer girebilir. Değilsen geri dön.”
|
||||||
|
Ama unutmayın, **kapı aslında kilitli değil**, sadece not bırakılmış.
|
||||||
|
|
||||||
|
### Doğru Yaklaşım Ne Olmalıydı?
|
||||||
|
|
||||||
|
Next.js gibi SSR destekli projelerde, özellikle özel route’lara erişim gerekiyorsa:
|
||||||
|
|
||||||
|
* Yetki kontrolü **sunucu tarafında (**`**getServerSideProps**`**)** yapılmalı,
|
||||||
|
* Ya da sayfa tamamen `middleware` ile koruma altına alınmalı (**abim** direkt bana bunu önerdi),
|
||||||
|
* Ve hiçbir şekilde yetkisiz kullanıcıya **gizli içerik render edilmemeli**. (Ben bunu yaptım.)
|
||||||
|
|
||||||
|
## Şimdi gelelim diğer araştırmalarıma, özellikle web projelerinde sık görülen güvenlik açıkları ve alınması gereken önlemler.
|
||||||
|
|
||||||
|
Yazılım geliştirirken çoğu zaman “çalışıyor mu?” sorusunu odak noktasına koyuyorduk ya. Ancak uygulamanın sorunsuz çalışması, onun güvenli olduğu anlamına hiçbir zaman gelmiyor. Kullanıcıdan gelen her veri, tarayıcıda görünen her bileşen ve sunucuya gönderilen her istek potansiyel bir açık barındırabilir.
|
||||||
|
|
||||||
|
İşte modern web projelerinde — özellikle Next.js gibi framework’lerle geliştirilenlerde — en sık karşılaşılan güvenlik açıkları ve bu açıklara karşı alınması gereken önlemler:
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 1\. Yetkisiz Erişim (Broken Access Control)
|
||||||
|
|
||||||
|
**Nedir?**
|
||||||
|
Kullanıcının kendisine ait olmayan kaynaklara erişebilmesi. Örneğin: başkasına ait içerikleri görüntüleyebilmesi, düzenleyebilmesi ya da silebilmesi.
|
||||||
|
|
||||||
|
**Nasıl oluşur?**
|
||||||
|
|
||||||
|
* Auth kontrolünün sadece frontend’de yapılması
|
||||||
|
* API endpoint’lerinde kullanıcıya ait verilerle ilgili kontrol yapılmaması
|
||||||
|
|
||||||
|
**Nasıl önlenir?**
|
||||||
|
|
||||||
|
* Her istek sunucu tarafında doğrulanmalı. Örneğin: `req.user.id === post.userId` gibi kontroller mutlaka yapılmalı
|
||||||
|
* Yetki kontrolü client’ta değil, backend ya da API route’larda yapılmalı.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 2\. XSS (Cross-Site Scripting)
|
||||||
|
|
||||||
|
**Nedir?**
|
||||||
|
Kötü niyetli bir kullanıcının uygulamaya zararlı JavaScript kodu enjekte etmesi ve bu kodun diğer kullanıcıların tarayıcısında çalışması.
|
||||||
|
|
||||||
|
|
||||||
|
**Nasıl oluşur?**
|
||||||
|
|
||||||
|
* Kullanıcıdan alınan verilerin doğrudan HTML’e yazılması
|
||||||
|
* `dangerouslySetInnerHTML` gibi yöntemlerin güvenlik önlemi olmadan kullanılması
|
||||||
|
|
||||||
|
**Nasıl önlenir?**
|
||||||
|
|
||||||
|
* Kullanıcıdan gelen tüm içerikler sanitize edilmeli. (örn: `DOMPurify`, `sanitize-html`)
|
||||||
|
* `dangerouslySetInnerHTML` kullanımı mutlaka filtreleme ile birlikte yapılmalı.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 3\. CSRF (Cross-Site Request Forgery)
|
||||||
|
|
||||||
|
**Nedir?**
|
||||||
|
Kullanıcının oturumunun açık olduğu bir anda, haberi olmadan kötü niyetli bir isteğin onun adına sunucuya gönderilmesi.
|
||||||
|
|
||||||
|
**Nasıl oluşur?**
|
||||||
|
|
||||||
|
* Kullanıcıdan gelen POST isteklerinin kimlik doğrulaması olmadan işlenmesi
|
||||||
|
|
||||||
|
**Nasıl önlenir?**
|
||||||
|
|
||||||
|
* CSRF token kullanımı (NextAuth, trpc, tRPC gibi çözümlerde desteklenir)
|
||||||
|
* CORS politikalarının sıkı şekilde tanımlanması
|
||||||
|
* SameSite cookie ayarlarının uygun yapılması
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 4\. SSR/ISR Fonksiyonlarında Gizli Bilgi Sızıntısı
|
||||||
|
|
||||||
|
**Nedir?**
|
||||||
|
Sunucu tarafında çalışması gereken bazı hassas verilerin yanlışlıkla istemciye taşınması.
|
||||||
|
|
||||||
|
**Nasıl oluşur?**
|
||||||
|
|
||||||
|
* `getServerSideProps` içinde alınan tüm verilerin `props` olarak frontend’e iletilmesi
|
||||||
|
* Admin panelde gizli verilerin, kontrolsüzce SSR sonucu sayfada görünmesi
|
||||||
|
|
||||||
|
**Nasıl önlenir?**
|
||||||
|
|
||||||
|
* Hassas veriler `props` olarak frontend’e gönderilmemeli
|
||||||
|
* Yalnızca gerekli ve güvenli veriler render edilmeli
|
||||||
|
* Gerekiyorsa ayrı bir API route ile sadece yetkili kullanıcılara veri sağlanmalı
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 5\. Güvensiz API Kullanımı
|
||||||
|
|
||||||
|
**Nedir?**
|
||||||
|
API route’larının herkes tarafından erişilebilir ve manipüle edilebilir olması.
|
||||||
|
|
||||||
|
**Nasıl oluşur?**
|
||||||
|
|
||||||
|
* Herhangi bir doğrulama yapmadan POST/PUT/DELETE isteklerinin kabul edilmesi
|
||||||
|
|
||||||
|
**Nasıl önlenir?**
|
||||||
|
|
||||||
|
* API route’larında oturum kontrolü (örneğin NextAuth ile `getServerSession`) (Ben bunu yeni öğrenmenin üzüntüsünü yaşıyorum.)
|
||||||
|
* Kullanıcıların sadece kendi verilerine işlem yapabilmesini sağlayan kontroller
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 6\. Rate Limiting Eksikliği
|
||||||
|
|
||||||
|
**Nedir?**
|
||||||
|
Saldırganların sürekli istek göndererek sistemin kaynaklarını tüketmesi (örneğin brute force, form spam).
|
||||||
|
|
||||||
|
**Nasıl oluşur?**
|
||||||
|
|
||||||
|
* API endpoint’lerinde istek sayısına sınır konulmaması
|
||||||
|
* Özellikle auth, şifre sıfırlama gibi kritik rotalarda koruma eksikliği
|
||||||
|
|
||||||
|
**Nasıl önlenir?**
|
||||||
|
|
||||||
|
* `express-rate-limit`, `next-rate-limit`, `upstash/ratelimit` gibi kütüphaneler kullanarak sınır koymak
|
||||||
|
* Captcha entegrasyonu (reCAPTCHA, **hCaptcha** benim favorim)
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### 7\. .env Verilerinin İstemciye Taşınması
|
||||||
|
|
||||||
|
**Nedir?**
|
||||||
|
Sunucuya özel gizli key’lerin istemci tarafına taşınması.
|
||||||
|
|
||||||
|
**Nasıl oluşur?**
|
||||||
|
|
||||||
|
* `.env` değişkenlerinin `NEXT_PUBLIC_` prefix’i ile kullanılması ama aslında gizli bir bilgi içermesi. (Ben bunu çok yapmışım, çok. Kimse beni uyarmadı, ama artık siz uyarıldınız değerli arkadaşlar.)
|
||||||
|
|
||||||
|
**Nasıl önlenir?**
|
||||||
|
|
||||||
|
* Gizli veriler sadece sunucu tarafında kullanılmalı
|
||||||
|
* `NEXT_PUBLIC_` sadece açık anahtarlar veya güvenli veriler için ayrılmalı
|
||||||
|
|
||||||
|
Buraya kadar okuyan herkese sonsuz teşekkür. Eğer sizlerin de bana tavsiyeleri varsa duymaktan mutluluk duyarım. Sağlıcakla.
|
||||||
@@ -0,0 +1,161 @@
|
|||||||
|
---
|
||||||
|
title: "Docker Nedir? — Kahveni Al, Docker’ı Konuşuyoruz."
|
||||||
|
category: "General"
|
||||||
|
date: "2025-07-03"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "docker-nedir-kahveni-al-docker-konu-uyoruz"
|
||||||
|
excerpt: "Docker Nedir? — Kahveni Al, Docker’ı Konuşuyoruz. Gelin biraz sohbbet edelim: Yazılım geliştirme dünyasında işler bazen biraz… dağınık. Bir yerde çalışan bir uygulama başka bir …"
|
||||||
|
coverImage: "/blog/images/docker-nedir-kahveni-al-docker-konu-uyoruz-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/docker-nedir-kahveni-al-docker%C4%B1-konu%C5%9Fuyoruz-de83718255e8"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Docker Nedir? — Kahveni Al, Docker’ı Konuşuyoruz.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Gelin biraz sohbbet edelim: Yazılım geliştirme dünyasında işler bazen biraz… dağınık. Bir yerde çalışan bir uygulama başka bir yerde çalışmaz, “bende çalışıyor” cümlesi ofis efsanesine dönüşür. Tabii ki uygulamanın sende çalışıp bir başkasında çalışmamasının bir çok sebebi var. Ama bugün onları konuşmayacağız. Biz bugün bu sorunların çoğunu çözmeyi vaad eden Docker’ı konuşacağız. Şimdi sahnemize “docker” çıkıyor, hem de kahraman edasıyla.
|
||||||
|
|
||||||
|
Docker, uygulamalarımızı ve onların bağımlılıklarını, çalıştıkları ortamla birlikte “konteyner” adı verilen hafif sanal kutuların içine koymamıza olanak tanıyan açık kaynaklı bir platform aslında. Ama merak etme, bu yazıda sadece teknik tanımların peşinden koşmayacağız. Ben nasıl anladıysam sana da öyle anlatacağım. Docker’ın ne olduğunu, neden bu kadar sevildiğini, geliştiricilerin neden onu ellerinden bırakmadığını birlikte keşfedeceğiz.
|
||||||
|
|
||||||
|
## Yazının Devamında Neler Var?
|
||||||
|
|
||||||
|
* Neden Docker’a ihtiyaç duyduk?
|
||||||
|
* Docker tam olarak ne yapar?
|
||||||
|
* Konteyner nedir, sanal makineden farkı ne?
|
||||||
|
* Docker ile ilk konteyner nasıl çalıştırılır?
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Neden Docker’a İhtiyaç Duyduk?
|
||||||
|
|
||||||
|
Bir yazılım projesine başladın. Geliştirme ortamını kurdun, kütüphaneleri yükledin, her şey tıkır tıkır çalışıyor. Ama sıra projeyi takım arkadaşına, test ortamına ya da sunucuya aktarmaya geldiğinde işler sarpa sarıyor. Çünkü…
|
||||||
|
|
||||||
|
> “Abi sende çalışıyor da, bende çalışmıyor ya.”
|
||||||
|
|
||||||
|
Bu hepimizin yaşadığı klasik bir senaryo. Çünkü her makine farklı: işletim sistemi farklı, kütüphane versiyonları farklı, yapılandırmalar farklı… Yani uygulamanın çalışması sadece yazılım ile alakalı değil, çalıştığı **ortamla** da ilgili.
|
||||||
|
|
||||||
|
İşte bu yüzden **Docker gibi araçlara ihtiyaç duyduk**. Çünkü yazılım sadece kod değil; onun bağımlılıkları, çalıştığı sistem, ayarları, portları, ortam değişkenleri… hepsi bir bütün. Docker, bu bütünlüğü “container (konteyner)” adını verdiğimiz izole kutulara sarıp, her yerde aynı şekilde çalışmasını sağlıyor.
|
||||||
|
|
||||||
|
## Docker Ne Yapar? — Büyülü Bir Sandık Gibi Düşün
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Docker, yazılımını alır, çalışması için gereken her şeyi yanına koyar (kütüphaneler, ortam ayarları, servisler vb.) ve bunları bir konteyner içine paketler. Bu konteyner, nereye götürürsen götür, aynı şekilde çalışır.
|
||||||
|
|
||||||
|
Şöyle düşün:
|
||||||
|
|
||||||
|
* Geliştirici bilgisayarı
|
||||||
|
* Test sunucusu
|
||||||
|
* Üretim ortamı
|
||||||
|
* Bulut sağlayıcılar
|
||||||
|
|
||||||
|
Docker sayesinde hepsi aynı ortamı görür. Çünkü her şey konteynerin içinde, bilgisayarında ne olursa olsun etkilenmez.
|
||||||
|
|
||||||
|
Ve en güzeli: Docker çok hafif bir şey. Sanal makineler gibi ağır değil. Saniyeler içinde başlatılır, kaynaklarını çok ama çok az tüketir. Yani hem hızlı hem taşınabilir hem de güvenilir. **Büyülü bir sandık.**
|
||||||
|
|
||||||
|
## Container Nedir? Sanal Makineden Farkı Ne?
|
||||||
|
|
||||||
|
Bu sorunun cevabı, Docker’ın neden bu kadar devrim yarattığını daha iyi anlamamıza yardım ediyor.
|
||||||
|
|
||||||
|
### Sanal Makine (Virtual Machine):
|
||||||
|
|
||||||
|
* Tam bir işletim sistemi çalıştırır (örneğin Ubuntu).
|
||||||
|
* Ağırdır, RAM ve diskten bolca yer kaplar.
|
||||||
|
* Başlatması zaman alır.
|
||||||
|
|
||||||
|
### Docker Konteyneri:
|
||||||
|
|
||||||
|
* Sadece uygulaman ve onun çalışması için gerekli olan şeyleri içerir.
|
||||||
|
* Ana sistemin çekirdeğini paylaşır.
|
||||||
|
* Çok daha hafiftir ve hızlı başlar.
|
||||||
|
* Aynı makine üzerinde birden fazla konteyner rahatlıkla çalışabilir.
|
||||||
|
|
||||||
|
## 🐳Docker ile İlk Konteynerimizi Çalıştıralım
|
||||||
|
|
||||||
|
Teori güzel, ama pratik olmadan biraz anlamsız kalıyor her şey. Şimdi Docker yüklü bir sistemde (Windows, Mac veya Linux fark etmez) ilk konteynerimizi çalıştırarak işe başlayalım.
|
||||||
|
|
||||||
|
### 1\. Docker Kurulu mu?
|
||||||
|
|
||||||
|
İlk adım olarak sisteminde Docker kurulu mu kontrol et. Terminal veya komut satırına şu komutu yaz:
|
||||||
|
|
||||||
|
docker \--version
|
||||||
|
|
||||||
|
Eğer kurulu değilse [aha da buradan](https://www.docker.com/products/docker-desktop/) Docker Desktop’u indirip yükleyebilirsin. Kurulum sonrası bilgisayarı yeniden başlatmak gerekebilir.
|
||||||
|
|
||||||
|
### 2\. İlk Docker Komutu: Hello World
|
||||||
|
|
||||||
|
docker run hello-world
|
||||||
|
|
||||||
|
Bu ne yapar dersen:
|
||||||
|
|
||||||
|
* Docker Hub’dan `hello-world` isimli bir imaj çeker.
|
||||||
|
* Bu imajı çalıştırır.
|
||||||
|
* Terminalde sana “Merhaba, Docker çalışıyor!” mesajı verir. **Verdi mi?**
|
||||||
|
|
||||||
|
### 3\. Kendi Uygulamamız için Dockerfile Oluşturalım
|
||||||
|
|
||||||
|
Şimdi gel, basit bir Python uygulamasını Docker içinde çalıştıralım.
|
||||||
|
|
||||||
|
|
||||||
|
`app.py` dosyamız:
|
||||||
|
|
||||||
|
print("Docker içinden merhaba!")
|
||||||
|
|
||||||
|
`Dockerfile`:
|
||||||
|
|
||||||
|
\# Temel imaj olarak Python kullan dedik.
|
||||||
|
FROM python:3.10-slim
|
||||||
|
|
||||||
|
\# Çalışma dizinini ayarladık
|
||||||
|
WORKDIR /app
|
||||||
|
|
||||||
|
\# Kod dosyasını konteynere kopyaladıl
|
||||||
|
COPY app.py .
|
||||||
|
|
||||||
|
\# Konteyner başlatıldığında ne çalıştırılacak?
|
||||||
|
CMD \["python", "app.py"\]
|
||||||
|
|
||||||
|
### Docker image oluştur:
|
||||||
|
|
||||||
|
Terminale şunu yaz:
|
||||||
|
|
||||||
|
docker build -t merhaba-dunya .
|
||||||
|
|
||||||
|
Uygulamayı çalıştır:
|
||||||
|
|
||||||
|
docker run merhaba-dunya
|
||||||
|
|
||||||
|
Ve boom! Terminalde şunu göreceksin:
|
||||||
|
|
||||||
|
Docker içinden merhaba!
|
||||||
|
|
||||||
|
### 4\. Peki Ne Oldu?
|
||||||
|
|
||||||
|
* Docker, Python tabanlı bir mini sistem oluşturdu. (Hazır şeysileri var böyle.)
|
||||||
|
* Senin `.py` dosyanı içine kopyaladı.
|
||||||
|
* Ve bunu küçük, taşınabilir bir konteyner olarak çalıştırdı.
|
||||||
|
|
||||||
|
İşte bu kadar! Artık uygulaman sistemden bağımsız olarak, **Docker konteyneri içinde** çalıştı. Senin için özel bir ortam kurmaya gerek yok. Nerede çalıştırırsan çalıştır, sonuç aynı olacak.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Sonuç — Docker Sadece Bir Araç Değil, Bir Alışkanlık (Bence)
|
||||||
|
|
||||||
|
Docker, modern yazılım geliştirme süreçlerinde sadece bir “araç” değil; **bir düşünme ve çalışma şekli**. Uygulamalarını izole ortamlarda çalıştırmak, bağımlılıkları yönetmek, “bende çalışıyor ama sunucuda bozuldu” gibi sorunları ortadan kaldırmak istiyorsan, Docker en büyük yardımcın olacak.
|
||||||
|
|
||||||
|
### Docker Neden Bu Kadar Seviliyor?
|
||||||
|
|
||||||
|
* Her ortamda aynı şekilde çalışır.
|
||||||
|
* Ekip çalışmasında uyum sağlar.
|
||||||
|
* Uygulamaları taşımayı kolaylaştırır.
|
||||||
|
* Otomasyon süreçlerini hızlandırır.
|
||||||
|
* Yerel geliştirmeden üretime kadar tam destek sunar.
|
||||||
|
|
||||||
|
Ve en güzeli? Öğrenmesi keyifli, kullanması hızlı.
|
||||||
|
Bir kez alıştığında her projene Docker desteği eklemek istersin. Çünkü özgürlük verir. Çünkü sistem karmaşasını senin yerine çözer.
|
||||||
|
|
||||||
|
Eğer bu yazıyı buraya kadar okuduysan, Docker dünyasına adım attın demektir. Şimdi tek yapman gereken denemek, öğrenmek. Okuduğun için sağol, görüşürüz.
|
||||||
@@ -0,0 +1,343 @@
|
|||||||
|
---
|
||||||
|
title: "Frontend Developer 2025 Yol Haritası (Kişisel Bakış Açısıyla)"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-10-06"
|
||||||
|
readTime: "8 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "frontend-developer-2025-yol-haritas-ki-isel-bak-a-s-yla"
|
||||||
|
excerpt: "Frontend Developer 2025 Yol Haritası (Kişisel Bakış Açısıyla) Giriş: Neden Bu Yazıyı Yazdım? Ben junior fullstack developer olarak çalışan, her gün yeni şeyler öğrenmeye çalışan …"
|
||||||
|
coverImage: "/blog/images/frontend-developer-2025-yol-haritas-ki-isel-bak-a-s-yla-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/frontend-developer-2025-yol-haritas%C4%B1-ki%C5%9Fisel-bak%C4%B1%C5%9F-a%C3%A7%C4%B1s%C4%B1yla-dda276fedfb7"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Frontend Developer 2025 Yol Haritası (Kişisel Bakış Açısıyla)
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### Giriş: Neden Bu Yazıyı Yazdım?
|
||||||
|
|
||||||
|
Ben junior fullstack developer olarak çalışan, her gün yeni şeyler öğrenmeye çalışan biriyim.
|
||||||
|
Son birkaç yılda frontend dünyası o kadar hızlı değişti ki, bir şeyleri “öğrenmek” değil, **“doğru sırada öğrenmek”** çok daha önemli hale geldi.
|
||||||
|
|
||||||
|
Geçtiğimiz haftalarda Coderspace Frontend Okulu’na başladım. Programın ilk haftasında, temel konulardan başlayıp modern framework’lere kadar ilerlerken aklıma şu soru geldi:
|
||||||
|
|
||||||
|
> _“Eğer bugün sıfırdan başlasaydım, frontend yolculuğuma nasıl bir rota çizerdim?”_
|
||||||
|
|
||||||
|
Bu soru aslında bu yazının çıkış noktası oldu.
|
||||||
|
|
||||||
|
Birçok yeni başlayan arkadaş gibi ben de zamanında “hangi dil?”, “hangi framework?”, “hangi proje?” gibi sorular arasında kayboldum. YouTube videoları, kurslar, roadmap’ler… Her biri ayrı bir yön gösteriyor ama hiçbiri **kişisel bir bağlam** sunmuyor.
|
||||||
|
|
||||||
|
Bu yüzden bu yazıyı yazmaya karar verdim:
|
||||||
|
Bir junior geliştirici olarak **2025 yılında frontend alanında kendini geliştirmek isteyenler için** hem kendi deneyimlerimden hem de sektördeki yeni trendlerden yola çıkarak bir **yol haritası** oluşturmak istedim.
|
||||||
|
|
||||||
|
Hazırsan başlayalım :)
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Frontend Dünyası 2025’te Nereye Gidiyor?
|
||||||
|
|
||||||
|
Frontend dünyası son birkaç yılda o kadar hızlı evrildi ki, artık bir framework öğrenmek yeterli değil — **düşünme biçimini** güncellemek gerekiyor. Eskiden “HTML, CSS, JS bil yeter” dönemindeydik; şimdi ise **UI tasarımını anlayan, performans optimizasyonu yapan, AI destekli araçlarla çalışan** geliştiriciler öne çıkıyor.
|
||||||
|
|
||||||
|
2025 itibariyle bu alandaki en büyük değişim, aslında bir “teknoloji değişimi” değil, bir **yaklaşım değişimi**.
|
||||||
|
|
||||||
|
### 1\. AI Destekli Geliştirme Artık Norm Haline Geldi
|
||||||
|
|
||||||
|
Yapay zekâ artık bir “yardımcı araç” değil, günlük üretim akışının bir parçası. GitHub Copilot, ChatGPT, Cursor, Replit Agent veya Vercel’in v0.dev gibi araçları, frontend geliştiricilerin işini hem hızlandırıyor hem de yaratıcılığı artırıyor.
|
||||||
|
|
||||||
|
Ama şunu fark ettim:
|
||||||
|
AI, her şeyi senin yerine yapmıyor.
|
||||||
|
Onu **doğru yönlendiren** ve **temelleri bilen** geliştiriciler için bir kaldıraç haline geliyor. Bu yüzden, 2025’te başarılı bir frontend geliştirici olmanın anahtarı: “_AI’ı kullanmak değil, AI ile birlikte düşünebilmek.”_
|
||||||
|
|
||||||
|
### 2\. Framework’lerde Konsolidasyon Dönemi
|
||||||
|
|
||||||
|
2019–2023 arası her ay yeni bir framework çıkıyordu; şimdi ise ekosistem **olgunlaşma** dönemine girdi.
|
||||||
|
React hâlâ güçlü, ama artık “tek seçenek” değil.
|
||||||
|
|
||||||
|
* **React 19** ile Server Components kalıcı hale geldi.
|
||||||
|
* **Next.js** App Router ve Server Actions ile “fullstack frontend” dönemini başlattı.
|
||||||
|
* **SvelteKit**, hafifliğiyle performans odaklı projelerde parlıyor.
|
||||||
|
* **SolidStart**, reactivity yaklaşımıyla “en hızlı render” yarışında.
|
||||||
|
* **Qwik** gibi frmework’ler “instant loading” kavramını ciddi biçimde değiştiriyor.
|
||||||
|
|
||||||
|
Yani artık soru “hangi framework?” değil,
|
||||||
|
|
||||||
|
> _“Projenin doğasına en uygun framework hangisi?”_
|
||||||
|
|
||||||
|
olmalı.
|
||||||
|
|
||||||
|
### 3\. Tasarım Odaklı Geliştiricilerin Yükselişi
|
||||||
|
|
||||||
|
Artık sadece kodu değil, **kullanıcı deneyimini** de düşünen geliştiriciler öne çıkıyor. 2025’te bir frontend geliştirici, Figma dosyasını okuyabilmeli, component hierarchy anlayabilmeli, spacing–contrast–motion ilişkisini yorumlayabilmeli.
|
||||||
|
|
||||||
|
Bu yüzden ben de kendi projelerimde sadece “nasıl çalışıyor?” değil,
|
||||||
|
“nasıl hissettiriyor?” sorusunu daha çok sormaya başladım.
|
||||||
|
|
||||||
|
### 4\. Edge ve Server-First Yaklaşım
|
||||||
|
|
||||||
|
Frontend artık sadece “tarayıcı”da değil.
|
||||||
|
Next.js, Remix, Nuxt gibi framework’ler **server-first** paradigmaya geçerek veri işlemenin büyük kısmını edge katmanına taşıyor.
|
||||||
|
|
||||||
|
Bu da demek oluyor ki:
|
||||||
|
|
||||||
|
* Daha az client-side JavaScript,
|
||||||
|
* Daha hızlı sayfa yüklenmesi,
|
||||||
|
* Daha düşük enerji tüketimi.
|
||||||
|
|
||||||
|
Yani frontend artık sadece “arayüz” değil, performans ve sürdürülebilirlik sorumluluğunu da taşıyor.
|
||||||
|
|
||||||
|
### 5\. Yeni Trend: Fullstack Frontend
|
||||||
|
|
||||||
|
Eskiden “backend bilmeyen frontend’ci” gayet normaldi.
|
||||||
|
Ama 2025’te durum değişti.
|
||||||
|
Next.js, Supabase, Firebase gibi araçlar sayesinde frontend geliştiriciler artık **API, veritabanı ve auth** süreçlerini de yönetebiliyor.
|
||||||
|
Bu da seni “fullstack frontend developer” tanımına (bana) yaklaştırıyor.
|
||||||
|
|
||||||
|
2025’te öne çıkan trendleri özetlemek gerekirse:
|
||||||
|
|
||||||
|
* Yapay zekâ entegrasyonu → hız ve verimlilik için şart.
|
||||||
|
* Framework seçimi → artık stratejik bir karar.
|
||||||
|
* Tasarım → kodun ayrılmaz bir parçası.
|
||||||
|
* Edge computing → performans standardı.
|
||||||
|
* Fullstack mindset → yeni jenerasyonun normali.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Temeller: Solid Bir Zemin Olmadan Hiçbir Şey Olmaz
|
||||||
|
|
||||||
|
Frontend dünyasında her şey değişiyor ama **değişmeyen tek şey temellerin gücü**. Yeni framework’ler, araçlar, kütüphaneler geliyor ama hepsi sonunda HTML, CSS ve JavaScript’in üstüne inşa ediliyor. Bu yüzden 2025’te “ilerlemek” isteyen herkesin yapması gereken ilk şey, **yeniden temele dönmek**.
|
||||||
|
|
||||||
|
### 1\. HTML — Yapının DNA’sı
|
||||||
|
|
||||||
|
HTML’i sadece etiket ezberlemek olarak görüyorsan, büyük resmi kaçırıyorsun.
|
||||||
|
Bugün semantic HTML yazmak, accessibility (erişilebilirlik) için kritik.
|
||||||
|
Tarayıcıların ve arama motorlarının içeriğini anlaması buna bağlı.
|
||||||
|
|
||||||
|
2025’te öğrenilmesi gereken HTML konuları:
|
||||||
|
|
||||||
|
* Semantic etiketler (`<header>`, `<main>`, `<section>`, `<article>`, `<nav>` vs.)
|
||||||
|
* Form yapıları ve validation
|
||||||
|
* Meta tag’lerin SEO ve sosyal medya önizlemeleri için kullanımı
|
||||||
|
* Lazy loading, responsive images (`srcset`, `picture`)
|
||||||
|
* Web component temelleri
|
||||||
|
|
||||||
|
### 2\. CSS — Görsel Düşünmenin Dili
|
||||||
|
|
||||||
|
CSS artık eski “deneme-yanılma” dönemini geçti.
|
||||||
|
Modern CSS ile layout oluşturmak, bir tasarımcının mantığıyla çalışmak anlamına geliyor.
|
||||||
|
2025’te CSS bilmek demek, şu konulara hâkim olmak demek:
|
||||||
|
|
||||||
|
* **Flexbox & Grid**: layout’u grid sistemleriyle kurmak
|
||||||
|
* **Responsive tasarım**: mobil öncelikli (mobile-first) düşünmek
|
||||||
|
* **Custom properties (CSS variables)**: temalar, mod switch’ler
|
||||||
|
* **Modern units**: `clamp()`, `minmax()`, `vw`, `vh`, `fr`
|
||||||
|
* **Animation & transition**: micro interaction’larla deneyim yaratmak
|
||||||
|
* **Tailwind CSS veya benzeri utility-first yapılar**
|
||||||
|
|
||||||
|
Ben artık projelere “CSS framework seçimi”nden önce **CSS temeli sağlam mı?** diye bakıyorum. Çünkü framework’ler değişiyor, ama layout mantığı hep aynı kalıyor.
|
||||||
|
|
||||||
|
### 3\. JavaScript — Mantığın Kalbi
|
||||||
|
|
||||||
|
JavaScript hâlâ web’in motoru.
|
||||||
|
Ama artık “for loop yazmak” değil, **modern düşünmek** gerekiyor.
|
||||||
|
|
||||||
|
2025’te JS öğrenmek, sadece syntax değil, yapı ve düşünme biçimi öğrenmek demek. Temel değil, **temelin temeli** olan konulara gerçekten hâkim ol:
|
||||||
|
|
||||||
|
* `let`, `const`, scope ve closure kavramları
|
||||||
|
* Asenkron yapı: `async/await`, `Promise`, `fetch`, `setTimeout`
|
||||||
|
* Array & Object manipülasyonu (`map`, `filter`, `reduce`)
|
||||||
|
* Modular yapı (`import/export`)
|
||||||
|
* DOM manipülasyonu (artık framework’lerle az da olsa hâlâ bilinmeli)
|
||||||
|
* Event bubbling, capturing, propagation
|
||||||
|
* Error handling, try/catch yapıları
|
||||||
|
* ES6+ özellikleri: destructuring, rest/spread, arrow functions
|
||||||
|
|
||||||
|
### 4\. Nasıl Öğrenmeli? (2025 Perspektifi)
|
||||||
|
|
||||||
|
Artık bilgiye ulaşmak kolay; önemli olan **nasıl öğrenileceğini bilmek**.
|
||||||
|
Bunun için birkaç öneri:
|
||||||
|
|
||||||
|
* **Proje tabanlı öğren:** 10 kurs bitir, ama 1 proje yapmazsan unutursun.
|
||||||
|
* **Görselleştir:** Figma + tarayıcı yan yana çalış, ne kodun neyi değiştirdiğini hisset. Gerçekten hisset, hissettiğin zaman daha keyifli oluyor her şey :)
|
||||||
|
* **Kaynak karmaşası yaratma:** 2–3 güvenilir kaynağa odaklan.
|
||||||
|
* **Soru sor:** StackOverflow, Reddit, Discord toplulukları. Bence her hatanı yapay zekaya sorma. Önce bu platformlarda araştır, doğru cevabı bulmak için saatlerce gezin.
|
||||||
|
* **Tekrar et:** Her hafta bir önceki hafta yazdığın kodu gözden geçir.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Modern Framework Seçimi: React mi, Vue mü, Svelte mi, Solid mi?
|
||||||
|
|
||||||
|
Frontend dünyasında herkesin sorduğu klasik soru:
|
||||||
|
|
||||||
|
> “Hangi framework’ü öğrenmeliyim?”
|
||||||
|
|
||||||
|
Ben de zamanında bu sorunun peşinden çok koştum. React mı öğrenmeliyim, yoksa Vue daha mı kolay? Svelte yeni ama hızlı diyorlar…
|
||||||
|
Gerçek şu ki 2025’e geldiğimizde bu sorunun **tek bir doğru cevabı yok**.
|
||||||
|
Ama yanlış bir yaklaşım var: Framework seçmeden önce **neden o framework’ü öğrenmek istediğini** bilmemek.
|
||||||
|
|
||||||
|
### Önce Şunu Kabul Edelim
|
||||||
|
|
||||||
|
Tüm framework’ler HTML, CSS ve JS temelleri üzerine kurulu.
|
||||||
|
Farklı syntax, farklı yaklaşımlar sunsalar da aslında aynı problemi çözmeye çalışıyorlar:
|
||||||
|
|
||||||
|
|
||||||
|
“Karmaşık kullanıcı arayüzlerini yönetilebilir hale getirmek.”
|
||||||
|
|
||||||
|
Yani React bilmek bir amaç değil, bir araç. Bu yüzden framework seçimini **trend** değil, **ihtiyaç** belirlemeli.
|
||||||
|
|
||||||
|
### 1- React (ve Next.js Ekosistemi)
|
||||||
|
|
||||||
|
React hâlâ ekosistemin en güçlü oyuncusu.
|
||||||
|
Ama 2025’te React öğrenmek = sadece `useState` bilmek değil.
|
||||||
|
|
||||||
|
React 19 ile birlikte:
|
||||||
|
|
||||||
|
* **Server Components** artık varsayılan hale geldi,
|
||||||
|
* **React Compiler** performans optimizasyonunu otomatikleştiriyor,
|
||||||
|
* ve **Next.js 15** sayesinde “frontend mi backend mi” sorusu neredeyse ortadan kalktı.
|
||||||
|
|
||||||
|
Next.js App Router, Server Actions ve Edge Functions ile birlikte artık React geliştiricileri sadece UI değil, **fullstack deneyim** üretebiliyor.
|
||||||
|
|
||||||
|
> _React = Geniş ekosistem, güçlü topluluk, kurumsal işler için güvenli liman.
|
||||||
|
> Ama öğrenme eğrisi dik ve sabır gerektiriyor._
|
||||||
|
|
||||||
|
**Kimler için ideal:**
|
||||||
|
|
||||||
|
* Freelance ya da startup ortamında çalışanlar
|
||||||
|
* “Backend’e de dokunayım” diyen fullstack meraklıları
|
||||||
|
* Kurumsal ölçekte ölçeklenebilir uygulama geliştirenler
|
||||||
|
|
||||||
|
### 2\. Vue.js
|
||||||
|
|
||||||
|
Vue hâlâ “öğrenmesi en keyifli framework” unvanını koruyor.
|
||||||
|
2025’te Vue 3 ve Composition API tamamen oturdu,
|
||||||
|
Nuxt 4 ile SSR deneyimi Next.js kalitesine yaklaştı.
|
||||||
|
|
||||||
|
Vue’nun güzelliği basitliğinde:
|
||||||
|
|
||||||
|
* React gibi karmaşık yapılandırmalar gerektirmiyor,
|
||||||
|
* Template yapısı HTML’e çok benziyor,
|
||||||
|
* Ve state yönetimi Pinia ile oldukça rahat.
|
||||||
|
|
||||||
|
> _Vue = Öğrenmesi kolay, üretime geçmesi hızlı, küçük/orta ölçekli projeler için mükemmel._
|
||||||
|
|
||||||
|
**Kimler için ideal:**
|
||||||
|
|
||||||
|
* UI mantığını sade bir şekilde öğrenmek isteyenler
|
||||||
|
* Prototip veya startup MVP’si çıkaran ekipler
|
||||||
|
* “React karmaşık geldi” diyen geliştiriciler
|
||||||
|
|
||||||
|
### 3\. Svelte ve SvelteKit
|
||||||
|
|
||||||
|
Svelte, framework dünyasının minimalist çocuğu.
|
||||||
|
Yani “az kodla çok iş” yaptırıyor.
|
||||||
|
Ama onu asıl özel yapan şey, **derleme aşamasında sanal DOM’u ortadan kaldırması.**
|
||||||
|
Bu da onu inanılmaz performanslı hale getiriyor.
|
||||||
|
|
||||||
|
SvelteKit 2.0 ile birlikte dosya tabanlı routing, SSR, API endpoints ve veritabanı entegrasyonu geldi.
|
||||||
|
Artık “Svelte sadece deneme projesi için” dönemi bitti.
|
||||||
|
|
||||||
|
> _Svelte = Küçük ama etkileyici projeler için performans canavarı.
|
||||||
|
> Ancak ekosistem hâlâ React kadar geniş değil._
|
||||||
|
|
||||||
|
**Kimler için ideal:**
|
||||||
|
|
||||||
|
* Performans ve sadelik odaklı düşünen geliştiriciler
|
||||||
|
* Yeni teknolojileri erken benimsemeyi sevenler
|
||||||
|
* “Yapay değil, doğal reactivity istiyorum” diyenler
|
||||||
|
|
||||||
|
### 4\. SolidJS
|
||||||
|
|
||||||
|
Solid, “React ama daha hızlı” mottosuyla geldi.
|
||||||
|
Reactivity sistemini compile-time’a taşıdığı için render performansı çok güçlü.
|
||||||
|
Ayrıca JSX yapısı React’e benzediği için geçiş kolay.
|
||||||
|
|
||||||
|
2025’te SolidStart (framework versiyonu) olgunlaştı ve fullstack çözümler sunmaya başladı.
|
||||||
|
Kısaca:
|
||||||
|
|
||||||
|
> _SolidJS = React’in düşünce yapısı + Svelte’in performansı._
|
||||||
|
|
||||||
|
Ama hâlâ öğrenmesi zor ve dokümantasyon kısıtlı.
|
||||||
|
|
||||||
|
**Kimler için ideal:**
|
||||||
|
|
||||||
|
* Derin teknik meraklıları
|
||||||
|
* “Yeni jenerasyon framework” arayanlar
|
||||||
|
* Deneysel, ileri düzey projelerde çalışanlar
|
||||||
|
|
||||||
|
Yani önce bir framework’te ustalaş, sonra diğerlerine “bakış açısı” olarak geç. Çünkü teknolojiler değişse de, **mantık kalıcı**.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## UI/UX Bilinci: Tasarım Gözünü Geliştirmek
|
||||||
|
|
||||||
|
Frontend geliştirici olmanın en yanlış anlaşılan tarafı şu:
|
||||||
|
|
||||||
|
> _“Ben tasarımcı değilim, sadece kod yazarım.”_
|
||||||
|
|
||||||
|
Oysa 2025’te bu bakış açısı geçerliliğini yitirdi.
|
||||||
|
Artık iyi bir frontend geliştirici, sadece çalışan arayüzler değil, **hissettiren deneyimler** oluşturuyor.
|
||||||
|
|
||||||
|
Kodu estetikle buluşturabilenler, bu dönemin en değerli geliştiricileri haline geldi.
|
||||||
|
|
||||||
|
### 1\. Tasarım Okuryazarı Olmak
|
||||||
|
|
||||||
|
Tasarım bilmek demek Figma’da piksel ile oynamak değil.
|
||||||
|
Renk kontrastını, hiyerarşiyi, boşluk kullanımını, kullanıcı akışını anlayabilmek demek.
|
||||||
|
Çünkü bu detaylar, bir kullanıcı “güzel olmuş” dediğinde farkında olmadan hissettiği şeylerdir.
|
||||||
|
|
||||||
|
Ben ilk kez UI/UX’e ilgimi fark ettiğimde (Emir arkadaşım sağolsun) şunu yaşadım:
|
||||||
|
Tasarımcı bana “spacing 8 yerine 12 olmalı” dediğinde içimden “4 pikselin ne önemi var?” demiştim.
|
||||||
|
Ama sonra fark ettim: o 4 piksel aslında **dengeyi** belirliyormuş.
|
||||||
|
|
||||||
|
Frontend’te bu dengeyi görebilmek, kod yazmak kadar önemli.
|
||||||
|
|
||||||
|
### 2\. Sistemli Tasarım Düşüncesi
|
||||||
|
|
||||||
|
UI/UX bilinci sadece estetik değil, **tutarlılık** meselesidir.
|
||||||
|
Bir projede her buton farklı görünüyor, her modal farklı davranıyorsa kullanıcı o ürüne güvenemez.
|
||||||
|
|
||||||
|
Bu yüzden artık modern frontend dünyasında “Design System” kavramı öne çıktı:
|
||||||
|
|
||||||
|
* **Tailwind + Shadcn/UI** ile yeniden kullanılabilir component’lar
|
||||||
|
* **Radix UI** ile erişilebilirlik garantili altyapılar
|
||||||
|
* **Framer Motion** ile micro animation’lar
|
||||||
|
* **Figma Tokens** ile tasarım ve kodun aynı dili konuşması
|
||||||
|
|
||||||
|
> _“Tasarım sistemi, estetik değil sürdürülebilirlik sağlar.”_
|
||||||
|
|
||||||
|
Bu anlayışla bir kere sistem kurduğunda, 10 proje boyunca aynı altyapıyı güvenle kullanabilirsin.
|
||||||
|
|
||||||
|
### 3\. Animasyon ve Duygusal Etki
|
||||||
|
|
||||||
|
Bir arayüz çalışabilir, ama hissettirmeyebilir.
|
||||||
|
2025’te fark yaratan frontend projeleri, **hareket** ile kullanıcıyla duygusal bağ kuruyor.
|
||||||
|
|
||||||
|
Framer Motion (Artık sadece motion), GSAP, LottieFiles gibi araçlar artık modern UI’nin ayrılmaz parçaları.
|
||||||
|
Ama burada ince bir çizgi var:
|
||||||
|
|
||||||
|
> _“Animasyon dikkat dağıtmak için değil, yönlendirmek için yapılır.”_
|
||||||
|
|
||||||
|
Ben kendi projelerimde bu farkı özellikle hissettim.
|
||||||
|
Butonun tıklanma animasyonu, yükleme geçişi veya hover efekti…
|
||||||
|
Küçük detaylar kullanıcıya “senin için özen gösterdim” hissi veriyor.
|
||||||
|
|
||||||
|
### 4\. UX = Empati
|
||||||
|
|
||||||
|
Tüm bunların özünde tek bir şey var: **empati**.
|
||||||
|
Kullanıcı ne hisseder, neye tıklar, nerede kaybolur?
|
||||||
|
Bu soruları sormadan yapılan her tasarım sadece “güzel” kalır ama “anlamlı” olmaz.
|
||||||
|
|
||||||
|
Benim için UI/UX bilinci, kodla empatiyi birleştirmek demek.
|
||||||
|
Her butonun, her spacing’in bir nedeni olması gerektiğini fark ettiğinde artık “arayüz yazmıyorsun” — **deneyim inşa ediyorsun.**
|
||||||
|
|
||||||
|
## Son Söz: Her Gün Bir Adım
|
||||||
|
|
||||||
|
Frontend öğrenmek bir sprint değil, bir maraton. Ve bu maratonda bazen hızlanırsın, bazen durur, bazen yönünü kaybedersin. Ama önemli olan koşmaya devam etmektir.
|
||||||
|
|
||||||
|
Ben de hâlâ aynı yoldayım.
|
||||||
|
Her gün bir şeyleri biraz daha iyi anlamaya, biraz daha sade yazmaya, biraz daha az hata yapmaya çalışıyorum. Bazen sadece 10 satır kod yazabiliyorum ama o 10 satır, dünkü benden daha iyi olduğumun kanıtı.
|
||||||
@@ -0,0 +1,212 @@
|
|||||||
|
---
|
||||||
|
title: "Frontend Mimarisinde En Zor Kısım: Karar Vermek"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-12-23"
|
||||||
|
readTime: "10 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "frontend-mimarisinde-en-zor-k-s-m-karar-vermek"
|
||||||
|
excerpt: "Frontend Mimarisinde En Zor Kısım: Karar Vermek TL;DR Frontend mimarisinde asıl zor kısım “en iyi pattern”i bulmak değil; hangi kararı, ne zaman ve ne kadar kesinlikle vereceğine karar …"
|
||||||
|
coverImage: "/blog/images/frontend-mimarisinde-en-zor-k-s-m-karar-vermek-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/frontend-mimarisinde-en-zor-k%C4%B1s%C4%B1m-karar-vermek-b3719c7aaacd"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Frontend Mimarisinde En Zor Kısım: Karar Vermek
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## **TL;DR**
|
||||||
|
|
||||||
|
Frontend mimarisinde asıl zor kısım “en iyi pattern”i bulmak değil; **hangi kararı, ne zaman ve ne kadar kesinlikle** vereceğine karar vermek. Çünkü frontend, ürün ihtiyaçlarıyla (hız, teslim tarihi, UX), ekip gerçekleriyle (tecrübe, sahiplik), ve teknik kısıtlarla (performans, bakım maliyeti) aynı anda pazarlık yapar. Bu yazıda mimari kararları “doğru/yanlış” ikileminden çıkarıp; **trade-off’larla yönetilen, geri alınabilirliği planlanan** ve ekibe uygun şekilde yazılı hale getirilen bir süreç olarak ele alacağım. Sonunda da kararları daha az stresli, daha izlenebilir ve daha sürdürülebilir hale getiren pratik bir yaklaşım paylaşacağım.
|
||||||
|
|
||||||
|
## İçerik
|
||||||
|
|
||||||
|
1. Frontend mimarisinde “karar verme” problemi
|
||||||
|
2. Frontend kararlarının neden diğer alanlara göre daha belirsiz?
|
||||||
|
3. “Doğru mimari” arayışının neden yanıltıcı olduğuna bakalım.
|
||||||
|
4. Geri alınabilir ve geri alınamaz kararlar arasındaki fark
|
||||||
|
5. Frontend mimarisinde olgunluğumun gelişimi
|
||||||
|
6. Karar vermemi kolaylaştıran düşünme çerçeveleri
|
||||||
|
7. Sonuç
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Frontend Mimarisinde “Karar Verme” Problemi
|
||||||
|
|
||||||
|
Frontend mimarisi dendiğinde çoğu kişinin aklına dosya yapıları, klasör isimleri ya da hangi state yönetim aracının kullanılacağı geliyor. Neden?
|
||||||
|
|
||||||
|
Oysa işin en zor kısmı bence bunların hiçbiri değil. En zor kısım, neye karar vereceğini bilmek. Açıkcası ben bunu fark ettikten sonra bunu araştırmaya ve bu yazıyı yazmaya başladım. Neden diye soruyor olabilirsin.
|
||||||
|
|
||||||
|
Çünkü frontend’de kararlar nadiren net oluyor. Genelde gri alanlarda dolaşır. Tam olarak “yanlış” değildir ama “kesin doğru” da değildir.
|
||||||
|
|
||||||
|
Günlük hayatta da benzer bir duruma benzetebiliriz bunu. Mesela yeni bir eve taşınırken:
|
||||||
|
“Bu koltuğu buraya mı koysam, yoksa sonra mı yerleştirsem?”
|
||||||
|
diye düşünürsün. Şu an koyarsan iş görür, ama ileride pişman olma ihtimali vardır. Koymazsan da ev eksik hissi verir.
|
||||||
|
|
||||||
|
Frontend mimarisindeki kararlar da aynen böyledir.
|
||||||
|
|
||||||
|
Bir component’i burada mı konumlandırmalıyım, yoksa daha genel bir yere mi almalıyım? Bu state gerçekten global mi, yoksa şimdilik local kalsa yeter mi? Bu yapı ileride büyür mü, yoksa şu an düşündüğümden küçük mü kalır?
|
||||||
|
|
||||||
|
Sorular bitmez. Çünkü frontend, sürekli değişen bir alanın tam ortasındadır.
|
||||||
|
|
||||||
|
Ürün fikri değişir, tasarım revize olur, kullanıcı davranışı farklı çıkar. Dün “çok mantıklı” görünen bir karar, bugün gereksiz hale gelebilir. Bu da frontend’de karar vermeyi teknik bir meseleden çok, **zamanlama ve sezgi** meselesine dönüştürür.
|
||||||
|
|
||||||
|
**İşin zor tarafı şu:** Çoğu frontend kararı, verildiği anda yanlış hissettirmez. Aksine, genelde işe yarar. Sayfa açılır, feature çalışır, herkes yoluna devam eder. Problem, bu kararların **birikmeye** başlamasıyla ortaya çıkar.
|
||||||
|
|
||||||
|
Bir gün gelir, projeye yeni biri girer ve şu soruyu sorar: **“Bunu neden böyle yaptım?”**
|
||||||
|
|
||||||
|
Ve sen o anda aynı benim gibi şunu fark edersin:
|
||||||
|
Aslında kötü bir karar vermemişsindir.
|
||||||
|
Sadece o an için doğru olan bir kararı, **fazla uzun süre taşımışsındır**.
|
||||||
|
|
||||||
|
Frontend mimarisinde karar verme problemi tam olarak budur.
|
||||||
|
Yanlış karar vermek değil; hangi kararın ne kadar süre geçerli olacağını kestirememek.
|
||||||
|
|
||||||
|
Bu yüzden frontend mimarisi, güçlü kurallardan çok; güçlü karar refleksleri gerektirir. Ve bu refleks, zamanla, hata yaparak ve geriye dönüp bakarak gelişir.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Frontend Kararlarının Neden Diğer Alanlara Göre Daha Belirsiz?
|
||||||
|
|
||||||
|
Frontend’de karar vermeyi zorlaştıran şey, teknik bilginin eksikliği değildir. Asıl mesele, **aynı anda çok fazla değişkenle muhatap olmaktır**. Backend ya da altyapı tarafında kararlar genellikle daha dar bir çerçevede alınır. Veri modeli, iş kuralları ve sistem sınırları daha nettir. Frontend’de ise bu netlik neredeyse hiçbir zaman yoktur.
|
||||||
|
|
||||||
|
Çünkü frontend, doğrudan insan davranışıyla temas eder. Bence bu çok gerici.
|
||||||
|
|
||||||
|
Kullanıcı ne yapar, nereye tıklar, nerede vazgeçer, neyi anlamaz… Bunların hiçbiri baştan kesin değildir. Tasarım aşamasında her şey çok mantıklı görünür ama gerçek kullanıcıyla karşılaştığında bambaşka sonuçlar ortaya çıkabilir. Bu da frontend’de alınan mimari kararları sürekli “geçici” hale getirir.
|
||||||
|
|
||||||
|
Bir de ürün tarafı vardır. Bugün “küçük bir özellik” olarak gelen bir istek, birkaç ay sonra ürünün merkezine oturabilir. İlk başta basitçe çözülen bir akış, zamanla onlarca farklı senaryoyu taşımak zorunda kalır. O noktada dönüp bakarsın ve şunu fark edersin: Mimari karar, ürünün evrimine ayak uyduramamıştır.
|
||||||
|
|
||||||
|
**Ekip dinamikleri de bu belirsizliği artırır.** Frontend projeleri çoğu zaman tek kişiyle başlar, sonra ekip büyür. Ya da tam tersi olur; ekip küçülür, sorumluluklar artar. Dün herkesin anladığı bir yapı, bugün kimsenin dokunmak istemediği bir alana dönüşebilir. Aynı mimari karar, farklı ekip yapılarında tamamen farklı sonuçlar doğurur.
|
||||||
|
|
||||||
|
Tüm bu nedenlerle frontend’de mimari kararlar, teknik doğrulardan çok **bağlama bağımlıdır**. Bugün doğru olan, yarın fazla gelir. Bugün basit olan, yarın yetersiz kalır.
|
||||||
|
|
||||||
|
Bu belirsizlik kötü bir şey değildir. Aksine, frontend’i canlı tutan şeydir. Ama bu gerçeği kabul etmeden mimari kurmaya çalışmak, insanı sürekli yanlış karar verdiğini düşünmeye iter. Oysa çoğu zaman sorun kararın kendisi değil, **koşulların değişmiş olmasıdır**.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## “Doğru Mimari” Arayışının Neden Yanıltıcı Olduğu
|
||||||
|
|
||||||
|
Frontend mimarisiyle ilgili en büyük tuzaklardan biri, bir noktada “doğru” bir yapı olduğuna inanmak. Sanki yeterince araştırırsak, yeterince örnek incelersek, sonunda herkes için geçerli olan o mimariyi bulacakmışız gibi hissederiz. En azından ben öyle hissediyorum ;)
|
||||||
|
|
||||||
|
Bu konu hakkında uzman, kalifiye frontend developer’lar ile konuştuğumda bana gerçekte frontend dünyasında böyle bir olayın olmadığını söylediler.
|
||||||
|
|
||||||
|
Bir yazıda, bir konferans konuşmasında ya da bir GitHub reposunda gördüğümüz mimari yapı genellikle bağlamından kopuktur. Orada çalışan şey, o ekip için, o ürün için, o zaman dilimi için çalışıyordur. Ama biz o yapıyı alıp kendi projemize koyduğumuzda aynı sonucu alacağımızın hiçbir garantisi yoktur.
|
||||||
|
|
||||||
|
Bu durum günlük hayatta da çok tanıdıktır. Bir arkadaşın ben bu yöntemle çok rahat kilo verdim demesi gibi. O yöntem onun hayatına, temposuna, alışkanlıklarına uygundur. Sen aynısını yaptığında aynı sonucu alamazsın. Frontend mimarisi de tam olarak böyle işler.
|
||||||
|
|
||||||
|
“Best practice” diye sunulan pek çok şey aslında **best context practice**’tir.
|
||||||
|
Bağlam değiştiğinde, doğrular da değişir.
|
||||||
|
|
||||||
|
Bir projede çok katmanlı, son derece düzenli bir mimari büyük bir avantajken; başka bir projede aynı yapı sadece yavaşlatıcı bir yüke dönüşebilir. Küçük bir ekip için fazla disiplin, büyük bir ekip için ise hayati bir düzen anlamına gelebilir.
|
||||||
|
|
||||||
|
“Doğru mimari” arayışı, farkında olmadan şunu da beraberinde getirir: Karar vermeyi ertemek.
|
||||||
|
|
||||||
|
Çünkü doğruyu ararken, “ya yanlış seçersem?” korkusu büyür. Bu korku da bizi ya hiç karar vermemeye ya da başkasının kararlarını kopyalamaya iter. Oysa mimari olgunluk, başkalarının kararlarını birebir uygulamak değil; **kendi bağlamında bilinçli tercihler yapabilmektir**.
|
||||||
|
|
||||||
|
Frontend mimarisinde iyi kararlar genellikle mükemmel değildir. Yeterince iyidir. Ve en önemlisi, **değiştirilebilir** olacak şekilde alınmıştır.
|
||||||
|
|
||||||
|
|
||||||
|
Bu noktada mesele, “en doğru mimari hangisi?” sorusu olmaktan çıkar.
|
||||||
|
Asıl soru şudur: “Bu mimari, şu anki koşullarda bize hizmet ediyor mu?”
|
||||||
|
|
||||||
|
Bu soruyu sorabildiğimiz anda, doğru mimari arayışından çıkıp sağlıklı mimari kararlar almaya başlarız.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Geri Alınabilir ve Geri Alınamaz Kararlar Arasındaki Fark
|
||||||
|
|
||||||
|
Frontend mimarisinde karar vermeyi gerçekten zorlaştıran şey, tüm kararların aynı ağırlıkta görünmesidir. İlk bakışta her şey “önemsiz bir detay” gibi durur. Bir klasör adı, bir componentin sınırı, bir state’in yeri… Hepsi küçük gibi hissettirir. Ama hepsi aynı değildir.
|
||||||
|
|
||||||
|
Bazı kararlar vardır; yanlış yapıldığında can sıkar ama düzeltilebilir.
|
||||||
|
Bazıları vardır; yanlış yapıldığında proje uzun süre onunla yaşamak zorunda kalır.
|
||||||
|
|
||||||
|
Aradaki fark, kararın **geri alınabilir olup olmamasıdır**.
|
||||||
|
|
||||||
|
Geri alınabilir kararlar, frontend projelerinin nefes almasını sağlar. Bir component’i başka bir yere taşımak, bir hook’u yeniden yazmak, bir sayfanın iç yapısını değiştirmek… Bunlar zaman alır ama mümkündür. Bu tür kararlar, genellikle cesurca ve hızlı verilebilir. Çünkü hata yapma maliyeti düşüktür.
|
||||||
|
|
||||||
|
Geri alınamaz kararlar ise bence çok korkunç. Verildiği anda çok mantıklı görünür ama zamanla projeyi şekillendirir.
|
||||||
|
|
||||||
|
Örneğin, tüm projeyi tek bir global state etrafında kurgulamak ya da her şeyi belirli bir mimari kalıba zorla oturtmak. Ya da ekip bu yapıyı gerçekten benimsemeden, ağır bir düzen kurmak. Bu kararlar geri almak istediğinde sadece kodu değil, **alışkanlıkları, mental modeli ve ekip akışını** da değiştirmen gerekir.
|
||||||
|
|
||||||
|
Günlük hayattan düşünürsek; bir gün dışarı çıkarken giydiğin ayakkabıyı değiştirmek kolaydır. Ama yaşadığın şehri değiştirmek kolay değildir. İkisi de “karar”dır ama etkileri aynı değildir. Frontend mimarisinde de benzer bir durum vardır.
|
||||||
|
|
||||||
|
Sorun şu ki, çoğu zaman bu iki karar türünü ayırt etmeyiz. Her kararı aynı ciddiyetle ele alır ya da tam tersi, hepsini sonra bakarız diyerek geçiştiririz. Oysa mimari olgunluk, kararların önem derecesini ayırt edebilmekle başlar.
|
||||||
|
|
||||||
|
İyi bir yaklaşım şudur:
|
||||||
|
\- Eğer bir karar geri alınamıyorsa, onu yavaş ver.
|
||||||
|
\- Eğer geri alınabiliyorsa, mükemmeli bekleme.
|
||||||
|
|
||||||
|
Bu bakış açısını öğrendiğimden ve uygulamaya başladığımdan beri frontend’de hem daha hızlı ilerledim hem de gereksiz stresimin önüne geçtim. Çünkü artık mesele “yanlış karar verdim mi?” değil, “bu kararı gerektiğinde geri alabilecek miyim?” sorusuna dönüştü.
|
||||||
|
|
||||||
|
Frontend mimarisinde güven veren şey, hatasız olmak değil; **hatalarla yaşayabilecek bir yapı kurmaktır**.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Frontend Mimarisinde Olgunluğumun Gelişimi
|
||||||
|
|
||||||
|
Frontend mimarisiyle ilişkim, çoğu geliştirici arkadaşımda olduğu gibi kurallarla başladı. İlk başlarda her şey netti. Çook doğru olan klasör yapıları vardı, olmazsa olmaz pattern’lerim vardı. Bunları uygularsam sorun yaşamayacağımı düşünüyordum. Bir projede ne kadar çok kural varsa, o kadar sağlam olacağına inanıyordum.
|
||||||
|
|
||||||
|
Sonra projeler büyümeye başladı.
|
||||||
|
|
||||||
|
Kurallara rağmen işler karışıyordu. Hatta bazen kurallar yüzünden daha da karışıyordu. Bir şeyi değiştirmek için çok fazla yere dokunmak gerekiyordu. Basit bir ihtiyacın çözümü, gereğinden fazla karmaşık hale geliyordu. O noktada ilk kez şunu fark ettim: Mimari, projeyi korumak kadar **kısıtlayabiliyordu** da.
|
||||||
|
|
||||||
|
Bu süreç içersinde çok güzel insanlar ile bu konu hakkında sohbetler ettim. Bol bol düşündüm. Bir süre sonra mimariye yaklaşımım değişti.
|
||||||
|
Daha esnek olmaya çalıştım. Kuralları azalttım, yapıların zamanla şekillenmesine izin verdim. Bu sefer de başka bir problem ortaya çıktı. Başlangıçta hızlı ilerleyen projeler, belli bir noktadan sonra anlaşılmaz hale geliyordu. Herkes kendi bildiği gibi ekleme yapıyor, ortak bir yön duygusu kayboluyordu.
|
||||||
|
|
||||||
|
Bu iki uç arasında gidip gelmek, bana mimari olgunluğun aslında dengeyle ilgili olduğunu öğretti.
|
||||||
|
|
||||||
|
Olgunlaştıkça şunu fark ediyorsun: Mimari, baştan kusursuz olmak zorunda değil. Ama **bilinçli** olmak zorunda.
|
||||||
|
|
||||||
|
Artık karar verirken şu soruları sormaya başladım:
|
||||||
|
|
||||||
|
* Bu yapı gerçekten bugün için mi gerekli?
|
||||||
|
* Yarın değişirse, bunu söküp atabilir miyim?
|
||||||
|
* Bu kararı ben mi anlayacağım, yoksa ekip de anlayabilecek mi?
|
||||||
|
|
||||||
|
En büyük değişim ise şurada oldu: Mimariyi savunulacak bir şey olarak değil, yaşayan bir şey olarak görmeye başladım.
|
||||||
|
|
||||||
|
Eskiden bir yapı kurduğumda, onun “bozulmaması” için uğraşıyordum. Şimdi ise bozulacağını kabul ediyorum. Hatta bozulmasını planlıyorum. Çünkü frontend projelerinde değişim kaçınılmaz. Olgunluk, bu değişimi engellemek değil, onunla birlikte akabilmek.
|
||||||
|
|
||||||
|
Bugün geriye dönüp baktığımda, frontend mimarisinde olgunluğumun artması daha karmaşık yapılar kurmamla değil, daha az ama daha anlamlı kararlar vermemle oldu. Her şeyi kontrol etmeye çalışmak yerine, hangi şeyleri kontrol etmem gerektiğini öğrenmek asıl dönüm noktasıydı.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Karar Vermemi Kolaylaştıran Düşünme Çerçeveleri
|
||||||
|
|
||||||
|
Frontend mimarisinde belli bir noktadan sonra fark ettiğim şey şu oldu: Daha fazla bilgi, karar vermeyi her zaman kolaylaştırmıyor. Bazen tam tersi oluyor. Ne kadar çok seçenek görürsen, o kadar kararsız kalıyorsun. Bu yüzden zamanla kendime bazı basit düşünme çerçeveleri oluşturdum. Mükemmel değiller ama karar verirken beni sakinleştiriyorlar. Belki sizi de sakinleştirirler.
|
||||||
|
|
||||||
|
İlk çerçeve şu: Bu karar bugün gerçekten gerekli mi, yoksa yarın da olur mu?
|
||||||
|
|
||||||
|
Birçok mimari tartışma aslında erken başlar. Henüz ürünün yönü netleşmemişken, olası tüm senaryoları düşünmeye çalışırız. Oysa çoğu karar, gerçekten ihtiyaç doğmadan verildiğinde yanlış olur. Eğer bir yapı bugün somut bir problemi çözmüyorsa, onu biraz ertelemek çoğu zaman daha sağlıklıdır.
|
||||||
|
|
||||||
|
İkinci çerçeve: Bu karar kimleri etkileyecek? Sadece kendimi değil, ekipteki diğer geliştiricileri de ya da gelecekteki beni düşünmeye başladığım an kararlar netleşiyor. Bu yapı yeni gelen birinin işini kolaylaştıracak mı, yoksa önce bunu öğrenmen lazım mı diyeceğiz? Eğer bir karar sürekli açıklama gerektiriyorsa, muhtemelen fazla karmaşıktır.
|
||||||
|
|
||||||
|
Üçüncü çerçeve: Yanılırsam bedeli ne olur? Her kararın bir hata ihtimali vardır. Burada önemli olan hata yapıp yapmamak değil, hatanın maliyetidir. Eğer yanlış yaparsam bir günümü mü alır, yoksa haftalarca sürecek bir refactor mı gerektirir? Bedeli düşük olan kararları hızlı, bedeli yüksek olanları yavaş almak ciddi bir fark yaratıyor.
|
||||||
|
|
||||||
|
Dördüncü çerçeve: Bu yapı büyümeye mi, değişmeye mi hazırlanıyor?
|
||||||
|
Frontend projeleri genelde büyüyeceği varsayılarak tasarlanır. Oysa çoğu proje büyümez, değişir. Akışlar değişir, öncelikler değişir, kullanıcı davranışı değişir. Bu yüzden mimariyi “daha fazla şey ekleriz” düşüncesinden çok, “bir şeyleri rahatça değiştirebilir miyiz?” sorusu üzerinden değerlendirmek kararları sadeleştiriyor.
|
||||||
|
|
||||||
|
Son olarak kendime sıkça şunu soruyorum: Bu kararı üç ay sonra savunabilir miyim? Bu sorunun cevabı evetse, karar genelde yeterince iyidir. Hayırsa, ya erken verilmiştir ya da gereğinden fazla iddialıdır. Mimari kararların hepsini sevmek zorunda değilim; ama neden aldığımı hatırlamak zorundayım.
|
||||||
|
|
||||||
|
Bu çerçeveler beni daha iyi bir YAZILIM MİMARI yapmadı belki, ama daha rahat bir geliştirici yaptı. Çünkü artık karar vermek, “doğruyu bulma” çabası değil; bilinçli bir tercih yapma süreci.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Sonuç
|
||||||
|
|
||||||
|
Bu yazıyı yazarken aslında bir şey öğretmeye değil, son zamanlarda kendimde fark ettiğim değişimleri paylaşmaya çalıştım. Frontend mimarisine bakışımın nasıl evrildiğini, karar verme sürecinin benim için neden daha merkezi bir hale geldiğini anlatmak istedim.
|
||||||
|
|
||||||
|
Eskiden mimariyi daha çok kurallar, yapılar ve “doğru çözümler” üzerinden düşünüyordum. Şimdi ise daha çok zamanlama, bağlam ve geri alınabilirlik üzerinden düşünüyorum. Daha az iddialı ama daha bilinçli kararlar almaya çalışıyorum. Her şeyi en baştan doğru yapmak yerine, değişime alan bırakan yapılar kurmanın beni hem teknik hem zihinsel olarak rahatlattığını fark ettim.
|
||||||
|
|
||||||
|
Bu değişim bir anda olmadı. Projeler büyüdükçe, bazı kararların yük haline geldiğini gördükçe, bazılarını da fazla ciddiye aldığımı fark ettikçe oluştu. Bugün geriye dönüp baktığımda, frontend mimarisinde ilerlemek benim için daha karmaşık çözümler üretmek değil; **hangi kararların gerçekten önemli olduğunu ayırt edebilmek** anlamına geliyor.
|
||||||
|
|
||||||
|
Eğer bu yazı, senin de bir kararın üzerine biraz daha düşünmene ya da “ben bunu neden böyle yapmıştım?” diye sormana sebep olduysa, amacına ulaşmış demektir. Frontend mimarisi çoğu zaman sessiz ilerler ama verdiğimiz kararlar uzun süre bizimle kalır.
|
||||||
|
|
||||||
|
Okuduğun için teşekkür ederim. Umarım bir yerinde sana da dokunmuştur
|
||||||
@@ -0,0 +1,162 @@
|
|||||||
|
---
|
||||||
|
title: "Frontend Testing Araçları: Jest ve Cypress ile Başlamak"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-09-20"
|
||||||
|
readTime: "5 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "frontend-testing-ara-lar-jest-ve-cypress-ile-ba-lamak"
|
||||||
|
excerpt: "Frontend Testing Araçları: Jest ve Cypress ile Başlamak Merhaba arkadaşlar! Yazılım geliştirmek, heyecan verici bir yolculuk ama aynı zamanda dikkatli olunması gereken bir süreç değil mi? …"
|
||||||
|
coverImage: "/blog/images/frontend-testing-ara-lar-jest-ve-cypress-ile-ba-lamak-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/frontend-testing-ara%C3%A7lar%C4%B1-jest-ve-cypress-ile-ba%C5%9Flamak-82ba26656a01"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Frontend Testing Araçları: Jest ve Cypress ile Başlamak
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**Merhaba arkadaşlar!**
|
||||||
|
|
||||||
|
Yazılım geliştirmek, heyecan verici bir yolculuk ama aynı zamanda dikkatli olunması gereken bir süreç değil mi? Kullanıcılar, uygulamalarımızdan her zaman en iyisini bekliyor ve bu beklentileri karşılamak için güvenilir, hatasız bir kod yazmak şart. İşte bu noktada test yazmanın önemi devreye giriyor.
|
||||||
|
|
||||||
|
Frontend alanı, kullanıcıların direk etkileşimde bulunduğu bir alan olduğu için, test yazmak daha da kritik hale geliyor. Unit testlerden E2E testlerine kadar pek çok farklı türde test var. Bu yazımda, seninle beraber popüler iki test aracı olan Jest ve Cypress’i keşfedeceğiz. Jest, JavaScript projelerinde sıkça tercih edilen bir test framework’ü, Cypress ise modern web uygulamaları için geliştirilmiş güçlü bir E2E test aracı. Bu araçların sağladığı avantajları ve nasıl kullanılacaklarını birlikte inceleyerek, test yazmaya dair daha fazla bilgi edinmene yardımcı olmayı umuyorum.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Jest Nedir?
|
||||||
|
|
||||||
|
Gelin bakalım, jest nedir? Jest, Facebook tarafından geliştirilen ve JavaScript projeleri için oldukça popüler bir test framework’üdür. Hızlı ve kullanıcı dostu olmasıyla bilinir; bu da onu hem yeni başlayanlar hem de deneyimli geliştiriciler için ideal bir seçim yapar. Jest, testleri yazmayı ve çalıştırmayı oldukça kolay hale getirir, böylece kodunu test etmek için saatler harcamana gerek kalmaz.
|
||||||
|
|
||||||
|
Peki, Jest’i ne zaman kullanmalısın? Eğer React componentleri üzerinde çalışıyorsan veya basit JavaScript fonksiyonlarını test etmek istiyorsan, Jest kesinlikle işine yarayacak. Özellikle unit test yazarken, Jest’in sağladığı araçlar ile hataları daha kolay tespit edebilir ve kodunu güvence altına alabilirsin.
|
||||||
|
|
||||||
|
Kurulum ise oldukça basit. Tek bir komutla Jest’i projene ekleyebilirsin:
|
||||||
|
|
||||||
|
npm install \--save-dev jest
|
||||||
|
|
||||||
|
Kurulumdan sonra, Jest’i kullanmaya başlamak için birkaç temel ayar yapman yeterli. Şimdi, basit bir test örneğiyle devam edelim.
|
||||||
|
|
||||||
|
function toplama(a, b) {
|
||||||
|
return a + b;
|
||||||
|
}
|
||||||
|
|
||||||
|
Bu fonksiyonu test etmek için Jest ile şöyle bir test yazabilirsin:
|
||||||
|
|
||||||
|
test('2 + 3 eşittir 5', () => {
|
||||||
|
expect(toplama(2, 3)).toBe(5);
|
||||||
|
});
|
||||||
|
|
||||||
|
İşte bu kadar! Testi çalıştırmak için terminalde `npm test` komutunu kullanabilirsin. Eğer her şey yolundaysa, testin geçtiğini göreceksin.
|
||||||
|
|
||||||
|
## Jest ile Test Örneği
|
||||||
|
|
||||||
|
Jest ile test yazmak, emin ol düşündüğünden çok daha kolay. Test senaryolarını yazarken, `describe` ve `it` blokları kullanarak yapıyı oluşturabilirsin. Bu, testlerinin daha düzenli ve okunabilir olmasını sağlar.
|
||||||
|
|
||||||
|
Örneğin, bir `toplama` fonksiyonunu test ederken şöyle bir yapı oluşturabilirsin:
|
||||||
|
|
||||||
|
describe('Toplama Fonksiyonu', () => {
|
||||||
|
it('2 + 3 eşittir 5', () => {
|
||||||
|
expect(toplama(2, 3)).toBe(5);
|
||||||
|
});
|
||||||
|
|
||||||
|
it('0 + 0 eşittir 0', () => {
|
||||||
|
expect(toplama(0, 0)).toBe(0);
|
||||||
|
});
|
||||||
|
});
|
||||||
|
|
||||||
|
Bu yapı ile fonksiyonunun farklı durumlarını test etmiş oluyorsun. `describe` bloğu, test grubu için bir başlık oluştururken, `it` blokları ise her bir test senaryosunu tanımlıyor. Basit değil mi?
|
||||||
|
|
||||||
|
## Mocking ve Spy Kullanımı
|
||||||
|
|
||||||
|
Bazen test ettiğin kod, dış bağımlılıklara (örneğin, API isteklerine) ihtiyaç duyabilir. Bu durumlarda, Jest’in sunduğu mocking ve spy özellikleri devreye giriyor. Mocking ile bağımlılıkları taklit edebilir ve testlerinizi izole edebilirsin.
|
||||||
|
|
||||||
|
Örneğin, bir API çağrısını mocklamak için şu şekilde yapabilirsin:
|
||||||
|
|
||||||
|
jest.mock('axios'); // axios kütüphanesini mockladık
|
||||||
|
|
||||||
|
it('API çağrısı başarılı olursa veriyi döndürmeli', async () => {
|
||||||
|
const veriler = { data: { isim: 'Ali' } };
|
||||||
|
axios.get.mockResolvedValue(veriler); // Mock cevap
|
||||||
|
|
||||||
|
const cevap = await apiCagir(); // Api istek atıyoruz
|
||||||
|
expect(cevap.isim).toBe('Ali');
|
||||||
|
});
|
||||||
|
|
||||||
|
## Snapshot Testing
|
||||||
|
|
||||||
|
Snapshot testing, bileşenlerinin görsel çıktılarının kaydedilmesi ve daha sonra bu çıktılarla karşılaştırılması için mükemmel bir yöntemdir. Özellikle React componentlerinde oldukça kullanışlıdır.
|
||||||
|
|
||||||
|
|
||||||
|
Bir bileşeni snapshot ile test etmek için, şu şekilde yazabilirsin:
|
||||||
|
|
||||||
|
import { render } from '@testing-library/react';
|
||||||
|
import MyComponent from './MyComponent';
|
||||||
|
|
||||||
|
test('MyComponent snapshot testi', () => {
|
||||||
|
const { asFragment } = render(<MyComponent />);
|
||||||
|
expect(asFragment()).toMatchSnapshot(); // Componentin çıktısını kaydediyor
|
||||||
|
});
|
||||||
|
|
||||||
|
## Cypress Nedir?
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Cypress, modern web uygulamaları için geliştirilmiş güçlü bir E2E (end-to-end) test aracı. Kullanıcı etkileşimlerini gerçek zamanlı olarak simüle edebilmesi, onu diğer test araçlarından ayıran en önemli özelliklerinden biri. Cypress, kullanıcıların uygulamanla nasıl etkileşimde bulunduğunu test ederken, hataları hızlı bir şekilde tespit etmeni sağlıyor.
|
||||||
|
|
||||||
|
Cypress ile test yazmak oldukça keyifli, çünkü her şey anlık geri bildirim almanı sağlayacak şekilde tasarlanmış. Testlerini yazarken tarayıcıda anlık olarak sonuçları görebilirsin; bu da debugging sürecini oldukça kolaylaştırır.
|
||||||
|
|
||||||
|
Cypress’i projene eklemek de oldukça basit. Tek bir komutla kurulumunu gerçekleştirebilirsin:
|
||||||
|
|
||||||
|
npm install cypress \--save-dev
|
||||||
|
|
||||||
|
Kurulumdan sonra, `npx cypress open` komutunu çalıştırarak Cypress arayüzünü açabilirsin. Buradan test senaryolarını kolayca yazmaya başlayabilirsin.
|
||||||
|
|
||||||
|
## Basit Bir Test Örneği
|
||||||
|
|
||||||
|
Cypress ile test yazmak için öncelikle test senaryonu belirlemen gerekiyor. Örneğin, bir web sayfasına erişip bir butona tıklayarak bir formu doldurmayı test edelim:
|
||||||
|
|
||||||
|
describe('Form Testi', () => {
|
||||||
|
it('Formu doldurmalı ve göndermeli', () => {
|
||||||
|
cy.visit('https://ornekwebsayfasi.com'); // Test edilecek web sayfasına git
|
||||||
|
cy.get('input\[name="isim"\]').type('Ali'); // İsim alanına "Ali" yaz
|
||||||
|
cy.get('input\[name="email"\]').type('ali@example.com'); // Email alanına söylediğimiz mailiyaz
|
||||||
|
cy.get('button\[type="submit"\]').click(); // Gönder butonuna tıkla
|
||||||
|
cy.get('.success-message').should('contain', 'Başarıyla gönderildi!'); // Başarı mesajını kontrol et
|
||||||
|
});
|
||||||
|
});
|
||||||
|
|
||||||
|
Yukarıdaki örnekte, bir formu doldurup gönderirken Cypress’in sağladığı basit komutları kullandık. `cy.visit()`, `cy.get()` ve `cy.type()` gibi komutlar ile kullanıcı etkileşimlerini simüle ettik.
|
||||||
|
|
||||||
|
## Cypress’in Sunduğu Avantajlar
|
||||||
|
|
||||||
|
Cypress’in en büyük avantajlarından biri, testleri yazarken anlık geri bildirim alabilmendir. Testler çalışırken, tarayıcıda hangi adımların gerçekleştiğini görüp hataları hemen tespit edebilirsin. Ayrıca, Cypress ile birlikte gelen görsel test aracı sayesinde, test sonuçlarını kolayca inceleyebilirsin.
|
||||||
|
|
||||||
|
Cypress, test ortamlarını yönetmekte de oldukça başarılıdır. Farklı ortamlar için ayarları yapılandırabilir, test verilerini kolayca oluşturabilirsin. Bu da, projeni test etme sürecini daha da verimli hale getirir.
|
||||||
|
|
||||||
|
## Jest ve Cypress Arasındaki Farklar
|
||||||
|
|
||||||
|
Jest ve Cypress, farklı test ihtiyaçlarını karşılamak için tasarlanmış iki güçlü araçtır. Ancak, hangi durumda hangisini kullanman gerektiğini bilmen önemli. İşte bu iki araç arasındaki temel farklar:
|
||||||
|
|
||||||
|
### Kullanım Alanları
|
||||||
|
|
||||||
|
* **Jest:** Jest, genellikle unit ve integration testler için kullanılır. JavaScript ve özellikle React projelerinde, componentlerin ve fonksiyonların bağımsız olarak test edilmesini sağlar. Jest, daha çok uygulamanın iç yapısını test ederken, dış bağımlılıklardan bağımsız bir şekilde çalışmanıza olanak tanır.
|
||||||
|
* **Cypress:** Cypress, end-to-end (E2E) testler için idealdir. Kullanıcı etkileşimlerini simüle ederek, uygulamanın tüm akışını test etmeni sağlar. Cypress ile, bir kullanıcının uygulamanı nasıl deneyimleyeceğini gerçek bir tarayıcı ortamında test edebilirsin.
|
||||||
|
|
||||||
|
### Test Yazım Tarzı
|
||||||
|
|
||||||
|
* **Jest:** Jest’te test yazarken, `describe`, `it` ve `expect` gibi yapıları kullanarak senaryoları belirli bir düzen içinde yazarsın. Mocking ve snapshot testing gibi özellikleri sayesinde, fonksiyonel testler yazmak oldukça kolaydır.
|
||||||
|
* **Cypress:** Cypress’te test yazarken, daha doğal bir kullanıcı akışı oluşturursun. `cy.get()`, `cy.type()`, ve `cy.click()` gibi komutlar ile kullanıcı etkileşimlerini simüle edersin. Bu, test yazımını daha basit hale getirir.
|
||||||
|
|
||||||
|
### Geribildirim Süreci
|
||||||
|
|
||||||
|
* **Jest:** Jest testlerini çalıştırırken sonuçları terminal üzerinden görürsün. Eğer bir test başarısız olursa, hata mesajlarını inceleyerek sorunu bulabilirsin. Ancak, anlık görselleştirme imkanı sınırlıdır.
|
||||||
|
* **Cypress:** Cypress, testleri çalıştırırken bir tarayıcı penceresinde anlık sonuçları gösterir. Testlerin hangi adımda başarısız olduğunu görerek, hataları daha kolay tespit edebilirsin. Bu görsel geribildirim, debugging sürecini oldukça hızlandırır.
|
||||||
|
|
||||||
|
### Hangi Aracı Ne Zaman Kullanmalısın?
|
||||||
|
|
||||||
|
* **Jest:** Eğer uygulamanın iç yapısını test etmek istiyorsan, fonksiyonları ve componentleri ayrı ayrı değerlendirmek için Jest’i kullan. Bu, özellikle React bileşenlerinde unit test yazmak için gayet ideal.
|
||||||
|
* **Cypress:** Kullanıcı akışlarını, etkileşimlerini ve tüm uygulama işlevselliğini test etmek istiyorsan, Cypress mükemmel bir seçim olacaktır. E2E testlerin ile kullanıcı deneyimini en gerçekçi şekilde değerlendirebilirsin.
|
||||||
|
|
||||||
|
## Sonuç
|
||||||
|
|
||||||
|
Test yazma pratiği, yazılım geliştirme sürecinin vazgeçilmez bir parçası. Hem Jest hem de Cypress, projelerinin kalitesini artırmak ve kullanıcı deneyimini iyileştirmek için güçlü araçlar sunuyor. Her iki aracın da kendine özgü avantajları ve kullanım alanları var, bu nedenle projenin ihtiyaçlarına göre en uygun olanı seçmek çok önemlidir. Ben de daha yeni yeni öğreniyorum ve bu süreçte öğrendiklerimi ise aktarmaya çalışyorum. **Umarım bu yazımda anlattıklarım sana yardımcı olmuştur. İyi kodlamalar!**
|
||||||
@@ -1,119 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Frontend Testing Araçları: Jest ve Cypress ile Başlamak"
|
|
||||||
category: "Testing"
|
|
||||||
date: "2026-02-22"
|
|
||||||
readTime: "9 min read"
|
|
||||||
author: "Poyraz Avsever"
|
|
||||||
excerpt: "Frontend tarafında kaliteyi korumanın en sağlam yolu testtir. Bu yazıda, farklı amaçlara hizmet eden..."
|
|
||||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*uNpkjRqVlaB2WbDl.png"
|
|
||||||
---
|
|
||||||
|
|
||||||
Frontend tarafında kaliteyi korumanın en sağlam yolu testtir. Bu yazıda, farklı amaçlara hizmet eden iki güçlü aracı birlikte ele alıyoruz: Jest ve Cypress.
|
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
## Jest Nedir?
|
|
||||||
|
|
||||||
Jest, özellikle unit ve integration testlerde sık kullanılan hızlı bir JavaScript test framework'üdür. React projelerinde de çok yaygın kullanılır.
|
|
||||||
|
|
||||||
### Kurulum
|
|
||||||
|
|
||||||
```bash
|
|
||||||
npm install --save-dev jest
|
|
||||||
```
|
|
||||||
|
|
||||||
### Basit Test Örneği
|
|
||||||
|
|
||||||
```js
|
|
||||||
function toplama(a, b) {
|
|
||||||
return a + b;
|
|
||||||
}
|
|
||||||
|
|
||||||
test("2 + 3 eşittir 5", () => {
|
|
||||||
expect(toplama(2, 3)).toBe(5);
|
|
||||||
});
|
|
||||||
```
|
|
||||||
|
|
||||||
### Grup Testleri
|
|
||||||
|
|
||||||
```js
|
|
||||||
describe("Toplama Fonksiyonu", () => {
|
|
||||||
it("2 + 3 eşittir 5", () => {
|
|
||||||
expect(toplama(2, 3)).toBe(5);
|
|
||||||
});
|
|
||||||
|
|
||||||
it("0 + 0 eşittir 0", () => {
|
|
||||||
expect(toplama(0, 0)).toBe(0);
|
|
||||||
});
|
|
||||||
});
|
|
||||||
```
|
|
||||||
|
|
||||||
### Mocking Örneği
|
|
||||||
|
|
||||||
```js
|
|
||||||
jest.mock("axios");
|
|
||||||
|
|
||||||
it("API çağrısı başarılı olursa veriyi döndürmeli", async () => {
|
|
||||||
const veriler = { data: { isim: "Ali" } };
|
|
||||||
axios.get.mockResolvedValue(veriler);
|
|
||||||
|
|
||||||
const cevap = await apiCagir();
|
|
||||||
expect(cevap.isim).toBe("Ali");
|
|
||||||
});
|
|
||||||
```
|
|
||||||
|
|
||||||
### Snapshot Örneği
|
|
||||||
|
|
||||||
```js
|
|
||||||
import { render } from "@testing-library/react";
|
|
||||||
import MyComponent from "./MyComponent";
|
|
||||||
|
|
||||||
test("MyComponent snapshot testi", () => {
|
|
||||||
const { asFragment } = render(<MyComponent />);
|
|
||||||
expect(asFragment()).toMatchSnapshot();
|
|
||||||
});
|
|
||||||
```
|
|
||||||
|
|
||||||
## Cypress Nedir?
|
|
||||||
|
|
||||||
Cypress, gerçek tarayıcıda çalışan ve kullanıcı akışlarını uçtan uca test etmeye odaklanan bir E2E test aracıdır.
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
### Kurulum
|
|
||||||
|
|
||||||
```bash
|
|
||||||
npm install cypress --save-dev
|
|
||||||
```
|
|
||||||
|
|
||||||
### Basit E2E Senaryosu
|
|
||||||
|
|
||||||
```js
|
|
||||||
describe("Form Testi", () => {
|
|
||||||
it("Formu doldurmalı ve göndermeli", () => {
|
|
||||||
cy.visit("https://ornekwebsayfasi.com");
|
|
||||||
cy.get('input[name="isim"]').type("Ali");
|
|
||||||
cy.get('input[name="email"]').type("ali@example.com");
|
|
||||||
cy.get('button[type="submit"]').click();
|
|
||||||
cy.get(".success-message").should("contain", "Başarıyla gönderildi!");
|
|
||||||
});
|
|
||||||
});
|
|
||||||
```
|
|
||||||
|
|
||||||
## Jest ve Cypress Farkı
|
|
||||||
|
|
||||||
### Jest Ne Zaman?
|
|
||||||
|
|
||||||
- Fonksiyon ve component düzeyi testler
|
|
||||||
- Mocking/snapshot ihtiyaçları
|
|
||||||
- Hızlı geri bildirim
|
|
||||||
|
|
||||||
### Cypress Ne Zaman?
|
|
||||||
|
|
||||||
- Kullanıcı akışı testleri
|
|
||||||
- Form, yönlendirme, auth gibi senaryolar
|
|
||||||
- Gerçek tarayıcı davranışı doğrulama
|
|
||||||
|
|
||||||
## Sonuç
|
|
||||||
|
|
||||||
Jest ve Cypress birbirinin alternatifi değil, tamamlayıcısıdır. Jest ile iç mantığı, Cypress ile gerçek kullanıcı deneyimini doğrulayarak daha güvenilir bir frontend geliştirme süreci kurulabilir.
|
|
||||||
@@ -0,0 +1,97 @@
|
|||||||
|
---
|
||||||
|
title: "GPT‑5 Geldi: OpenAI’nin Yeni Modeli Neler Sunuyor?"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-08-08"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "gpt-5-geldi-openainin-yeni-modeli-neler-sunuyor"
|
||||||
|
excerpt: "GPT‑5 Geldi: OpenAI’nin Yeni Modeli Neler Sunuyor? Her şeyin hızla değiştiği bir çağdayız. Teknoloji, özellikle yapay zeka tarafında neredeyse her gün “devrimsel” bir gelişme …"
|
||||||
|
coverImage: "/blog/images/gpt-5-geldi-openainin-yeni-modeli-neler-sunuyor-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/gpt-5-geldi-openainin-yeni-modeli-neler-sunuyor-88d67735a272"
|
||||||
|
---
|
||||||
|
|
||||||
|
# GPT‑5 Geldi: OpenAI’nin Yeni Modeli Neler Sunuyor?
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Her şeyin hızla değiştiği bir çağdayız. Teknoloji, özellikle yapay zeka tarafında neredeyse her gün “devrimsel” bir gelişme yaşanıyor. Bu gelişmelerin başını çekenlerden biri de tahmin edeceğiniz gibi OpenAI.
|
||||||
|
|
||||||
|
Ve işte o beklenen an geldi: **GPT‑5** artık aramızda!
|
||||||
|
|
||||||
|
ChatGPT’yi, kod yazarken, blog yazarken, ödev hazırlarken ya da sadece bir şeyler karalarken kullanan biriyseniz, benim gibi, bu yeni modelin neler sunduğunu duymak isteyeceksiniz.
|
||||||
|
|
||||||
|
Hadi gelin, GPT‑5’e birlikte göz atalım.
|
||||||
|
|
||||||
|
## 1\. Neler Yeni? — GPT‑5 Bize Neler Getiriyor?
|
||||||
|
|
||||||
|
GPT‑5 yalnızca “daha büyük” ya da “daha hızlı” bir model değil. Aynı zamanda daha zeki, daha dikkatli ve daha insan gibi düşünen — en azından öyle iddaa edilen — bir model.
|
||||||
|
|
||||||
|
### İşte öne çıkan bazı yenilikler:
|
||||||
|
|
||||||
|
* **Daha Derin Düşünme:** Karmaşık sorularda artık lafı dolandırmak yerine düşünmeye gerçekten zaman ayırıyor gibi duruyor. Cevapları daha yapılandırılmış ve daha az yüzeysel olacağını söylüyorlar..
|
||||||
|
* **Akıllı Yönlendirme:** Artık kullanıcı olarak bizler “Hangi modeli seçmeliyim?” diye düşünmemize gerek yok. GPT‑5, sorunun yapısına göre mini, thinking, pro gibi alt varyantlara kendisi geçiş yapabiliyor.
|
||||||
|
* **Uzun Bağlam Hafızası:** 256.000 token’lık bağlam penceresiyle GPT‑5, upuzun dokümanları unutmadan okuyabiliyor. Yani sadece üç cümle önce ne dediğini değil, üç sayfa önceki bağlamı da hatırlıyor. Bu bence en önemli gelişmelerden bir tanesi…
|
||||||
|
* **Daha Az Uydurma, Halüsinasyon (Hallucination):** GPT‑5’in en büyük iddiası, önceki modellere göre çok daha az “uydurması”. Bilmediği yerde net bir şekilde bunu belirtiyor, tahmin yürütmekten kaçınıyor. Ki bence bu da güzel bir gelişme.
|
||||||
|
* **Kişiselleştirme ve Kişilik Seçimi:** ChatGPT’de artık modellerin kişilikleri varmış. İster meraklı bir “Nerd”, istersen dinleyici bir “Listener” ile konuşabiliyormuşuz. Bu da kullanıcı deneyimini daha eğlenceli ve gerçek hissettiriyormuş. Ne kadar doğrudur bakıp göreceğiz.
|
||||||
|
|
||||||
|
Kısaca GPT‑5, sadece daha gelişmiş değil, aynı zamanda daha duyarlı, daha kontrollü ve daha yardımcı bir yapay zeka deneyimi sunuyor bizlere.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Böyle değilde…
|
||||||
|
|
||||||
|
### GPT‑4 ile GPT‑5 Arasındaki Farklar
|
||||||
|
|
||||||
|
GPT‑4 zaten etkileyiciydi. Ancak GPT‑5 bu temelin üzerine çok şey koyarak geldi. Aralarındaki farkları sade ve anlaşılır bir şekilde şöyle özetleyebiliriz:
|
||||||
|
|
||||||
|
**1\. Düşünme Derinliği**
|
||||||
|
GPT‑4 çoğu zaman doğru cevabı veriyor ama bazı konularda yüzeyde kalıyordu. GPT‑5 ise daha sistemli düşünüyor, gerekirse cevabı bölümlere ayırıyor, alternatifleri tartıyor. Kısacası, sadece konuşmuyor; düşünerek cevap veriyor.
|
||||||
|
|
||||||
|
|
||||||
|
**2\. Bağlam Hafızası**
|
||||||
|
GPT‑4’ün maksimum bağlam penceresi yaklaşık 32.000 token civarındaydı. Ki bu ne bana ne de sizlere yetmiyordu. GPT‑5’te bu sayı 256.000 token’a kadar çıktı. Bu da demek oluyor ki, çok daha uzun belgeler, konuşmalar ve kod blokları arasında bağlantı kurabiliyor.
|
||||||
|
|
||||||
|
**3\. Doğruluk ve Uydurma Oranı**
|
||||||
|
GPT‑4 zaman zaman kendine çok güvenerek hatalı bilgi verebiliyordu. Sırf bunun yüzünden defalarca hata yaptım. “Evet kesinllikle doğrusu bu”…GPT‑5 bu konuda daha temkinli. Bilmediği şeyleri açıkça belirtme eğiliminde ve doğruluk oranı genel olarak daha yüksek.
|
||||||
|
|
||||||
|
**4\. Otomatik Model Yönlendirmesi**
|
||||||
|
GPT‑4 kullanırken “hangi modelle çalışıyorum?” sorusunu sorabilirdiniz. Bunu sormuyor olsanız dahi belki sizin sorunuza daha kötü cevap verecek bir model ile çalışıyordunuz. Fakat artık GPT‑5’te bu ortadan kalkıyor. Sistem, sorunun karmaşıklığına göre en uygun varyantı (örneğin GPT‑5-mini, GPT‑5-pro) kendi seçiyor.
|
||||||
|
|
||||||
|
**5\. Kişilik Seçenekleri ve Etkileşim Biçimi**
|
||||||
|
GPT‑4’te etkileşimler daha nötr ve genel yapılıydı. GPT‑5’te ise farklı kişilik profilleri sunuluyor (örn. nerd, listener, robot vs.). Bu da kullanıcının modelle kurduğu ilişkiyi daha kişisel ve keyifli hale getiriyor. Bunu denemek lazım ama kulağa güzel geliyor tabii ki.
|
||||||
|
|
||||||
|
**6\. Çoklu Platform ve Entegrasyon Desteği**
|
||||||
|
GPT‑5, Google Takvim, Gmail, Drive gibi hizmetlerle entegrasyon sağlayabiliyor. Bu da onu kişisel asistan gibi kullanabilmeyi mümkün kılıyor. GPT‑4’te böyle bir yetenek bulunmuyordu.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 2\. Kimin İşine Yarar Bu?
|
||||||
|
|
||||||
|
GPT‑5'in geliştirilmiş özellikleri kulağa hoş geliyor ama asıl soru şu: Bu model gerçekten kimin işine yarayacak?
|
||||||
|
|
||||||
|
Cevap: Aslında hepimizin. Biliyorum saçma bir cevap oldu.
|
||||||
|
|
||||||
|
* **Yazılı içerik üretenler için**, GPT‑5 daha akıcı, tutarlı ve bağlama uygun metinler yazabiliyor. Blog yazarları, içerik editörleri ve sosyal medya yöneticileri artık daha az düzeltme yaparak daha fazla iş çıkarabilir yani.
|
||||||
|
* **Yazılım geliştiriciler için**, modelin daha iyi hata yakalama, kod tamamlama ve algoritmik düşünme becerileri çok büyük bir avantaj. Özellikle yeni başlayanlar için adeta bir asistan gibi çalışıyor. Ki daha da önemlisi artık bilmiyorum diyor. Yani saçma saçma kodlar yazıp hemen arkasından özür dilemiyor. Yani umarım böyle olur…
|
||||||
|
* **Öğrenciler ve akademisyenler için**, karmaşık konuları sadeleştirme, uzun metinleri özetleme veya araştırma desteği gibi görevlerde GPT‑5 oldukça etkili.
|
||||||
|
* **İş dünyasında**, rapor yazımı, e-posta taslakları, toplantı özetleri ya da strateji fikirleri gibi alanlarda ciddi zaman kazancı sağlıyor.
|
||||||
|
|
||||||
|
GPT‑5, sadece teknolojik olarak daha ileri değil, aynı zamanda hayatın her alanında daha kullanılabilir bir yardımcı haline gelmiş durumda. Gerçi GPT-4 öyle değil miydi, tartışılır.
|
||||||
|
|
||||||
|
## Sonuç: GPT‑5 ile Nereye Gidiyoruz?
|
||||||
|
|
||||||
|
GPT‑5, yalnızca bir güncelleme değil; yapay zekanın hayatımızdaki yerini yeniden tanımlayan bir adım. Daha doğru, daha düşünceli ve daha kullanıcı dostu olması, onu sadece bir araç olmaktan çıkarıp gerçek bir dijital yardımcıya dönüştürüyor.
|
||||||
|
|
||||||
|
Bu gelişmelerin benim için heyecan verici yanı şu: GPT‑5 şu an elimizdeki haliyle bile oldukça güçlü, ama bu daha başlangıç. OpenAI’nin uzun vadeli hedefi yapay genel zekaya (AGI) ulaşmak. GPT‑5 ise bu yolda atılmış en somut adımlardan biri olarak görülüyor bence.
|
||||||
|
|
||||||
|
Elbette her teknolojide olduğu gibi GPT‑5’in de sınırları ve riskleri var. Ancak doğru kullanıldığında, özellikle üretkenlik, eğitim, iletişim ve iş hayatı gibi alanlarda ciddi katkılar sunma potansiyeli yüksek.
|
||||||
|
|
||||||
|
Sadece “daha iyi yanıtlar” değil, aynı zamanda “daha iyi sorular sorma” çağındayız artık.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Bu yazıyı beğendiysen, yorumlarını duymak isterim.
|
||||||
@@ -1,84 +0,0 @@
|
|||||||
---
|
|
||||||
title: "JSX’den TSX’e Geçiş: Kişisel Bir Deneyim"
|
|
||||||
category: "TypeScript"
|
|
||||||
date: "2026-02-18"
|
|
||||||
readTime: "8 min read"
|
|
||||||
author: "Poyraz Avsever"
|
|
||||||
excerpt: "JavaScript'ten TypeScript'e geçiş, özellikle React projelerinde kod kalitesini gözle görülür şekilde artırıyor..."
|
|
||||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*yRK5eL_pqabAhrn7"
|
|
||||||
---
|
|
||||||
|
|
||||||
JavaScript'ten TypeScript'e geçiş, özellikle React projelerinde kod kalitesini gözle görülür şekilde artırıyor. Bu yazıda JSX'ten TSX'e geçişte yaşadığım deneyimi, zorlukları ve kazançları paylaşıyorum.
|
|
||||||
|
|
||||||
## Neden TypeScript?
|
|
||||||
|
|
||||||
Geçiş kararının temel nedeni daha güvenli ve öngörülebilir kod yazabilmekti. Dinamik tip yapısı bazı durumlarda hızlı başlatma sağlasa da, proje büyüdükçe hata ayıklama maliyetini artırabiliyor.
|
|
||||||
|
|
||||||
## Geçiş Sürecinde İzlediğim Yol
|
|
||||||
|
|
||||||
- Temel `props` ve `state` tiplerini netleştirdim.
|
|
||||||
- Bileşenleri tek seferde değil, kademeli şekilde TSX'e taşıdım.
|
|
||||||
- Hata mesajlarını rehber gibi kullanıp tip sistemini adım adım oturttum.
|
|
||||||
|
|
||||||
## JSX ve TSX Karşılaştırması
|
|
||||||
|
|
||||||
### JSX Örneği
|
|
||||||
|
|
||||||
```jsx
|
|
||||||
import React from "react";
|
|
||||||
|
|
||||||
const Greeting = ({ name }) => {
|
|
||||||
return <h1>Hello, {name}!</h1>;
|
|
||||||
};
|
|
||||||
|
|
||||||
export default Greeting;
|
|
||||||
```
|
|
||||||
|
|
||||||
### TSX Örneği
|
|
||||||
|
|
||||||
```tsx
|
|
||||||
import React from "react";
|
|
||||||
|
|
||||||
interface GreetingProps {
|
|
||||||
name: string;
|
|
||||||
}
|
|
||||||
|
|
||||||
const Greeting: React.FC<GreetingProps> = ({ name }) => {
|
|
||||||
return <h1>Hello, {name}!</h1>;
|
|
||||||
};
|
|
||||||
|
|
||||||
export default Greeting;
|
|
||||||
```
|
|
||||||
|
|
||||||
## Farklar
|
|
||||||
|
|
||||||
### Tip Kontrolü
|
|
||||||
|
|
||||||
- JSX: Yerleşik tip güvenliği yoktur.
|
|
||||||
- TSX: `props` ve `state` açıkça tiplenebilir.
|
|
||||||
|
|
||||||
### Geliştirici Deneyimi
|
|
||||||
|
|
||||||
- JSX: IDE desteği daha sınırlı olabilir.
|
|
||||||
- TSX: Otomatik tamamlama ve erken hata yakalama daha güçlüdür.
|
|
||||||
|
|
||||||
### Kod Güvenliği
|
|
||||||
|
|
||||||
- JSX: Runtime'da hata görme ihtimali daha yüksektir.
|
|
||||||
- TSX: Hataların önemli kısmı derleme aşamasında yakalanır.
|
|
||||||
|
|
||||||
## Karşılaştığım Zorluklar
|
|
||||||
|
|
||||||
- Eski JavaScript kodunu tip sistemine uyarlamak zaman aldı.
|
|
||||||
- Bazı bağımlılıklarda ek tip tanımları gerekebildi.
|
|
||||||
- Başlangıçta tip kuralları yavaşlatıyor gibi görünse de, orta vadede geliştirme hızını artırdı.
|
|
||||||
|
|
||||||
## Elde Ettiğim Kazanımlar
|
|
||||||
|
|
||||||
- Daha güvenli kod tabanı
|
|
||||||
- Daha güçlü IDE desteği
|
|
||||||
- Daha kolay bakım ve refactor
|
|
||||||
|
|
||||||
## Sonuç
|
|
||||||
|
|
||||||
JSX'ten TSX'e geçiş ilk etapta zahmetli görünse de, uzun vadede proje kalitesini artıran önemli bir yatırım. Özellikle ekipli geliştirmede TypeScript, ortak bir kalite standardı oluşturuyor.
|
|
||||||
@@ -1,30 +1,40 @@
|
|||||||
---
|
---
|
||||||
title: "Kullanıcı Araştırması ve Persona Oluşturma: Tasarımın Gizli Kahramanları"
|
title: "Kullanıcı Araştırması ve Personas Oluşturma: Tasarımın Gizli Kahramanları"
|
||||||
category: "UX"
|
category: "General"
|
||||||
date: "2026-02-05"
|
date: "2024-09-02"
|
||||||
readTime: "6 min read"
|
readTime: "2 min read"
|
||||||
author: "Poyraz Avsever"
|
author: "Poyraz Avsever"
|
||||||
excerpt: "Tasarım dünyasında, ürünlerimizin kullanıcılarımızın ihtiyaçlarını en iyi şekilde karşılamasını istemek..."
|
slug: "kullan-c-ara-t-rmas-ve-personas-olu-turma-tasar-m-n-gizli-kahramanlar"
|
||||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*BEVhh2Et54wytkaA.jpg"
|
excerpt: "Kullanıcı Araştırması ve Personas Oluşturma: Tasarımın Gizli Kahramanları Tasarım dünyasında, ürünlerimizin kullanıcılarımızın ihtiyaçlarını en iyi şekilde karşılamasını …"
|
||||||
|
coverImage: "/blog/images/kullan-c-ara-t-rmas-ve-personas-olu-turma-tasar-m-n-gizli-kahramanlar-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/kullan%C4%B1c%C4%B1-ara%C5%9Ft%C4%B1rmas%C4%B1-ve-personas-olu%C5%9Fturma-tasar%C4%B1m%C4%B1n-gizli-kahramanlar%C4%B1-2930cf7dbe13"
|
||||||
---
|
---
|
||||||
|
|
||||||
|
# Kullanıcı Araştırması ve Personas Oluşturma: Tasarımın Gizli Kahramanları
|
||||||
|
|
||||||
|
|
||||||
Tasarım dünyasında, ürünlerimizin kullanıcılarımızın ihtiyaçlarını en iyi şekilde karşılamasını istemek, hepimizin ortak amacı. Ancak bu hedefe ulaşmak için bazen en temel adımları gözden kaçırabiliyoruz. Bu adımlardan biri de kullanıcı araştırması ve personas oluşturma. Gelin, bu iki önemli adımı nasıl gerçekleştirebileceğimizi ve tasarım sürecindeki kritik rollerini birlikte keşfedelim.
|
Tasarım dünyasında, ürünlerimizin kullanıcılarımızın ihtiyaçlarını en iyi şekilde karşılamasını istemek, hepimizin ortak amacı. Ancak bu hedefe ulaşmak için bazen en temel adımları gözden kaçırabiliyoruz. Bu adımlardan biri de kullanıcı araştırması ve personas oluşturma. Gelin, bu iki önemli adımı nasıl gerçekleştirebileceğimizi ve tasarım sürecindeki kritik rollerini birlikte keşfedelim.
|
||||||
|
|
||||||
## Kullanıcı Araştırması: “Yolu Aydınlatan Işık”
|
### Kullanıcı Araştırması: “Yolu Aydınlatan Işık”
|
||||||
|
|
||||||
Kullanıcı araştırması, tasarım sürecinin temel taşlarından biridir. Ancak ne yazık ki, bu adım sıklıkla atlanabiliyor veya yeterince önemsenmiyor. Peki, neden bu kadar önemli?
|
Kullanıcı araştırması, tasarım sürecinin temel taşlarından biridir. Ancak ne yazık ki, bu adım sıklıkla atlanabiliyor veya yeterince önemsenmiyor. Peki, neden bu kadar önemli?
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
Kullanıcı araştırması, gerçek kullanıcıların ihtiyaçlarını, beklentilerini ve zorluklarını anlamamıza yardımcı olur. Yani, tasarımımızın doğru yolda olup olmadığını bilmek için bir tür GPS cihazı gibi düşünün. Anketler, mülakatlar, gözlem ve kullanım testleri gibi yöntemlerle toplanan veriler, tasarım kararlarımızı şekillendirir. Bu veriler olmadan, tasarım sürecimiz kısa bir yolculuk olurdu; hem kullanıcı hem de tasarımcı için tatmin edici olmayan bir yolculuk.
|
Kullanıcı araştırması, gerçek kullanıcıların ihtiyaçlarını, beklentilerini ve zorluklarını anlamamıza yardımcı olur. Yani, tasarımımızın doğru yolda olup olmadığını bilmek için bir tür GPS cihazı gibi düşünün. Anketler, mülakatlar, gözlem ve kullanım testleri gibi yöntemlerle toplanan veriler, tasarım kararlarımızı şekillendirir. Bu veriler olmadan, tasarım sürecimiz kısa bir yolculuk olurdu; hem kullanıcı hem de tasarımcı için tatmin edici olmayan bir yolculuk.
|
||||||
|
|
||||||
## Personas Oluşturma: Kullanıcılarımızı Tanıyalım
|
## Personas Oluşturma: Kullanıcılarımızı Tanıyalım
|
||||||
|
|
||||||
Kullanıcı araştırmasından elde ettiğimiz verileri, personas adı verilen karakterlere dönüştürürüz. Persona, gerçek kullanıcıların temsilcisi olan hayali bir karakterdir. Bu karakterler, tasarım sürecinde karar alırken göz önünde bulundurmamız gereken “ideal” kullanıcılarımızı temsil eder.
|
Kullanıcı araştırmasından elde ettiğimiz verileri, personas adı verilen karakterlere dönüştürürüz. Persona, gerçek kullanıcıların temsilcisi olan hayali bir karakterdir. Bu karakterler, tasarım sürecinde karar alırken göz önünde bulundurmamız gereken “ideal” kullanıcılarımızı temsil eder.
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
Bir persona oluştururken, demografik bilgilerden tutun, kullanıcıların hedeflerine, ihtiyaçlarına ve acı noktalarına kadar birçok ayrıntıyı dikkate alırız. Örneğin, “Mert”, 28 yaşında bir yazılım geliştirici olabilir. Mert, verimliliği artırmak isteyen bir teknoloji meraklısıdır ve kullanıcı dostu ara yüzler arar. Mert’in bu özellikleri, tasarım sürecinde ihtiyaçlarını karşılamak için nelere dikkat etmemiz gerektiğini anlamamıza yardımcı olur.
|
Bir persona oluştururken, demografik bilgilerden tutun, kullanıcıların hedeflerine, ihtiyaçlarına ve acı noktalarına kadar birçok ayrıntıyı dikkate alırız. Örneğin, “Mert”, 28 yaşında bir yazılım geliştirici olabilir. Mert, verimliliği artırmak isteyen bir teknoloji meraklısıdır ve kullanıcı dostu ara yüzler arar. Mert’in bu özellikleri, tasarım sürecinde ihtiyaçlarını karşılamak için nelere dikkat etmemiz gerektiğini anlamamıza yardımcı olur.
|
||||||
|
|
||||||
## Personas’ın Gücü: Empati ve Odaklanma
|
|
||||||
|

|
||||||
|
|
||||||
|
### Personas’ın Gücü: Empati ve Odaklanma
|
||||||
|
|
||||||
Personalar oluşturmanın bir başka avantajı da, ekibinizin kullanıcılarla daha empatik bir bağ kurmasına yardımcı olmasıdır. Persona karakterlerinizle sohbet ederken, onların ihtiyaçlarını ve beklentilerini anlamak daha kolay hale gelir. Bu empati, tasarım kararlarınızda daha bilinçli ve kullanıcı merkezli bir yaklaşım benimsemenizi sağlar.
|
Personalar oluşturmanın bir başka avantajı da, ekibinizin kullanıcılarla daha empatik bir bağ kurmasına yardımcı olmasıdır. Persona karakterlerinizle sohbet ederken, onların ihtiyaçlarını ve beklentilerini anlamak daha kolay hale gelir. Bu empati, tasarım kararlarınızda daha bilinçli ve kullanıcı merkezli bir yaklaşım benimsemenizi sağlar.
|
||||||
|
|
||||||
@@ -36,4 +46,4 @@ Kullanıcı araştırması ve personas oluşturma, sadece tasarım sürecinin bi
|
|||||||
|
|
||||||
Sonuç olarak, kullanıcınızı tanıdığınızda ve onların beklentilerine uygun çözümler sunduğunuzda, sadece daha etkili bir tasarım değil, aynı zamanda daha tatmin edici bir kullanıcı deneyimi elde edersiniz. Tasarım dünyasında başarılı olmak için bu adımları asla atlamayın; çünkü kullanıcılarınızı anlamak, başarılı tasarımların sırrıdır.
|
Sonuç olarak, kullanıcınızı tanıdığınızda ve onların beklentilerine uygun çözümler sunduğunuzda, sadece daha etkili bir tasarım değil, aynı zamanda daha tatmin edici bir kullanıcı deneyimi elde edersiniz. Tasarım dünyasında başarılı olmak için bu adımları asla atlamayın; çünkü kullanıcılarınızı anlamak, başarılı tasarımların sırrıdır.
|
||||||
|
|
||||||
> “Tasarım sadece nasıl göründüğü ya da nasıl hissettirdiği ile ilgili bir şey değildir. Tasarım nasıl çalıştığı ile ilgilidir.” — Steve Jobs
|
> **“Tasarım sadece nasıl göründüğü ya da nasıl hissettirdiği ile ilgili bir şey değildir. Tasarım nasıl çalıştığı ile ilgilidir.” — Steve Jobs**
|
||||||
@@ -0,0 +1,60 @@
|
|||||||
|
---
|
||||||
|
title: "Mikro Etkileşimlerde İkon Kullanımı"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-10-07"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "mikro-etkile-imlerde-i-kon-kullan-m"
|
||||||
|
excerpt: "Mikro Etkileşimlerde İkon Kullanımı Düşün bir, bir uygulamada ya da web sitesinde gezinirken en çok neler dikkatini çeker? Butonların rengi mi, metinlerin düzeni mi yoksa kullanıcı …"
|
||||||
|
coverImage: "/blog/images/mikro-etkile-imlerde-i-kon-kullan-m-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/mikro-etkile%C5%9Fimlerde-i%CC%87kon-kullan%C4%B1m%C4%B1-2262a71d9a4a"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Mikro Etkileşimlerde İkon Kullanımı
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Düşün bir, bir uygulamada ya da web sitesinde gezinirken en çok neler dikkatini çeker? Butonların rengi mi, metinlerin düzeni mi yoksa kullanıcı deneyimini zenginleştiren o küçük ama can alıcı hareketler mi? İşte o “küçük ama can alıcı” dediğimiz şeyler mikro etkileşimlerdir. Bu mikro etkileşimlerde kullanılan ikonlar ise, çoğu zaman fark etmeden bize rehberlik eder, bir işlemi yaparken içimizi rahatlatır ve neyin doğru neyin yanlış gittiğini anında gösterir.
|
||||||
|
|
||||||
|
Ama işin aslı şu ki, ikonlar sadece süs değil. Onlar, kullanıcıyla sessiz bir dilde konuşan en etkili araçlardan biridir.
|
||||||
|
|
||||||
|
### Mikro Etkileşim Nedir?
|
||||||
|
|
||||||
|
Öncelikle şunu bir netleştirelim: Mikro etkileşim dediğimiz şey, dijital dünyadaki “küçük sihirlerdir.” Mesela, bir “gönder” butonuna tıkladığında çıkan minik animasyon, ya da bir formu doldururken doğru ya da yanlış olduğunu gösteren simgeler. Bunlar bize minik ama önemli bilgiler verir. “Evet, doğru yoldasın!” ya da “Bir sorun var, bir göz at istersen.” gibi :)
|
||||||
|
|
||||||
|
Bu küçük etkileşimlerin kullanıcı deneyimine büyük katkıları var çünkü onlar, arayüzde sessiz bir şekilde bize kılavuzluk ediyorlar. Ve bu kılavuzlar, ikonlar sayesinde daha anlamlı hale geliyor.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### İkonların Mikro Etkileşimdeki Rolü
|
||||||
|
|
||||||
|
Şimdi gözünü kapat ve en son kullandığın bir uygulamayı düşün. Belki bir sosyal medya uygulaması, belki bir e-ticaret sitesi. Muhtemelen bazı butonlara bastığında veya bazı işlemleri gerçekleştirdiğinde küçük animasyonlar gördün, değil mi? İşte bu animasyonların içindeki ikonlar sana aslında bir mesaj veriyor. Mesela, bir e-posta formu doldururken yanlış yazdığın bir alanı işaret eden kırmızı bir “çarpı” ya da başarılı bir işlem sonrası beliren yeşil bir “tik”. İşte bunlar, sadece tasarımın göze hoş görünmesini sağlamakla kalmıyor, aynı zamanda kullanıcının ne durumda olduğunu anlatan sessiz yardımcılar olarak karşımıza çıkıyor.
|
||||||
|
|
||||||
|
|
||||||
|
**Bir örnek düşünelim:** Diyelim ki bir butona tıkladın ve yükleme süreci başladı. Karşına dönen bir çark ya da bir yükleme simgesi geldi. Bu sırada bu küçük animasyon ve ikon, sana “Merak etme, işlem devam ediyor, bekle!” mesajını veriyor. Eğer bu geri bildirimi almasaydın, muhtemelen endişelenecek ve işlemin gerçekleşmediğini düşünecektin. İşte tam da bu noktada, ikonlar kullanıcı deneyiminin hayati bir parçası haline geliyor. Kulağa önemli geliyor değil mi?
|
||||||
|
|
||||||
|
### Kullanıcı Yönlendirmesi: İkonlar Ne Zaman ve Nasıl Kullanılmalı?
|
||||||
|
|
||||||
|
Mikro etkileşimlerde ikonların bir nevi “sessiz rehber” olduğunu söylemiştik. Peki bu rehberler ne zaman devreye girmeli ve nasıl tasarlanmalı?
|
||||||
|
|
||||||
|
1. **Doğrulama (Onay İkonları):**
|
||||||
|
En sık gördüğümüz mikro etkileşimlerden biri. Bir işlemin başarıyla tamamlandığını göstermek için yeşil bir tik simgesi kullanmak, kullanıcıya “Harika, işin tamam!” der. Bu ikonlar, genellikle formlar, ödeme işlemleri ya da kayıt süreçlerinde kullanılır. Amaç, kullanıcıya her şeyin yolunda olduğunu anında göstermektir.
|
||||||
|
2. **Uyarılar ve Hatalar (Hata İkonları):**
|
||||||
|
Yanlış ya da eksik yapılan bir işlemde, kırmızı bir çarpı ya da uyarı ikonu ile kullanıcıya “Dur bir dakika, burada bir sorun var” mesajı verilir. Bu ikonlar, kullanıcıyı bir problem olduğunda anında bilgilendirir ve sorunu çözmek için gerekli adımları atmasına yardımcı olur. Ancak burada önemli olan şey, kullanıcıyı sadece uyarmak değil, aynı zamanda onu çözüm yoluna da yönlendirmektir.
|
||||||
|
3. **Yükleme ve Bekleme Durumları (Yükleme İkonları):**
|
||||||
|
En yaygın kullanılan mikro etkileşimlerden biri de “yükleme” ikonlarıdır. Bir işlem devam ederken beliren dönen çark, zaman kaydırması ya da ilerleme çubuğu, kullanıcıya sabırlı olmasını ve işlemin tamamlanmak üzere olduğunu söyler. Bu ikonlar, kullanıcıyı bilgilendirmenin yanı sıra, onların sabrını da test etmeden süreç hakkında bilgi verir.
|
||||||
|
4. **Animasyonlu İkonlar:**
|
||||||
|
Bazı mikro etkileşimlerde ikonlar sadece sabit kalmaz, küçük hareketlerle kullanıcıya bilgi verir. Mesela, bir buton üzerine geldiğinde büyüyen veya renklendirilen bir ikon, butona basmak üzere olduğunu hatırlatır ve harekete geçirme (call to action) gücünü artırır. Aynı şekilde, bir işlemi gerçekleştirdikten sonra ikonun ufak bir kutlama hareketi yapması (örneğin, bir onay ikonu patlayan konfeti şeklinde) kullanıcıyı mutlu eder.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### Sonuç: Küçük Detaylar Büyük Farklar Yaratır
|
||||||
|
|
||||||
|
Mikro etkileşimler ve bu etkileşimlerde kullanılan ikonlar, kullanıcı deneyiminde “küçük ama etkili” roller üstlenir. Doğru yerlerde ve doğru şekilde kullanıldıklarında, ikonlar sadece arayüzdeki boşlukları doldurmaz, aynı zamanda kullanıcının yönünü bulmasını sağlar, hatalarını düzeltmesine yardımcı olur ve ona rehberlik eder. Yani, her ikon aslında kullanıcıyla sessiz bir diyalog kurar. Bu diyalogu ne kadar etkili hale getirirsen, kullanıcı o kadar memnun olur.
|
||||||
|
|
||||||
|
Unutma, bazen küçük detaylar büyük farklar yaratır. Bu yüzden bir tasarımcı olarak, mikro etkileşimlerde kullandığın ikonların gücünü asla küçümseme!
|
||||||
|
|
||||||
|
Umarım bu yazım sizlere bir şeyler katmıştır. **Herkese iyi tasarımlar ve kodlamalar!**
|
||||||
@@ -0,0 +1,246 @@
|
|||||||
|
---
|
||||||
|
title: "Next.js 15 Gelmiş, Neler Değişti Peki?"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-07-18"
|
||||||
|
readTime: "7 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "next-js-15-gelmi-neler-de-i-ti-peki"
|
||||||
|
excerpt: "Next.js 15 Gelmiş, Neler Değişti Peki? Selam! Yeni bir Next.js sürümü daha geldi ve beraberinde yine pek çok yenilik ve bazı dikkat edilmesi gereken değişiklikler getirdi. Eğer aktif …"
|
||||||
|
coverImage: "/blog/images/next-js-15-gelmi-neler-de-i-ti-peki-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/next-js-15-gelmi%C5%9F-neler-de%C4%9Fi%C5%9Fti-peki-651cd716839b"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Next.js 15 Gelmiş, Neler Değişti Peki?
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Next.js
|
||||||
|
|
||||||
|
### Selam!
|
||||||
|
|
||||||
|
Yeni bir Next.js sürümü daha geldi ve beraberinde yine pek çok yenilik ve bazı dikkat edilmesi gereken değişiklikler getirdi. Eğer aktif olarak Next.js ile projeler geliştiriyorsan, (benim gibi) bu sürüm seni heyecanlandırabilir.
|
||||||
|
|
||||||
|
Next.js 15; React 19 desteği, performans odaklı yenilikler ve geliştirici deneyimini iyileştiren pek çok özellikle birlikte geliyor. Ancak bu sürümle birlikte bazı alışkanlıklarımızı da değiştirmemiz gerekecek ne yazıkki. Oysa ben alışkanlıklarımı severim. Her neyse, özellikle App Router kullananlar için önemli yapısal güncellemeler var.
|
||||||
|
|
||||||
|
Bu yazıda, Next.js 15 ile gelen yenilikleri sade ve anlaşılır bir dille özetlemeye çalışacağım. Bu büyük değişiklikler neler, hangi özellikler projeni hızlandırır, geçiş sırasında nelere dikkat etmen gerekir — hepsini tek tek ele alacağız.
|
||||||
|
|
||||||
|
Hazırsan, detaylara geçelim.
|
||||||
|
|
||||||
|
## React 19 Desteği
|
||||||
|
|
||||||
|
Next.js 15’in belki de en çok dikkat çeken yeniliklerinden biri: **React 19 desteği**. React tarafında uzun süredir beklenen bazı özellikler nihayet bu sürümle birlikte hayatımıza girmeye başlıyor ve Next.js de bu geçişi oldukça sorunsuz hale getirmeye çalışıyor.
|
||||||
|
|
||||||
|
Eğer App Router kullanıyorsan, React 19 ile gelen birçok yeniliği doğrudan projende kullanmaya başlayabilirsin. Özellikle form yönetimi, UI bildirimleri ve server actions gibi konularda işler artık daha da kolaylaşıyor.
|
||||||
|
|
||||||
|
Ama önce yeni **React Özellikleri** neler onu anlamamız lazım.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
React 19
|
||||||
|
|
||||||
|
## Öne Çıkan Yeni React Özellikleri:
|
||||||
|
|
||||||
|
* `**useActionState**`: Form işlemleri sırasında daha kolay state yönetimi yapmanı sağlıyor.
|
||||||
|
* `**useFormStatus**` (geliştirilmiş hali): Form durumunu daha rahat kontrol edebiliyorsun, örneğin submit aşamasında butonları otomatik devre dışı bırakmak gibi.
|
||||||
|
* **Form Actions**: Artık form verilerini doğrudan sunucu tarafında handle edebiliyorsun; bu da güvenlik ve performans açısından büyük avantaj.
|
||||||
|
|
||||||
|
Henüz React 19 tam anlamıyla stable değil, ancak Next.js 15 ile birlikte bu yeni API’leri kullanmaya başlayarak şimdiden adapte olabilirsin. Tabii istersen React 18 ile devam etmek de mümkün — özellikle Pages Router kullanan projelerde bu seçenek hâlâ geçerli.
|
||||||
|
|
||||||
|
Yani özetle: React 19 geliyor, Next.js hazır ve sen de hazırsan hemen bu yeni versiyona geçiş yapabilirsin.
|
||||||
|
|
||||||
|
## Async Request API’leri (BREAKING CHANGE)
|
||||||
|
|
||||||
|
Evet, geldik bu sürümün en dikkat edilmesi gereken değişikliklerinden birine. Artık bazı yerleşik Next.js API’leri **async** hale geldi. Bu da demek oluyor ki artık `await` yazmadan eskisi gibi kullanamıyoruz.
|
||||||
|
|
||||||
|
## Neler async oldu?
|
||||||
|
|
||||||
|
Aşağıdaki API’ler artık asenkron çalışıyor:
|
||||||
|
|
||||||
|
* `cookies()`
|
||||||
|
* `headers()`
|
||||||
|
* `draftMode()`
|
||||||
|
* `params`
|
||||||
|
* `searchParams`
|
||||||
|
|
||||||
|
Bu API’leri kullanırken `await` yazman şart. Yani şöyle şeyler artık gerekiyor:
|
||||||
|
|
||||||
|
const cookies = await cookies()
|
||||||
|
|
||||||
|
## Nereleri etkiliyor?
|
||||||
|
|
||||||
|
Bu değişiklik özellikle şuraları etkiliyor:
|
||||||
|
|
||||||
|
* Layout dosyaları
|
||||||
|
* Sayfa (`page.tsx`) bileşenleri
|
||||||
|
* Route handler’lar (`route.ts`)
|
||||||
|
* Metadata fonksiyonları
|
||||||
|
|
||||||
|
Yani bu dosyaların içinde yukarıdaki API’leri kullanıyorsan hepsini async fonksiyonlara çevirmen gerekiyor. Aksi takdirde derleme veya çalışma zamanında hata alırsın.
|
||||||
|
|
||||||
|
## Kolay Geçiş için Codemod
|
||||||
|
|
||||||
|
Neyse ki Next.js ekibi bizi unutmamış ve bu geçişi kolaylaştırmak için bir araç sunmuş:
|
||||||
|
|
||||||
|
npx @next/codemod@latest async\-request\-apis
|
||||||
|
|
||||||
|
Bu komut sayesinde projenin içindeki eski kullanım biçimleriniz otomatik olarak async hale getirilebiliyor. Yine de kodu gözden geçirmek şart, çünkü her proje özelinde ufak dokunuşlar gerekebilir.
|
||||||
|
|
||||||
|
Sonuç olarak: Bu değişiklik ilk bakışta uğraştırıcı gibi görünebilir ama uzun vadede daha net bir veri yönetimi ve daha modern bir yapı sunuyor. Kodun daha tahmin edilebilir ve kontrol edilebilir olması da cabası bence.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Caching Davranışlarındaki Değişiklikler (BREAKING CHANGE)
|
||||||
|
|
||||||
|
Next.js 15 ile birlikte cache sistemi de baştan aşağı yenilendi diyebiliriz. Bu değişiklik, özellikle veri çekme (`fetch`), route handler’lar ve client-side navigasyon gibi konularda çalışanları doğrudan ilgilendiriyor.
|
||||||
|
|
||||||
|
### Ne Değişti Peki?
|
||||||
|
|
||||||
|
Artık `**fetch()**` **çağrıları ve** `**GET**` **route handler’ları varsayılan olarak cache'lenmiyor**.
|
||||||
|
Yani daha önce otomatik olarak static hale gelen veri çekme işlemleri artık her çağrıldığında yeniden çalışıyor.
|
||||||
|
|
||||||
|
Bu durum, bazı projeler için performans düşüşüne neden olabilir. Ama merak etme, kontrol tamamen sende.
|
||||||
|
|
||||||
|
### Nasıl Eski Davranışı Geri Getiririm?
|
||||||
|
|
||||||
|
Eğer bir verinin cache’lenmesini ve static hale gelmesini istiyorsan artık bunu **açıkça belirtmen gerekiyor**.
|
||||||
|
|
||||||
|
export const dynamic = 'force-static'
|
||||||
|
|
||||||
|
veya daha esnek bir yapı istersen, `next.config.js` dosyasına aşağıdaki gibi bir ayar da ekleyebilirsin:
|
||||||
|
|
||||||
|
experimental: {
|
||||||
|
fetchCache: {
|
||||||
|
defaultStaleTime: 60 \* 1000 // 1 dakika
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
### Bizi Neden Uğraştırıyorlar, Bu Değişiklik Neden Geldi?
|
||||||
|
|
||||||
|
Next.js artık daha deterministik bir sistem kurmak istiyor. Otomatik cache davranışları bazen beklenmeyen sonuçlar doğurabiliyordu. Bu yeni sistemle birlikte, her veri kaynağı için cache kararı tamamen geliştiriciye bırakılıyor. Bu da daha şeffaf ve yönetilebilir bir yapı sağlıyor.
|
||||||
|
|
||||||
|
|
||||||
|
Özetle: Eskiden “neden cache’lendi bu veri?” diye düşünüyorsan, artık bu sorunun cevabı sensin 🙂
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Turbopack Artık Kararlı
|
||||||
|
|
||||||
|
Next.js’in uzun zamandır üzerinde çalıştığı **Turbopack**, sonunda `next dev --turbo` komutu ile **kararlı (stable)** hale geldi. Eğer proje boyutun büyümeye başladıysa ve “neden bu kadar yavaş build alıyorum?” diyorsan, bu bölüm tam sana göre.
|
||||||
|
|
||||||
|
### Turbopack Nedir?
|
||||||
|
|
||||||
|
Turbopack, Webpack’in yerini alması planlanan, Rust tabanlı yepyeni bir bundler. Ama sadece alternatif değil, **çok daha hızlı**.
|
||||||
|
|
||||||
|
**Next.js 15 ile gelen bazı ölçümler:**
|
||||||
|
|
||||||
|
* İlk build süresi: %46'ya kadar daha hızlı
|
||||||
|
* Fast Refresh: %96’ya varan hız artışı
|
||||||
|
* Geliştirme sunucusu başlatma: %77 daha hızlı
|
||||||
|
|
||||||
|
diyor yani Vercel, deneyip göreceğiz.
|
||||||
|
|
||||||
|
### Nasıl Kullanılır?
|
||||||
|
|
||||||
|
Geliştirme ortamında Turbopack’i şöyle aktifleştirebilirsin:
|
||||||
|
|
||||||
|
next dev \--turbo
|
||||||
|
|
||||||
|
Ve eğer üretim ortamında da kullanmak istersen (şu an hâlâ alpha aşamasında ama 15.4 ile iyice olgunlaştı):
|
||||||
|
|
||||||
|
next build \--turbo
|
||||||
|
|
||||||
|
Tabii production tarafında dikkatli olmakta fayda var. Bazı üçüncü parti kütüphanelerde henüz %100 uyumlu olmayabilir. Ama gelişim çok hızlı ilerliyor.
|
||||||
|
|
||||||
|
### Neden Önemli?
|
||||||
|
|
||||||
|
Geliştirme sürecindeki en büyük zaman kaybı genellikle derleme (build) ve sayfa yenileme (refresh) anlarında yaşanır. (Bence) Turbopack bu noktada fark yaratıyor. Özellikle büyük projelerde çok ciddi zaman kazandırıyor ve akışını bozmadan kod yazmaya devam etmeni sağlıyor.
|
||||||
|
|
||||||
|
**Kısacası:** Artık Next.js projelerinde “derleme yavaş” bahanesi yavaş yavaş tarih oluyor. Turbopack sayesinde daha hızlı, daha tepkisel ve daha konforlu bir geliştirme süreci bizleri bekliyor gibi gözüküyor.
|
||||||
|
|
||||||
|
Harika, şimdi sıra geldi Next.js 15 ile birlikte hayatımıza giren ve geliştirici deneyimini doğrudan iyileştiren araçlara. Kod yazarken zaman kazandıran, hata ayıklamayı kolaylaştıran ve projeyi daha iyi anlamamıza yardımcı olan birkaç güzel yenilik var:
|
||||||
|
|
||||||
|
## Yeni Geliştirici Tool’ları: Daha Akıllı, Daha Yardımcı
|
||||||
|
|
||||||
|
Next.js 15 sadece performans değil, geliştirici konforu açısından da önemli yenilikler getirdi. Bu sürümle birlikte hem yeni araçlar eklendi hem de var olan bazı sistemler daha kullanıcı dostu hale getirildi.
|
||||||
|
|
||||||
|
### 1\. `@next/codemod` CLI
|
||||||
|
|
||||||
|
Next.js projeni yeni sürüme geçirirken en büyük yardımcın olacak araç bu.
|
||||||
|
Özellikle async API değişiklikleri gibi manuel müdahale gerektiren konularda, `codemod` senin yerine kodu otomatik olarak dönüştürüyor.
|
||||||
|
|
||||||
|
Kullanımı çok basit:
|
||||||
|
|
||||||
|
npx @next/codemod@latest async\-request\-apis
|
||||||
|
|
||||||
|
Sadece async dönüşümü değil, başka dönüşümler için de bu aracı kullanabilirsin. Kod tabanını hızlıca yeni sürüme uygun hale getiriyor.
|
||||||
|
|
||||||
|
### 2\. Statik Route Göstergesi
|
||||||
|
|
||||||
|
Geliştirme ortamında artık her route’un statik mi dinamik mi olduğunu sayfa başında küçük bir etiketle görebiliyorsun.
|
||||||
|
Bu özellik özellikle performans optimizasyonu yaparken çok işe yarıyor. Hangi sayfaların gerçekten static render edildiğini anında fark edebiliyorsun. Şahsen ben zorlanıyordum bu nokta da çoğu zaman.
|
||||||
|
|
||||||
|
### 3\. Geliştirilmiş Hata Ayıklama (Hydration ve Runtime)
|
||||||
|
|
||||||
|
Hydration hatası mı aldın? (BEN SÜREKLİ ALIYORUM, BIKTIM ARTIK) Eskiden terminale bak, stack trace incele, hangi component sorumlu bul derken epey zaman kaybolurdu. Artık çok daha kullanışlı bir hata ekranı seni karşılıyor.
|
||||||
|
|
||||||
|
* Hangi bileşen kaynaklı hata verdiği
|
||||||
|
* Ne zaman tetiklendiği
|
||||||
|
* React’ın hangi lifecycle aşamasında olduğu gibi bilgiler doğrudan görsel olarak sunuluyor.
|
||||||
|
|
||||||
|
Özetle: Next.js 15 ile “debug” süreci daha kısa, “upgrade” süreci daha kolay, ve hangi sayfanın nasıl render edildiğini anlamak artık çok daha basit. Geliştirici deneyimi ciddi anlamda ileri taşınmış diyebiliriz.
|
||||||
|
|
||||||
|
## Gözlemlenebilirlik (Observability) ve `instrumentation.js`
|
||||||
|
|
||||||
|
Uygulaman canlıya çıktı, her şey güzel görünüyor ama… Bir yerlerde bir şey yavaş, bir endpoint zaman zaman hata veriyor. İşte bu noktada **gözlemlenebilirlik (observability)** devreye giriyor.
|
||||||
|
|
||||||
|
Next.js 15 ile birlikte gelen `instrumentation.js` artık **kararlı (stable)** durumda ve projene entegre etmek oldukça kolay.
|
||||||
|
|
||||||
|
### Peki `instrumentation.js` nedir?
|
||||||
|
|
||||||
|
Bu dosya, uygulamanın sunucu tarafında gerçekleşen istekleri izlemeni ve gerektiğinde özel işlemler yapmanı sağlar. Yani bir nevi “arka planda olan biteni yakalayan kanca” gibi düşünebilirsin.
|
||||||
|
|
||||||
|
### İki ana özellik var:
|
||||||
|
|
||||||
|
* `**register()**`: Uygulama başladığında bir kez çalışır. Örneğin APM veya log sistemini burada başlatabilirsin.
|
||||||
|
* `**onRequestError()**`: Herhangi bir istek hata verdiğinde tetiklenir. Hangi route, hangi hata, ne zaman... hepsi burada toplanabilir.
|
||||||
|
|
||||||
|
### Ne İşe Yarıyor Yani?
|
||||||
|
|
||||||
|
* Performans takibi (örn: bir endpoint hep 300ms üzerinde mi çalışıyor?)
|
||||||
|
* APM entegrasyonları (örnek: Sentry, OpenTelemetry)
|
||||||
|
* Hata loglama sistemleri (örn: request bazlı loglama)
|
||||||
|
|
||||||
|
// instrumentation.ts
|
||||||
|
export function register() {
|
||||||
|
console.log('Server started')
|
||||||
|
}
|
||||||
|
|
||||||
|
export function onRequestError(error) {
|
||||||
|
console.error('Request error:', error)
|
||||||
|
}
|
||||||
|
|
||||||
|
Yani artık ne zaman, ne oldu, neden oldu gibi sorulara çok daha kolay yanıt bulabiliyorsun.
|
||||||
|
|
||||||
|
Sonuç olarak: Next.js 15 artık sadece “görsel olarak düzgün çalışan” değil, arka planda da izlenebilen, ölçülebilen ve analiz edilebilen projeler oluşturman için altyapı sunuyor.
|
||||||
|
|
||||||
|
## Sonuç: Next.js 15 ile Daha Hızlı, Daha Kontrol Edilebilir Projeler
|
||||||
|
|
||||||
|
Next.js 15, sadece “yeni bir sürüm” değil; hem geliştirici deneyimini iyileştiren hem de modern web uygulamalarının ihtiyaçlarına daha iyi cevap veren ciddi bir adım.
|
||||||
|
|
||||||
|
Özellikle React 19 desteği, Turbopack’in kararlı hale gelmesi ve observability araçları, projeni daha sağlam temellere oturtmanı sağlıyor.
|
||||||
|
|
||||||
|
Tabii ki bazı breaking change ler var — özellikle async API’ler ve cache davranışları. Ama bu değişiklikler seni zorlamaktan çok, kodunun daha bilinçli, daha yönetilebilir olmasını hedefliyor. Ve Next.js ekibi, bu geçişi kolaylaştırmak için gerekli araçları da sunmuş durumda.
|
||||||
|
|
||||||
|
Eğer projeni güncellemeyi düşünüyorsan:
|
||||||
|
|
||||||
|
* Önce bir yedeğini al,
|
||||||
|
* `codemod` ile geçişi başlat,
|
||||||
|
* ve yavaş yavaş yeni sistemleri test etmeye başla.
|
||||||
|
|
||||||
|
İleriyi düşünen projeler için Next.js 15 gerçekten güçlü bir temel sunuyor.
|
||||||
|
|
||||||
|
Buraya kadar okuyan herkese teşekkürler, görüşmek üzere.
|
||||||
@@ -0,0 +1,232 @@
|
|||||||
|
---
|
||||||
|
title: "Next.js ile Edge Functions: Hızlı Web Uygulamaları Nasıl Geliştirilir?"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-09-17"
|
||||||
|
readTime: "5 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "next-js-ile-edge-functions-h-zl-web-uygulamalar-nas-l-geli-tirilir"
|
||||||
|
excerpt: "Next.js ile Edge Functions: Hızlı Web Uygulamaları Nasıl Geliştirilir? TL;DR (Too Long; Didn’t Read): Edge Functions, kullanıcıya en yakın konumda çalışan, hızlı serverless …"
|
||||||
|
coverImage: "/blog/images/next-js-ile-edge-functions-h-zl-web-uygulamalar-nas-l-geli-tirilir-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/next-js-ile-edge-functions-h%C4%B1zl%C4%B1-web-uygulamalar%C4%B1-nas%C4%B1l-geli%C5%9Ftirilir-d94eafacf50e"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Next.js ile Edge Functions: Hızlı Web Uygulamaları Nasıl Geliştirilir?
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
**TL;DR (Too Long; Didn’t Read):**
|
||||||
|
Edge Functions, kullanıcıya en yakın konumda çalışan, hızlı serverless fonksiyonlardır.
|
||||||
|
|
||||||
|
Next.js ile tek satırda `runtime = 'edge'` diyerek bunu kullanabilirsin.
|
||||||
|
Global kullanıcılar için gecikme süresini azaltır, kişiselleştirilmiş içerik, A/B testleri ve caching için idealdir.
|
||||||
|
|
||||||
|
### Nasıl İlerleyeceğim?
|
||||||
|
|
||||||
|
* **Giriş**
|
||||||
|
* **Edge Functions Nedir?**
|
||||||
|
* **Next.js ile Edge Functions Kullanımı**
|
||||||
|
* **Kullanım Senaryoları**
|
||||||
|
* **Avantajlar ve Sınırlamalar**
|
||||||
|
* **Sonuç ve Öneriler**
|
||||||
|
|
||||||
|
## Giriş
|
||||||
|
|
||||||
|
Modern web uygulamalarında hız, kullanıcı deneyiminin en kritik parçasıdır. Eminim sizinde sayfa biraz uzun yüklendiğinde siteden çıkmışlığınız vardır.
|
||||||
|
|
||||||
|
Sayfa yüklenme süresindeki milisaniyelik farklar bile kullanıcı davranışını değiştirebilir, dönüşüm oranlarını etkileyebilir.
|
||||||
|
|
||||||
|
Peki nasıl hızlandıracağız? İşte tam bu noktada **Edge Functions** devreye giriyor. Kullanıcıya en yakın yerde çalışan bu küçük fonksiyonlar, global ölçekte gecikmeyi minimuma indirir ve sunucu yükünü hafifletir.
|
||||||
|
|
||||||
|
Bu yazıda, Edge Functions’ın ne olduğunu, Next.js ile nasıl entegre edildiğini ve hangi senaryolarda en iyi sonucu verdiğini adım adım inceleyeceğiz.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Edge Functions Nedir?
|
||||||
|
|
||||||
|
Edge Functions, kullanıcıya **en yakın veri merkezinde** çalışan küçük, serverless fonksiyonlardır.
|
||||||
|
|
||||||
|
Böylece bir kullanıcı İstanbul’dan bir istekte bulunduğunda, bu istek ABD’deki ana sunucuya gitmek yerine İstanbul’a en yakın veri merkezinde işlenir.
|
||||||
|
|
||||||
|
Bu yaklaşım şu avantajları sağlar:
|
||||||
|
|
||||||
|
* **Düşük gecikme (low latency):** İstekler daha hızlı yanıtlanır.
|
||||||
|
* **Daha iyi kullanıcı deneyimi:** Sayfalar ve API yanıtları daha hızlı yüklenir.
|
||||||
|
* **Global ölçeklenebilirlik:** Dünyanın her yerindeki kullanıcılar benzer hızda erişim sağlar.
|
||||||
|
|
||||||
|
export const runtime = 'edge';
|
||||||
|
|
||||||
|
export async function GET(req: Request) {
|
||||||
|
const country = req.headers.get('x-vercel-ip-country') || 'US';
|
||||||
|
|
||||||
|
return new Response(
|
||||||
|
JSON.stringify({ currency: country === 'TR' ? '₺' : '$' }),
|
||||||
|
{ headers: { 'Content-Type': 'application/json' } }
|
||||||
|
);
|
||||||
|
}
|
||||||
|
|
||||||
|
Mesela bu örnekte, istek hangi ülkeden gelirse gelsin **en yakın edge node’da** çalışır ve kullanıcıya uygun para birimi döner.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Next.js ile Edge Functions Kullanımı
|
||||||
|
|
||||||
|
Next.js, Edge Functions kullanmayı son derece kolay hale getiriyor sağ olsun. Bir API Route’u edge üzerinde çalıştırmak için tek yapman gereken`**runtime = 'edge'**` satırını eklemektir.
|
||||||
|
|
||||||
|
### 1\. Basit Bir Edge Function Oluşturalım
|
||||||
|
|
||||||
|
Örnek olarak `app/api/hello/route.ts` dosyası oluşturalım:
|
||||||
|
|
||||||
|
export const runtime = 'edge';
|
||||||
|
|
||||||
|
export async function GET() {
|
||||||
|
return new Response(
|
||||||
|
JSON.stringify({ message: 'Merhaba Edge!' }),
|
||||||
|
{ headers: { 'Content-Type': 'application/json' } }
|
||||||
|
);
|
||||||
|
}
|
||||||
|
|
||||||
|
Bu kadar :) Artık bu endpoint, global olarak edge sunucularında çalışacak.
|
||||||
|
|
||||||
|
Tarayıcıda `/api/hello` yoluna girdiğinde şöyle bir sonuç göreceksin:
|
||||||
|
|
||||||
|
{ "message": "Merhaba Edge!" }
|
||||||
|
|
||||||
|
### 2\. Middleware ile Edge Kullanımı
|
||||||
|
|
||||||
|
Next.js middleware yapısı **varsayılan olarak edge üzerinde çalışır.**
|
||||||
|
Örneğin kullanıcıyı oturum durumuna göre yönlendirmek için:
|
||||||
|
|
||||||
|
// middleware.ts
|
||||||
|
import { NextResponse } from 'next/server';
|
||||||
|
|
||||||
|
export function middleware(req: Request) {
|
||||||
|
const isLoggedIn = Boolean(req.headers.get('x-user-auth'));
|
||||||
|
if (!isLoggedIn) {
|
||||||
|
return NextResponse.redirect(new URL('/login', req.url));
|
||||||
|
}
|
||||||
|
return NextResponse.next();
|
||||||
|
}
|
||||||
|
|
||||||
|
Bu middleware, kullanıcıya en yakın edge node’da çalışır, bu sayede yönlendirmeler çok daha hızlıdır.
|
||||||
|
|
||||||
|
### 3\. Dikkat Edilmesi Gerekenler
|
||||||
|
|
||||||
|
* Node.js özel modülleri (ör. `fs`, `net`) desteklenmez.
|
||||||
|
* Edge fonksiyonlar kısa süreli, stateless olmalıdır. Bu gerçekten önemli.
|
||||||
|
* Daha uzun işlemler için normal serverless fonksiyon veya API route kullanılabilir.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Kullanım Senaryoları
|
||||||
|
|
||||||
|
### 1\. Kişiselleştirme (Geo → para birimi / dil)
|
||||||
|
|
||||||
|
Burada amaç kullanıcının ülkesi veya şehri bazında anında içerik/pref seçimi. Peki Nasıl? Edge’te request header’larından ülkeyi al, yanıtı kişiselleştir.
|
||||||
|
|
||||||
|
|
||||||
|
_Örnek (app/api/prefs/route.ts):_
|
||||||
|
|
||||||
|
export const runtime = 'edge';
|
||||||
|
|
||||||
|
export async function GET(req: Request) {
|
||||||
|
const country = req.headers.get('x-vercel-ip-country') || 'US';
|
||||||
|
const currency = country === 'TR' ? '₺' : '$';
|
||||||
|
return new Response(JSON.stringify({ currency }), {
|
||||||
|
headers: { 'Content-Type': 'application/json' }
|
||||||
|
});
|
||||||
|
}
|
||||||
|
|
||||||
|
Bu kod ile Türkiye’den gelen kullanıcı **₺** görürken, ABD’den gelen kullanıcı **$** görecektir.
|
||||||
|
|
||||||
|
### 2\. A/B Test (Varyant Dağıtımı)
|
||||||
|
|
||||||
|
Amacımız yeni bir özelliği kullanıcıların belirli bir yüzdesine göstermek. Mesela bir şeyi test etmek istiyor ya da bölge bazlı özellik geliştirmek istiyor olabilirsiniz.
|
||||||
|
|
||||||
|
import { NextResponse } from 'next/server';
|
||||||
|
|
||||||
|
export const config = { matcher: \['/'\] };
|
||||||
|
|
||||||
|
export function middleware(req: Request) {
|
||||||
|
const cookie = req.headers.get('cookie') || '';
|
||||||
|
const variant = /variant=(A|B)/.exec(cookie)?.\[1\] || (Math.random() < 0.5 ? 'A' : 'B');
|
||||||
|
|
||||||
|
const res = NextResponse.next();
|
||||||
|
res.headers.append('Set-Cookie', \`variant=${variant}; Path=/; Max-Age=2592000; SameSite=Lax\`);
|
||||||
|
return res;
|
||||||
|
}
|
||||||
|
|
||||||
|
Bu örnek kullanıcıya A veya B varyantını atar ve tüm isteklerde tutarlı kalmasını sağlar.
|
||||||
|
|
||||||
|
### 3\. Feature Flags (Kademeli Açılış)
|
||||||
|
|
||||||
|
Burada ise amacımız yeni özellikleri %10 / %50 gibi kademelerle yayına almak. Yukarıdaki ile benzer sebeplerden bunu yapmak istiyor olabilirsiniz.
|
||||||
|
|
||||||
|
export const runtime = 'edge';
|
||||||
|
|
||||||
|
export async function GET() {
|
||||||
|
const enabled = Math.random() < 0.2; // %20 açık
|
||||||
|
return new Response(JSON.stringify({ newFeature: enabled }), {
|
||||||
|
headers: { 'Content-Type': 'application/json' }
|
||||||
|
});
|
||||||
|
}
|
||||||
|
|
||||||
|
Gerçekte kullanıcı kimliğine göre hash alırsan, aynı kullanıcı her zaman aynı sonucu görür.
|
||||||
|
|
||||||
|
### 4\. Edge Cache (Hızlı Yanıtlar)
|
||||||
|
|
||||||
|
Okuma ağırlıklı API’leri CDN üzerinde önbelleğe almak için bu tarz bir ihtiyacınız olabilir.
|
||||||
|
|
||||||
|
export const runtime = 'edge';
|
||||||
|
|
||||||
|
export async function GET() {
|
||||||
|
const data = { headlines: \['Edge is fast', 'Next.js 15 released'\] };
|
||||||
|
return new Response(JSON.stringify(data), {
|
||||||
|
headers: {
|
||||||
|
'Content-Type': 'application/json',
|
||||||
|
'Cache-Control': 'public, s-maxage=120, stale-while-revalidate=300'
|
||||||
|
}
|
||||||
|
});
|
||||||
|
}
|
||||||
|
|
||||||
|
Bu sayede kullanıcılar her istekte milisaniyeler içinde yanıt alır.
|
||||||
|
|
||||||
|
## Avantajlar ve Sınırlamalar
|
||||||
|
|
||||||
|
Edge Functions güçlü ama her senaryoda doğru tercih olmayabilir. Sizin için artılarını ve eksilerini listeledim.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Sonuç ve Öneriler
|
||||||
|
|
||||||
|
Edge Functions, modern web uygulamalarının **hız ve kullanıcı deneyimi** sorunlarına güçlü bir çözüm sunuyor. Kullanıcıya en yakın konumda çalışan bu fonksiyonlar sayesinde:
|
||||||
|
|
||||||
|
* Sayfalar çok daha hızlı yüklenir,
|
||||||
|
* Global kitlelere eşit performans sağlanır,
|
||||||
|
* Sunucu maliyetleri optimize edilir.
|
||||||
|
* Sunucu maliyetleri optimize edilir.
|
||||||
|
|
||||||
|
Eğer global erişimi olan bir projen varsa, özellikle:
|
||||||
|
|
||||||
|
* **Kişiselleştirilmiş içerik** sunuyorsan,
|
||||||
|
* **A/B testleri** yapıyorsan,
|
||||||
|
* **Hızlı yönlendirme ve middleware** ihtiyacın varsa,
|
||||||
|
|
||||||
|
Edge Functions kullanmayı mutlaka denemelisin.
|
||||||
|
|
||||||
|
Buraya kadar okuduğun için teşekkür ederim! 🙌
|
||||||
|
|
||||||
|
Bu yazının sana Edge Functions konusunda fikir verdiğini ve yeni şeyler deneme isteğini uyandırdığını umuyorum.
|
||||||
|
|
||||||
|
[**Instagram**](https://www.instagram.com/poyraz_avsever/) — [**LinkedIn**](https://www.linkedin.com/in/poyrazavsever) — [**Kişisel Web Sitem**](https://www.poyrazavsever.com)
|
||||||
|
|
||||||
|
Bir sonraki yazıda görüşmek üzere, **sağlıcakla!**
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
> _Görseller_ **_Gemini_** _ile oluşturulmuştur._
|
||||||
@@ -0,0 +1,181 @@
|
|||||||
|
---
|
||||||
|
title: "React ile Dinamik Bir Kullanıcı Profil Sayfası Nasıl Tasarlanır?"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-11-19"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "react-ile-dinamik-bir-kullan-c-profil-sayfas-nas-l-tasarlan-r"
|
||||||
|
excerpt: "React ile Dinamik Bir Kullanıcı Profil Sayfası Nasıl Tasarlanır? Giriş Kullanıcı profil sayfalarının modern web uygulamalarındaki önemini göstermeye çalışıyorum. Dinamik ve …"
|
||||||
|
coverImage: "/blog/images/react-ile-dinamik-bir-kullan-c-profil-sayfas-nas-l-tasarlan-r-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/react-ile-dinamik-bir-kullan%C4%B1c%C4%B1-profil-sayfas%C4%B1-nas%C4%B1l-tasarlan%C4%B1r-12d56031c253"
|
||||||
|
---
|
||||||
|
|
||||||
|
# React ile Dinamik Bir Kullanıcı Profil Sayfası Nasıl Tasarlanır?
|
||||||
|
|
||||||
|
|
||||||
|
## Giriş
|
||||||
|
|
||||||
|
* Kullanıcı profil sayfalarının modern web uygulamalarındaki önemini göstermeye çalışıyorum.
|
||||||
|
* Dinamik ve özelleştirilebilir tasarımların kullanıcı deneyimini nasıl geliştirdiğini ele alıyorum.
|
||||||
|
* Yazının amacı ise React kullanarak temel bir dinamik profil sayfası oluşturmayı öğretmek.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### Peki “Profil Sayfası” derken neyi kastediyorum?
|
||||||
|
|
||||||
|
Profil sayfaları, kullanıcıların kendilerini tanıtabildiği, bilgilerini, yeteneklerini ve aktivitelerini sergileyebildiği dijital bir alan aslında. Bu sayfalar, genellikle bir web sitelerinde kullanıcı ile diğer kişiler arasında bir köprü görevi görür.
|
||||||
|
|
||||||
|
|
||||||
|
Modern profil sayfalarında şu özellikler sıklıkla bulunur:
|
||||||
|
|
||||||
|
* **Kullanıcı Bilgileri:** İsim, fotoğraf, biyografi gibi temel tanıtıcı bilgiler.
|
||||||
|
* **Portföy veya Ürünler:** Kullanıcının yeteneklerini veya sunduğu hizmetleri sergilediği bölümler.
|
||||||
|
* **Etkileşim:** Kullanıcıların yorum bırakabildiği, favorilere ekleme gibi özelliklerle sosyal bir deneyim sunan alanlar.
|
||||||
|
* **Özelleştirilebilir Arayüz:** Karanlık mod gibi kullanıcı tercihlerine göre şekillenebilir tasarımlar.
|
||||||
|
|
||||||
|
Bir profil sayfası, sadece estetik bir tasarım değil, aynı zamanda kullanıcı etkileşimlerini ve deneyimini optimize eden bir yapıdır. Bu yazıda, React kullanarak bu tür bir dinamik profil sayfasını nasıl geliştirebileceğinizi öğreneceksiniz.
|
||||||
|
|
||||||
|
## 1\. Proje İçin Gereksinimler
|
||||||
|
|
||||||
|
* React kurulumu için kısa bir rehber: `create-react-app` veya `Vite` kullanımı.
|
||||||
|
* Gerekli paketler:
|
||||||
|
* **React Router**: Sayfa geçişlerini yönetmek için.
|
||||||
|
* **Axios veya Fetch API**: Verileri almak için.
|
||||||
|
* **CSS Framework veya Kütüphane**: Tailwind CSS, Material-UI veya Bootstrap. Tercihim Tailwind CSS.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 2\. Sayfa Tasarımının Planlanması
|
||||||
|
|
||||||
|
* Profil sayfasında bulunabilecek bileşenler:
|
||||||
|
* **Hakkında Bölümü**: Kullanıcının adı, fotoğrafı, biyografisi.
|
||||||
|
* **Eğitim ve Sertifikalar**: Dinamik liste.
|
||||||
|
* **Ürünler**: Kullanıcının sattığı ürünler için bir grid yapısı.
|
||||||
|
* **Freelance İlanlar**: İş ilanlarının gösterimi.
|
||||||
|
* **Yorumlar**: Kullanıcıya gelen geri bildirimler.
|
||||||
|
* Component yapısının belirlenmesi:
|
||||||
|
* `ProfileHeader`, `About`, `ProductsList`, `JobsList`, `CommentsSection`.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 3\. React ile Projeye Başlama
|
||||||
|
|
||||||
|
### 3.1. Proje Yapısı
|
||||||
|
|
||||||
|
src/
|
||||||
|
│── components/
|
||||||
|
│ │── ProfileHeader.jsx
|
||||||
|
│ │── About.jsx
|
||||||
|
│ │── ProductsList.jsx
|
||||||
|
│ │── JobsList.jsx
|
||||||
|
│ │── CommentsSection.jsx
|
||||||
|
│── App.js
|
||||||
|
│── index.js
|
||||||
|
|
||||||
|
### 3.2. Temel Profil Verileri
|
||||||
|
|
||||||
|
* Bir `data.js` dosyası oluşturarak mock veriler eklemek:
|
||||||
|
|
||||||
|
export cocst userData = {
|
||||||
|
name: "Poyraz Avsever",
|
||||||
|
bio: "Yazılım geliştirici ve Tasarımcı",
|
||||||
|
photo: "/images/profile.jpg",
|
||||||
|
education: \[
|
||||||
|
{ id: 1, degree: "Yazılım Mühendisliği", institution: "OSTİM Teknik Üniversitesi" },
|
||||||
|
\],
|
||||||
|
products: \[{ id: 1, name: "CRM Yazılımı", price: "$100" }\],
|
||||||
|
jobs: \[{ id: 1, title: "Frontend Developer", description: "Freelance iş ilanı" }\],
|
||||||
|
comments: \[{ id: 1, author: "Halitcan Emir", text: "Harika bir iş çıkarmışsınız!" }\],
|
||||||
|
};
|
||||||
|
|
||||||
|
### 3.3. API Simülasyonu
|
||||||
|
|
||||||
|
* Mock servis oluşturmak için **json-server** kullanımı.
|
||||||
|
|
||||||
|
## 4\. Bileşenlerin Geliştirilmesi
|
||||||
|
|
||||||
|
### 4.1. ProfileHeader.jsx
|
||||||
|
|
||||||
|
const ProfileHeader = ({ name, bio, photo }) => (
|
||||||
|
<div className="profile-header">
|
||||||
|
<img src={photo} alt="Profile" />
|
||||||
|
<h1>{name}</h1>
|
||||||
|
<p>{bio}</p>
|
||||||
|
</div>
|
||||||
|
);
|
||||||
|
export default ProfileHeader;
|
||||||
|
|
||||||
|
### 4.2. Dinamik Liste Bileşeni: ProductsList.jsx
|
||||||
|
|
||||||
|
const ProductsList = ({ products }) => (
|
||||||
|
<div className="products-list">
|
||||||
|
{products.map(product => (
|
||||||
|
<div key={product.id}>
|
||||||
|
<h2>{product.name}</h2>
|
||||||
|
<p>{product.price}</p>
|
||||||
|
</div>
|
||||||
|
))}
|
||||||
|
</div>
|
||||||
|
);
|
||||||
|
export default ProductsList;
|
||||||
|
|
||||||
|
## 5\. Veri Çekme ve Kullanıcı Arayüzünü Tamamlama
|
||||||
|
|
||||||
|
* **useEffect** ile veri çekme:
|
||||||
|
|
||||||
|
import { useState, useEffect } from "react";
|
||||||
|
import axios from "axios";
|
||||||
|
|
||||||
|
const \[data, setData\] = useState(null);
|
||||||
|
|
||||||
|
useEffect(() => {
|
||||||
|
axios.get("/api/user").then(response => setData(response.data));
|
||||||
|
}, \[\])
|
||||||
|
|
||||||
|
* **Props Drilling** veya **Context API** kullanarak verilerin bileşenlere aktarımı.
|
||||||
|
|
||||||
|
## 6\. Ek Özellikler
|
||||||
|
|
||||||
|
### 6.1. Yorum Ekleme Formu
|
||||||
|
|
||||||
|
Kullanıcıların profil hakkında geri bildirim yapabilmesi için bir yorum ekleme formu oluşturabilirsiniz.
|
||||||
|
|
||||||
|
### 6.2. Favoriler Listesi
|
||||||
|
|
||||||
|
Kullanıcıların belirli ürünleri favorilerine ekleyebilmesini sağlayarak etkileşimi artırabilirsiniz. Favoriler, genellikle bir “kalp” ikonu ile seçilebilir ve bir liste halinde gösterilir.
|
||||||
|
|
||||||
|
### 6.3. Dark-Light Mode Desteği
|
||||||
|
|
||||||
|
Modern kullanıcılar karanlık modu tercih edebiliyor. React ve Tailwind CSS kullanarak kolayca bir **Dark Mode** özelliği eklenebilir.
|
||||||
|
|
||||||
|
### 6.4. Aktivite Akışı
|
||||||
|
|
||||||
|
Profil sahibinin son etkinliklerini göstermek, kullanıcıların güncel faaliyetlerini takip etmesine olanak tanır.
|
||||||
|
Örnek: “Halitcan, yeni bir ürün ekledi” veya “Halit, bir yorum aldı”.
|
||||||
|
|
||||||
|
### 6.5. Kullanıcı Odaklı Öneriler
|
||||||
|
|
||||||
|
Kullanıcıların profil verilerine göre özel öneriler sunabilirsiniz. Örneğin:
|
||||||
|
|
||||||
|
* Satılan ürünlere benzer öneriler
|
||||||
|
* Alınan yorumlara göre iyileştirme ipuçları
|
||||||
|
* Kullanıcının ilgisini çekebilecek diğer profiller
|
||||||
|
|
||||||
|
## Sonuç
|
||||||
|
|
||||||
|
Bu yazıda, React kullanarak dinamik ve kullanıcı dostu bir profil sayfası tasarlamanın yollarını adım adım ele aldık. Modern web uygulamalarında bu tür sayfalar, kullanıcı deneyimini güçlendiren temel bir bileşendir.
|
||||||
|
|
||||||
|
Ele aldığımız özellikler şunlardı:
|
||||||
|
|
||||||
|
* **Temel Profil Bilgileri:** Kullanıcı adı, biyografi ve fotoğraf gibi temel bilgiler.
|
||||||
|
* **Dinamik Veri Kullanımı:** API entegrasyonu ile gerçek zamanlı veri çekme.
|
||||||
|
* **Ek Özellikler:** Yorum ekleme, favoriler listesi, dark mode ve öneriler gibi kullanıcı etkileşimini artıran işlevler.
|
||||||
|
|
||||||
|
React’in modüler yapısı sayesinde bu özellikler kolayca geliştirilebilir, özelleştirilebilir ve projelere entegre edilebilir. Özellikle kullanıcıların geri bildirimlerini dikkate alarak sürekli iyileştirme yapmak, profil sayfalarını bir adım öteye taşır.
|
||||||
|
|
||||||
|
Kendi projelerinizde bu adımları takip ederek, hem teknik becerilerinizi geliştirebilir hem de kullanıcılar için daha değerli bir deneyim sunabilirsiniz. Bu yazıdaki yöntemleri ve örnekleri genişleterek daha fazla özellik eklemek tamamen sizin yaratıcılığınıza kalmış!
|
||||||
|
|
||||||
|
Eğer bu yazıda değinmediğim bir konu veya başka bir sorunuz varsa, yorumlarınızı paylaşmaktan çekinmeyin. Mutlu kodlamalar! Sağlıcakla…😊
|
||||||
@@ -0,0 +1,112 @@
|
|||||||
|
---
|
||||||
|
title: "React Native Nedir? Avantajları ve Dezavantajları"
|
||||||
|
category: "General"
|
||||||
|
date: "2025-01-18"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "react-native-nedir-avantajlar-ve-dezavantajlar"
|
||||||
|
excerpt: "React Native Nedir? Avantajları ve Dezavantajları Mobil uygulama geliştirme dünyasında, birden fazla platform için tek bir kod tabanı ile çalışma imkânı sunan teknolojiler giderek …"
|
||||||
|
coverImage: "/blog/images/react-native-nedir-avantajlar-ve-dezavantajlar-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/react-native-nedir-avantajlar%C4%B1-ve-dezavantajlar%C4%B1-4b26608a03cd"
|
||||||
|
---
|
||||||
|
|
||||||
|
# **React Native Nedir? Avantajları ve Dezavantajları**
|
||||||
|
|
||||||
|
|
||||||
|
Mobil uygulama geliştirme dünyasında, birden fazla platform için tek bir kod tabanı ile çalışma imkânı sunan teknolojiler giderek popülerlik kazanıyor. Bugün sizlere bunlardan biri olan “React Native” teknolojisini anlatmaya çalışacağım. Dilerseniz başlayalım.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
React Native, bu teknolojilerden biri olarak, hem iOS hem de Android için çapraz platform uygulamalar geliştirmek üzere Facebook tarafından 2015 yılında piyasaya sürülen bir teknoloji.
|
||||||
|
|
||||||
|
React Native, JavaScript dilini ve React kütüphanesini kullanarak, mobil cihazların native özelliklerinden faydalanan, performansı yüksek uygulamalar geliştirmeye olanak tanır. Native bileşenlerle iletişimi sağlamak için bir “bridge” (köprü) yapısı kullanan React Native, geliştiricilere hızlı ve esnek bir çalışma ortamı sunar. Bu yazıda, React Native’i daha yakından inceleyerek avantajları ve dezavantajlarını detaylı bir şekilde ele alacağız.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## React Native’in Temel Özellikleri
|
||||||
|
|
||||||
|
1. **JavaScript ile Mobil Geliştirme:** React Native, günümüzde yaygın bir şekilde kullanılan JavaScript dilini temel alır. Bu, web geliştiricilerinin kolayca adapte olmasını sağlıyor ve yeni geliştirici arkadaşlarımızında öğrenim sürecini oldukça hızlandırıyor.
|
||||||
|
2. **Native Bileşenler ile Entegrasyon:** React Native, platforma özgü native bileşenleri kullanarak uygulamaların performansını artırır. Bu da, hem iOS hem de Android cihazlar için optimize edilmiş bir deneyim sunar.
|
||||||
|
3. **Hot Reloading (Canlı Yenileme):** Kodda yapılan değişiklikleri anında görmenizi sağlayan bu özellik, geliştirme sürecini oldukça hızlandırdığını ve geliştiricilerin daha verimli çalışmasına olanak tanıdığını da söyleyebiliriz.
|
||||||
|
4. **Modüler ve Kütüphaneler:** React Native, zengin bir kütüphane ekosistemine sahiptir. Bununda sizlere kullanıma hazır çözümler sunacağını ve kimi noktalarda zamandan tasarruf ettireceğini belirtebiliriz.
|
||||||
|
|
||||||
|
## Avantajları
|
||||||
|
|
||||||
|
### 1\. Çapraz Platform Desteği
|
||||||
|
|
||||||
|
React Native ile tek bir kod yazarak hem iOS hem de Android uygulamaları oluşturabilirsin. Bu, zaman ve maliyet tasarrufu sağlarken, ekiplerin çapraz platform geliştirme için ayrı ekipler kurmasının da önüne geçer.
|
||||||
|
|
||||||
|
### 3\. Zengin Kütüphane Ekosistemi
|
||||||
|
|
||||||
|
React Native, topluluk tarafından desteklenen birçok kütüphane ve önceden hazırlanmış modül sunar. Firebase, Redux gibi popüler teknolojilerle kolay entegrasyon sağlayarak geliştiricilerin projelerini kolaylaştırır.
|
||||||
|
|
||||||
|
### 4\. Native Performans
|
||||||
|
|
||||||
|
React Native, uygulamaların native özelliklerini kullanarak hem iOS hem de Android platformlarında hızlı bir deneyim sunar. Özellikle temel düzeydeki uygulamalar için bu performans fark edilir derecede iyidir.
|
||||||
|
|
||||||
|
### 5\. Büyük ve Aktif Topluluk
|
||||||
|
|
||||||
|
React Native, dünyanın dört bir yanından geliştiricilerin katıldığı aktif bir topluluğa sahiptir. Sıkça karşılaşılan sorunları çözmek için çok sayıda kaynak ve destek mevcuttur.
|
||||||
|
|
||||||
|
## Dezavantajları
|
||||||
|
|
||||||
|
### 1\. Performans Kısıtlamaları
|
||||||
|
|
||||||
|
React Native, çok karmaşık grafiklere sahip veya yoğun işlem gerektiren uygulamalarda native kod kadar iyi performans sunamayabilir. Bu tür uygulamalar için tamamen native bir yaklaşım tercih edilebilir.
|
||||||
|
|
||||||
|
### 2\. Bridge (Köprü) Yapısı Bağımlılığı
|
||||||
|
|
||||||
|
React Native, JavaScript kodu ile native bölümler arasında bir köprü kullanarak iletişim sağlar. Bu yapı bazen gecikmelere neden olabilir ve uygulama yanıt verme sürelerini etkileyebilir.
|
||||||
|
|
||||||
|
### 3\. Yüksek Öğrenme Eğrisi
|
||||||
|
|
||||||
|
React Native’i etkin bir şekilde kullanmak için, JavaScript ve React ekosistemine hakim olmanız önemlidir. Yeni geliştiriciler için bu, zaman alıcı olabilir. — _Kaldı ki buna dezavantaj demek çok doğru olmaz çünkü şuan bu yazıyı okuyorsanız zaten Javascript ve React ekosistemine de aşinalığınız vardır .-_
|
||||||
|
|
||||||
|
## Hangi Durumlarda React Native Kullanılmalı?
|
||||||
|
|
||||||
|
React Native, çapraz platform desteğine ihtiyacınız olduğu ve uygulamalarınızın hem iOS hem de Android cihazlarda çalışmasını istediğiniz durumlarda idealdir. Özellikle başlangıç aşamasında olan projeler ve minimum uygulanabilir ürün (MVP) geliştirme süreçlerinde maliyet ve zaman tasarrufu sağlar. Ancak, yoğun işlem gücü veya özel grafik tasarımı gerektiren uygulamalarda native geliştirme yöntemlerini tercih etmek daha uygun olabilir.
|
||||||
|
|
||||||
|
## Nasıl Öğrenmeye Başlayabilirsiniz?
|
||||||
|
|
||||||
|
React Native öğrenmeye başlamak isteyenler için birkaç öneri:
|
||||||
|
|
||||||
|
1. **JavaScript ve React Bilginizi Tazeleyin:** React Native, JavaScript ve React üzerine kurulu olduğundan, öncelikle bu konularda temel bilgilere sahip olmanız çok önemli. React’in bileşen yapısı ve temel konseptlerini öğrenmek başlangıç için faydalı olacaktır.
|
||||||
|
2. **Resmi Belgelerden Başlayın:** React Native’in resmi dökümantasyonu oldukça kapsamlı ve başlangıç düzeyinden ileri seviyeye kadar rehberler sunar. Bu kaynakları takip ederek en azından temel kavramları öğrenebilirsiniz.
|
||||||
|
3. **Küçük Projeler Geliştirin:** Öğrendiklerinizi pekiştirmek için küçük projeler yapmaya başlayın. Örneğin, bir yapılacaklar listesi (To-Do List) uygulaması veya basit bir hava durumu uygulaması geliştirebilirsiniz.
|
||||||
|
4. **Online Kurslara Katılın:** Udemy, Coursera veya YouTube gibi platformlarda React Native ile ilgili birçok eğitim videosu ve kurs bulunmakta. Bu kurslar, adım adım ilerlemenizi sağlar.
|
||||||
|
5. **Topluluklara Katılın:** React Native geliştirici topluluklarına katılarak sorular sorabilir, diğer geliştiricilerden destek alabilir ve projelere katkıda bulunabilirsiniz. Stack Overflow, Reddit ve GitHub bu platformların başında geliyor.
|
||||||
|
6. **Kütüphaneleri İnceleyin:** React Native’in ekosisteminde birçok kullanışlı kütüphane bulunmakta. Örneğin, “React Navigation” ile navigasyon sistemleri oluşturabilir veya “Redux” ile state yönetimi yapabilirsiniz.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Flutter’dan Farkı Nedir?
|
||||||
|
|
||||||
|
Flutter ve React Native, çapraz platform uygulama geliştirme çözümleri sunar ancak farklı yaklaşımlar benimserler:
|
||||||
|
|
||||||
|
|
||||||
|
**Dil Kullanımı:**
|
||||||
|
|
||||||
|
* React Native, JavaScript’i temel alırken; Flutter, Google’ın geliştirdiği Dart programlama dilini kullanır. Dart, birçok geliştirici için yeni bir dil olabilirken, JavaScript geniş bir kitle tarafından zaten bilinmektedir.
|
||||||
|
|
||||||
|
**UI Yaklaşımı:**
|
||||||
|
|
||||||
|
* Flutter, kendi widget sistemini kullanarak tamamen bağımsız bir kullanıcı arayüzü sunar. React Native ise native bileşenleri kullandığından, uygulamalar platforma özgü bir görünüm sağlar.
|
||||||
|
|
||||||
|
**Performans:**
|
||||||
|
|
||||||
|
* Flutter, Dart kodunu native koda dönüştürerek “bridge” kullanmaz ve bu da daha iyi bir performans sağlar. React Native’de, JavaScript ile native kod arasında bir köprü olduğu için bu durum performansı birazda olsa etkileyebilir.
|
||||||
|
|
||||||
|
**Topluluk ve Ekosistem:**
|
||||||
|
|
||||||
|
* React Native, daha uzun süredir piyasada olduğu için daha geniş bir topluluğa ve daha fazla kütüphane desteğine sahiptir. Flutter ise hızla büyüyen bir topluluğa sahiptir ancak hala bazı alanlarda sınırlamalar yaşatabilir.
|
||||||
|
|
||||||
|
**Hot Reload:**
|
||||||
|
|
||||||
|
* Her iki teknoloji de Hot Reload özelliği sunar, ancak Flutter’ın bu özelliği daha hızlı ve kararlı çalıştığı durumlar olabiliyor.
|
||||||
|
|
||||||
|
**Platform Desteği:**
|
||||||
|
|
||||||
|
* Flutter, tek bir kod tabanı ile mobil, web ve masaüstü uygulamaları geliştirme imkânı sunar. React Native de web ve masaüstü desteği sağlar ancak bu alanlarda Flutter kadar güçlü değildir.
|
||||||
|
|
||||||
|
Flutter mı React Native mi tercih edeceğiniz, proje gereksinimlerinize ve ekip becerilerinize bağlıdır. Daha yerel bir his isteyen ve JavaScript’e aşina ekipler için React Native ideal olabilirken, performans odaklı ve özelleştirilmiş UI çözümleri isteyenler için Flutter tercih edilebilir.
|
||||||
@@ -0,0 +1,185 @@
|
|||||||
|
---
|
||||||
|
title: "RSS ile Bilgi Akışını Algoritmadan Uzaklaştır."
|
||||||
|
category: "General"
|
||||||
|
date: "2025-08-24"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "rss-ile-bilgi-ak-n-algoritmadan-uzakla-t-r"
|
||||||
|
excerpt: "RSS ile Bilgi Akışını Algoritmadan Uzaklaştır. Algoritmalar değil, tercihlerin yön verdiği bir içerik akışını nasıl kuracağını anlatacağım bugün sana. 15 dakikada RSS’e …"
|
||||||
|
coverImage: "/blog/images/rss-ile-bilgi-ak-n-algoritmadan-uzakla-t-r-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/rss-ile-bilgi-ak%C4%B1%C5%9F%C4%B1n%C4%B1-algoritmadan-uzakla%C5%9Ft%C4%B1r-a30340175da3"
|
||||||
|
---
|
||||||
|
|
||||||
|
# RSS ile Bilgi Akışını Algoritmadan Uzaklaştır.
|
||||||
|
|
||||||
|
|
||||||
|
Algoritmalar değil, tercihlerin yön verdiği bir içerik akışını nasıl kuracağını anlatacağım bugün sana. 15 dakikada RSS’e geçiş, araçlar, mini projeler ve pratik ipuçları bu yazı içersinde. Dilersen başlayalım!
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## TL;DR
|
||||||
|
|
||||||
|
* RSS, web sitelerinin yeni içeriklerini kronolojik ve reklamsız biçimde takip etmeni sağlar.
|
||||||
|
* 15 dakikada: bir okuyucu seç → 3–5 kaynağa abone ol → klasörle → bildirimleri ayarla → OPML yedekle.
|
||||||
|
* Geliştiriciysen: basit bir XML şablonuyla kendi RSS’ini üret veya bir betikle haftalık özet e-postası gönder.
|
||||||
|
|
||||||
|
## Neden 2025’te RSS hâlâ anlamlı?
|
||||||
|
|
||||||
|
* **Kronolojik ve şeffaf:** “Önce sana bunu gösterelim” mantığı yok; yeni olan en üstte.
|
||||||
|
* **Odaklı:** Gürültüyü azaltır; reklam, öneri, sonsuz kaydırma yok. Sen bunu beğendiğine göre bunu da beğenirsin gibi yönlendirmeler yok. Neyi takip etmek istiyorsan onu takip ediyorsun. Çok basit değil mi?
|
||||||
|
* **Taşınabilir:** OPML ile tüm aboneliklerini bir dosyada yedekleyip başka okuyucuya taşıyabilirsin. Bağımlılık derdin yok.
|
||||||
|
* **Esnek:** Haber, blog, podcast, hatta iş ilanı siteleri… Birçok formatı tek akışta birleştirirsin. Tek bir yer üzerinden sade, anlamlı bir arayüzle hepsini görürsün.
|
||||||
|
|
||||||
|
## RSS nedir?
|
||||||
|
|
||||||
|
**RSS (Really Simple Syndication)**, sitelerin yeni içeriklerini makinece okunabilir bir XML dosyası üzerinden yayınlamasıdır. Okuyucu (reader) uygulaması bu XML’i düzenli aralıklarla kontrol eder, yeni yazıları “okunmamış” olarak sana getirir. Konsept çok basit ve çok anlamlı.
|
||||||
|
|
||||||
|
## Nasıl çalışır?
|
||||||
|
|
||||||
|
Bir RSS besleği (feed), temelde şu elemanlardan oluşur:
|
||||||
|
|
||||||
|
* **channel:** Besleğin kendisine dair meta (başlık, açıklama, site adresi).
|
||||||
|
* **item:** Her bir içerik girdisi (başlık, bağlantı, tarih, özet, içerik).
|
||||||
|
* **enclosure (opsiyonel):** Dosya ekleri (ör: podcast mp3).
|
||||||
|
|
||||||
|
Okuyucu uygulama bu XML’i indirir → değişiklik tarihine bakar → yeni “item”ları kutuna düşürür. Basit, hızlı ve güvenilir.
|
||||||
|
|
||||||
|
## Hangi problemleri çözer?
|
||||||
|
|
||||||
|
* Farklı platformlarda dağınık duran içerikleri **tek merkezde** toplar.
|
||||||
|
* Algoritmik akışların tetiklediği **dikkat dağınıklığını** azaltır. Benim en büyük problemim bu. Youtube’a bir şey öğrenmek için giremez oldum.
|
||||||
|
* İçeriklerin kaybolmasını engeller; hepsi **kronolojik** sıradadır. Gayet basit.
|
||||||
|
|
||||||
|
## Başlarken: Bir RSS okuyucu seç
|
||||||
|
|
||||||
|
Aşağıdaki kategorilerden birini seçmen çoğu kullanıcı için yeterlidir. (Araç isimleri örnektir; benzer seçenekler çoktur.)
|
||||||
|
|
||||||
|
* **Web tabanlı:** tarayıcıdan her yerde erişim (ör. bulut tabanlı okuyucular).
|
||||||
|
* **Masaüstü:** klavye kısayolları ve rahat okuma (ör. macOS/Windows için native uygulamalar).
|
||||||
|
* **Mobil:** boş zamanlarda yakalama (iOS/Android uygulamaları).
|
||||||
|
* **Kendin barındır:** kontrol ve mahremiyet (ör. self-hosted çözümler. Belki bir yazıda da bunu öğreniriz.).
|
||||||
|
|
||||||
|
> _Poyraz’ın Tavsiyesi: Web + mobil kombinasyonu en pratiktir. Başlangıçta ücretsiz bir plan yeter. Şuna bakabilirsiniz:_ [_Fluent Reader_](https://hyliu.me/fluent-reader/)
|
||||||
|
|
||||||
|
## 15 Dakikada RSS’e Geçiş (Adım Adım)
|
||||||
|
|
||||||
|
1. **Okuyucu kur** → web hesabı aç veya uygulamayı indir.
|
||||||
|
2. **3–5 kaynak bul:**
|
||||||
|
|
||||||
|
* 2 teknoloji/blog (ör. kişisel bloglar)
|
||||||
|
* 1 haber sitesi (ör. yerel/güncel)
|
||||||
|
* 1 ilgi alanı (tasarım, veri, yapay zekâ)
|
||||||
|
|
||||||
|
**3\. Feed’i bul ve ekle:**
|
||||||
|
|
||||||
|
* Site üst/alt bölümünde **RSS** / **Feed** ikonu
|
||||||
|
* URL sonlarında sık görülen yollar bunlar: `/feed`, `/rss`, `/atom.xml`
|
||||||
|
|
||||||
|
**4\. Klasörle:** `Teknoloji`, `Tasarım`, `Günlük` gibi basit klasörler.
|
||||||
|
|
||||||
|
|
||||||
|
**5\. Bildirim ayarla:** Sadece “önemli” klasöre bildirim aç; hepsine değil.
|
||||||
|
|
||||||
|
**6\. OPML yedekle:** Okuyucu ayarlarında **Dışa Aktar (Export OPML)**. Dosyayı sakla.
|
||||||
|
|
||||||
|
## Mini Proje #1: Kendi RSS besleğini üret (statik site/blog)
|
||||||
|
|
||||||
|
Bir blog yazılarını programatik olarak RSS’e dökmek istersen, en yalın şablon aşağıdaki gibidir. (RSS 2.0 örneği)
|
||||||
|
|
||||||
|
<?xml version="1.0" encoding="UTF-8"?>
|
||||||
|
<rss version\="2.0"\>
|
||||||
|
<channel\>
|
||||||
|
<title\>Ornek Blog</title\>
|
||||||
|
<link\>https://ornek.site</link\>
|
||||||
|
<description\>Son yazılar</description\>
|
||||||
|
<language\>tr-TR</language\>
|
||||||
|
<lastBuildDate\>Sun, 24 Aug 2025 10:00:00 +0300</lastBuildDate\>
|
||||||
|
<item\>
|
||||||
|
<title\>İlk Yazım</title\>
|
||||||
|
<link\>https://ornek.site/ilk-yazim</link\>
|
||||||
|
<guid isPermaLink\="true"\>https://ornek.site/ilk-yazim</guid\>
|
||||||
|
<pubDate\>Sat, 23 Aug 2025 09:00:00 +0300</pubDate\>
|
||||||
|
<description\><!\[CDATA\[Kısa bir özet veya HTML içerik.\]\]></description\>
|
||||||
|
</item\>
|
||||||
|
</channel\>
|
||||||
|
</rss\>
|
||||||
|
|
||||||
|
### **Üretim seçenekleri:**
|
||||||
|
|
||||||
|
* Statik site jeneratörleri (ör. Next.js, Astro, Hugo) için plugin/route ile dinamik üretim ki ben böyle yapıyorum.
|
||||||
|
* Backend’de (Node, Python, .NET vb.) bir `/rss.xml` endpoint’i de bir tercih.
|
||||||
|
|
||||||
|
> _Poyraz’ın İpucusu:_ `_guid_` _değerini kalıcı yap; okuyucular aynı yazıyı tekrar göstermesin._
|
||||||
|
|
||||||
|
## Mini Proje #2: RSS’den haftalık özet e-postası (Node.js)
|
||||||
|
|
||||||
|
Aşağıdaki iskelet, birkaç feed’i okuyup son 7 günün başlıklarını toparlar. (Gereksinimler: `rss-parser`, e-posta için bir SMTP veya servis.)
|
||||||
|
|
||||||
|
// package.json: rss-parser ve nodemailer ekleyin
|
||||||
|
// npm i - pnpm add - yarn i rss-parser nodemailer
|
||||||
|
|
||||||
|
const Parser = require('rss-parser');
|
||||||
|
const nodemailer = require('nodemailer');
|
||||||
|
const parser = new Parser();
|
||||||
|
|
||||||
|
const FEEDS = \[
|
||||||
|
'https://ornek.site/rss.xml',
|
||||||
|
'https://baska.site/feed'
|
||||||
|
\];
|
||||||
|
|
||||||
|
async function fetchItemsLast7Days() {
|
||||||
|
const now = new Date();
|
||||||
|
const weekAgo = new Date(now.getTime() - 7\*24\*60\*60\*1000);
|
||||||
|
const items = \[\];
|
||||||
|
|
||||||
|
for (const url of FEEDS) {
|
||||||
|
const feed = await parser.parseURL(url);
|
||||||
|
for (const item of feed.items) {
|
||||||
|
const d = new Date(item.isoDate || item.pubDate || 0);
|
||||||
|
if (d >= weekAgo) {
|
||||||
|
items.push({ title: item.title, link: item.link, date: d, source: feed.title });
|
||||||
|
}
|
||||||
|
}
|
||||||
|
}
|
||||||
|
|
||||||
|
// Tarihe göre yeni → eski
|
||||||
|
return items.sort((a, b) => b.date - a.date);
|
||||||
|
}
|
||||||
|
|
||||||
|
async function sendEmail(summaryHtml) {
|
||||||
|
const transporter = nodemailer.createTransport({
|
||||||
|
host: process.env.SMTP\_HOST,
|
||||||
|
port: 587,
|
||||||
|
secure: false,
|
||||||
|
auth: { user: process.env.SMTP\_USER, pass: process.env.SMTP\_PASS }
|
||||||
|
});
|
||||||
|
|
||||||
|
await transporter.sendMail({
|
||||||
|
from: 'RSS Özet <no-reply@senin-domainin.com>',
|
||||||
|
to: 'sen@eposta.com',
|
||||||
|
subject: 'Haftalık RSS Özeti',
|
||||||
|
html: summaryHtml
|
||||||
|
});
|
||||||
|
}
|
||||||
|
|
||||||
|
function renderHtml(items){
|
||||||
|
const lis = items.map(i => \`<li><a href="${i.link}"\>${i.title}</a> — <em>${i.source}</em></li>\`).join('');
|
||||||
|
return \`<h2>Bu Hafta</h2><ul>${lis}</ul>\`;
|
||||||
|
}
|
||||||
|
|
||||||
|
(async () => {
|
||||||
|
const items = await fetchItemsLast7Days();
|
||||||
|
const html = renderHtml(items);
|
||||||
|
if (items.length) await sendEmail(html);
|
||||||
|
})();
|
||||||
|
|
||||||
|
> P_oyraz’ın İpucusu: Bunu bir zamanlayıcıyla (cron, GitHub Actions, serverless scheduler) haftada 1 kez tetikle._
|
||||||
|
|
||||||
|
## Sonuç Olarak Değerli Sen
|
||||||
|
|
||||||
|
* Bugün bir okuyucu seç ve 3–5 feed ekle.
|
||||||
|
* Haftalık bir zaman dilimi belirle (ör. Pazar akşamı 30 dk) ve kaçırdıklarını yakala.
|
||||||
|
* OPML yedeğini al; sonra Mini Proje #2’yi deneyip haftalık özetini otomatikleştir.
|
||||||
|
|
||||||
|
Kendi kurduğun RSS düzenini (araçlar, klasör yapısı, ipuçları) yorumlarda paylaşabilir ve başkalarına ilham olabilirsin. Bu yazıyı faydalı bulduysan, kaydet ve paylaş ki daha fazla kişinin “bilgi akışını algoritmadan uzaklaştırmasına” yardım etmiş ol. Teşekkürler.
|
||||||
@@ -0,0 +1,318 @@
|
|||||||
|
---
|
||||||
|
title: "Svelte ile İlk Adımlar: React ve Vue’ya Karşı Hızlı mı?"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-09-14"
|
||||||
|
readTime: "8 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "svelte-ile-i-lk-ad-mlar-react-ve-vueya-kar-h-zl-m"
|
||||||
|
excerpt: "Svelte ile İlk Adımlar: React ve Vue’ya Karşı Hızlı mı? Öncellikle herkese merhaba. Bildiğiniz gibi frontend dünyasında çeşitli frameworkler ve kütüphanelerle tanışmak her …"
|
||||||
|
coverImage: "/blog/images/svelte-ile-i-lk-ad-mlar-react-ve-vueya-kar-h-zl-m-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/svelte-ile-i%CC%87lk-ad%C4%B1mlar-react-ve-vueya-kar%C5%9F%C4%B1-h%C4%B1zl%C4%B1-m%C4%B1-c5ae640145c9"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Svelte ile İlk Adımlar: React ve Vue’ya Karşı Hızlı mı?
|
||||||
|
|
||||||
|
|
||||||
|
Öncellikle herkese merhaba. Bildiğiniz gibi frontend dünyasında çeşitli frameworkler ve kütüphanelerle tanışmak her geliştiricinin geçtiği bir süreçtir. React, Vue ve Angular gibi devlerin arasına yeni bir oyuncu olarak giren Svelte, son dönemde popülerliğini artırdı. Peki, Svelte’i diğerlerinden ayıran temel farklar neler ve neden daha hızlı? Bu yazımda, Svelte’in yapısını, performans avantajlarını ve React ile Vue’ya karşı neden daha hızlı olduğunu inceleyelim.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Svelte Nedir ve Nasıl Çalışır?
|
||||||
|
|
||||||
|
Svelte, 2016 yılında Rich Harris tarafından geliştirilmiş, modern web uygulamaları oluşturmak için kullanılan bir framework’tür. Ancak Svelte’i diğer frameworklerden ayıran temel fark, bir _framework_ değil, bir **_compiler_ (derleyici**) olmasıdır. Bu, Svelte’in çalışma zamanı kütüphanesi olmadan doğrudan tarayıcıda çalıştığı anlamına gelir.
|
||||||
|
|
||||||
|
React ve Vue, tarayıcıda bir sanal DOM (Virtual DOM) kullanarak bileşenleri yönetir. Herhangi bir değişiklik olduğunda, sanal DOM ile gerçek DOM karşılaştırılır ve güncellenir. Bu işlem, her ne kadar optimize edilse de, tarayıcı üzerinde ekstra bir yük oluşturur. Svelte ise sanal DOM kullanmaz. Bunun yerine, bileşenlerin oluşturulma anında, doğrudan etkin ve optimize edilmiş JavaScript kodu üretir. Bu da onlara göre minimal bşr hız dahi olsa avantaj kazandırır.
|
||||||
|
|
||||||
|
## Svelte’i Neden Daha Hızlı Yapan Unsurlar?
|
||||||
|
|
||||||
|
1. **Compile-time Optimizasyonlar**
|
||||||
|
Svelte’in en büyük avantajlarından biri, değişikliklerin compile-time’da optimize edilmesidir. Diğer frameworkler, tarayıcıda çalışma zamanı sırasında gerekli işlemleri yaparken, Svelte bu işlemleri geliştirme aşamasında yapar ve tarayıcıya doğrudan optimize edilmiş, minimal kod sunar.
|
||||||
|
2. **Sanal DOM Yok**
|
||||||
|
Svelte, sanal DOM kullanmadığı için performans kaybı yaşamaz. React ve Vue, değişiklikleri sanal DOM’da işleyip ardından gerçek DOM’a yansıtırken, Svelte bu adımı atlar ve direkt olarak gerçek DOM üzerinde çalışır. Bu da uygulamanın daha hızlı tepki vermesini sağlar.
|
||||||
|
3. **Daha Küçük Bundle Boyutları**
|
||||||
|
Svelte, framework kütüphanesini projeye dahil etmez. Bunun yerine, sadece bileşenlerde kullanılan kod derlenir ve çıktı dosyası oluşturulur. Bu sayede final bundle boyutu küçülür ve sayfa yükleme süreleri hızlanır.
|
||||||
|
4. **Reaktif Yapı**
|
||||||
|
Svelte, reaktiviteyi bir dil özelliği gibi ele alır. Bir değişkenin değerini güncellediğinizde, Svelte otomatik olarak bu değişkenin kullanıldığı bileşenleri yeniden render eder. Bu, React ve Vue’da kullanılan state management yapılarından daha hafif ve hızlıdır.
|
||||||
|
|
||||||
|
## Svelte mi, React/Vue mu?
|
||||||
|
|
||||||
|
Tabii ki de her framework’ün kendine has avantajları ve kullanım alanları vardır. React ve Vue, geniş topluluk desteği, zengin ekosistem ve olgunlaşmış bir yapıya sahiptir. Ancak performans, küçük boyutlu projeler ve basitlik öncelikli olduğunda, Svelte dikkat çeken bir seçenek haline gelir.
|
||||||
|
|
||||||
|
Svelte, özellikle performansın kritik olduğu projelerde (örneğin düşük performanslı cihazlarda çalışacak uygulamalarda) önemli bir fark yaratabilir. Ayrıca, minimal yapısı sayesinde öğrenmesi de oldukça kolaydır. Bu yüzden yeni başlayanlar için de ideal bir tercih olabilir. Gelin örnek olarak react ve svelte yazımında ki farklara da göz atalım.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## React vs Svelte: Bileşen Oluşturma ve State Yönetimi
|
||||||
|
|
||||||
|
### React’ta Bir Bileşen ve State Yönetimi
|
||||||
|
|
||||||
|
React’ta bir bileşen oluşturmak ve state yönetmek için genellikle `useState` hook'u kullanılır. İşte basit bir sayaç bileşeni örneği:
|
||||||
|
|
||||||
|
// React'ta sayaç bileşeni
|
||||||
|
import React, { useState } from 'react';
|
||||||
|
function Counter() {
|
||||||
|
const \[count, setCount\] = useState(0);
|
||||||
|
return (
|
||||||
|
<div>
|
||||||
|
<p>Count: {count}</p>
|
||||||
|
<button onClick={() => setCount(count + 1)}>
|
||||||
|
Increase
|
||||||
|
</button>
|
||||||
|
</div>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
export default Counter;
|
||||||
|
|
||||||
|
Burada React’in `useState` hook'u ile state yönetimi sağlanır. `onClick` olayında state güncellenir ve bileşen yeniden render edilir. Peki bunu svelte ile nasıl yapıyoruz?
|
||||||
|
|
||||||
|
### Svelte’te Aynı Bileşen
|
||||||
|
|
||||||
|
Svelte’de aynı işlevselliği elde etmek çok daha basit ve doğrudan olur. State yönetimi doğrudan JavaScript değişkenleri üzerinden yapılır ve Svelte reaktif yapısı sayesinde değişiklikler otomatik olarak bileşenleri yeniden render eder:
|
||||||
|
|
||||||
|
<!-- Svelte'te sayaç bileşeni -->
|
||||||
|
<script\> let count = 0;</script\>
|
||||||
|
|
||||||
|
<div\>
|
||||||
|
<p\>Count: {count}</p\>
|
||||||
|
<button on:click\={() => count += 1}>
|
||||||
|
Increase
|
||||||
|
</button\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
Bu daha büyük projelerde dez avantaj yaratabilir fakat küçük çaplı projelerde sürecin hızlanmasına olanak tanır.
|
||||||
|
|
||||||
|
## React vs Svelte: Props Kullanımı
|
||||||
|
|
||||||
|
### React’ta Props Kullanımı
|
||||||
|
|
||||||
|
React’ta bir bileşene `props` geçirerek veri aktarımı şu şekilde yapılır:
|
||||||
|
|
||||||
|
// React'ta parent bileşen
|
||||||
|
import React from 'react';
|
||||||
|
import Greeting from './Greeting';
|
||||||
|
|
||||||
|
function App() {
|
||||||
|
return <Greeting name="Svelte" />;
|
||||||
|
}
|
||||||
|
|
||||||
|
export default App;
|
||||||
|
|
||||||
|
// React'ta child bileşen
|
||||||
|
function Greeting({ name }) {
|
||||||
|
return <p>Hello, {name}!</p>;
|
||||||
|
}
|
||||||
|
|
||||||
|
export default Greeting;
|
||||||
|
|
||||||
|
Burada `Greeting` bileşenine `props` olarak `name` değerini geçiyoruz ve bu props'u child bileşende kullanıyoruz.
|
||||||
|
|
||||||
|
### Svelte’te Props Kullanımı
|
||||||
|
|
||||||
|
Svelte’de props kullanımı ise daha basit ve doğrudandır:
|
||||||
|
|
||||||
|
<!-- Svelte'te parent bileşen -->
|
||||||
|
<script\> import Greeting from './Greeting.svelte';</script\>
|
||||||
|
|
||||||
|
<Greeting name\="Svelte" />
|
||||||
|
|
||||||
|
<!-- Svelte'te child bileşen -->
|
||||||
|
<script\> export let name;</script\>
|
||||||
|
|
||||||
|
<p\>Hello, {name}!</p\>
|
||||||
|
|
||||||
|
Svelte’de bir değişkeni `export` ederek dışarıdan bileşene veri aktarılabilir. Bu, React'taki `props` yapısına karşılık gelir ve çok daha sade bir kullanım sunar. Aslında yine aynı yere varıyoruz. Daha komplike projelerde tercih edilmeyebilir.
|
||||||
|
|
||||||
|
## React vs Svelte: Form ve Event Yönetimi
|
||||||
|
|
||||||
|
### React’ta Form ve Event Yönetimi
|
||||||
|
|
||||||
|
React’ta formlarda state yönetimi ve event handling biraz daha karmaşık olabilir:
|
||||||
|
|
||||||
|
import React, { useState } from 'react';
|
||||||
|
|
||||||
|
function Form() {
|
||||||
|
const \[inputValue, setInputValue\] = useState('');
|
||||||
|
|
||||||
|
const handleChange = (e) => {
|
||||||
|
setInputValue(e.target.value);
|
||||||
|
};
|
||||||
|
|
||||||
|
return (
|
||||||
|
<div>
|
||||||
|
<input type="text" value={inputValue} onChange={handleChange} />
|
||||||
|
<p>Input: {inputValue}</p>
|
||||||
|
</div>
|
||||||
|
);
|
||||||
|
}
|
||||||
|
|
||||||
|
export default Form;
|
||||||
|
|
||||||
|
Her input değişikliğinde state güncellenir ve render tetiklenir.
|
||||||
|
|
||||||
|
### Svelte’te Form ve Event Yönetimi
|
||||||
|
|
||||||
|
Svelte’de form kontrolü ve event yönetimi ise çok daha basit:
|
||||||
|
|
||||||
|
<script\> let inputValue = '';</script\>
|
||||||
|
|
||||||
|
<div\>
|
||||||
|
<input type\="text" bind:value\={inputValue} />
|
||||||
|
<p\>Input: {inputValue}</p\>
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
Svelte’de `bind` ifadesi ile bir input elemanını doğrudan bir değişkene bağlayabilirsiniz. Bu, iki yönlü veri bağlamayı (two-way binding) çok basit hale getirir. Gelin burada ki ana mantığı anladığımıza göre biraz daha Svelte’e odaklanalım ve Svelte’in özelliklerini daha derinlemesine inceleyelim.
|
||||||
|
|
||||||
|
## Svelte’de Lifecycle Metotları
|
||||||
|
|
||||||
|
Svelte’de lifecycle metotları, bileşenlerin yaşam döngüsü içinde belirli anlarda çalıştırmak istediğimiz kodları tanımlamamıza olanak tanır. Svelte, bu amaçla birkaç temel fonksiyon sunar:
|
||||||
|
|
||||||
|
* `onMount`: Bileşen DOM'a yerleştirildiğinde çalışır.
|
||||||
|
* `beforeUpdate`: DOM güncellenmeden hemen önce çalışır.
|
||||||
|
* `afterUpdate`: DOM güncellendikten hemen sonra çalışır.
|
||||||
|
* `onDestroy`: Bileşen DOM'dan kaldırıldığında çalışır.
|
||||||
|
|
||||||
|
### onMount Örneği:
|
||||||
|
|
||||||
|
Svelte’de bir bileşenin DOM’a eklenmesiyle birlikte yapılacak işlemleri `onMount` fonksiyonu ile tanımlayabilirsiniz:
|
||||||
|
|
||||||
|
<script\> import { onMount } from 'svelte';
|
||||||
|
|
||||||
|
let data;
|
||||||
|
|
||||||
|
onMount(async () => {
|
||||||
|
const res = await fetch('https://jsonplaceholder.typicode.com/todos/1');
|
||||||
|
data = await res.json();
|
||||||
|
});</script\>
|
||||||
|
|
||||||
|
<div\>
|
||||||
|
{#if data}
|
||||||
|
<p\>{data.title}</p\>
|
||||||
|
{/if}
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
Bu örnekte `onMount`, bileşen DOM’a yerleştiği anda bir API çağrısı yapar ve sonuçları ekranda görüntüler.
|
||||||
|
|
||||||
|
## Svelte’de Reaktivite
|
||||||
|
|
||||||
|
Svelte’in en güçlü özelliklerinden biri reaktiviteyi doğal olarak ele almasıdır. Bir değişkenin değerinde bir değişiklik olduğunda, Svelte bu değişikliği otomatik olarak takip eder ve ilgili bileşeni yeniden render eder.
|
||||||
|
|
||||||
|
|
||||||
|
Svelte’de reaktiviteyi tetiklemek için sadece bir değişkenin değerini güncellemek yeterlidir. Reaktif ifadeler `let` anahtar kelimesiyle tanımlanır ve herhangi bir ek kod yazılmasına gerek kalmaz.
|
||||||
|
|
||||||
|
**Reaktif İfadeler:**
|
||||||
|
|
||||||
|
<script\> let count = 0;
|
||||||
|
let doubled;
|
||||||
|
|
||||||
|
// $: ifadesi, reaktif bir bloğu işaretler
|
||||||
|
$: doubled = count \* 2;</script\>
|
||||||
|
|
||||||
|
<p\>Count: {count}</p\>
|
||||||
|
<p\>Doubled: {doubled}</p\>
|
||||||
|
<button on:click\={() => count++}>Increase</button\>
|
||||||
|
|
||||||
|
Bu örnekte, `count` değişkeni her arttığında `doubled` reaktif olarak güncellenir ve bu değişiklik ekrana yansır.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Svelte’de Store Kullanımı
|
||||||
|
|
||||||
|
Svelte, küçük projeler için bileşenler arası veri paylaşımı amacıyla oldukça basit bir state yönetim sistemi sunar. Bunun için **store** adı verilen bir yapı kullanılır. Svelte, 3 tür store sağlar: **writable**, **readable** ve **derived** store’lar.
|
||||||
|
|
||||||
|
### Writable Store Örneği:
|
||||||
|
|
||||||
|
Writable store, bileşenler arasında güncellenebilir bir veri paylaşımı sağlar. Aşağıda bir sayaç uygulaması için writable store kullanımını görebilirsiniz:
|
||||||
|
|
||||||
|
<!-- store.js -->
|
||||||
|
import { writable } from 'svelte/store';
|
||||||
|
|
||||||
|
export const count = writable(0);
|
||||||
|
|
||||||
|
<!-- App.svelte -->
|
||||||
|
<script\> import { count } from './store';</script\>
|
||||||
|
|
||||||
|
<p\>Count: {$count}</p\>
|
||||||
|
<button on:click\={() => count.update(n => n + 1)}>Increase</button\>
|
||||||
|
|
||||||
|
Store değerine erişmek için `$` işaretini kullanarak reaktif bir bağlama yapabilirsiniz. Ayrıca, `count.update()` ile store değerini güncelleyebilirsiniz. Gördüğünüz gibi oldukça basit.
|
||||||
|
|
||||||
|
## SvelteKit: Modern Web Uygulamaları İçin Güçlü Bir Araç
|
||||||
|
|
||||||
|
Svelte’in yanı sıra, **SvelteKit** de güçlü bir araç olarak ön plana çıkıyor. SvelteKit, Svelte’in üzerine inşa edilmiş bir framework’tür ve özellikle modern web uygulamaları geliştirmek için tasarlanmıştır. SSR (Sunucu Tarafı Rendering), statik site oluşturma, rotalama (routing) ve çok daha fazlasını kolayca entegre edebilmenizi sağlar.
|
||||||
|
|
||||||
|
### SvelteKit’in Temel Özellikleri:
|
||||||
|
|
||||||
|
* **Sunucu Tarafı Rendering (SSR)**: SvelteKit, uygulamanın sunucu tarafında render edilmesine olanak tanır, bu da SEO dostu sayfalar ve hızlı ilk render süreleri anlamına gelir.
|
||||||
|
* **Statik Site Üretimi**: Dinamik verileri çekip statik HTML dosyaları oluşturmak için kullanılabilir. Bu, SvelteKit’i hem dinamik hem de statik siteler için mükemmel bir seçim haline getirir.
|
||||||
|
* **API Route’ları**: SvelteKit ile kendi API’larınızı oluşturabilirsiniz. Bu, tam anlamıyla bir full-stack uygulama geliştirmeyi mümkün kılar.
|
||||||
|
|
||||||
|
Svelte’in sunduğu sadelik, reaktivite ve performans avantajları ile özellikle küçük ve orta ölçekli projeler için harika bir çözüm sunar. Sonraki adım olarak **SvelteKit** kullanarak, daha geniş kapsamlı projelere yönelik işlevsellikler ekleyebilirsiniz.
|
||||||
|
|
||||||
|
## Sonuç
|
||||||
|
|
||||||
|
Svelte, modern web geliştirme dünyasında performans ve sadelik arayanlar için mükemmel bir çözüm sunuyor. React ve Vue gibi popüler framework’lere kıyasla daha basit bir yapıya sahiptir Svelte.
|
||||||
|
|
||||||
|
Svelte’in en büyük avantajlarından biri, öğrenmesi kolay ve reaktif yapısının doğal olarak sade olmasıdır. Bir değişkenin değerini güncellemek bile bileşenleri yeniden render etmek için yeterli olurken, lifecycle metodları ve store yönetimi de basit ve sezgiseldir. Ayrıca, animasyonlar ve geçiş efektleri gibi işlevler için de dahili destek sunarak, harici kütüphanelere olan ihtiyacı ortadan kaldırır.
|
||||||
|
|
||||||
|
Özellikle küçük ve performansın kritik olduğu projelerde, düşük bellek tüketimi ve hızlı çalışma süreleri sayesinde Svelte, dikkat çeken bir seçenek haline gelir. Ancak daha büyük projeler ve geniş ekosistem desteği gereken durumlarda React ve Vue gibi framework’ler hâlâ güçlü birer alternatif olabilir.
|
||||||
|
|
||||||
|
Svelte, hem yeni başlayanlar hem de deneyimli geliştiriciler için güçlü bir araç sunarken, performans ve basitlikten ödün vermeyen bir çözüm arayanların radarında olmayı hak ediyor. Gelin şimdi “Svelte’i nasıl daha derinlemesine öğrenebiliriz bir bakalım.”
|
||||||
|
|
||||||
|
## Kaynaklar
|
||||||
|
|
||||||
|
Svelte’i öğrenmek için birçok ücretsiz ve kaliteli kaynak bulunuyor. Aşağıda benim de kaynak olarak aldığım hem videolar hem de yazılar ile Svelte’i derinlemesine öğrenebilirsiniz.
|
||||||
|
|
||||||
|
### YouTube Videoları
|
||||||
|
|
||||||
|
1. **Svelte Crash Course (Traversy Media)**
|
||||||
|
|
||||||
|
* [Svelte Crash Course](https://www.youtube.com/watch?v=zojEMeQGGHs)
|
||||||
|
* Bu video, Svelte’in temellerini anlamak ve basit bir proje oluşturmak için mükemmel bir başlangıç noktası. React ve Vue gibi popüler framework’lere aşina olanlar için Svelte’in farklılıkları net bir şekilde açıklanıyor.
|
||||||
|
|
||||||
|
**2\. Learn Svelte in 5 Minutes (Web Dev Simplified)**
|
||||||
|
|
||||||
|
* [Learn Svelte in 5 Minutes](https://www.youtube.com/watch?v=uK2RnIzrQ0M)
|
||||||
|
* Svelte’in temel yapısını hızlıca öğrenmek isteyenler için kısa ve etkili bir video.
|
||||||
|
|
||||||
|
**3\. SvelteKit Crash Course (Net Ninja)**
|
||||||
|
|
||||||
|
* [SvelteKit Crash Course](https://www.youtube.com/watch?v=UU7MgYIbtAk)
|
||||||
|
* Svelte’in modern web uygulamaları için geliştirilmiş framework’ü olan SvelteKit’i detaylıca incelemek ve ilk projeni geliştirmek için bu video rehber olacaktır.
|
||||||
|
|
||||||
|
### Yazılı Kaynaklar ve Makaleler
|
||||||
|
|
||||||
|
1. **Svelte Resmi Dokümantasyon**
|
||||||
|
|
||||||
|
* Svelte Documentation
|
||||||
|
* Svelte’in dökümanyasyonu, framework’ün her yönünü detaylıca açıklayan, başlangıç seviyesinden ileri seviyeye kadar her geliştiriciye hitap eden kapsamlı bir kaynak. Dökümanyasyon okumayı seviyorsanız başka bir kaynağa ihtiyacınız kalacağını düşünmüyorum.
|
||||||
|
|
||||||
|
**2\. Svelte for Beginners: A Hands-On Guide (Smashing Magazine)**
|
||||||
|
|
||||||
|
* Svelte for Beginners
|
||||||
|
* Smashing Magazine’in hazırladığı bu rehber, Svelte ile çalışmaya başlamak isteyenler için adım adım bir yol haritası sunuyor. Kesinlikle göz atmalısınız.
|
||||||
|
|
||||||
|
**3\. Understanding Svelte Reactivity (Dev.to)**
|
||||||
|
|
||||||
|
* Understanding Svelte Reactivity
|
||||||
|
* Svelte’in reaktif yapısını derinlemesine anlamak isteyenler için harika bir makale. Reaktiviteyi diğer framework’lerle karşılaştırarak Svelte’in farkını anlatıyor.
|
||||||
|
|
||||||
|
**4\. Svelte vs React: What’s The Difference? (LogRocket Blog)**
|
||||||
|
|
||||||
|
* Svelte vs React
|
||||||
|
* Svelte ve React arasındaki farkları daha ayrıntılı bir şekilde incelemek için bu makale, framework’lerin avantajlarını ve kullanım alanlarını karşılaştırıyor. Ben de bu yazıda ki karşılaştırmalarımda kaynak olarak burayı kullandım.
|
||||||
|
|
||||||
|
### Online Kurslar
|
||||||
|
|
||||||
|
1. **Svelte.js — The Complete Guide (Udemy)**
|
||||||
|
|
||||||
|
* Svelte.js — The Complete Guide
|
||||||
|
* Udemy’de yer alan bu kapsamlı kurs, Svelte’in temellerini ve ileri düzey özelliklerini öğrenmek isteyen geliştiriciler için ideal.
|
||||||
|
|
||||||
|
**2\. Learn Svelte and Sapper from Scratch (Frontend Masters)**
|
||||||
|
|
||||||
|
* Learn Svelte from Scratch
|
||||||
|
* Frontend Masters tarafından sunulan bu kurs, Svelte ve onun eski framework’ü olan Sapper üzerinde yoğunlaşarak modern uygulama geliştirmeye odaklanıyor. Bakmanızı tavsiye ederim.
|
||||||
|
|
||||||
|

|
||||||
@@ -1,204 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Svelte ile İlk Adımlar: React ve Vue’ya Karşı Hızlı mı?"
|
|
||||||
category: "Frontend"
|
|
||||||
date: "2026-02-14"
|
|
||||||
readTime: "11 min read"
|
|
||||||
author: "Poyraz Avsever"
|
|
||||||
excerpt: "Frontend dünyasında React, Vue ve Angular gibi güçlü seçenekler var. Son yıllarda bu listeye güçlü bir alternatif..."
|
|
||||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*Dx04pr9plejiCcWI.png"
|
|
||||||
---
|
|
||||||
|
|
||||||
Frontend dünyasında React, Vue ve Angular gibi güçlü seçenekler var. Son yıllarda bu listeye güçlü bir alternatif olarak Svelte de eklendi. Peki Svelte'i farklı yapan ne ve neden çoğu senaryoda daha hızlı hissediliyor?
|
|
||||||
|
|
||||||
## Svelte Nedir?
|
|
||||||
|
|
||||||
Svelte, geleneksel anlamda sadece bir runtime framework değil; derleme (compile-time) odaklı bir yaklaşıma sahip. Uygulama çalışmadan önce bileşenleri optimize edip tarayıcıya daha sade JavaScript gönderir.
|
|
||||||
|
|
||||||
## Svelte'i Hızlı Yapan Unsurlar
|
|
||||||
|
|
||||||
- **Compile-time optimizasyon**: İşin büyük kısmı build aşamasında çözülür.
|
|
||||||
- **Virtual DOM yok**: Ara katman maliyetini azaltır.
|
|
||||||
- **Daha küçük bundle**: Runtime yükü azalır.
|
|
||||||
- **Doğal reaktivite**: Basit state güncellemeleri için ek soyutlamalara daha az ihtiyaç duyulur.
|
|
||||||
|
|
||||||
## React ve Svelte Karşılaştırması
|
|
||||||
|
|
||||||
### 1. State Yönetimi
|
|
||||||
|
|
||||||
React örneği:
|
|
||||||
|
|
||||||
```jsx
|
|
||||||
import React, { useState } from "react";
|
|
||||||
|
|
||||||
function Counter() {
|
|
||||||
const [count, setCount] = useState(0);
|
|
||||||
|
|
||||||
return (
|
|
||||||
<div>
|
|
||||||
<p>Count: {count}</p>
|
|
||||||
<button onClick={() => setCount(count + 1)}>Increase</button>
|
|
||||||
</div>
|
|
||||||
);
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
Svelte örneği:
|
|
||||||
|
|
||||||
```svelte
|
|
||||||
<script>
|
|
||||||
let count = 0;
|
|
||||||
</script>
|
|
||||||
|
|
||||||
<div>
|
|
||||||
<p>Count: {count}</p>
|
|
||||||
<button on:click={() => (count += 1)}>Increase</button>
|
|
||||||
</div>
|
|
||||||
```
|
|
||||||
|
|
||||||
### 2. Props Kullanımı
|
|
||||||
|
|
||||||
React:
|
|
||||||
|
|
||||||
```jsx
|
|
||||||
function Greeting({ name }) {
|
|
||||||
return <p>Hello, {name}!</p>;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
Svelte:
|
|
||||||
|
|
||||||
```svelte
|
|
||||||
<script>
|
|
||||||
export let name;
|
|
||||||
</script>
|
|
||||||
|
|
||||||
<p>Hello, {name}!</p>
|
|
||||||
```
|
|
||||||
|
|
||||||
### 3. Form Yönetimi
|
|
||||||
|
|
||||||
React:
|
|
||||||
|
|
||||||
```jsx
|
|
||||||
import React, { useState } from "react";
|
|
||||||
|
|
||||||
function Form() {
|
|
||||||
const [inputValue, setInputValue] = useState("");
|
|
||||||
|
|
||||||
return (
|
|
||||||
<div>
|
|
||||||
<input
|
|
||||||
type="text"
|
|
||||||
value={inputValue}
|
|
||||||
onChange={(e) => setInputValue(e.target.value)}
|
|
||||||
/>
|
|
||||||
<p>Input: {inputValue}</p>
|
|
||||||
</div>
|
|
||||||
);
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
Svelte:
|
|
||||||
|
|
||||||
```svelte
|
|
||||||
<script>
|
|
||||||
let inputValue = "";
|
|
||||||
</script>
|
|
||||||
|
|
||||||
<div>
|
|
||||||
<input type="text" bind:value={inputValue} />
|
|
||||||
<p>Input: {inputValue}</p>
|
|
||||||
</div>
|
|
||||||
```
|
|
||||||
|
|
||||||
## Lifecycle Metotları
|
|
||||||
|
|
||||||
Svelte tarafında en sık kullanılan lifecycle fonksiyonları:
|
|
||||||
|
|
||||||
- `onMount`
|
|
||||||
- `beforeUpdate`
|
|
||||||
- `afterUpdate`
|
|
||||||
- `onDestroy`
|
|
||||||
|
|
||||||
`onMount` örneği:
|
|
||||||
|
|
||||||
```svelte
|
|
||||||
<script>
|
|
||||||
import { onMount } from "svelte";
|
|
||||||
|
|
||||||
let data;
|
|
||||||
|
|
||||||
onMount(async () => {
|
|
||||||
const res = await fetch("https://jsonplaceholder.typicode.com/todos/1");
|
|
||||||
data = await res.json();
|
|
||||||
});
|
|
||||||
</script>
|
|
||||||
|
|
||||||
{#if data}
|
|
||||||
<p>{data.title}</p>
|
|
||||||
{/if}
|
|
||||||
```
|
|
||||||
|
|
||||||
## Reaktivite
|
|
||||||
|
|
||||||
Svelte'in en güçlü taraflarından biri, reaktif ifadeleri dil seviyesinde desteklemesi:
|
|
||||||
|
|
||||||
```svelte
|
|
||||||
<script>
|
|
||||||
let count = 0;
|
|
||||||
$: doubled = count * 2;
|
|
||||||
</script>
|
|
||||||
|
|
||||||
<p>Count: {count}</p>
|
|
||||||
<p>Doubled: {doubled}</p>
|
|
||||||
<button on:click={() => count++}>Increase</button>
|
|
||||||
```
|
|
||||||
|
|
||||||
## Store Kullanımı
|
|
||||||
|
|
||||||
Bileşenler arası state paylaşımı için `store` yapısı çok kullanışlıdır.
|
|
||||||
|
|
||||||
`store.js`:
|
|
||||||
|
|
||||||
```js
|
|
||||||
import { writable } from "svelte/store";
|
|
||||||
|
|
||||||
export const count = writable(0);
|
|
||||||
```
|
|
||||||
|
|
||||||
`App.svelte`:
|
|
||||||
|
|
||||||
```svelte
|
|
||||||
<script>
|
|
||||||
import { count } from "./store";
|
|
||||||
</script>
|
|
||||||
|
|
||||||
<p>Count: {$count}</p>
|
|
||||||
<button on:click={() => count.update((n) => n + 1)}>Increase</button>
|
|
||||||
```
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
## SvelteKit Neden Önemli?
|
|
||||||
|
|
||||||
SvelteKit, Svelte üzerine kurulu modern bir framework'tür. Özellikle şu konularda güçlüdür:
|
|
||||||
|
|
||||||
- SSR (Server-Side Rendering)
|
|
||||||
- Statik site üretimi
|
|
||||||
- Dosya tabanlı routing
|
|
||||||
- API endpoint tanımları
|
|
||||||
|
|
||||||
Bu yapı, Svelte'i küçük projelerden ürün seviyesine taşımayı kolaylaştırır.
|
|
||||||
|
|
||||||
## Sonuç
|
|
||||||
|
|
||||||
Svelte, performans ve sadelik odaklı bir geliştirme deneyimi sunuyor. Küçük ve orta ölçekli projelerde çok hızlı sonuç verir; büyük projelerde ise SvelteKit ile birlikte oldukça güçlü bir seçenek haline gelir.
|
|
||||||
|
|
||||||
## Kaynaklar
|
|
||||||
|
|
||||||
- [Svelte Documentation](https://svelte.dev/docs)
|
|
||||||
- [Svelte Tutorial](https://svelte.dev/tutorial)
|
|
||||||
- [SvelteKit Documentation](https://kit.svelte.dev/docs)
|
|
||||||
- [LogRocket - Svelte vs React](https://blog.logrocket.com/svelte-vs-react/)
|
|
||||||
|
|
||||||

|
|
||||||
@@ -1,125 +0,0 @@
|
|||||||
---
|
|
||||||
title: "Tailwind CSS ile Tasarım Sürecini Nasıl Hızlandırabilirsiniz?"
|
|
||||||
category: "Frontend"
|
|
||||||
date: "2026-02-10"
|
|
||||||
readTime: "10 min read"
|
|
||||||
author: "Poyraz Avsever"
|
|
||||||
excerpt: "Tailwind CSS, son dönemde front-end geliştiriciler arasında çok popüler hale geldi. Klasik CSS..."
|
|
||||||
coverImage: "/news/performance.svg"
|
|
||||||
---
|
|
||||||
|
|
||||||
Tailwind CSS, son dönemde front-end geliştiriciler arasında çok popüler hale geldi. Klasik CSS yaklaşımına göre daha hızlı prototipleme imkanı sunması ve esnek yapısı, özellikle ürün geliştirme süreçlerinde ciddi zaman kazandırıyor.
|
|
||||||
|
|
||||||
|
|
||||||
## Tailwind CSS Nedir?
|
|
||||||
|
|
||||||
Tailwind CSS, utility-first yaklaşımını benimseyen bir CSS framework'üdür. Yani özel class isimleri üretmek yerine, hazır utility class'ları doğrudan bileşen üzerinde kullanırsın.
|
|
||||||
|
|
||||||
## Neden Tailwind CSS Kullanmalıyız?
|
|
||||||
|
|
||||||
### 1. Hızlı ve Kolay Stil Geliştirme
|
|
||||||
|
|
||||||
Klasik CSS ile:
|
|
||||||
|
|
||||||
```css
|
|
||||||
.btn {
|
|
||||||
background-color: #3490dc;
|
|
||||||
color: #fff;
|
|
||||||
padding: 1rem;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
Tailwind ile:
|
|
||||||
|
|
||||||
```html
|
|
||||||
<button class="bg-blue-500 text-white p-4">Click Me</button>
|
|
||||||
```
|
|
||||||
|
|
||||||
### 2. Daha Az CSS Karmaşası
|
|
||||||
|
|
||||||
Büyük projelerde CSS dosyaları büyüdükçe sınıf yönetimi zorlaşır. Tailwind ile stil kararları bileşen seviyesinde alınır; bu da dağınıklığı azaltır.
|
|
||||||
|
|
||||||
### 3. Responsive Tasarım Daha Basit
|
|
||||||
|
|
||||||
```html
|
|
||||||
<div class="text-sm md:text-lg lg:text-xl">
|
|
||||||
Responsive Metin
|
|
||||||
</div>
|
|
||||||
```
|
|
||||||
|
|
||||||
Tek satırda farklı kırılımlar için tipografi kontrolü yapabilirsin.
|
|
||||||
|
|
||||||
## Tailwind'i Daha Verimli Kullanma İpuçları
|
|
||||||
|
|
||||||
### 1. `tailwind.config.js` Dosyasını Özelleştir
|
|
||||||
|
|
||||||
```js
|
|
||||||
module.exports = {
|
|
||||||
theme: {
|
|
||||||
extend: {
|
|
||||||
colors: {
|
|
||||||
customBlue: "#1e3a8a",
|
|
||||||
},
|
|
||||||
spacing: {
|
|
||||||
128: "32rem",
|
|
||||||
},
|
|
||||||
},
|
|
||||||
},
|
|
||||||
};
|
|
||||||
```
|
|
||||||
|
|
||||||
### 2. `@apply` ile Tekrarları Azalt
|
|
||||||
|
|
||||||
```css
|
|
||||||
.btn-primary {
|
|
||||||
@apply bg-blue-500 text-white font-bold py-2 px-4 rounded;
|
|
||||||
}
|
|
||||||
```
|
|
||||||
|
|
||||||
### 3. Üretimde Kullanılmayan Stilleri Temizle
|
|
||||||
|
|
||||||
```js
|
|
||||||
module.exports = {
|
|
||||||
purge: ["./src/**/*.html", "./src/**/*.js"],
|
|
||||||
};
|
|
||||||
```
|
|
||||||
|
|
||||||
### 4. JIT Modunu Kullan
|
|
||||||
|
|
||||||
```js
|
|
||||||
module.exports = {
|
|
||||||
mode: "jit",
|
|
||||||
};
|
|
||||||
```
|
|
||||||
|
|
||||||
### 5. Mobile-first Düşün
|
|
||||||
|
|
||||||
```html
|
|
||||||
<div class="text-sm md:text-lg lg:text-xl">
|
|
||||||
Responsive Metin
|
|
||||||
</div>
|
|
||||||
```
|
|
||||||
|
|
||||||
Önce küçük ekranlardan başlayıp yukarı doğru ölçeklemek genelde daha temiz sonuç verir.
|
|
||||||
|
|
||||||
### 6. Eklenti Ekosisteminden Yararlan
|
|
||||||
|
|
||||||
- `@tailwindcss/forms`
|
|
||||||
- `@tailwindcss/typography`
|
|
||||||
- `tailwind-scrollbar`
|
|
||||||
|
|
||||||
Bu eklentilerle ortak UI ihtiyaçlarını daha hızlı çözebilirsin.
|
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
## Sonuç
|
|
||||||
|
|
||||||
Tailwind CSS, doğru kullanıldığında hem hız hem de bakım kolaylığı sağlar. Özellikle hızlı iterasyon gereken projelerde, utility-first yaklaşımı ciddi avantaj sunar.
|
|
||||||
|
|
||||||
## Kaynaklar
|
|
||||||
|
|
||||||
- [Tailwind CSS Dokümantasyon](https://tailwindcss.com/docs)
|
|
||||||
- [Configuration](https://tailwindcss.com/docs/configuration)
|
|
||||||
- [Optimizing for Production](https://tailwindcss.com/docs/optimizing-for-production)
|
|
||||||
- [JIT Mode](https://tailwindcss.com/docs/just-in-time-mode)
|
|
||||||
- [Plugins](https://tailwindcss.com/docs/plugins)
|
|
||||||
@@ -0,0 +1,138 @@
|
|||||||
|
---
|
||||||
|
title: "Tailwind CSS ile Tasarım Sürecini Nasıl Hızlandırabilirsiniz?"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-09-14"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "tailwind-css-ile-tasar-m-s-recini-nas-l-h-zland-rabilirsiniz"
|
||||||
|
excerpt: "Tailwind CSS ile Tasarım Sürecini Nasıl Hızlandırabilirsiniz? Tailwind CSS, son dönemde front-end geliştiricilerin gözdesi haline geldi. Klasik CSS yazımına göre daha oldukça hızlı ve …"
|
||||||
|
coverImage: "/blog/images/tailwind-css-ile-tasar-m-s-recini-nas-l-h-zland-rabilirsiniz-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/tailwind-css-ile-tasar%C4%B1m-s%C3%BCrecini-nas%C4%B1l-h%C4%B1zland%C4%B1rabilirsiniz-90ef7fbd9faf"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Tailwind CSS ile Tasarım Sürecini Nasıl Hızlandırabilirsiniz?
|
||||||
|
|
||||||
|
|
||||||
|
Tailwind CSS, son dönemde front-end geliştiricilerin gözdesi haline geldi. Klasik CSS yazımına göre daha oldukça hızlı ve esnek bir yapı sunması, özellikle hızlı prototipleme ve özelleştirilmiş tasarımlar oluşturma süreçlerinde büyük avantaj sağlıyor. Bu yazıda, Tailwind CSS ile nasıl **daha hızlı ve verimli** bir tasarım süreci yaratabileceğinizi adım adım ele alacağız. Her şeyden önce gelin “tailwind css nedir ve neden kullanmalıyız?” diye bir soralım.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## **Tailwind CSS Nedir ve Neden Kullanmalıyız?**
|
||||||
|
|
||||||
|
Tailwind CSS, klasik CSS yazımında alışık olduğumuz “class tanımla, sonra stilleri yaz” yöntemine alternatif olarak ortaya çıkmış, utility-first (yardımcı sınıf temelli) bir CSS framework’ü. Yani, önceden tanımlanmış küçük stil sınıflarını doğrudan HTML elementlerine ekleyerek stil verebiliyorsun. Örneğin, bir buton için `bg-blue-500`, `text-white`, `p-4` gibi sınıfları ekleyerek, doğrudan istediğin görünüme hızlıca ulaşabilirsin.
|
||||||
|
|
||||||
|
### Neden Tailwind Kullanmalıyız?
|
||||||
|
|
||||||
|
**1- Hızlı ve Kolay**
|
||||||
|
CSS de her yeni stil için bir class yazman gerekiyor. Örneğin, bir butonun arka plan rengi, yazı rengi ve padding gibi özelliklerini tanımlamak için stil dosyana şöyle bir kod yazıyorsun:,
|
||||||
|
|
||||||
|
.btn {
|
||||||
|
background-color: #3490dc;
|
||||||
|
color: #fff;
|
||||||
|
padding: 1rem;
|
||||||
|
}
|
||||||
|
|
||||||
|
Tailwind de ise aynı butonu şu şekilde oluşturabilirsin:
|
||||||
|
|
||||||
|
<button class\="bg-blue-500 text-white p-4"\>Click Me</button\>h
|
||||||
|
|
||||||
|
Yani, her şey HTML içerisinde çok daha hızlı bir şekilde yönetilebiliyor. Bu da stili hızlıca oluşturmanı ve üzerinde anında değişiklik yapmanı sağlıyor. Üstelik terimler daha basite indirgendiği için kafa karışıklığından da kurtuluyoruz.
|
||||||
|
|
||||||
|
**2- CSS Dosyası Karmasından Kurtul**
|
||||||
|
|
||||||
|
CSS’de büyük projelerde zamanla stil dosyaları karmaşık hale gelebilir. Sınıf isimlerini organize etmek ve tutarlı bir sistem oturtmak zor olabilir. Tailwind ile ise her stil bileşeni için yeniden sınıf yazmak yerine, utility sınıflarını kullanarak kod tekrarını ve karmaşayı azaltıyorsun. Yani, tek bir dosya içinde “hangi sınıf hangi stili uyguluyor” derdine girmiyorsun.
|
||||||
|
|
||||||
|
**3- Responsive Tasarım Kolaylığı**
|
||||||
|
CSS de her ekran boyutu için ayrı media query yazman gerekiyor fakat Tailwind’de bu iş çok daha kolay. Örneğin:
|
||||||
|
|
||||||
|
<div class\="text-sm md:text-lg lg:text-xl"\>
|
||||||
|
Responsive Metin
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
Bu kod, küçük ekranlarda `text-sm`, orta ekranlarda `text-lg`, büyük ekranlarda `text-xl` sınıflarını uygular. Media query yazmaya gerek yok. Bana kalırsa Tailwind’in sağladığı en büyük avantajlardan birisi de bu.
|
||||||
|
|
||||||
|
## Tailwind CSS’i Daha Verimli Kullanmanın Yolları
|
||||||
|
|
||||||
|
Tailwind CSS’in gücünü tam anlamıyla kullanmak için bazı ipuçları işini hızlandırabilir ve kodunu daha temiz hale getirebilir:
|
||||||
|
|
||||||
|
1. **Config Dosyasını Özelleştir**
|
||||||
|
|
||||||
|
Tailwind’in sunduğu yapı taşlarını kendi projen için optimize edebilirsin. `tailwind.config.js` dosyasını kullanarak renk paletlerini, fontları ve spacing değerlerini özelleştirmen, projende tutarlı bir tasarım sistemi oluşturmanı sağlar. Örneğin:
|
||||||
|
|
||||||
|
module.exports \= {
|
||||||
|
theme: {
|
||||||
|
extend: {
|
||||||
|
colors: {
|
||||||
|
customBlue: '#1e3a8a',
|
||||||
|
},
|
||||||
|
spacing: {
|
||||||
|
'128': '32rem',
|
||||||
|
},
|
||||||
|
},
|
||||||
|
},
|
||||||
|
}
|
||||||
|
|
||||||
|
2\. **@apply Direktifini Kullan**
|
||||||
|
|
||||||
|
|
||||||
|
Aynı stilleri tekrar tekrar yazmak yerine Tailwind’in `@apply` direktifini kullanarak ortak stilleri bir araya getiren sınıflar oluşturabilirsin. Böylece hem kodun daha temiz olur hem de yönetimi kolaylaşır. Örneği bir butonu projende onlarca defa kullanacaksan `@apply`ile tanımlayabilirsin.
|
||||||
|
|
||||||
|
.btn-primary {
|
||||||
|
@apply bg-blue-500 text-white font-bold py-2 px-4 rounded;
|
||||||
|
}
|
||||||
|
|
||||||
|
3\. **PurgeCSS ile Dosya Boyutunu Küçült**
|
||||||
|
|
||||||
|
Tailwind projelerde kullanılmayan stiller de oluşturur. Bu yüzden dosya boyutunu optimize etmek için üretim aşamasında `purge` özelliğini kullanarak kullanılmayan stilleri kaldırabilirsin. Bu, özellikle büyük projelerde performansı artırır.
|
||||||
|
|
||||||
|
module.exports = {
|
||||||
|
purge: \['./src/\*\*/\*.html', './src/\*\*/\*.js'\]
|
||||||
|
}
|
||||||
|
|
||||||
|
**4\. Tailwind JIT Modunu Etkinleştir**
|
||||||
|
|
||||||
|
Tailwind’in Just-In-Time (JIT) modunu kullanarak, yazdığın sınıfların anında oluşturulmasını ve CSS dosyasının minimum seviyede tutulmasını sağlayabilirsin. Bu mod, Tailwind’in en güncel ve dinamik şekilde çalışmasını sağlar.
|
||||||
|
|
||||||
|
module.exports = {
|
||||||
|
mode: 'jit'
|
||||||
|
}
|
||||||
|
|
||||||
|
5\. **Responsive Tasarımı Kolaylaştır**
|
||||||
|
|
||||||
|
Tailwind ile responsive tasarımlar oluşturmak çok basittir. Sınıfların başına `sm:`, `md:`, `lg:` gibi prefix'ler ekleyerek farklı ekran boyutlarına göre stilleri kolayca tanımlayabilirsin. Bu, mobil uyumluluğu hızla sağlamanın en etkili yollarından biri. Web sitesini tasarlamaya başlarken mobil versiyonlardan başlarsan daha rahat edersin. **Küçükten büyüğe**
|
||||||
|
|
||||||
|
<div class\="text-sm md:text-lg lg:text-xl"\>
|
||||||
|
Responsive Metin
|
||||||
|
</div\>
|
||||||
|
|
||||||
|
6\. **Tailwind Eklentilerini Keşfet**
|
||||||
|
|
||||||
|
Tailwind’in ekosisteminde birçok faydalı eklenti mevcut. Özellikle form bileşenleri, tipografi veya animasyonlar için Tailwind eklentileri işini daha da kolaylaştırabilir. Örneğin, `@tailwindcss/forms`eklentisi ile form stillerini güzelleştirebilirsin. `@tailwind-scrollbar`eklentisi ile scrollbar’larını özelleştirebilirsin. İnternetten detaylı bir aramayla işine yarayanları bulabilir, projelerine kolay bir şekilde entegre edebilirsin.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Bu ipuçlarıyla, Tailwind CSS’i daha verimli kullanabilir ve projelerinde daha temiz, düzenli bir kod yapısına ulaşabilirsin! Kendi projelerinde Tailwind’i kullanarak, hem zaman kazanmaya başlayacak hem de bu alan da daha özgür olacaksın. Bu yazıda sunduğum ipuçları ile Tailwind CSS’i daha verimli kullanabilir, projelerinde fark yaratabilirsin. Hemen dene, iş akışını nasıl dönüştürdüğünü gör!
|
||||||
|
|
||||||
|
### **Başarılar ve keyifli kodlamalar!**
|
||||||
|
|
||||||
|
## **Kaynaklar**
|
||||||
|
|
||||||
|
1. **Tailwind CSS Resmi Dokümantasyonu**
|
||||||
|
Tailwind’in utility-first yapısına dair tüm detaylar ve kullanım örneklerini burada bulabilirsin:
|
||||||
|
[https://tailwindcss.com/docs](https://tailwindcss.com/docs)
|
||||||
|
2. **Tailwind CSS Konfigürasyon Rehberi**
|
||||||
|
Tailwind’in `tailwind.config.js` dosyasını nasıl özelleştirebileceğin hakkında daha fazla bilgi için:
|
||||||
|
[https://tailwindcss.com/docs/configuration](https://tailwindcss.com/docs/configuration)
|
||||||
|
3. **PurgeCSS ile Optimizasyon**
|
||||||
|
Tailwind ile kullanılan PurgeCSS hakkında detaylı rehber için:
|
||||||
|
[https://tailwindcss.com/docs/optimizing-for-production](https://tailwindcss.com/docs/optimizing-for-production)
|
||||||
|
4. **Tailwind CSS Just-In-Time (JIT) Modu**
|
||||||
|
Tailwind JIT modunun nasıl etkinleştirileceği ve faydaları hakkında daha fazla bilgi:
|
||||||
|
[https://tailwindcss.com/docs/just-in-time-mode](https://tailwindcss.com/docs/just-in-time-mode)
|
||||||
|
5. **Tailwind CSS Eklentileri**
|
||||||
|
Forms, Typography gibi eklentilerin nasıl kullanılacağına dair rehberler:
|
||||||
|
[https://tailwindcss.com/docs/plugins](https://tailwindcss.com/docs/plugins)
|
||||||
|
|
||||||
|
Bu kaynaklar, Tailwind CSS’i daha derinlemesine öğrenmek ve projelerinde en iyi şekilde kullanmak için faydalı olacaktır.
|
||||||
@@ -0,0 +1,152 @@
|
|||||||
|
---
|
||||||
|
title: "Three.js: 3 Boyutlu Dünyaya Merhaba"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-12-02"
|
||||||
|
readTime: "3 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "three-js-3-boyutlu-d-nyaya-merhaba"
|
||||||
|
excerpt: "Three.js: 3 Boyutlu Dünyaya Merhaba Dostlar, bugün size bir yazılımcının 3D dünyaya giriş hikayesini anlatacağım. Hani şu hayal gücünüzde dönen küreler, ışıklar, gölgeler var …"
|
||||||
|
coverImage: "/blog/images/three-js-3-boyutlu-d-nyaya-merhaba-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/three-js-3-boyutlu-d%C3%BCnyaya-merhaba-07b174dd6759"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Three.js: 3 Boyutlu Dünyaya Merhaba
|
||||||
|
|
||||||
|
|
||||||
|
Dostlar, bugün size bir yazılımcının 3D dünyaya giriş hikayesini anlatacağım. Hani şu hayal gücünüzde dönen küreler, ışıklar, gölgeler var ya… Hazırsanız, Three.js ile yolculuğa çıkıyoruz!
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### “Bu Ne Güzel Bir Kütüphane!”
|
||||||
|
|
||||||
|
Three.js ile tanışmam bundan çok uzun zaman önce @Emir Uluçay arkadaşım sayesinde oldu. Ekranda bir küp dönüyordu. Basit bir küp işte, ama dönüyor. Kodu inceledikçe “Vay be, bunları yapabiliyorsam daha neler yaparım!” dedim. Ve böylece Three.js ile tanıştım oldum. O gün bugündür siz tembellik deyin, ben zamanım olmadı diyeyim bir türlü oturup 2 kelam edememiştik three.js ile. Fakat şuan staj yaptığım şirkette Three.js öğrenme taski girilmesin mi… Şimdi bakalım neymiş ne değilmiş bu arkadaş.
|
||||||
|
|
||||||
|
## Three.js: Nedir, Ne Değildir?
|
||||||
|
|
||||||
|
Three.js, **JavaScript ile tarayıcı üzerinde 3D grafikler oluşturmak için kullanılan bir kütüphane.** Basit bir küpten karmaşık bir 3D şehre kadar her şeyi tasarlayabilirsiniz. Ama önce şunu netleştirelim:
|
||||||
|
|
||||||
|
* **Three.js bir oyun motoru değildir.** Yani Unity ya da Unreal Engine gibi her şeyi tek çatı altında sunmaz. Ama WebGL’in üstüne güzel bir soyutlama katmanı ekleyerek 3D grafiklerle uğraşmayı eğlenceli hale getirir.
|
||||||
|
* **Three.js, WebGL’in süper kahramanı gibidir.** WebGL doğrudan GPU ile çalışır ve yüksek performans sağlar, ama kullanması zor olabilir. Three.js, bu karmaşıklığı giderir ve size daha az kodla harika işler yapma şansı verir.
|
||||||
|
|
||||||
|
## Peki Three.js Neler Sunar?
|
||||||
|
|
||||||
|
### 1\. Sahne Yönetimi (Scene Management)
|
||||||
|
|
||||||
|
Three.js, bir sahne (scene) oluşturmanıza olanak tanır. Sahne, 3D dünyanızı barındıran bir konteyner gibidir. İçine nesneler, ışıklar ve kameralar ekleyebilirsiniz.
|
||||||
|
|
||||||
|
const scene = new THREE.Scene();
|
||||||
|
|
||||||
|
### 2\. Kameralar
|
||||||
|
|
||||||
|
Kameralar, 3D sahnenizi “görmeyi” sağlar. Three.js’de iki ana kamera türü vardır:
|
||||||
|
|
||||||
|
* **PerspectiveCamera**: İnsan gözünün görme şekline benzer. Uzak nesneler daha küçük görünür.
|
||||||
|
* **OrthographicCamera**: Nesneler uzaklıklarına göre boyut değiştirmez. Teknik çizimler için kullanışlıdır.
|
||||||
|
|
||||||
|
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);
|
||||||
|
camera.position.z = 5;
|
||||||
|
|
||||||
|
### 3\. Geometri ve Malzeme (Geometry & Material)
|
||||||
|
|
||||||
|
Geometri, 3D dünyanızdaki nesnelerin şekillerini tanımlar: küreler, kutular, düzlemler… Malzeme ise bu şekillerin nasıl görüneceğini belirler. Örneğin, mat mı parlak mı, hangi renkte olacak?
|
||||||
|
|
||||||
|
const geometry = new THREE.BoxGeometry();
|
||||||
|
const material = new THREE.MeshBasicMaterial({ color: 0x00ff00 });
|
||||||
|
const cube = new THREE.Mesh(geometry, material);
|
||||||
|
scene.add(cube);
|
||||||
|
|
||||||
|
### 4\. Işıklandırma (Lighting)
|
||||||
|
|
||||||
|
Işık, sahnenizi gerçekçi hale getirir. Three.js, çeşitli ışık türleri sunar:
|
||||||
|
|
||||||
|
* AmbientLight (Genel aydınlatma)
|
||||||
|
* PointLight (Nokta ışığı)
|
||||||
|
* DirectionalLight (Güneş gibi yönlendirilmiş ışık)
|
||||||
|
|
||||||
|
const light = new THREE.PointLight(0xffffff, 1, 100);
|
||||||
|
light.position.set(10, 10, 10);
|
||||||
|
scene.add(light);
|
||||||
|
|
||||||
|
### 5\. Renderer
|
||||||
|
|
||||||
|
Renderer, sahnenizi tarayıcıda görüntülemenizi sağlar. Three.js’nin WebGLRenderer’ı, GPU’nun gücünü kullanarak sahneleri hızlı bir şekilde çizer.
|
||||||
|
|
||||||
|
const renderer = new THREE.WebGLRenderer();
|
||||||
|
renderer.setSize(window.innerWidth, window.innerHeight);
|
||||||
|
document.body.appendChild(renderer.domElement);
|
||||||
|
|
||||||
|
### 6\. Animasyon
|
||||||
|
|
||||||
|
Three.js ile sahnenizi canlandırabilirsiniz. Bu, genellikle bir **animasyon döngüsü** kullanılarak yapılır:
|
||||||
|
|
||||||
|
function animate() {
|
||||||
|
requestAnimationFrame(animate);
|
||||||
|
cube.rotation.x += 0.01;
|
||||||
|
cube.rotation.y += 0.01;
|
||||||
|
renderer.render(scene, camera);
|
||||||
|
}
|
||||||
|
animate();
|
||||||
|
|
||||||
|
## Neler Yapabilirsiniz?
|
||||||
|
|
||||||
|
1. **Etkileşimli 3D Web Siteleri**: Hareket eden nesneler, dönen küpler, dinamik arka planlar…
|
||||||
|
2. **3D Veri Görselleştirme**: Haritalar, grafikler ve simülasyonlar.
|
||||||
|
3. **Basit Oyunlar**: Oyun motoru olmasa da basit 3D oyunlar oluşturabilirsiniz. (DENEYECEĞİM!!!)
|
||||||
|
4. **VR ve AR Deneyimleri**: WebXR ile sanal ve artırılmış gerçeklik projeleri geliştirmek mümkün.
|
||||||
|
|
||||||
|
### Gelin bir önreğe bakalım
|
||||||
|
|
||||||
|
import \* as THREE from 'three';
|
||||||
|
|
||||||
|
// Sahne oluştur
|
||||||
|
const scene = new THREE.Scene();
|
||||||
|
|
||||||
|
// Kamera ve ışık
|
||||||
|
const camera = new THREE.PerspectiveCamera(75, window.innerWidth / window.innerHeight, 0.1, 1000);
|
||||||
|
camera.position.z = 5;
|
||||||
|
|
||||||
|
// Renderer
|
||||||
|
const renderer = new THREE.WebGLRenderer();
|
||||||
|
renderer.setSize(window.innerWidth, window.innerHeight);
|
||||||
|
document.body.appendChild(renderer.domElement);
|
||||||
|
|
||||||
|
// Geometri ve malzeme
|
||||||
|
const geometry = new THREE.BoxGeometry();
|
||||||
|
const material = new THREE.MeshBasicMaterial({ color: 0x00ff00 });
|
||||||
|
const cube = new THREE.Mesh(geometry, material);
|
||||||
|
|
||||||
|
scene.add(cube);
|
||||||
|
|
||||||
|
// Animasyon
|
||||||
|
function animate() {
|
||||||
|
requestAnimationFrame(animate);
|
||||||
|
cube.rotation.x += 0.01;
|
||||||
|
cube.rotation.y += 0.01;
|
||||||
|
renderer.render(scene, camera);
|
||||||
|
}
|
||||||
|
animate();
|
||||||
|
|
||||||
|
Evet, yukarıdaki kod bir küp çizer ve onu döndürür. **Kodun içine girmekten korkmayın.** Bir kez parçaları anlarsanız LEGO gibi bir araya geliyor.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
### “Tamam Ama Neden Three.js?”
|
||||||
|
|
||||||
|
Öncelikle, tarayıcıda 3D yapmak demek WebGL kullanmak demek. WebGL, ham haliyle biraz karmaşık. Ama Three.js tüm bu karmaşıklığı alıyor, paketliyor ve yazılımcı dostu bir hale getiriyor. Yani otobanda giderken GPS ile yol bulmak gibi!
|
||||||
|
|
||||||
|
### Nereden Başlamalı?
|
||||||
|
|
||||||
|
Başlamak için şu adımları izleyebilirsiniz:
|
||||||
|
|
||||||
|
1. Three.js Dokümantasyonu: Resmi dokümantasyon, her şeyin kapısı.
|
||||||
|
2. YouTube ve Medium: İnanın, topluluk her şeyi sizin için çözmüş.
|
||||||
|
|
||||||
|
### Kendiniz Deneyin!
|
||||||
|
|
||||||
|
Son olarak, deney yapmaktan korkmayın. Küpleri küre yapın, sahneyi ışıklarla doldurun, kamerayı döndürün. Three.js, size hayal gücünüzü ekrana yansıtma şansı tanıyor.
|
||||||
|
|
||||||
|
|
||||||
|
Unutmayın, her devasa proje bir dönmeyle başlayan küple başlar. Şimdi sıra sizde!
|
||||||
|
|
||||||
|
**Not:** Yazıyı hazırlarken birkaç sahne çizdim, şimdi onları biraz daha geliştirmeye gidiyorum. :) Sorularınız varsa yorum bırakabilirsiniz!
|
||||||
@@ -0,0 +1,102 @@
|
|||||||
|
---
|
||||||
|
title: "JSX’den TSX’e Geçiş: Kişisel Bir Deneyim"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-09-17"
|
||||||
|
readTime: "3 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "typescript-ile-javascriptten-tsx-e-ge-i-ki-isel-bir-deneyim"
|
||||||
|
excerpt: "JSX’den TSX’e Geçiş: Kişisel Bir Deneyim Merhaba arkadaşlar! Son zamanlarda JavaScript’ten TypeScript’e geçiş yapmak üzerine yoğun bir şekilde çalışıyorum ve bu süreçte …"
|
||||||
|
coverImage: "/blog/images/typescript-ile-javascriptten-tsx-e-ge-i-ki-isel-bir-deneyim-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/typescript-ile-javascriptten-tsx-e-ge%C3%A7i%C5%9F-ki%C5%9Fisel-bir-deneyim-308bdb14f1d0"
|
||||||
|
---
|
||||||
|
|
||||||
|
# JSX’den TSX’e Geçiş: Kişisel Bir Deneyim
|
||||||
|
|
||||||
|
|
||||||
|
Merhaba arkadaşlar!
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Son zamanlarda JavaScript’ten TypeScript’e geçiş yapmak üzerine yoğun bir şekilde çalışıyorum ve bu süreçte yaşadıklarımı sizlerle paylaşmak istiyorum. TypeScript, JavaScript’in sunduğu dinamik yapının üzerine statik tiplerin eklenmesiyle kod yazım sürecini bir adım ileriye taşıyor. Peki ben neden geçiyorum? Şuan bir ekiple beraber bir proje üzerinde çalışıyoruz. Ve buna karar kaldık. Bu geçişin benim için nasıl bir yolculuk olduğunu anlatmak, belki sizlere de bu konuda yardımcı olabilir.
|
||||||
|
|
||||||
|
## Başlangıç: Neden TypeScript?
|
||||||
|
|
||||||
|
İlk olarak, TypeScript’e geçiş yapma kararımızın arkasında daha sağlam ve hatasız bir kod yazma isteğimiz vardı. JavaScript’te dinamik tipler bazen kafa karıştırıcı olabiliyor ve bu, büyük projelerde hata ayıklama sürecini zorlaştırıyor. TypeScript, bu sorunları çözmek için tip güvenliği ve geliştirilmiş hata ayıklama yetenekleri sunuyor.
|
||||||
|
|
||||||
|
## İlk Adımlar: JS’den TSX’e
|
||||||
|
|
||||||
|
Geçiş süreci, özellikle JSX’ten TSX’e geçerken bazı zorluklar getirdi. İlk başta, tip tanımlamaları ve interface’lerle ilgili kafam karışmadı değil. Ancak, bu süreçte birkaç önemli adım izlemeye başladım:
|
||||||
|
|
||||||
|
1. **Temel Tip Tanımlamaları**: Öncelikle, projedeki temel tipleri tanımlamaya başladım. Bu, özellikle props ve state gibi yapılar için çok faydalı oldu. TypeScript ile, her bir prop ve state’in türünü belirleyerek, olası hataları erkenden yakalayabiliyorum.
|
||||||
|
2. **TSX ile JSX’yi Anlama**: JSX’ten TSX’e geçişte en önemli şeylerden biri, type checking (tip kontrolü) özelliğinden yararlanmak. Bu, bileşenlerin doğru tipteki verilerle çalışıp çalışmadığını kontrol etmeme yardımcı oldu.
|
||||||
|
3. **Gradual Migration (Aşamalı Geçiş)**: Geçiş sürecini bir anda yapmadım. Bunun yerine, projeyi kademeli olarak TypeScript’e taşıdım. Bu sayede, karşılaştığım sorunları daha kolay çözebildim ve büyük değişiklikler yapmadan önce küçük parçalar üzerinde çalışabildim.
|
||||||
|
|
||||||
|
Gelin küçük bir karşılaştırma yapalım.
|
||||||
|
|
||||||
|
## JSX (JavaScript XML)
|
||||||
|
|
||||||
|
JSX, React bileşenlerinde JavaScript kodunu HTML benzeri bir sözdizimi ile yazmamıza olanak tanır. Ancak, JSX’te tip kontrolü yapılmıyor.
|
||||||
|
|
||||||
|
import React from 'react';
|
||||||
|
|
||||||
|
const Greeting = ({ name }) => {
|
||||||
|
return <h1>Hello, {name}!</h1>;
|
||||||
|
};
|
||||||
|
|
||||||
|
export default Greeting;
|
||||||
|
|
||||||
|
## TSX (TypeScript XML)
|
||||||
|
|
||||||
|
TSX ise, JSX’in TypeScript ile birleştirilmiş hali olup, tip kontrolü ve daha iyi hata ayıklama özellikleri sunuyor. Tip güvenliği sağlıyor ve bu, bileşenlerin beklenmedik hatalara karşı korunmasına yardımcı oluyor.
|
||||||
|
|
||||||
|
import React from 'react';
|
||||||
|
|
||||||
|
// Props için TypeScript ile tip tanımlaması
|
||||||
|
interface GreetingProps {
|
||||||
|
name: string;
|
||||||
|
}
|
||||||
|
|
||||||
|
const Greeting: React.FC<GreetingProps\> = ({ name }) => {
|
||||||
|
return <h1>Hello, {name}!</h1>;
|
||||||
|
};
|
||||||
|
|
||||||
|
export default Greeting;
|
||||||
|
|
||||||
|
## Karşılaştırma
|
||||||
|
|
||||||
|
1. **Tip Kontrolü**:
|
||||||
|
|
||||||
|
* JSX: Tip kontrolü yoktur.
|
||||||
|
* TSX: Props ve state için tip tanımlamaları yapılabilir.
|
||||||
|
|
||||||
|
**2\. Geliştirici Deneyimi**:
|
||||||
|
|
||||||
|
* JSX: Kod tamamlama ve hata ayıklama sınırlıdır.
|
||||||
|
* TSX: Daha iyi kod tamamlama ve erken hata tespiti sağlar.
|
||||||
|
|
||||||
|
**3\. Kod Güvenliği**:
|
||||||
|
|
||||||
|
* JSX: Tip hatalarına karşı koruma yoktur.
|
||||||
|
* TSX: Tip hatalarını önlemeye yardımcı olur ve daha güvenli kod sağlar.
|
||||||
|
|
||||||
|
Bu örnekler, JSX ve TSX arasındaki temel farkları gösteriyor sanırım. Kısaca TypeScript kullanarak daha sağlam ve güvenli bir kod yazabilirsiniz arkadaşlar.
|
||||||
|
|
||||||
|
## Yaşadığım Zorluklar
|
||||||
|
|
||||||
|
TypeScript’e geçiş yaparken karşılaştığım bazı zorluklar oldu. En büyük sorunlardan biri, eski JavaScript kodunun TypeScript’e uyumlu hale getirilmesiydi. Özellikle, mevcut kodlarda eksik tip tanımlamaları ve uyumsuzluklar bulmak bazen zaman alabiliyor. Düzeltiyorum, çok zaman alıyor. Ayrıca, bazı kütüphaneler ve araçlar TypeScript ile tam uyumlu olmayabiliyor, bu da ekstra uyum sorunlarına neden olabiliyor. Fakat daha sonra dönüp baktığım zaman bunlara değdini görüyorum.
|
||||||
|
|
||||||
|
## Faydalar
|
||||||
|
|
||||||
|
Ancak, TypeScript’in avantajları bu zorlukları gölgede bırakıyor. İşte bu geçişten elde ettiğim bazı önemli faydalar:
|
||||||
|
|
||||||
|
1. **Daha Güvenli Kod**: TypeScript sayesinde, kodumda hata yapma olasılığım azaldı. Tip güvenliği, hataları daha erken aşamada tespit etmemi sağlıyor.
|
||||||
|
2. **Daha İyi Geliştirici Deneyimi**: TypeScript, editörde daha iyi kod tamamlama ve hata ayıklama araçları sunuyor. Bu, geliştirme sürecimi daha verimli hale getiriyor.
|
||||||
|
3. **Daha Kolay Bakım**: Tip tanımlamaları ve interface’ler, kodun bakımını ve genişletilmesini kolaylaştırıyor. Bu, özellikle büyük projelerde büyük bir avantaj.
|
||||||
|
|
||||||
|
## Sonuç
|
||||||
|
|
||||||
|
TypeScript’e geçiş yapmak, benim için zorlu ama öğretici bir süreç oldu. Bu geçiş, uzun vadede daha sağlam ve sürdürülebilir kod yazmama yardımcı oldu. Eğer siz de JavaScript’ten TypeScript’e geçmeyi düşünüyorsanız, başlangıçta bazı zorluklar yaşayabilirsiniz ama bu çabanın karşılığını eminim uzun vadede göreceksiniz.
|
||||||
|
|
||||||
|
|
||||||
|
Umarım bu yazı, TypeScript’e geçiş yapmayı düşünenler için faydalı olur. Siz de deneyimlerinizi veya sorularınızı paylaşmak isterseniz, yorumlarda buluşalım!
|
||||||
@@ -1,116 +1,134 @@
|
|||||||
---
|
---
|
||||||
title: "UX Tasarımı ve İnsan Psikolojisi"
|
title: "UX Tasarımı ve İnsan Psikolojisi"
|
||||||
category: "UX"
|
category: "General"
|
||||||
date: "2026-02-26"
|
date: "2024-09-23"
|
||||||
readTime: "12 min read"
|
readTime: "8 min read"
|
||||||
author: "Poyraz Avsever"
|
author: "Poyraz Avsever"
|
||||||
excerpt: "UX (Kullanıcı Deneyimi) tasarımı, teknolojiyle etkileşime geçen herkesin deneyimini iyileştirmeye..."
|
slug: "ux-tasar-m-ve-i-nsan-psikolojisi"
|
||||||
coverImage: "https://miro.medium.com/v2/resize:fit:1400/format:webp/0*5OUFz00g3w5ee2lV.jpg"
|
excerpt: "UX Tasarımı ve İnsan Psikolojisi UX (Kullanıcı Deneyimi) tasarımı, teknolojiyle etkileşime geçen herkesin deneyimini iyileştirmeye yönelik bir disiplin. Web siteleri, mobil uygulamalar ve …"
|
||||||
|
coverImage: "/blog/images/ux-tasar-m-ve-i-nsan-psikolojisi-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/ux-tasar%C4%B1m%C4%B1-ve-i%CC%87nsan-psikolojisi-f6570a41ab9b"
|
||||||
---
|
---
|
||||||
|
|
||||||
|
# UX Tasarımı ve İnsan Psikolojisi
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
UX (Kullanıcı Deneyimi) tasarımı, teknolojiyle etkileşime geçen herkesin deneyimini iyileştirmeye yönelik bir disiplin. Web siteleri, mobil uygulamalar ve dijital ürünlerin, kullanıcının ihtiyaçlarını hızlı ve etkili bir şekilde karşılayacak şekilde tasarlanması gerekiyor. İyi bir UX tasarımı, sadece estetik değil, aynı zamanda işlevsellik ve kullanılabilirlik üzerine de yoğunlaşıyor. Bu yazıda, UX tasarımında dikkate alınması gereken temel ilkeleri keşfedeceğiz. Gelin başlayalım.
|
UX (Kullanıcı Deneyimi) tasarımı, teknolojiyle etkileşime geçen herkesin deneyimini iyileştirmeye yönelik bir disiplin. Web siteleri, mobil uygulamalar ve dijital ürünlerin, kullanıcının ihtiyaçlarını hızlı ve etkili bir şekilde karşılayacak şekilde tasarlanması gerekiyor. İyi bir UX tasarımı, sadece estetik değil, aynı zamanda işlevsellik ve kullanılabilirlik üzerine de yoğunlaşıyor. Bu yazıda, UX tasarımında dikkate alınması gereken temel ilkeleri keşfedeceğiz. Gelin başlayalım.
|
||||||
|
|
||||||
|
## 1\. Kullanıcı Merkezli Yaklaşım
|
||||||
## UX Tasarımında Temel İlkeler
|
|
||||||
|
|
||||||
### Kullanıcı Merkezli Yaklaşım
|
|
||||||
|
|
||||||
UX tasarımında en önemli kural, tasarımın tamamen kullanıcıya odaklanmasıdır. Ürün ya da hizmeti kullanacak kişilerin ihtiyaçlarını, beklentilerini ve sorunlarını anlamadan iyi bir kullanıcı deneyimi sunmak imkansızdır. Kullanıcı araştırmaları, anketler ve testler ile kullanıcıların nelerden hoşlandığını ve hangi sorunlarla karşılaştıklarını anlamak bu süreçte kritik rol oynar. Örneğin bir tasarıma başlamadan önce hedef kitlenizle enpati kurun arkadaşlar. Onların yolculuğunu anlamaya çalışın ve ardından tasarıma başlayın.
|
UX tasarımında en önemli kural, tasarımın tamamen kullanıcıya odaklanmasıdır. Ürün ya da hizmeti kullanacak kişilerin ihtiyaçlarını, beklentilerini ve sorunlarını anlamadan iyi bir kullanıcı deneyimi sunmak imkansızdır. Kullanıcı araştırmaları, anketler ve testler ile kullanıcıların nelerden hoşlandığını ve hangi sorunlarla karşılaştıklarını anlamak bu süreçte kritik rol oynar. Örneğin bir tasarıma başlamadan önce hedef kitlenizle enpati kurun arkadaşlar. Onların yolculuğunu anlamaya çalışın ve ardından tasarıma başlayın.
|
||||||
### Basitlik ve Anlaşılırlık
|
|
||||||
|
## 2\. Basitlik ve Anlaşılırlık
|
||||||
|
|
||||||
Basitlik, kullanıcıların hızlıca istedikleri sonuca ulaşmalarını sağlar. Karmaşık arayüzler, kafa karıştırıcı ikonlar ya da gereksiz adımlar kullanıcıyı yavaşlatır ve deneyimi kötüleştirir. İyi bir UX tasarımı, sadece ihtiyaç duyulan özellikleri ön plana çıkararak gereksiz detayları yok etmeli. Yine bir örnek verelim. Kullanıcının hangi işlemleri yerine getirmek istediğine odaklanın. Ve onları en kısa ve kolay yol ile nasıl sağlarım diye düşünün. Elbet bir kaç çıkış yolu bulacaksınız.
|
Basitlik, kullanıcıların hızlıca istedikleri sonuca ulaşmalarını sağlar. Karmaşık arayüzler, kafa karıştırıcı ikonlar ya da gereksiz adımlar kullanıcıyı yavaşlatır ve deneyimi kötüleştirir. İyi bir UX tasarımı, sadece ihtiyaç duyulan özellikleri ön plana çıkararak gereksiz detayları yok etmeli. Yine bir örnek verelim. Kullanıcının hangi işlemleri yerine getirmek istediğine odaklanın. Ve onları en kısa ve kolay yol ile nasıl sağlarım diye düşünün. Elbet bir kaç çıkış yolu bulacaksınız.
|
||||||
### Tutarlılık
|
|
||||||
|
## 3\. Tutarlılık
|
||||||
|
|
||||||
Tutarlılık, kullanıcının arayüzü daha hızlı ve kolay öğrenmesini sağlar. Web sitenizde ya da uygulamanızda butonların, menülerin ve diğer öğelerin tutarlı bir şekilde yerleştirilmesi, kullanıcıya tanıdık bir deneyim sunar. Yani her ikonunuz farklı bir ikon pakettinden olmasın. Ayrıca, farklı sayfalarda aynı etkileşim kalıplarını uygulamak, kullanıcıların rahat bir şekilde gezinti yapmalarını sağlar. Yani elinizden geldiğince tasarımda renk, tipografi ve ikon kullanımlarını koruyarak kullanıcıya bütün halinde bir deneyim sunun. Aksi taktirde kullanıcıyı tasarımınıza yabancılaştırabilirsiniz. Bunu kim ister, değil mi?
|
Tutarlılık, kullanıcının arayüzü daha hızlı ve kolay öğrenmesini sağlar. Web sitenizde ya da uygulamanızda butonların, menülerin ve diğer öğelerin tutarlı bir şekilde yerleştirilmesi, kullanıcıya tanıdık bir deneyim sunar. Yani her ikonunuz farklı bir ikon pakettinden olmasın. Ayrıca, farklı sayfalarda aynı etkileşim kalıplarını uygulamak, kullanıcıların rahat bir şekilde gezinti yapmalarını sağlar. Yani elinizden geldiğince tasarımda renk, tipografi ve ikon kullanımlarını koruyarak kullanıcıya bütün halinde bir deneyim sunun. Aksi taktirde kullanıcıyı tasarımınıza yabancılaştırabilirsiniz. Bunu kim ister, değil mi?
|
||||||
### Erişilebilirlik
|
|
||||||
|
## 4\. Erişilebilirlik
|
||||||
|
|
||||||
İyi bir UX tasarımı, herkes tarafından erişilebilir olmalıdır. Farklı yeteneklere sahip kullanıcıların da ürün ya da hizmetinizi kullanabileceğini düşünmek zorundasınız. Bu, renk körü kullanıcılara uygun renk kontrastları sağlamaktan, ekran okuyucularına uyumlu içerik sunmaya kadar geniş bir alanı kapsar. Bir de buradan örnek verelim. Tasarımda sürekli olarak erişilebilirlik kurallarını takip etmelisiniz. Aynı zamanda ttasarımınızı farklı kullanıcı grupları için test edin.
|
İyi bir UX tasarımı, herkes tarafından erişilebilir olmalıdır. Farklı yeteneklere sahip kullanıcıların da ürün ya da hizmetinizi kullanabileceğini düşünmek zorundasınız. Bu, renk körü kullanıcılara uygun renk kontrastları sağlamaktan, ekran okuyucularına uyumlu içerik sunmaya kadar geniş bir alanı kapsar. Bir de buradan örnek verelim. Tasarımda sürekli olarak erişilebilirlik kurallarını takip etmelisiniz. Aynı zamanda ttasarımınızı farklı kullanıcı grupları için test edin.
|
||||||
### Geri Bildirim ve Etkileşim
|
|
||||||
|
## 5\. Geri Bildirim ve Etkileşim
|
||||||
|
|
||||||
Kullanıcıların yaptıkları her eylemde, ara yüzden bir geri bildirim beklerler. Bir butona tıklamak, formu doldurmak ya da bir işlemi başlatmak gibi eylemlerde ara yüzün kullanıcıyı bilgilendirmesi gerekir. Geri bildirimler, yapılan işlemin başarıyla tamamlandığını ya da bir hata olduğunu gösterir ve bu, kullanıcıya güven verir. Örneğin bir işlemde bekleme süresi varsa, yükleme animasyonu ile kullanıcının beklemesi gerektiğini, arka planda bir işlem olduğunu söylemeniz gerekir. Aksi takdirke kullanıcı ne olduğunu anlayamaz. Ya da bir buton düşünelim. Bu buton kullanıcının gönderi paylaşmasını sağlayan “gönder” butonu olsun. Eğer siz kullanıcı gönder butonuna bastığı zaman bir geribildirim vermezseniz kullanıcı çalışmadığını zannedip defalarca kez butona basabilir. Bu ve bunlar gibi onlarca senaryodan kaçınmak için geri bildirimleri unutmayın!
|
Kullanıcıların yaptıkları her eylemde, ara yüzden bir geri bildirim beklerler. Bir butona tıklamak, formu doldurmak ya da bir işlemi başlatmak gibi eylemlerde ara yüzün kullanıcıyı bilgilendirmesi gerekir. Geri bildirimler, yapılan işlemin başarıyla tamamlandığını ya da bir hata olduğunu gösterir ve bu, kullanıcıya güven verir. Örneğin bir işlemde bekleme süresi varsa, yükleme animasyonu ile kullanıcının beklemesi gerektiğini, arka planda bir işlem olduğunu söylemeniz gerekir. Aksi takdirke kullanıcı ne olduğunu anlayamaz. Ya da bir buton düşünelim. Bu buton kullanıcının gönderi paylaşmasını sağlayan “gönder” butonu olsun. Eğer siz kullanıcı gönder butonuna bastığı zaman bir geribildirim vermezseniz kullanıcı çalışmadığını zannedip defalarca kez butona basabilir. Bu ve bunlar gibi onlarca senaryodan kaçınmak için geri bildirimleri unutmayın!
|
||||||
|
|
||||||

|
|
||||||
|

|
||||||
|
|
||||||
İyi bir UX tasarımının temeli, kullanıcıyı merkeze alarak basit, tutarlı, erişilebilir ve etkileşimli bir deneyim sunmaktır. Bu ilkeleri uygulamak, ürününüzün sadece iyi görünmesini değil, aynı zamanda kullanılabilir ve kullanıcı dostu olmasını sağlar. Unutmayın, başarılı bir UX tasarımı, sadece tasarımın görselliğiyle değil, kullanıcının deneyimiyle ilgilidir. Gelin şimdi biraz daha spesifik konulara inelim.
|
İyi bir UX tasarımının temeli, kullanıcıyı merkeze alarak basit, tutarlı, erişilebilir ve etkileşimli bir deneyim sunmaktır. Bu ilkeleri uygulamak, ürününüzün sadece iyi görünmesini değil, aynı zamanda kullanılabilir ve kullanıcı dostu olmasını sağlar. Unutmayın, başarılı bir UX tasarımı, sadece tasarımın görselliğiyle değil, kullanıcının deneyimiyle ilgilidir. Gelin şimdi biraz daha spesifik konulara inelim.
|
||||||
|
|
||||||
## Renk Psikolojisi ve UX Tasarımı
|
## Renk Psikolojisi ve UX Tasarımı
|
||||||
|
|
||||||

|
|
||||||
|

|
||||||
|
|
||||||
Renkler, kullanıcıların bir ara yüzle nasıl etkileşime gireceğini ve onu nasıl algılayacağını doğrudan etkileyen güçlü bir araçtır. Renk psikolojisi, insanların renkler aracılığıyla duygusal tepkiler verdiğini gösterir. Bu tepkiler kullanıcı deneyimini önemli ölçüde etkileyebilir. İyi bir UX tasarımcısı, renklerin bu etkisini anlamalı ve kullanıcının hislerini, kararlarını ve genel deneyimini olumlu yönde etkileyen renk paletleri seçmelidir. Bakalım bu renkler içimizde nasıl hisler uyandırıyor?
|
Renkler, kullanıcıların bir ara yüzle nasıl etkileşime gireceğini ve onu nasıl algılayacağını doğrudan etkileyen güçlü bir araçtır. Renk psikolojisi, insanların renkler aracılığıyla duygusal tepkiler verdiğini gösterir. Bu tepkiler kullanıcı deneyimini önemli ölçüde etkileyebilir. İyi bir UX tasarımcısı, renklerin bu etkisini anlamalı ve kullanıcının hislerini, kararlarını ve genel deneyimini olumlu yönde etkileyen renk paletleri seçmelidir. Bakalım bu renkler içimizde nasıl hisler uyandırıyor?
|
||||||
|
|
||||||
### Kırmızı: Dikkat Çekici ve Uyarıcı
|
### Kırmızı: Dikkat Çekici ve Uyarıcı
|
||||||
|
|
||||||
Kırmızı renk, genellikle uyarı ya da aciliyet ifade eden durumlarda kullanılır. Hızlı dikkat çekmek, önemli bir eylemi öne çıkarmak ya da tehlike belirten bir uyarı vermek için idealdir. Ancak aşırı kullanımda kullanıcıyı rahatsız edebilir, bu yüzden stratejik olarak kullanılması önemlidir. Örneğin ödeme işlemi gibi kritik adımları vurgulmak ya da hata mesajlarını göstermek için kırmızıyı kullanabilirsin.
|
Kırmızı renk, genellikle uyarı ya da aciliyet ifade eden durumlarda kullanılır. Hızlı dikkat çekmek, önemli bir eylemi öne çıkarmak ya da tehlike belirten bir uyarı vermek için idealdir. Ancak aşırı kullanımda kullanıcıyı rahatsız edebilir, bu yüzden stratejik olarak kullanılması önemlidir. Örneğin ödeme işlemi gibi kritik adımları vurgulmak ya da hata mesajlarını göstermek için kırmızıyı kullanabilirsin.
|
||||||
|
|
||||||
### Yeşil: Doğallık ve Güven
|
### Yeşil: Doğallık ve Güven
|
||||||
|
|
||||||
Yeşil, genellikle doğa, huzur ve güven ile ilişkilendirilir. Aynı zamanda başarılı işlemleri işaret etmek için de yaygın olarak kullanılır. Yeşil renk, kullanıcıya güven ve rahatlık hissi verir, bu yüzden olumlu mesajlar ve işlemlerde tercih edilebilir. Örneğin “tamamlandı” mesajlarında yeşili kullanarak kullanıcıyı pozitif yönde bilgilendirebilirsiniz.
|
Yeşil, genellikle doğa, huzur ve güven ile ilişkilendirilir. Aynı zamanda başarılı işlemleri işaret etmek için de yaygın olarak kullanılır. Yeşil renk, kullanıcıya güven ve rahatlık hissi verir, bu yüzden olumlu mesajlar ve işlemlerde tercih edilebilir. Örneğin “tamamlandı” mesajlarında yeşili kullanarak kullanıcıyı pozitif yönde bilgilendirebilirsiniz.
|
||||||
|
|
||||||
### Mavi: Güven ve Profesyonellik
|
### Mavi: Güven ve Profesyonellik
|
||||||
|
|
||||||
Mavi, güven ve sadakati temsil eden bir renktir. Bu nedenle, bankacılık veya kurumsal siteler gibi güvenin önemli olduğu alanlarda sıklıkla tercih edilir. Aynı zamanda sakinlik ve dinginlik hissi verdiği için kullanıcının yoğun bilgiyle karşılaştığı ara yüzlerde dengeleyici bir unsur olabilir. Örneğin güvenlik işlemlerini, bilgilendirme mesajlarını, ve ya ana butonları vurgulamak için maviyi tercih edebilirsiniz.
|
Mavi, güven ve sadakati temsil eden bir renktir. Bu nedenle, bankacılık veya kurumsal siteler gibi güvenin önemli olduğu alanlarda sıklıkla tercih edilir. Aynı zamanda sakinlik ve dinginlik hissi verdiği için kullanıcının yoğun bilgiyle karşılaştığı ara yüzlerde dengeleyici bir unsur olabilir. Örneğin güvenlik işlemlerini, bilgilendirme mesajlarını, ve ya ana butonları vurgulamak için maviyi tercih edebilirsiniz.
|
||||||
|
|
||||||
### Sarı: Enerji ve Dikkat
|
### Sarı: Enerji ve Dikkat
|
||||||
|
|
||||||
Sarı renk, genellikle enerji, neşe ve iyimserlik hissi uyandırır. Kullanıcının dikkatini çekmek için kullanılabilecek güçlü bir renktir. Ancak çok parlak sarı tonları dikkat dağınıklığına neden olabilir, bu yüzden dikkatli ve dengeli kullanılması gerekir.
|
Sarı renk, genellikle enerji, neşe ve iyimserlik hissi uyandırır. Kullanıcının dikkatini çekmek için kullanılabilecek güçlü bir renktir. Ancak çok parlak sarı tonları dikkat dağınıklığına neden olabilir, bu yüzden dikkatli ve dengeli kullanılması gerekir.
|
||||||
|
|
||||||
### Turuncu: Canlılık ve Hareket
|
### Turuncu: Canlılık ve Hareket
|
||||||
|
|
||||||
Turuncu renk, enerjik ve hareketli bir his uyandırır. Kırmızı gibi dikkat çekici olmasına rağmen, daha sıcak ve davetkar bir ton sunar. Kullanıcının harekete geçmesi gerektiği durumlarda turuncu, iyi bir yönlendirme aracı olabilir. Örneğin kampanya mesajları gibi teşvik edici öğelerde kullanabilirsiniz.
|
Turuncu renk, enerjik ve hareketli bir his uyandırır. Kırmızı gibi dikkat çekici olmasına rağmen, daha sıcak ve davetkar bir ton sunar. Kullanıcının harekete geçmesi gerektiği durumlarda turuncu, iyi bir yönlendirme aracı olabilir. Örneğin kampanya mesajları gibi teşvik edici öğelerde kullanabilirsiniz.
|
||||||
|
|
||||||
### Renklerin Tutarlı Kullanımı
|
**Renklerin Tutarlı Kullanımı**
|
||||||
Renklerin tutarlı bir şekilde kullanılması da kullanıcı deneyimi için önemlidir. Aynı renklerin sürekli olarak benzer işlevler için kullanılması, kullanıcıya bir tür zihinsel model oluşturur ve ara yüzde daha kolay gezinmesini sağlar.
|
Renklerin tutarlı bir şekilde kullanılması da kullanıcı deneyimi için önemlidir. Aynı renklerin sürekli olarak benzer işlevler için kullanılması, kullanıcıya bir tür zihinsel model oluşturur ve ara yüzde daha kolay gezinmesini sağlar.
|
||||||
|
|
||||||
Renklerin daha detaylı incelemek için internete renk teorisi yazarak yalnızca bu konu üzerinde yoğunlaşmış onlarca yazı ve video bulabilirsiniz. Ben UX tasarım üzerinde büyük bir rol oynayan renkleri detaylıca öğrenmenizi tavsiye ediyorum.
|
|
||||||
|
_Renklerin daha detaylı incelemek için internete renk teorisi yazarak yalnızca bu konu üzerinde yoğunlaşmış onlarca yazı ve video bulabilirsiniz. Ben UX tasarım üzerinde büyük bir rol oynayan renkleri detaylıca öğrenmenizi tavsiye ediyorum._
|
||||||
|
|
||||||
## Kullanıcı Alışkanlıkları ve Davranış Kalıpları
|
## Kullanıcı Alışkanlıkları ve Davranış Kalıpları
|
||||||
|
|
||||||

|
|
||||||
|

|
||||||
|
|
||||||
Kullanıcı alışkanlıkları ve davranış kalıpları, başarılı bir UX tasarımının temel taşlarından biridir. İnsanlar dijital ürünlerle etkileşim kurarken belirli bir düzen ve beklenti oluşturur, bu düzen tasarımcıların rehberi olmalıdır. Kullanıcıların nasıl düşündüğünü, nasıl hareket ettiğini ve ürünlerle nasıl etkileşime geçtiğini anlamak, UX tasarımında daha etkili çözümler sunmanı sağlar.
|
Kullanıcı alışkanlıkları ve davranış kalıpları, başarılı bir UX tasarımının temel taşlarından biridir. İnsanlar dijital ürünlerle etkileşim kurarken belirli bir düzen ve beklenti oluşturur, bu düzen tasarımcıların rehberi olmalıdır. Kullanıcıların nasıl düşündüğünü, nasıl hareket ettiğini ve ürünlerle nasıl etkileşime geçtiğini anlamak, UX tasarımında daha etkili çözümler sunmanı sağlar.
|
||||||
|
|
||||||
## F-Tarama Deseni
|
### F-Tarama Deseni
|
||||||
|
|
||||||

|
|
||||||
|

|
||||||
|
|
||||||
Kullanıcılar, genellikle bir sayfayı yukarıdan aşağıya ve soldan sağa doğru tararlar. Bu tarama davranışı, “F-tarama deseni” olarak bilinir ve birçok web sitesinde yaygın bir kullanıcı alışkanlığıdır. Kullanıcılar, ilk olarak sayfanın üst kısmına (başlık ve menü), ardından sol tarafa ve sayfanın en önemli kısımlarına dikkat ederler. Bu, bilgiyi en etkili şekilde sunmak ve kullanıcıların dikkatini çekmek için kullanabileceğiniz bir tasarım stratejisidir. Örneğin en önemli içerikleri ve eylemleri (CTA) sayfanın üst kısmında ve sol tarafa yakın konumlandırarak kullanıcıları doğru yönlendirebilirisiniz.
|
Kullanıcılar, genellikle bir sayfayı yukarıdan aşağıya ve soldan sağa doğru tararlar. Bu tarama davranışı, “F-tarama deseni” olarak bilinir ve birçok web sitesinde yaygın bir kullanıcı alışkanlığıdır. Kullanıcılar, ilk olarak sayfanın üst kısmına (başlık ve menü), ardından sol tarafa ve sayfanın en önemli kısımlarına dikkat ederler. Bu, bilgiyi en etkili şekilde sunmak ve kullanıcıların dikkatini çekmek için kullanabileceğiniz bir tasarım stratejisidir. Örneğin en önemli içerikleri ve eylemleri (CTA) sayfanın üst kısmında ve sol tarafa yakın konumlandırarak kullanıcıları doğru yönlendirebilirisiniz.
|
||||||
|
|
||||||
## Zihinsel Modeller ve Beklentiler
|
### Zihinsel Modeller ve Beklentiler
|
||||||
|
|
||||||
Kullanıcılar, daha önce deneyimledikleri benzer sistemlere dayanarak zihinsel modeller oluştururlar. Örneğin, bir e-ticaret sitesinde “sepet” ikonunu görmek, kullanıcının bir ürünü alışverişe ekleyebileceğini gösterir. Bu tür zihinsel modeller, kullanıcının ürününüzü nasıl kullanacağını ve ne bekleyeceğini tahmin eder. En basit tabirle kullanıcıların alışık olduğu ve rahat ettikleri kalıpları göz önünde bulundurarak, tanıdık ikonlar, yapılandırmalar ve etkileşimlerle tasarımınızı destekleyin.
|
Kullanıcılar, daha önce deneyimledikleri benzer sistemlere dayanarak zihinsel modeller oluştururlar. Örneğin, bir e-ticaret sitesinde “sepet” ikonunu görmek, kullanıcının bir ürünü alışverişe ekleyebileceğini gösterir. Bu tür zihinsel modeller, kullanıcının ürününüzü nasıl kullanacağını ve ne bekleyeceğini tahmin eder. En basit tabirle kullanıcıların alışık olduğu ve rahat ettikleri kalıpları göz önünde bulundurarak, tanıdık ikonlar, yapılandırmalar ve etkileşimlerle tasarımınızı destekleyin.
|
||||||
|
|
||||||
## Bilgilere Hızlı Ulaşma İsteği
|
### Bilgilere Hızlı Ulaşma İsteği
|
||||||
|
|
||||||
Kullanıcılar dijital ortamda hızlı bilgi edinme eğilimindedir. Özellikle mobil cihazlarda gezinirken, bilgiye çabuk ve zahmetsiz bir şekilde ulaşmak isterler. Karmaşık bir navigasyon, yavaş yüklenen sayfalar ya da çok fazla tıklama gerektiren işlemler, kullanıcıyı yavaşlatır ve bu da memnuniyetsizlik yaratır. Peki ne yapmalısınız? Ara yüzünüzdeki gereksiz adımları ve karmaşıklığı ortadan kaldırmalı, kullanıcının ihtiyaç duyduğu bilgilere hızlıca ulaşmasını sağlayan basit ve sade bir yapı oluşturmalısınız.
|
Kullanıcılar dijital ortamda hızlı bilgi edinme eğilimindedir. Özellikle mobil cihazlarda gezinirken, bilgiye çabuk ve zahmetsiz bir şekilde ulaşmak isterler. Karmaşık bir navigasyon, yavaş yüklenen sayfalar ya da çok fazla tıklama gerektiren işlemler, kullanıcıyı yavaşlatır ve bu da memnuniyetsizlik yaratır. Peki ne yapmalısınız? Ara yüzünüzdeki gereksiz adımları ve karmaşıklığı ortadan kaldırmalı, kullanıcının ihtiyaç duyduğu bilgilere hızlıca ulaşmasını sağlayan basit ve sade bir yapı oluşturmalısınız.
|
||||||
|
|
||||||
## Eylem ve Sonuç İlişkisi
|
### Eylem ve Sonuç İlişkisi
|
||||||
|
|
||||||
Kullanıcılar, yaptıkları eylemlerin sonucunu hemen görmek isterler. Örneğin, bir form doldurulduğunda “gönder” butonuna basıldığında hemen bir geri bildirim beklerler. Eğer bir eylem gerçekleşmezse ya da geri bildirim gecikirse, kullanıcılar karışıklık ya da hayal kırıklığı yaşayabilirler. Kullanıcıların yaptıkları işlemlerin sonucunu anında bildiren geri bildirim mekanizmaları (yükleme animasyonları, başarı/hata mesajları) ekleyerek kullanıcıyı her aşamada bilgilendirin.
|
Kullanıcılar, yaptıkları eylemlerin sonucunu hemen görmek isterler. Örneğin, bir form doldurulduğunda “gönder” butonuna basıldığında hemen bir geri bildirim beklerler. Eğer bir eylem gerçekleşmezse ya da geri bildirim gecikirse, kullanıcılar karışıklık ya da hayal kırıklığı yaşayabilirler. Kullanıcıların yaptıkları işlemlerin sonucunu anında bildiren geri bildirim mekanizmaları (yükleme animasyonları, başarı/hata mesajları) ekleyerek kullanıcıyı her aşamada bilgilendirin.
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Kullanıcıların dijital ürünlerle etkileşim kurarken geliştirdiği alışkanlıkları ve davranış kalıplarını anlamak, onların beklentilerini karşılayan etkili UX tasarımları oluşturmanın anahtarıdır. Kullanıcı deneyimini geliştirmek için F-tarama deseni, zihinsel modeller ve hızlı bilgi edinme eğilimini göz önünde bulundurmalısın. Bu tür alışkanlıkları ve davranışları dikkate alan bir tasarım, kullanıcıyı ürünle daha uyumlu bir şekilde buluşturur.
|
_Kullanıcıların dijital ürünlerle etkileşim kurarken geliştirdiği alışkanlıkları ve davranış kalıplarını anlamak, onların beklentilerini karşılayan etkili UX tasarımları oluşturmanın anahtarıdır. Kullanıcı deneyimini geliştirmek için F-tarama deseni, zihinsel modeller ve hızlı bilgi edinme eğilimini göz önünde bulundurmalısın. Bu tür alışkanlıkları ve davranışları dikkate alan bir tasarım, kullanıcıyı ürünle daha uyumlu bir şekilde buluşturur._
|
||||||
|
|
||||||
## Duygusal Tasarım (Emotional Design)
|
## Duygusal Tasarım (Emotional Design)
|
||||||
|
|
||||||

|

|
||||||
|
|
||||||
Kullanıcı deneyimi (UX) tasarımında, duygusal tasarım, sadece işlevselliği değil, aynı zamanda kullanıcıların hislerini ve duygusal tepkilerini de dikkate alır. İnsanlar yalnızca mantıksal kararlar vermezler; duyguları da karar alma süreçlerinde önemli bir rol oynar. Bu nedenle, tasarımın hem kullanışlı hem de duygusal bir bağ kurabilen bir yapıya sahip olması, kullanıcıların ürünle daha derin ve kalıcı bir etkileşim kurmalarını sağlar.
|
Kullanıcı deneyimi (UX) tasarımında, duygusal tasarım, sadece işlevselliği değil, aynı zamanda kullanıcıların hislerini ve duygusal tepkilerini de dikkate alır. İnsanlar yalnızca mantıksal kararlar vermezler; duyguları da karar alma süreçlerinde önemli bir rol oynar. Bu nedenle, tasarımın hem kullanışlı hem de duygusal bir bağ kurabilen bir yapıya sahip olması, kullanıcıların ürünle daha derin ve kalıcı bir etkileşim kurmalarını sağlar.
|
||||||
|
|
||||||
## Duyguların UX’teki Rolü
|
### Duyguların UX’teki Rolü
|
||||||
|
|
||||||
Kullanıcıların bir ürünle olan etkileşimleri sırasında hissettikleri duygular, ürün hakkındaki genel düşüncelerini ve bağlılıklarını doğrudan etkiler. İyi bir duygusal tasarım, kullanıcıyı mutlu edebilir, güvende hissettirebilir veya onu motive edebilir. Öte yandan, kötü bir duygusal deneyim, kullanıcıyı hayal kırıklığına uğratabilir ve bu da üründen vazgeçmesine neden olabilir. Ne yapacağız peki? Kullanıcının belirli bir noktada nasıl hissetmesini istediğinizi düşünün. Örneğin, bir satın alma işlemi sırasında kullanıcıya güven vermek için samimi ve açık bir dil kullanabilir, işlemin sonunda “Teşekkürler, harika bir seçim yaptınız!” gibi mesajlarla kullanıcıyı memnun edebilirsiniz.
|
Kullanıcıların bir ürünle olan etkileşimleri sırasında hissettikleri duygular, ürün hakkındaki genel düşüncelerini ve bağlılıklarını doğrudan etkiler. İyi bir duygusal tasarım, kullanıcıyı mutlu edebilir, güvende hissettirebilir veya onu motive edebilir. Öte yandan, kötü bir duygusal deneyim, kullanıcıyı hayal kırıklığına uğratabilir ve bu da üründen vazgeçmesine neden olabilir. Ne yapacağız peki? Kullanıcının belirli bir noktada nasıl hissetmesini istediğinizi düşünün. Örneğin, bir satın alma işlemi sırasında kullanıcıya güven vermek için samimi ve açık bir dil kullanabilir, işlemin sonunda “Teşekkürler, harika bir seçim yaptınız!” gibi mesajlarla kullanıcıyı memnun edebilirsiniz.
|
||||||
|
|
||||||
## Norman’ın Duygusal Tasarım Teorisi
|
### Norman’ın Duygusal Tasarım Teorisi
|
||||||
|
|
||||||
Gelin üst tarafta ki fotoğrafın ne olduğuna bakalım. Duygusal tasarım teorisinin öncülerinden olan Don Norman, insanların ürünlerle olan etkileşimlerinde üç farklı düzeyde tepki verdiklerini öne sürer: içgüdüsel (visceral), davranışsal (behavioral) ve yansıtıcı (reflective) tepkiler.
|
Gelin üst tarafta ki fotoğrafın ne olduğuna bakalım. Duygusal tasarım teorisinin öncülerinden olan Don Norman, insanların ürünlerle olan etkileşimlerinde üç farklı düzeyde tepki verdiklerini öne sürer: içgüdüsel (visceral), davranışsal (behavioral) ve yansıtıcı (reflective) tepkiler.
|
||||||
|
|
||||||
- İçgüdüsel Düzey (Visceral): Kullanıcının ilk bakışta verdiği tepkidir. Ürünün görünüşü, renkleri ve şekli kullanıcıda hızlı bir duygusal tepki uyandırır. Tasarımın estetiği ve görsel unsurları bu aşamada önemlidir.
|
1. **İçgüdüsel Düzey (Visceral)**: Kullanıcının ilk bakışta verdiği tepkidir. Ürünün görünüşü, renkleri ve şekli kullanıcıda hızlı bir duygusal tepki uyandırır. Tasarımın estetiği ve görsel unsurları bu aşamada önemlidir.
|
||||||
- Davranışsal Düzey (Behavioral): Ürünün kullanım kolaylığı ve işlevselliği ile ilgilidir. Kullanıcı, ürünü kullanırken ne kadar rahat hissettiğini değerlendirir. Bu, kullanıcının arayüzde gezinirken ne kadar rahat olduğuna ve ürünün işlevselliğine dayanır.
|
2. **Davranışsal Düzey (Behavioral)**: Ürünün kullanım kolaylığı ve işlevselliği ile ilgilidir. Kullanıcı, ürünü kullanırken ne kadar rahat hissettiğini değerlendirir. Bu, kullanıcının arayüzde gezinirken ne kadar rahat olduğuna ve ürünün işlevselliğine dayanır.
|
||||||
- Yansıtıcı Düzey (Reflective): Kullanıcının ürünü kullandıktan sonra verdiği bilinçli tepkiyi içerir. Kullanıcı, ürün hakkında ne düşündüğünü ve nasıl hissettiğini sorgular. Bu aşamada, kullanıcı ürünü bir bütün olarak değerlendirir ve bu ürünle uzun vadeli bir bağ kurup kurmayacağını belirler.
|
3. **Yansıtıcı Düzey (Reflective)**: Kullanıcının ürünü kullandıktan sonra verdiği bilinçli tepkiyi içerir. Kullanıcı, ürün hakkında ne düşündüğünü ve nasıl hissettiğini sorgular. Bu aşamada, kullanıcı ürünü bir bütün olarak değerlendirir ve bu ürünle uzun vadeli bir bağ kurup kurmayacağını belirler.
|
||||||
|
|
||||||
Öneri: Tasarımınızın bu üç düzeyde de kullanıcıya hitap ettiğinden emin olun. Görsel açıdan etkileyici, işlevsel açıdan kullanıcı dostu ve genel olarak pozitif bir deneyim sunan bir ara yüz oluşturun.
|
**Öneri**: Tasarımınızın bu üç düzeyde de kullanıcıya hitap ettiğinden emin olun. Görsel açıdan etkileyici, işlevsel açıdan kullanıcı dostu ve genel olarak pozitif bir deneyim sunan bir ara yüz oluşturun.
|
||||||
|
|
||||||

|
|
||||||
|
|
||||||
## Görsel ve Metinsel İletişimin Duygusal Etkisi
|

|
||||||
|
|
||||||
|
### Görsel ve Metinsel İletişimin Duygusal Etkisi
|
||||||
|
|
||||||
Görseller ve metinler, kullanıcıda duygusal bir etki yaratmanın en güçlü yollarından biridir. Renkler, yazı tipleri, ikonlar ve görseller kullanıcının duygusal tepkilerini şekillendirir. Aynı zamanda, kullanılan dil de kullanıcıyla duygusal bir bağ kurmanın bir başka önemli aracıdır. Dostane ve samimi bir dil, kullanıcının kendini daha rahat ve güvende hissetmesini sağlar. Yine birkaç tavsiye vermek istiyorum. Tasarımınızda ilham verici, güven veren ya da eğlenceli bir dil kullanarak kullanıcıyı daha iyi hissettirebilirsiniz. Ayrıca görsellerde insan yüzleri, gülen ifadeler gibi pozitif imgeler kullanarak kullanıcıların daha samimi bir bağ kurmasını sağlayabilirsiniz.
|
Görseller ve metinler, kullanıcıda duygusal bir etki yaratmanın en güçlü yollarından biridir. Renkler, yazı tipleri, ikonlar ve görseller kullanıcının duygusal tepkilerini şekillendirir. Aynı zamanda, kullanılan dil de kullanıcıyla duygusal bir bağ kurmanın bir başka önemli aracıdır. Dostane ve samimi bir dil, kullanıcının kendini daha rahat ve güvende hissetmesini sağlar. Yine birkaç tavsiye vermek istiyorum. Tasarımınızda ilham verici, güven veren ya da eğlenceli bir dil kullanarak kullanıcıyı daha iyi hissettirebilirsiniz. Ayrıca görsellerde insan yüzleri, gülen ifadeler gibi pozitif imgeler kullanarak kullanıcıların daha samimi bir bağ kurmasını sağlayabilirsiniz.
|
||||||
|
|
||||||
@@ -124,4 +142,4 @@ Unutma, iyi bir kullanıcı deneyimi tasarımı, sadece bir ürünün kullanıla
|
|||||||
|
|
||||||
> Tasarım sadece bir iş değil, bir hikaye anlatmaktır. Bu hikayede kullanıcıyı başrole koyduğun sürece başarıya ulaşman kaçınılmazdır.
|
> Tasarım sadece bir iş değil, bir hikaye anlatmaktır. Bu hikayede kullanıcıyı başrole koyduğun sürece başarıya ulaşman kaçınılmazdır.
|
||||||
|
|
||||||
Okuduğunuz için teşekkür ederim. İyi tasarımlar!
|
### Okuduğunuz için teşekkür ederim. İyi tasarımlar!
|
||||||
@@ -0,0 +1,93 @@
|
|||||||
|
---
|
||||||
|
title: "Webpack vs Vite: Frontend Projelerinde Build Araçları Karşılaştırması"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-10-04"
|
||||||
|
readTime: "4 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "webpack-vs-vite-frontend-projelerinde-build-ara-lar-kar-la-t-rmas"
|
||||||
|
excerpt: "Webpack vs Vite: Frontend Projelerinde Build Araçları Karşılaştırması Frontend geliştirme dünyası oldukça dinamik ve her gün yeni araçlar ortaya çıkıyor. Projeler büyüdükçe …"
|
||||||
|
coverImage: "/blog/images/webpack-vs-vite-frontend-projelerinde-build-ara-lar-kar-la-t-rmas-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/webpack-vs-vite-frontend-projelerinde-build-ara%C3%A7lar%C4%B1-kar%C5%9F%C4%B1la%C5%9Ft%C4%B1rmas%C4%B1-fb8f24c4d095"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Webpack vs Vite: Frontend Projelerinde Build Araçları Karşılaştırması
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Frontend geliştirme dünyası oldukça dinamik ve her gün yeni araçlar ortaya çıkıyor. Projeler büyüdükçe, kodlarımızı derlemek ve sunmak da bir o kadar karmaşık hale geliyor. İşte burada build araçları devreye giriyor! Bu araçlar, kodunuzu optimize edip tarayıcıya hızlı bir şekilde sunmanızı sağlıyor.
|
||||||
|
|
||||||
|
Bugün, Webpack ve Vite adında iki popüler build aracını ele alacağız. Açıkçası ben de bu iki aracı daha yeni karşılaştıracak kadar deneyimledim. Gelin bakalım neler deneyimlemişim? Webpack, uzun yıllardır sektörde kendine sağlam bir yer edinmişken, Vite son zamanlarda hızla popülerlik kazanıyor. Peki, bu iki aracın arasında ne gibi farklar var? Hangi durumda hangisini kullanmalısınız? Merak etmeyin, bu yazıda bu sorulara cevap arayacağız!
|
||||||
|
|
||||||
|
Hadi başlayalım!
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Webpack Nedir?
|
||||||
|
|
||||||
|
Webpack, özellikle büyük ve karmaşık projeler için tasarlanmış güçlü bir modül paketleyicisidir. JavaScript, CSS, resimler gibi farklı dosya türlerini bir araya getirip optimize ederek tek bir dosya haline getirebilir. Ayrıca, eklentileri ve yükleyicileri sayesinde projeye özel ihtiyaçları karşılamak için oldukça esneklik sunar. Webpack’in popülaritesi, onun özelleştirilebilirliğinden geliyor; ama bu da beraberinde öğrenme eğrisini getiriyor. İlk başta biraz karmaşık görünebilir, ama bir kez öğrendiğinizde, projelerinizi daha verimli bir şekilde yönetebilirsiniz.
|
||||||
|
|
||||||
|
### Avantajları:
|
||||||
|
|
||||||
|
* **Esneklik:** Projeye özel yapılandırma seçenekleri ile oldukça özelleştirilebilir.
|
||||||
|
* **Eklenti Desteği:** Birçok eklenti ile işlevselliğini artırabilirsiniz.
|
||||||
|
* **Kapsamlı Topluluk:** Geniş bir kullanıcı tabanına sahip, bu nedenle sorunlarınıza çözüm bulmak genelde kolaydır.
|
||||||
|
|
||||||
|
### Dezavantajları:
|
||||||
|
|
||||||
|
* **Öğrenme Eğrisi:** Başlangıçta biraz karmaşık gelebilir ve doğru yapılandırmayı bulmak zaman alabilir.
|
||||||
|
* **Geliştirme Süresi:** Yapılandırma süresi, küçük projelerde zaman kaybına neden olabilir.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Vite Nedir?
|
||||||
|
|
||||||
|
Vite, daha hızlı bir geliştirme deneyimi sunmak için tasarlanmış modern bir build aracıdır. Geliştiricilere, anlık olarak değişikliklerinizi görebileceğiniz bir ortam sunar. Vite, ES modüllerini kullanarak yalnızca ihtiyaç duyulan modülleri yükler, bu da geliştirme sürecini oldukça hızlandırır. Ayrıca, Vite ile projelerinizi kurmak çok daha basit ve hızlı!
|
||||||
|
|
||||||
|
### Avantajları:
|
||||||
|
|
||||||
|
* **Hızlı Başlangıç:** Hızlı bir şekilde projeye başlamak ve çalıştırmak için mükemmel bir seçenek.
|
||||||
|
* **Anlık Güncellemeler:** Değişikliklerinizin anında yansıtılması, geliştirme sürecini keyifli hale getirir.
|
||||||
|
* **Basit Yapılandırma:** Minimal yapılandırma gereksinimi, yeni başlayanlar için büyük bir avantaj.
|
||||||
|
|
||||||
|
### Dezavantajları:
|
||||||
|
|
||||||
|
* **Kısıtlı Eklenti Desteği:** Webpack kadar geniş bir eklenti desteğine sahip değil, ancak zamanla bu durum değişiyor.
|
||||||
|
* **Karmaşık Projelerde Sınırlı:** Daha karmaşık yapılandırmalar gerektiren projelerde bazı zorluklar yaşanabilir.
|
||||||
|
|
||||||
|
## Hangi Durumda Hangi Araç?
|
||||||
|
|
||||||
|
* **Yeni Başlayanlar:** Eğer yeni bir projeye başlıyorsanız ve hızlı bir şekilde ilerlemek istiyorsanız, Vite sizin için harika bir seçim. Minimal yapılandırma ve hızlı geliştirme ortamı ile zaman kaybını önler.
|
||||||
|
* **Büyük ve Karmaşık Projeler:** Eğer daha büyük, karmaşık bir projede çalışıyorsanız ve özelleştirme ihtiyaçlarınız varsa, Webpack daha uygun bir seçenek olabilir. Bir kez kurulduğunda, sağladığı esneklik oldukça faydalıdır.
|
||||||
|
* **Hız ve Verimlilik:** Geliştirme sürecinin hızını önemsiyorsanız, Vite’in sunduğu anlık güncellemeler ile iş akışınızı daha akıcı hale getirebilirsiniz.
|
||||||
|
|
||||||
|
## Sonuç
|
||||||
|
|
||||||
|
Sonuç olarak, Webpack ve Vite, frontend geliştirme süreçlerinde farklı ihtiyaçlara hitap eden güçlü araçlardır. Webpack, esnekliği ve özelleştirilebilirliği ile büyük projelerde avantaj sağlarken, Vite, hız ve basitlik arayan geliştiricilere mükemmel bir deneyim sunar.
|
||||||
|
|
||||||
|
|
||||||
|
Eğer projeniz karmaşık yapıda değilse ve hızlı bir başlangıç arıyorsanız, Vite ile yola çıkmak iyi bir seçim olacaktır. Öte yandan, daha kapsamlı bir projeye girişiyorsanız, Webpack’in sunduğu geniş özellikler ve eklentiler ile işinizi kolaylaştırabilirsiniz.
|
||||||
|
|
||||||
|
En nihayetinde, hangi aracı seçeceğiniz, projenizin gereksinimlerine ve kişisel tercihinize bağlı. Her iki araç da frontend geliştirme dünyasında kendine özgü bir yer edindi ve ihtiyaçlarınıza uygun olanı seçerek, projelerinizi daha verimli bir şekilde yönetebilirsiniz.
|
||||||
|
|
||||||
|
Umuyorum ki bu yazı, hangi build aracını seçeceğinize karar vermenize yardımcı olmuştur. Hangi aracı kullandığınızdan bağımsız olarak, keyifli geliştirme süreçleri dilerim!
|
||||||
|
|
||||||
|
## Kaynaklar
|
||||||
|
|
||||||
|
1. **Webpack Resmi Dokümantasyonu**
|
||||||
|
Webpack hakkında detaylı bilgi ve yapılandırma seçenekleri için resmi dokümantasyonu ziyaret edebilirsiniz.
|
||||||
|
[https://webpack.js.org/concepts/](https://webpack.js.org/concepts/)
|
||||||
|
2. **Vite Resmi Dokümantasyonu**
|
||||||
|
Vite’in nasıl kurulacağı ve kullanılacağı hakkında ayrıntılı bilgiler için resmi web sitesine göz atın.
|
||||||
|
[https://vitejs.dev/guide/](https://vitejs.dev/guide/)
|
||||||
|
3. **“Webpack vs. Vite: Which Build Tool Is Right for You?” — Smashing Magazine**
|
||||||
|
Bu makalede, Webpack ve Vite arasındaki karşılaştırmalar daha derinlemesine ele alınmaktadır.
|
||||||
|
[https://smashingtips.com/programming/webpack-vs-vite-choosing-right-build-tool-for-your-next-web-project/](https://smashingtips.com/programming/webpack-vs-vite-choosing-right-build-tool-for-your-next-web-project/)
|
||||||
|
4. **YouTube — Vite Crash Course**
|
||||||
|
Vite ile hızlı bir başlangıç yapmak için bu YouTube videosunu izleyebilirsiniz.
|
||||||
|
[https://www.youtube.com/watch?v=89NJdbYTgJ8](https://www.youtube.com/watch?v=89NJdbYTgJ8)
|
||||||
|
5. **“The Complete Guide to Webpack” —Traversy Media**
|
||||||
|
Webpack’in derinlemesine incelendiği bu kaynak, yeni başlayanlar için faydalı olabilir.
|
||||||
|
[https://www.youtube.com/watch?v=IZGNcSuwBZs](https://www.youtube.com/watch?v=IZGNcSuwBZs)
|
||||||
@@ -0,0 +1,70 @@
|
|||||||
|
---
|
||||||
|
title: "Yazılım Dünyasında Hitabet Sanatının Gücü: İletişimin Yazılım Dünyasına e-Etkisi"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-10-15"
|
||||||
|
readTime: "5 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "yaz-l-m-d-nyas-nda-hitabet-sanat-n-n-g-c-i-leti-imin-yaz-l-m-d-nyas-na-e-etkisi"
|
||||||
|
excerpt: "Yazılım Dünyasında Hitabet Sanatının Gücü: İletişimin Yazılım Dünyasına e-Etkisi Yazılım geliştiricileri genellikle teknik becerileriyle tanınır, ancak etkili iletişim ve …"
|
||||||
|
coverImage: "/blog/images/yaz-l-m-d-nyas-nda-hitabet-sanat-n-n-g-c-i-leti-imin-yaz-l-m-d-nyas-na-e-etkisi-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/yaz%C4%B1l%C4%B1m-d%C3%BCnyas%C4%B1nda-hitabet-sanat%C4%B1n%C4%B1n-g%C3%BCc%C3%BC-i%CC%87leti%C5%9Fimin-yaz%C4%B1l%C4%B1m-d%C3%BCnyas%C4%B1na-e-etkisi-a1a1bbcf6db6"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Yazılım Dünyasında Hitabet Sanatının Gücü: İletişimin Yazılım Dünyasına e-Etkisi
|
||||||
|
|
||||||
|
|
||||||
|
Yazılım geliştiricileri genellikle teknik becerileriyle tanınır, ancak etkili iletişim ve müzakere becerileri de başarı için hayati önem taşır. Son zamanlarda okulumda “Münazara ve Hitabet” kulübünü kurmak ile uğraşıyorum. Okulum teknik bir okul olduğu için bu tarz etkinliklere “mühendis” adayı arkadaşlarım “ne gerek var ki?” gözü ile bakıyorlar. Bende bu yazımda, yazılım dünyasında hitabetin neden önemli olduğunu, projelerde nasıl fark yaratabileceğini ve geliştiricilerin kendilerini nasıl daha iyi ifade edebileceğini ele alacağım.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 1\. Takım İçi İletişimin Önemi:
|
||||||
|
|
||||||
|
Yazılım projelerinde ekipler, genellikle farklı disiplinlerden gelen kişilerden oluşur. Frontend, backend, UI/UX, proje yöneticileri ve diğer roller arasında sağlıklı bir iletişim kurulmadığında, projenin ilerlemesi aksayabilir. Hitabet yeteneği burada devreye girer. Basit bir örnek düşünelim. Bir frontend developer hem backend dev. ile hem de uı/ux designer ile beraber çalışır. Frontend developerın iletişim yeteneği ne kadar yeterli olursa süreçte o kadar hızlanır ve verimli hale gelir. Gelin beraber bir kaç başlığa göz atalım.
|
||||||
|
|
||||||
|
* **Sorunları Etkili Bir Şekilde Tartışma**: Takım içinde teknik kararlar alınırken, karmaşık konular herkesin anlayacağı bir şekilde tartışılmalıdır. Herkesin bir fikri olduğu zaman, çatışmalar kaçınılmazdır. İyi bir hitabet, bu fikirleri hem açık hem de yapıcı bir şekilde ortaya koymayı sağlar.
|
||||||
|
* **Örnek**: Bir ekipte yazılım mimarisinin nasıl olacağı üzerine bir tartışma olduğunu düşün. Biri mikro servis mimarisini savunurken, diğeri monolitik yapının daha uygun olacağını düşünür. Burada sadece teknik argümanlar değil, bu argümanları ne kadar etkili ve ikna edici sunduğunuz da kararı etkileyebilir.
|
||||||
|
* **Empati ve Aktif Dinleme**: İletişim sadece konuşmakla bitmez; takım üyelerinin ne söylediğini anlamak ve onların bakış açısını dikkate almak da önemlidir. Aktif dinleme, ekip içindeki güveni artırır ve daha etkili çözümler bulunmasına katkı sağlar.
|
||||||
|
* **Strateji**: Teknik tartışmalarda diğerlerinin argümanlarını tam olarak anladığınızı göstermek, karşı tarafın güvenini kazanmanıza yardımcı olabilir. “Anladığım kadarıyla, sen X teknolojisinin Y soruna uygun olduğunu düşünüyorsun. Peki Z hakkında ne düşünüyorsun?” gibi ifadeler kullanarak tartışmaları olumlu bir yöne çevirebilirsiniz.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 2\. Müşteri ile İletişim:
|
||||||
|
|
||||||
|
Yazılımcılar, genellikle sadece teknik problemlerle değil, aynı zamanda müşteri isteklerini anlamak ve doğru çözümler sunmakla da uğraşırlar. Müşteri iletişiminde hitabet sanatı, teknik detayların anlaşılır bir şekilde aktarılması ve karşı tarafı ikna etmek için hayati bir beceridir.
|
||||||
|
|
||||||
|
* **Karmaşık Terimlerin Sadeleştirilmesi**: Müşteriler, çoğu zaman teknik detaylara hakim değildir. Teknik bir konuyu çok fazla detaya girmeden anlatabilmek, müşteriyle sağlıklı bir ilişki kurmanın anahtarıdır. Yazılım dünyasında karşılaşılan sorunları çözebilmek için bu durumu etkili bir şekilde açıklayabilmek, projelerin başarıya ulaşmasına katkı sağlar.
|
||||||
|
* **Örnek**: Müşteri, API entegrasyonu hakkında bir şeyler soruyor. Onlara teknik terimlerle dolu bir cevap yerine, API’nin işlevini günlük hayattan bir örnekle açıklamak, müşterinin projeye olan güvenini artıracaktır: “API, farklı yazılımlar arasında köprü kuran bir sistemdir. Örneğin, bir uygulama üzerinden bir bankadan bilgi almak gibi.”
|
||||||
|
* **Beklentilerin Yönetimi**: Müşteriler genellikle hızlı sonuçlar görmek ister. Ancak her zaman istekleri karşılamak mümkün olmayabilir. Burada etkili iletişim ve hitabet becerileri, müşteri beklentilerini gerçekçi bir şekilde yönetmeyi sağlar.
|
||||||
|
* **Strateji**: Müşteriye doğrudan “Bunu yapamayız” demek yerine, “Bu aşamada X sorunu çözebiliriz, ancak Y özelliği daha fazla zaman gerektiriyor, bunu sonraki aşamaya bırakabiliriz” demek, hem daha olumlu bir algı yaratır hem de süreci kontrol altına almanızı sağlar.
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 3\. Sunum ve Paylaşım Kültürü:
|
||||||
|
|
||||||
|
Teknik bilgiyi aktarmak, özellikle karmaşık projelerde veya toplantılarda önemli bir beceridir. İyi bir hitabet, yazılım dünyasında teknik bilginin doğru anlaşılmasını sağlayarak projelere yön verebilir.
|
||||||
|
|
||||||
|
* **Etkili Sunum Teknikleri**: Yazılımcılar sadece kod yazmakla kalmaz; teknik çözüm önerilerini ekiplere veya müşterilere sunmaları gerekir. Bu noktada, anlaşılır ve ikna edici bir sunum yapmak önemlidir. PowerPoint gibi araçlar teknik bilgileri görselleştirmek için etkili olabilir, ancak sunumda kullanılan dil de en az görseller kadar önemlidir.
|
||||||
|
* **Öneri**: Karmaşık teknik çözümleri anlatırken basit dil kullanmak, hem takım arkadaşlarının hem de müşterilerin sizi daha iyi anlamasını sağlar. Kendi projende öğrendiğin bir çözümü kısa ve anlaşılır bir şekilde sunabilir ve ardından soruları alarak detaylandırabilirsin.
|
||||||
|
* **Paylaşım Kültürünün Geliştirilmesi**: Yazılım ekiplerinde bilgi paylaşımı, takımın genel başarısını artırır. Eğer bir yazılımcı olarak öğrendiğiniz yeni bir teknolojiyi veya çözümü paylaşmazsanız, ekipte bilgi asimetrisi oluşabilir. Hitabet sanatı burada, bilgi paylaşımında kullanılacak stratejilerin geliştirilmesini sağlar.
|
||||||
|
* **Strateji**: Haftalık teknik toplantılar, bilgi paylaşımı için mükemmel bir fırsattır. Toplantılarda teknik bir konuda kısa sunumlar yaparak ekibin genel bilgisini artırabilir ve tartışma ortamları yaratarak takımın problem çözme becerilerini güçlendirebilirsin.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## 4\. Kritik Düşünme ve Problem Çözme:
|
||||||
|
|
||||||
|
Münazırlık ve hitabet gibi disiplinler, analitik düşünme becerilerini geliştirir. Yazılım geliştirme sürecinde karşılaşılan sorunlar karşısında hızlı ve mantıklı çözümler üretmek, başarıya giden yolda kritik bir rol oynar.
|
||||||
|
|
||||||
|
* **Analitik ve Sistematik Yaklaşım**: Hitabetin özünde, bir konuyu sistematik bir şekilde çözümleyebilmek ve bunu mantıklı argümanlarla destekleyebilmek vardır. Yazılım projelerinde de aynı prensip geçerlidir. Bir problemle karşılaştığınızda, onu alt başlıklara bölmek, her bir başlık için çözümler üretmek ve bu çözümleri karşılaştırarak en iyi yolu seçmek etkili bir strateji olabilir.
|
||||||
|
* **Öneri**: Yazılım projelerinde karşılaştığın bir sorunu çözme sürecini, bir münazara gibi ele alabilirsin. Öncelikle sorunu tanımla, ardından olası çözümleri argümanlarla savun ve nihayetinde en mantıklı çözümü belirleyip uygulamaya geç.
|
||||||
|
* **Eleştirel Düşünme**: Münazırlıkta eleştirel düşünme yeteneği geliştirilir. Aynı şekilde, yazılım projelerinde de her zaman mevcut çözümleri sorgulamak, daha iyi yollar aramak önemlidir. “Bu kod daha iyi yazılabilir mi?” veya “Bu mimari gerçekten en iyisi mi?” gibi sorular sorarak daha etkili çözümler bulabilirsin.
|
||||||
|
* **Strateji**: Bir problemle karşılaştığında, “bu sorunu çözmenin farklı yolları nelerdir?” sorusunu sormak, bakış açını genişletecektir. Alternatif çözümleri araştırarak ve karşılaştırarak daha yaratıcı çözümler bulabilirsin.
|
||||||
|
|
||||||
|
## Sonuç olarak:
|
||||||
|
|
||||||
|
Yazılım dünyasında teknik bilgi önemli olsa da, hitabet sanatı bu bilginin en doğru şekilde aktarılmasını sağlar. İyi bir yazılımcı olmanın yanı sıra, etkili bir iletişimci ve müzakereci olmak da projelerde fark yaratmanı sağlar. Yazılım ve hitabetin bu kesişim noktasında kendini geliştirerek, kariyerinde büyük adımlar atabilir ve ekiplere liderlik edebilirsin.
|
||||||
|
|
||||||
|
|
||||||
|
Okuduğunuz için teşekkür ederim ❤
|
||||||
@@ -0,0 +1,73 @@
|
|||||||
|
---
|
||||||
|
title: "Yazılım Geliştirme Süreçlerinde Agile ve Scrum"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-10-24"
|
||||||
|
readTime: "5 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "yaz-l-m-geli-tirme-s-re-lerinde-agile-ve-scrum"
|
||||||
|
excerpt: "Yazılım Geliştirme Süreçlerinde Agile ve Scrum Yazılım projeleri yürütürken işler her zaman planlandığı gibi gitmez, değil mi? Bazen günlerce uğraşırsın, tam her şey yolunda …"
|
||||||
|
coverImage: "/blog/images/yaz-l-m-geli-tirme-s-re-lerinde-agile-ve-scrum-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/yaz%C4%B1l%C4%B1m-geli%C5%9Ftirme-s%C3%BCre%C3%A7lerinde-agile-ve-scrum-45ad7f7b9ce6"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Yazılım Geliştirme Süreçlerinde Agile ve Scrum
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Yazılım projeleri yürütürken işler her zaman planlandığı gibi gitmez, değil mi? Bazen günlerce uğraşırsın, tam her şey yolunda derken, müşteriden “Bir de şu özelliği eklesek mi?” diye bir e-posta gelir. Tamam, bu işleri bambaşka bir hale sokar ama işin güzelliği burada: Agile ve Scrum tam da böyle durumlar için var. E hadi o zaman, bu yaklaşımların iş ortamını nasıl değiştirdiğine bakalım.
|
||||||
|
|
||||||
|
### 1\. Agile ve Scrum: Kulağa Tanıdık Geliyor Ama Tam Olarak Ne Anlama Geliyor?
|
||||||
|
|
||||||
|
Başlangıç olarak şunu bir netleştirelim: Agile, bir düşünce biçimi. Yazılım geliştirme sürecinde hızlı, esnek ve sürekli değişen şartlara uyum sağlayan bir yaklaşım. Bir nevi, “Her an her şey olabilir, önemli olan buna hızla uyum sağlamak” mantığı. Scrum ise bu Agile felsefesini alıp uygulamaya dökmenin bir yolu.
|
||||||
|
|
||||||
|
Düşünsene, büyük bir projeyi küçük küçük parçalara bölüyorsun, her parçada ne yaptığını değerlendiriyorsun, sürekli geribildirim alıyorsun ve gerektiğinde yön değiştiriyorsun. Yani kısacası, işler raydan çıkmadan önce düzeltme şansın oluyor. “Bu da nereden çıktı?” demek yerine, yeni duruma göre şekil alıyorsun.
|
||||||
|
|
||||||
|
### 2\. Herkesin Aynı Sayfada Olması: Takım İçi İletişim ve Daily Stand-up Toplantıları
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Şimdi bir düşün, hepimiz işte bazı günler dalıp gidiyoruz. Gün boyu kod yazıyorsun, bir problemi çözmeye odaklanıyorsun ve bir bakıyorsun ki gün bitmiş. Ama böyle zamanlarda takım arkadaşların ne yapıyor, hangi noktadalar? İşte burada _daily stand-up_ toplantıları devreye giriyor. Her sabah yapılan bu kısa toplantılar (genellikle 10–15 dakika), herkesin ne üzerinde çalıştığını, herhangi bir sorunu olup olmadığını paylaşması için mükemmel bir fırsat. Şahsen şuan ki (10/24/2024) stajımda bunu deneyimleyen birisi olarak söylüyorum. Gerçekten bir şeylerin farklı olduğunu hissediyorsun.
|
||||||
|
|
||||||
|
Ama dur, burada mesele sadece “Dün şu işleri yaptım” demek değil. Asıl güzellik, takımın aynı sayfada kalmasını sağlamak. Herkes bir araya gelip hızlıca “Bu sprint’te neredeyiz, ilerleyebiliyor muyuz?” diye bir kontrol yapıyor. Bu, küçük ama etkili bir dokunuş. Çünkü bazen farkında olmadan bir şeylerin ters gitmesine rağmen herkes işine dalmış olabilir ve o küçük problemler büyüyebilir. Ama bu toplantılar sayesinde, bir sıkıntı varsa anında ortaya çıkıyor.
|
||||||
|
|
||||||
|
Bir örnek üzerinden düşünelim: Diyelim ki bir takım arkadaşı GUI üzerinde çalışıyor, diğer arkadaş ise veri tabanıyla ilgili bir sorunu çözmeye uğraşıyor. İki iş birbirinden bağımsız gibi görünse de, aslında arka planda veri tabanındaki bir problem GUI’nin ilerlemesini engelleyebilir. Daily stand-up toplantılarında bu durum fark edilip hemen çözüm için adımlar atılabilir. Böylece, bir hafta sonra “Neden GUI tarafında ilerleyemedik?” diye kimse şaşırmaz. Sorun daha küçükken fark edilir ve ekip beraber çözüm üretir.
|
||||||
|
|
||||||
|
Bir de bu toplantıların güzel yanı şu: Kimse tek başına bir sorunu çözmeye çalışırken boğulmuyor. Bir problem mi var? Toplantıda paylaş ve takımın geri kalanı nasıl yardımcı olabileceğini hemen değerlendirir. Mesela, bir arkadaşın o gün kendisine atanmış işi hızla bitirip senin sorununa el atabilir. Bu da işlerin hızlanmasını sağlar ve kimse “yalnız” hissetmez.
|
||||||
|
|
||||||
|
Bir stand-up toplantısının sohbetini şöyle hayal edebilirsin:
|
||||||
|
|
||||||
|
* **Ali:** “Dün veri tabanı performans sorunlarını çözmeye çalışıyordum ama hala bazı gecikmeler var.”
|
||||||
|
* **Ayşe:** “GUI tarafında veriler zamanında gelmediği için ilerleyemedim. Sanırım senin yaşadığın problemle ilgili olabilir.”
|
||||||
|
* **Mehmet:** “Ali, bu veri tabanı sorunlarıyla daha önce uğraşmıştım. İstersen bugün seninle beraber çözmeye çalışabilirim.”
|
||||||
|
|
||||||
|
Bu tür bir iletişim, takımın tüm üyelerinin işlerine daha bilinçli bir şekilde odaklanmasını sağlar. Ayrıca sorunlar büyümeden çözüldüğü için işlerin rayında gitme olasılığı artar. Stand-up toplantılarında kimse kendini yalnız hissetmez, çünkü herkes birbirini desteklemek için oradadır.
|
||||||
|
|
||||||
|
|
||||||
|
Unutmayalım, bu toplantılar sıkıcı ya da uzun sürmek zorunda değil. Tam tersine, verimli olması için hızlı ve net olmalı. Takım üyeleri sadece önemli noktaları paylaşmalı. Bu yüzden çoğu stand-up toplantısı ayakta yapılır, böylece zaman kaybedilmez ve herkes işinin başına döner.
|
||||||
|
|
||||||
|
Bir başka faydası ise şu: Herkes projede neler olup bittiğini öğrenir. Mesela, genelde frontend ekibi backend’in tam olarak neyle uğraştığını bilmez, ya da tersine. Ama stand-up’lar sayesinde herkes birbirinin ilerleyişini takip eder, kim hangi konuda yardıma ihtiyaç duyuyorsa hızlıca çözüm bulur. Ve bu, işlerin tıkanmadan ilerlemesini sağlar.
|
||||||
|
|
||||||
|
### 3\. Esneklik Şart: Planlar Değiştiğinde Panik Yapmamak
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
Şu klasik senaryoyu biliyorsun: Bir proje planı çizilir, her şey tıkır tıkır işleyecekmiş gibi görünür. Ama bir süre sonra müşterinin istekleri değişir, yeni gereksinimler gelir ya da teknik bir sorun ortaya çıkar. İşte o noktada genelde işler sarpa sarar. Ama Agile ve Scrum tam da bu anlar için mükemmel bir çözüm sunuyor.
|
||||||
|
|
||||||
|
Agile’da planlar katı değildir, esnektir. Yani “Plan bozuldu, ne yapacağız?” diye strese girmiyorsunuz. Ekip olarak yeni duruma göre yön değiştiriyor ve yolunuza devam ediyorsunuz. Hatta bu yaklaşım sayesinde değişiklikler bir sorun olmaktan çıkıyor, aksine ekibin uyum yeteneğini geliştiriyor. Bir bakıma “Değişim mi? Hadi bakalım, yapalım!” diyorsun. Ve emin olun oldukça işe yarıyor.
|
||||||
|
|
||||||
|
### 4\. Sürekli Gelişim Kültürü
|
||||||
|
|
||||||
|
Agile felsefesinin merkezinde “sürekli gelişim” var. Sprint sonunda yapılan retrospektif toplantıları, ekibin performansını değerlendirmesi için harika bir fırsat sunuyor. Bu toplantılarda neyin iyi gittiğini, neyin geliştirilebileceğini ve gelecek sprintlerde nelerden kaçınılması gerektiğini konuşursunuz.
|
||||||
|
|
||||||
|
Bu da hem kişisel gelişimi destekler hem de takım olarak daha verimli çalışmanıza olanak tanır. Kısacası, Agile ve Scrum sadece projeleri değil, ekipleri de sürekli geliştiren bir yapı sunuyor.
|
||||||
|
|
||||||
|
### 5\. Takım Olarak Sorumluluk Paylaşımı
|
||||||
|
|
||||||
|
Scrum, bireylerin değil, ekibin başarısına odaklanır. Bu da sorumluluğun tüm takım tarafından paylaşıldığı bir çalışma kültürü oluşturur. Yani, bir proje başarılı olursa bu herkesin başarısıdır. Aynı şekilde, bir problem çıktığında da suçlayacak birini aramak yerine, takım olarak çözüm üretmek için harekete geçilir.
|
||||||
|
|
||||||
|
### Sonuç Olarak: Agile ve Scrum ile Daha Hızlı, Daha Güçlü Bir Ekip
|
||||||
|
|
||||||
|
Sonuç olarak, Agile ve Scrum yaklaşımları, ekiplerin sadece iş yapma şekillerini değil, aynı zamanda birbirleriyle olan ilişkilerini de köklü bir şekilde değiştirebilir. Daily stand-up toplantıları gibi pratikler, iletişimi güçlendirirken sorunların hızla çözülmesini sağlar. Takım arkadaşlarınla her gün düzenli olarak bir araya gelmek, projelerinizin daha verimli ilerlemesine ve herkesin işinden daha fazla keyif almasına katkıda bulunur.
|
||||||
|
|
||||||
|
Agile ve Scrum, yalnızca bir yöntem değil, aynı zamanda ekiplerin birlikte daha iyi çalışmasını sağlayan bir kültür. Eğer bir ekip olarak sürekli gelişmeyi hedefliyorsanız, bu yaklaşımları benimsemek, hem projelerinizi hem de ekip dinamiklerinizi güçlendirebilir. Kim bilir, belki de sıradaki projede bu yöntemler sayesinde başarıyı yakalayacak ve iş hayatının tadını çıkaracaksınız!
|
||||||
@@ -0,0 +1,98 @@
|
|||||||
|
---
|
||||||
|
title: "Yazılım Projelerinde Düzen ve Verimlilik İçin: Conventional Commits Nedir?"
|
||||||
|
category: "General"
|
||||||
|
date: "2024-08-23"
|
||||||
|
readTime: "3 min read"
|
||||||
|
author: "Poyraz Avsever"
|
||||||
|
slug: "yaz-l-m-projelerinde-d-zen-ve-verimlilik-i-in-conventional-commits-nedir"
|
||||||
|
excerpt: "Yazılım Projelerinde Düzen ve Verimlilik İçin: Conventional Commits Nedir? Yazılım geliştirme sürecinde, kod yazmanın ötesinde pek çok detayla uğraşıyoruz. Commit mesajları da bu …"
|
||||||
|
coverImage: "/blog/images/yaz-l-m-projelerinde-d-zen-ve-verimlilik-i-in-conventional-commits-nedir-cover.jpg"
|
||||||
|
canonicalUrl: "https://medium.com/@poyrazavsever/yaz%C4%B1l%C4%B1m-projelerinde-d%C3%BCzen-ve-verimlilik-i%CC%87%C3%A7in-conventional-commits-nedir-4413e05ffbbf"
|
||||||
|
---
|
||||||
|
|
||||||
|
# Yazılım Projelerinde Düzen ve Verimlilik İçin: Conventional Commits Nedir?
|
||||||
|
|
||||||
|
|
||||||
|
Yazılım geliştirme sürecinde, kod yazmanın ötesinde pek çok detayla uğraşıyoruz. Commit mesajları da bu sürecin kritik bir parçası tabii ki. Ancak commit mesajları, bazen dağınık, anlaşılmaz ve düzensiz olabiliyor. İşte bu noktada “**Conventional Commits”** devreye giriyor.
|
||||||
|
|
||||||
|
|
||||||
|

|
||||||
|
|
||||||
|
## Conventional Commits Nedir?
|
||||||
|
|
||||||
|
Conventional Commits, commit mesajlarınızı belirli bir formata oturtan bir yazılım standardı. Amaç, her commit’in ne yaptığını net bir şekilde ifade etmek ve proje geçmişini daha anlaşılır hale getirmek. Commit mesajlarınızı bu standarda göre yazmak, projeyi daha düzenli, takip edilebilir ve sürdürülebilir kılar. Gelin şimdi beraber inceleyelim.
|
||||||
|
|
||||||
|
## Neden Conventional Commits Kullanmalıyız?
|
||||||
|
|
||||||
|
### 1\. Anlaşılabilirlik
|
||||||
|
|
||||||
|
Commit geçmişinin anlaşılabilir olması hepimiz için önemli. Bu standart, projede yapılan değişikliklerin kolayca takip edilmesini sağlıyor. Büyük projelerde, hangi commit’in hangi sorunu çözdüğünü veya hangi yeni özelliği eklediğini anlamak zaman zaman zorlaştığı için bu gibi standartları kullanmak yazılımcıların işini kolaylaştırıyor.
|
||||||
|
|
||||||
|
### 2\. İzlenebilirlik ve Şeffaflık
|
||||||
|
|
||||||
|
Commit mesajlarımızı tutarlı ve net hale getirmek, proje geçmişimizde yapılan değişikliklerin izlenmesini kolaylaştırıyor. Özellikle **geriye dönük uyumluluğu** bozan değişikliklerde, bu düzenlemeler büyük bir avantaj sağlıyor.
|
||||||
|
|
||||||
|
## Peki Bu Commit Mesajları Nasıl Yazılıyor?
|
||||||
|
|
||||||
|
Conventional Commits’e göre, her commit mesajı üç ana bölümden oluşur:
|
||||||
|
|
||||||
|
1. **Başlık (Summary):** Mesajın türünü ve kısaca ne yaptığını belirtir.
|
||||||
|
2. **Gövde (Body):** Değişikliğin detaylarını açıklar. Neden yapıldığını ve nasıl yapıldığını anlatır.
|
||||||
|
3. **Altbilgi (Footer):** Breaking changes gibi uyumluluğu bozan değişiklikler veya kapatılan sorunlar burada belirtilir.
|
||||||
|
|
||||||
|
## Commit Türleri
|
||||||
|
|
||||||
|
Commit mesajları belirli türlerle başlar. İşte en yaygın kullanılan türler: [Daha detaylı commit türlerini incelemek için tıklayın.](https://www.conventionalcommits.org/en/v1.0.0/)
|
||||||
|
|
||||||
|
* **feat:** Yeni bir özellik eklenmesi.
|
||||||
|
* **fix:** Bir hatanın düzeltilmesi.
|
||||||
|
* **docs:** Sadece dokümantasyonla ilgili değişiklikler.
|
||||||
|
* **style:** Kodun işleyişini değiştirmeyen biçimlendirme (boşluklar, noktalı virgüller vb.).
|
||||||
|
* **refactor:** Kodda, işlevini değiştirmeyen yeniden düzenleme.
|
||||||
|
|
||||||
|
**Gelin beraber örnek bir Commit Mesajını inceleyelim:**
|
||||||
|
|
||||||
|
> feat(login): add JWT authentication
|
||||||
|
>
|
||||||
|
> Added JWT authentication to the login process to enhance security.
|
||||||
|
> This change involves updating the login controller and modifying the user model.
|
||||||
|
>
|
||||||
|
> BREAKING CHANGE: The user model now requires a JWT token for all login operations.
|
||||||
|
|
||||||
|
1. **Başlık (Summary):**
|
||||||
|
|
||||||
|
* `**feat:**`
|
||||||
|
Commit türünü belirtir. Burada `feat` (feature) türü kullanılmış, bu da commit'in projeye yeni bir özellik eklediğini gösterir. Başka türler de kullanılabilir, örneğin `fix` (bir hatayı düzeltmek), `docs` (dokümantasyon güncellemeleri) gibi.
|
||||||
|
* `**(login):**`
|
||||||
|
Parantez içinde belirtilen bölüm, bu özelliğin veya değişikliğin hangi modülü veya bölümü etkilediğini gösterir. Burada `login` kullanılmış, yani yapılan değişiklik, login (giriş) süreciyle ilgilidir.
|
||||||
|
* `**add JWT authentication:**`
|
||||||
|
Bu, commit'in yaptığı spesifik değişikliği kısa ve öz bir şekilde açıklar. Burada, JWT (JSON Web Token) ile kimlik doğrulamanın login sürecine eklendiği belirtiliyor.
|
||||||
|
|
||||||
|
2\. **Gövde (Body):**
|
||||||
|
|
||||||
|
* **İlk Cümle:**
|
||||||
|
“Added JWT authentication to the login process to enhance security.”
|
||||||
|
Bu cümle, yapılan değişikliğin amacını ve sonucunu açıklar. Burada, JWT kimlik doğrulamasının login sürecine eklendiği ve bunun güvenliği artırmak amacıyla yapıldığı belirtiliyor.
|
||||||
|
* **İkinci Cümle:**
|
||||||
|
“This change involves updating the login controller and modifying the user model.”
|
||||||
|
Bu cümle, değişikliğin hangi dosya veya modülleri etkilediğini daha detaylı açıklar. Burada, login controller’ın güncellendiği ve user model’in değiştirildiği belirtiliyor.
|
||||||
|
|
||||||
|
3\. **Altbilgi (Footer):**
|
||||||
|
|
||||||
|
* `**BREAKING CHANGE:**`
|
||||||
|
Bu ifade, uyumluluğu bozan bir değişiklik olduğunu gösterir. Eğer bir commit, mevcut kodun çalışmasını bozacak bir değişiklik yapıyorsa, bu mutlaka belirtilmelidir. Bu, diğer geliştiricilerin bu değişiklikten haberdar olmasını sağlar.
|
||||||
|
* **Detay:**
|
||||||
|
“The user model now requires a JWT token for all login operations.”
|
||||||
|
Bu açıklama, uyumluluğu bozan değişikliğin ne olduğunu detaylandırır. Burada, kullanıcı modelinin artık tüm giriş işlemleri için bir JWT token gerektirdiği belirtiliyor. Bu, diğer geliştiricilerin bu değişikliği uygularken dikkatli olmaları gerektiğini ifade eder.
|
||||||
|
|
||||||
|
## Sonuç olarak
|
||||||
|
|
||||||
|
Conventional Commits, yazılım geliştirme sürecimizi daha düzenli, anlaşılır ve verimli hale getirdi. Commit mesajlarımızı belirli bir yapıya oturtarak, proje yönetimimizi daha sürdürülebilir ve izlenebilir bir hale getirdik.
|
||||||
|
|
||||||
|
|
||||||
|
Eğer siz de projelerinizde daha düzenli bir commit geçmişi istiyorsanız, Conventional Commits’i denemenizi tavsiye ederim.
|
||||||
|
|
||||||
|
## Kaynak
|
||||||
|
|
||||||
|
* [https://www.conventionalcommits.org/en/v1.0.0/](https://www.conventionalcommits.org/en/v1.0.0/)
|
||||||
|
* [https://developer.vonage.com/en/blog/3-reasons-why-you-should-use-conventional-commits](https://developer.vonage.com/en/blog/3-reasons-why-you-should-use-conventional-commits)
|
||||||
@@ -1,42 +1,35 @@
|
|||||||
# Medium Yazılarını Kişisel Web Sitesine Taşıma Planı
|
# Medium Yazılarını Arşiv Beklemeden (Hızlı) Taşıma Planı
|
||||||
|
|
||||||
Bu plan, Medium üzerindeki içeriklerin poyrazavsever.com (poyraz-portal) altyapısına Markdown formatında, SEO dostu ve kalıcı bir şekilde aktarılması için hazırlanmıştır.
|
Bu plan, Medium'un "Download your information" sürecini beklemeden, yayındaki makaleleri doğrudan URL üzerinden Markdown formatına dönüştürmek için tasarlanmıştır.
|
||||||
|
|
||||||
---
|
---
|
||||||
|
|
||||||
## 1. Hazırlık ve Veri Edinme
|
## 1. Yöntem Seçimi ve Araç Kurulumu
|
||||||
* **Arşiv Talebi:** Medium Ayarları > Güvenlik > "Download your information" sekmesinden tüm verilerin yedeğini iste.
|
* **CLI (Toplu Çekim):** Tüm yazıları tek seferde çekmek için terminal üzerinden `medium-to-markdown` gibi araçları hazırla.
|
||||||
* **Yerel Çalışma Alanı:** Bilgisayarında `medium-migration` adlı geçici bir klasör oluştur ve gelen .zip dosyasını buraya ayıkla.
|
* **Eklenti (Tekil Çekim):** Eğer yazı sayısı az ise, tarayıcıya "MarkDownload" veya "Medium to Markdown" eklentisini kur.
|
||||||
* **İçerik Analizi:** `posts` klasöründeki HTML dosyalarını incele. Hangi yazıların taşınacağına, hangilerinin taslak olarak kalacağına karar ver.
|
* **Klasör Yapısı:** Kendi web siten (poyrazavsever.com) içinde yazılar için geçici bir `/temp-blog` klasörü oluştur.
|
||||||
|
|
||||||
## 2. Format Dönüştürme (HTML -> Markdown)
|
## 2. İçerikleri Otomatik Çekme
|
||||||
* **Araç Seçimi:** HTML dosyalarını Markdown'a (.md) çevirmek için bir kütüphane (Turndown vb.) veya hazır bir CLI aracı belirle.
|
* **Kullanıcı Yazılarını Listeleme:** Medium profilindeki (medium.com/@kullaniciadi) tüm yazı linklerini bir liste haline getir.
|
||||||
* **Frontmatter Yapılandırması:** Her Markdown dosyasının başına sitenin (Next.js/Astro vb.) okuyabileceği metadata bloklarını ekle:
|
* **Dönüştürme Komutunu Çalıştırma:** Terminal kullanarak tüm halka açık yazıları Markdown dosyası olarak yerel bilgisayarına indir.
|
||||||
* Başlık (Title)
|
* **Kontrol:** İndirilen dosyaların `.md` uzantılı olduğunu ve içeriklerin (özellikle kod bloklarının) okunaklı olduğunu doğrula.
|
||||||
* Yayın Tarihi (Date)
|
|
||||||
* Kategori/Etiketler (Tags)
|
|
||||||
* Kapak Görseli Yolu (Cover Image)
|
|
||||||
* Medium Orijinal Linki (Canonical URL için)
|
|
||||||
* **Slug Temizliği:** Dosya isimlerini URL uyumlu hale getir (Örn: `yazi-basligi.md`).
|
|
||||||
|
|
||||||
## 3. Medya ve Görsel Yönetimi
|
## 3. Metadata (Frontmatter) Düzenleme
|
||||||
* **Görsel İndirme:** Markdown içindeki Medium kaynaklı (miro.medium.com) görselleri yerel `/public/blog` klasörüne indir.
|
* **Başlık ve Tarih:** Her dosyanın en üstüne sitenin tanıması için gerekli bilgileri ekle (Title, Date, Slug).
|
||||||
* **Link Güncelleme:** Markdown dosyasındaki uzak görsel linklerini, kendi sitendeki yerel yollarla değiştir.
|
* **Kategori Atama:** Yazıları Medium'daki etiketlerine göre klasörle veya etiket metadatalarını güncelle.
|
||||||
* **Optimizasyon:** İndirilen görselleri WebP formatına çevirerek site hızını artır.
|
* **Özet (Excerpt):** Yazıların giriş kısmından kısa birer özet oluşturup dosyaların başına ekle.
|
||||||
|
|
||||||
## 4. İçerik ve Kod Blokları Kontrolü
|
## 4. Görsel ve Medya Optimizasyonu
|
||||||
* **Kod Blokları:** Medium'daki kod bloklarının ve Gist yerleştirmelerinin Markdown'da ` ``` ` içine doğru şekilde girip girmediğini kontrol et.
|
* **Görsel Kaynakları:** Markdown içindeki `https://miro.medium.com/...` ile başlayan görsel linklerini tespit et.
|
||||||
* **Dahili Linkler:** Yazıların içinde başka Medium yazılarına verdiğin linkleri, kendi sitendeki yeni linklerle güncelle.
|
* **Yerel Kaydetme:** Bu görselleri manuel veya bir script yardımıyla indirip sitendeki `/public/images/blog` klasörüne taşı.
|
||||||
* **Bileşen Dönüştürme:** Eğer sitende özel UI bileşenleri kullanıyorsan (Örn: `poyraz-ui`), Markdown içindeki bazı yapıları bu bileşenlere uyarla.
|
* **Yol Güncelleme:** Markdown dosyalarındaki görsel linklerini kendi sunucundaki yeni yollarla (`/images/blog/yazi1.jpg` gibi) değiştir.
|
||||||
|
|
||||||
## 5. SEO ve Yönlendirme Stratejisi
|
## 5. Web Sitesine Entegrasyon
|
||||||
* **Canonical URL:** Arama motorlarının kopya içerik algılamaması için, web sitendeki yazıların `<head>` kısmına orijinal Medium linkini "canonical" olarak ekle.
|
* **Dosya Transferi:** Hazırlanan `.md` dosyalarını sitenin içerik yönetim sistemine (Content klasörüne) kopyala.
|
||||||
* **Medium Güncelleme:** (Opsiyonel) Medium'daki yazılarını silmek yerine, en üstüne "Bu yazı artık poyrazavsever.com adresinde güncellenmektedir" notu ve linki ekle.
|
* **Link Kontrolü:** Yazı içindeki diğer Medium yazılarına giden linkleri, kendi sitendeki yeni URL yapısına göre (`/blog/yazi-adi`) güncelle.
|
||||||
|
* **SEO Ayarı:** Her yazı için `canonical` etiketini Medium'daki orijinal linki gösterecek şekilde ayarla (Bu adım SEO için kritiktir).
|
||||||
|
|
||||||
## 6. Yayınlama ve Test
|
## 6. Yayın ve Doğrulama
|
||||||
* **Yerel Test:** Yazıları kendi portalında (localhost) render et. Görselleri, linkleri ve kod bloklarını manuel olarak test et.
|
* **Local Build:** Projeyi yerelde çalıştırarak görsellerin ve stilin (UI) doğru göründüğünden emin ol.
|
||||||
* **Deployment:** İçerikleri GitHub repo'na pushla ve siteni yayına al.
|
* **Deployment:** Değişiklikleri ana repo'na gönder ve yayına al.
|
||||||
* **Dizin Bildirimi:** Yeni URL'leri Google Search Console üzerinden dizine eklenmesi için gönder.
|
* **Yönlendirme:** (Opsiyonel) Medium profilindeki biyografi kısmına "Yazılarım artık poyrazavsever.com/blog adresinde!" notunu ekle.
|
||||||
|
|
||||||
---
|
|
||||||
**Not:** Bu işlem bir kez yapıldıktan sonra, gelecekte yazacağın yazıları önce kendi sitende yayınlayıp sonra Medium'a "Import" etmen (Cross-posting) iş akışını çok daha kolaylaştıracaktır.
|
|
||||||
@@ -0,0 +1,28 @@
|
|||||||
|
https://medium.com/@poyrazavsever/frontend-mimarisinde-en-zor-k%C4%B1s%C4%B1m-karar-vermek-b3719c7aaacd
|
||||||
|
https://medium.com/@poyrazavsever/clean-architecture-frontende-nas%C4%B1l-uyarlan%C4%B1r-2db91f7e7c97
|
||||||
|
https://medium.com/@poyrazavsever/frontend-developer-2025-yol-haritas%C4%B1-ki%C5%9Fisel-bak%C4%B1%C5%9F-a%C3%A7%C4%B1s%C4%B1yla-dda276fedfb7
|
||||||
|
https://medium.com/@poyrazavsever/next-js-ile-edge-functions-h%C4%B1zl%C4%B1-web-uygulamalar%C4%B1-nas%C4%B1l-geli%C5%9Ftirilir-d94eafacf50e
|
||||||
|
https://medium.com/@poyrazavsever/rss-ile-bilgi-ak%C4%B1%C5%9F%C4%B1n%C4%B1-algoritmadan-uzakla%C5%9Ft%C4%B1r-a30340175da3
|
||||||
|
https://medium.com/@poyrazavsever/gpt-5-geldi-openainin-yeni-modeli-neler-sunuyor-88d67735a272
|
||||||
|
https://medium.com/@poyrazavsever/deneyimlemeden-%C3%B6%C4%9Frenmeniz-gereken-g%C3%BCvenlik-a%C3%A7%C4%B1klar%C4%B1-55c31f58c2b2
|
||||||
|
https://medium.com/@poyrazavsever/next-js-15-gelmi%C5%9F-neler-de%C4%9Fi%C5%9Fti-peki-651cd716839b
|
||||||
|
https://medium.com/@poyrazavsever/docker-nedir-kahveni-al-docker%C4%B1-konu%C5%9Fuyoruz-de83718255e8
|
||||||
|
https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-5-b%C3%B6l%C3%BCm-materialize-5fd3c99862c2
|
||||||
|
https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-4-b%C3%B6l%C3%BCm-chakra-ui-529192099789
|
||||||
|
https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-3-b%C3%B6l%C3%BCm-bulma-7576b893d449
|
||||||
|
https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-2-b%C3%B6l%C3%BCm-foundation-68b08997cea3
|
||||||
|
https://medium.com/@poyrazavsever/css-frameworkleri-tan%C4%B1yoruz-1-b%C3%B6l%C3%BCm-bootstrap-232619268cc8
|
||||||
|
https://medium.com/@poyrazavsever/react-native-nedir-avantajlar%C4%B1-ve-dezavantajlar%C4%B1-4b26608a03cd
|
||||||
|
https://medium.com/@poyrazavsever/three-js-3-boyutlu-d%C3%BCnyaya-merhaba-07b174dd6759
|
||||||
|
https://medium.com/@poyrazavsever/react-ile-dinamik-bir-kullan%C4%B1c%C4%B1-profil-sayfas%C4%B1-nas%C4%B1l-tasarlan%C4%B1r-12d56031c253
|
||||||
|
https://medium.com/@poyrazavsever/yaz%C4%B1l%C4%B1m-geli%C5%9Ftirme-s%C3%BCre%C3%A7lerinde-agile-ve-scrum-45ad7f7b9ce6
|
||||||
|
https://medium.com/@poyrazavsever/yaz%C4%B1l%C4%B1m-d%C3%BCnyas%C4%B1nda-hitabet-sanat%C4%B1n%C4%B1n-g%C3%BCc%C3%BC-i%CC%87leti%C5%9Fimin-yaz%C4%B1l%C4%B1m-d%C3%BCnyas%C4%B1na-e-etkisi-a1a1bbcf6db6
|
||||||
|
https://medium.com/@poyrazavsever/mikro-etkile%C5%9Fimlerde-i%CC%87kon-kullan%C4%B1m%C4%B1-2262a71d9a4a
|
||||||
|
https://medium.com/@poyrazavsever/webpack-vs-vite-frontend-projelerinde-build-ara%C3%A7lar%C4%B1-kar%C5%9F%C4%B1la%C5%9Ft%C4%B1rmas%C4%B1-fb8f24c4d095
|
||||||
|
https://medium.com/@poyrazavsever/ux-tasar%C4%B1m%C4%B1-ve-i%CC%87nsan-psikolojisi-f6570a41ab9b
|
||||||
|
https://medium.com/@poyrazavsever/frontend-testing-ara%C3%A7lar%C4%B1-jest-ve-cypress-ile-ba%C5%9Flamak-82ba26656a01
|
||||||
|
https://medium.com/@poyrazavsever/typescript-ile-javascriptten-tsx-e-ge%C3%A7i%C5%9F-ki%C5%9Fisel-bir-deneyim-308bdb14f1d0
|
||||||
|
https://medium.com/@poyrazavsever/svelte-ile-i%CC%87lk-ad%C4%B1mlar-react-ve-vueya-kar%C5%9F%C4%B1-h%C4%B1zl%C4%B1-m%C4%B1-c5ae640145c9
|
||||||
|
https://medium.com/@poyrazavsever/tailwind-css-ile-tasar%C4%B1m-s%C3%BCrecini-nas%C4%B1l-h%C4%B1zland%C4%B1rabilirsiniz-90ef7fbd9faf
|
||||||
|
https://medium.com/@poyrazavsever/kullan%C4%B1c%C4%B1-ara%C5%9Ft%C4%B1rmas%C4%B1-ve-personas-olu%C5%9Fturma-tasar%C4%B1m%C4%B1n-gizli-kahramanlar%C4%B1-2930cf7dbe13
|
||||||
|
https://medium.com/@poyrazavsever/yaz%C4%B1l%C4%B1m-projelerinde-d%C3%BCzen-ve-verimlilik-i%CC%87%C3%A7in-conventional-commits-nedir-4413e05ffbbf
|
||||||
@@ -38,7 +38,12 @@
|
|||||||
"@types/react-dom": "^19",
|
"@types/react-dom": "^19",
|
||||||
"eslint": "^9",
|
"eslint": "^9",
|
||||||
"eslint-config-next": "16.1.6",
|
"eslint-config-next": "16.1.6",
|
||||||
|
"medium-to-markdown": "^0.0.3",
|
||||||
|
"puppeteer": "^24.40.0",
|
||||||
|
"puppeteer-extra": "^3.3.6",
|
||||||
|
"puppeteer-extra-plugin-stealth": "^2.11.2",
|
||||||
"tailwindcss": "^4",
|
"tailwindcss": "^4",
|
||||||
|
"turndown": "^7.2.4",
|
||||||
"typescript": "^5"
|
"typescript": "^5"
|
||||||
}
|
}
|
||||||
}
|
}
|
||||||
|
|||||||
|
After Width: | Height: | Size: 164 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 71 KiB |
|
After Width: | Height: | Size: 108 KiB |
|
After Width: | Height: | Size: 75 KiB |
|
After Width: | Height: | Size: 221 KiB |
|
After Width: | Height: | Size: 305 KiB |
|
After Width: | Height: | Size: 230 KiB |
|
After Width: | Height: | Size: 98 KiB |
|
After Width: | Height: | Size: 47 KiB |
|
After Width: | Height: | Size: 77 KiB |
|
After Width: | Height: | Size: 88 KiB |
|
After Width: | Height: | Size: 178 KiB |
|
After Width: | Height: | Size: 273 KiB |
|
After Width: | Height: | Size: 49 KiB |
|
After Width: | Height: | Size: 100 KiB |
|
After Width: | Height: | Size: 82 KiB |
|
After Width: | Height: | Size: 115 KiB |
|
After Width: | Height: | Size: 46 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 29 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 14 KiB |
|
After Width: | Height: | Size: 22 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 4.8 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 18 KiB |
|
After Width: | Height: | Size: 6.3 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 6.3 KiB |
|
After Width: | Height: | Size: 1.3 MiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 395 KiB |
|
After Width: | Height: | Size: 461 KiB |
|
After Width: | Height: | Size: 463 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 6.9 KiB |
|
After Width: | Height: | Size: 27 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 67 KiB |
|
After Width: | Height: | Size: 62 KiB |
|
After Width: | Height: | Size: 11 KiB |
|
After Width: | Height: | Size: 75 KiB |
|
After Width: | Height: | Size: 20 KiB |
|
After Width: | Height: | Size: 16 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 7.7 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 32 KiB |
|
After Width: | Height: | Size: 17 KiB |
|
After Width: | Height: | Size: 349 KiB |
|
After Width: | Height: | Size: 3.1 KiB |
|
After Width: | Height: | Size: 172 KiB |
|
After Width: | Height: | Size: 212 KiB |
|
After Width: | Height: | Size: 373 KiB |
|
After Width: | Height: | Size: 35 KiB |
|
After Width: | Height: | Size: 42 KiB |