Aşağıdaki görevi yerine getiren bir Python fonksiyonu yaz:
Görev: [FONKSİYON_AÇIKLAMASI]
Gereksinimler:
- Type hints kullan
- Docstring ekle
- Edge case'leri handle et
- En az 3 unit test yaz (pytest)
- Karmaşıklığı belirt
- Alternatif çözüm öner
Aşağıdaki görevi yerine getiren bir Python fonksiyonu yaz:
Görev: [FONKSİYON_AÇIKLAMASI]
Gereksinimler:
- Type hints kullan
- Docstring ekle
- Edge case'leri handle et
- En az 3 unit test yaz (pytest)
- Karmaşıklığı belirt
- Alternatif çözüm öner
Örnek görev: Bir listedeki tekrarları koruyarak sıralı biçimde temizleyen fonksiyon. Çıktı: Type hint ve docstring içeren temiz bir Python fonksiyonu; boş liste, tek eleman ve tekrar eden değerler için pytest testleri. Karmaşıklık: O(n) zaman, O(n) ek alan. Alternatif: Sıra gerekmiyorsa set tabanlı çözüm.
Aşağıdaki kod değişikliği için uygun git commit mesajı yaz:
Değişiklikler:
[DEĞİŞİKLİKLER]
Conventional Commits formatı kullan:
- tip(kapsam): açıklama
- Body: ne ve neden değiştiğini açıkla
- Footer: breaking changes varsa belirt
3 alternatif öner.
Aşağıdaki kod değişikliği için uygun git commit mesajı yaz:
Değişiklikler:
[DEĞİŞİKLİKLER]
Conventional Commits formatı kullan:
- tip(kapsam): açıklama
- Body: ne ve neden değiştiğini açıkla
- Footer: breaking changes varsa belirt
3 alternatif öner.
feat(auth): add password reset flow. Body: Kullanıcıların güvenli bir token ile parola yenilemesini sağlayan akış eklendi; token süresi ve tek kullanımlık doğrulama uygulandı. Alternatifler: fix(auth): handle expired reset tokens; feat(account): implement secure password recovery. Breaking change: Yok.
OWASP standardına uygun penetrasyon testi rapor şablonu oluşturan prompt.
Bir siber güvenlik uzmanı olarak [SİSTEM_TÜRÜ] için OWASP metodolojisine uygun penetrasyon testi raporu hazırla. Executive summary, vulnerability assessment (CVSS v3.1 puanlama), risk matrisi, technical findings ve remediation planı bölümlerini detaylandır.
Bir siber güvenlik uzmanı olarak [SİSTEM_TÜRÜ] için OWASP metodolojisine uygun penetrasyon testi raporu hazırla. Executive summary, vulnerability assessment (CVSS v3.1 puanlama), risk matrisi, technical findings ve remediation planı bölümlerini detaylandır.
Executive summary: İncelenen web uygulamasında iki yüksek, üç orta ve dört düşük riskli bulgu tespit edildi. CVSS v3.1 ile puanlama yapıldı; en yüksek bulgu yetkilendirme kontrolünün eksikliği. Risk matrisi etki ve olasılığı gösterir. Remediation planı: acil erişim kontrolü, 30 gün içinde güvenli başlıklar, 60 gün içinde sürekli tarama. Kanıtlar hassas veri içermeden eklenir.
Büyük ölçekli veritabanlarında execution plan, karmaşık JOIN ve indeksleme optimizasyonu yapmak.
Sen bir kıdemli veritabanı performans mimarısın. Aşağıdaki karmaşık SQL sorgusunu ve çalışma planını (Execution Plan) optimize et:
Veritabanı Türü: [VERITABANI_TURU]
SQL Sorgusu:
```sql
[SORGU]
```
Tablo İstatistikleri ve İndeksler: [TABLO_BILGISI]
Lütfen şu başlıklarla analiz sun:
1. Execution Plan Analizi ve Maliyet Darboğazları
2. Bileşik İndeks (Composite Index) ve Kapsayan İndeks (Covering Index) Önerileri
3. Query Rewrite: Alt sorguları (Subquery) JOIN veya CTE'ye dönüştürme
4. Benchmark Test Planı (p95 / p99 gecikme süreleri karşılaştırması).
Sen bir kıdemli veritabanı performans mimarısın. Aşağıdaki karmaşık SQL sorgusunu ve çalışma planını (Execution Plan) optimize et:
Veritabanı Türü: [VERITABANI_TURU]
SQL Sorgusu:
```sql
[SORGU]
```
Tablo İstatistikleri ve İndeksler: [TABLO_BILGISI]
Lütfen şu başlıklarla analiz sun:
1. Execution Plan Analizi ve Maliyet Darboğazları
2. Bileşik İndeks (Composite Index) ve Kapsayan İndeks (Covering Index) Önerileri
3. Query Rewrite: Alt sorguları (Subquery) JOIN veya CTE'ye dönüştürme
4. Benchmark Test Planı (p95 / p99 gecikme süreleri karşılaştırması).
1. Execution Plan Analizi: Sorgu orders tablosunda Full Table Scan yapıyor.
2. İndeks Önerisi: CREATE INDEX idx_orders_status_date ON orders(status, created_at INCLUDE(total_amount));
3. Query Rewrite: Gereksiz SELECT * yerine yalnızca ihtiyaç duyulan alanlar seçildi.
[PROJE_ADI] projesi için RESTful API tasarla.
Kaynaklar: [KAYNAKLAR]
Her endpoint için:
- HTTP method ve URL
- Request body/params
- Response formatı (JSON)
- Status kodları
- Yetkilendirme gereksinimleri
- Swagger/OpenAPI spec
GET /api/v1/projects/{id}/tasks: Proje görevlerini döndürür. Yetkilendirme: Bearer token. Başarılı yanıt: 200 ve tasks dizisi. Hatalar: 401 yetkisiz, 404 proje bulunamadı, 422 geçersiz parametre. Sayfalama: page ve limit. OpenAPI tanımı; request, response şemaları ve örnek hata gövdeleriyle birlikte hazırlanır.
Aşağıdaki SQL sorgusunu optimize et:
```sql
[SORGU]
```
Analiz et:
- Execution plan tahmini
- Index önerileri
- Query rewrite alternatifleri
- N+1 problemi kontrolü
- Partition/sharding önerileri
- Performans karşılaştırması
Execution plan incelemesi: Tam tablo taraması yerine customer_id ve created_at üzerinde bileşik indeks önerildi. Sorgu yeniden yazımı: Gereksiz alt sorgu JOIN ile sadeleştirildi. N+1 riski: İlişkili kayıtlar tek sorguda eager loading ile alınmalı. Beklenti: Orta veri setinde sorgu süresi 420 ms seviyesinden 70 ms seviyesine düşebilir; gerçek sonuç benchmark ile doğrulanmalı.
[PROJE_ADI] projesi için veritabanı şeması tasarla.
Gereksinimler: [GEREKSİNİMLER]
Çıktı:
- ER diyagramı açıklaması
- Tablo yapıları (SQL)
- İlişkiler ve constraint'ler
- Index stratejisi
- Normalizasyon seviyesi
- Örnek veriler (INSERT)
Tablolar: users, projects, tasks ve task_comments. İlişkiler: users birden çok project, projects birden çok task, tasks birden çok comment. Constraintler: foreign key, benzersiz e-posta ve durum enumu. İndeksler: projects.owner_id, tasks.project_id ve tasks.status. Normalizasyon: Üçüncü normal form. Örnek INSERT kayıtları ve ER diyagramı açıklaması eklenir.
[TEKNOLOJİ_STACK] projesi için CI/CD pipeline tasarla.
Platform: [GitHub Actions/GitLab CI/Jenkins]
Pipeline:
- Build aşaması
- Test (unit, integration, e2e)
- Güvenlik taraması
- Staging deploy
- Production deploy
- Rollback stratejisi
- YAML yapılandırma dosyası
Aşamalar: Checkout kodu; bağımlılık kurulumu; unit ve integration testleri; SAST ve bağımlılık taraması; staging dağıtımı; manuel onay; production dağıtımı. Başarısızlıkta önceki imaja otomatik rollback yapılır. Pipeline sırlarını secret store üzerinden okur. Her adım artefact, log ve bildirim üretir; YAML yapılandırması branch kurallarıyla birlikte sunulur.
Yavaş çalışan karmaşık SQL sorgularını analiz ederek indeksleme stratejileri ve sorgu yeniden yazımı (query rewrite) ile optimize etmek.
Aşağıdaki yavaş çalışan SQL sorgusunu ve veritabanı şemasını optimize et:
Veritabanı Türü: [MYSQL_POSTGRESQL_ORACLE_MSSQL]
Sorgu:
```sql
[SQL_SORGU]
```
Tablo Boyutları ve Mevcut İndeksler: [TABLOLAR_INDEKSLER]
Optimizasyon Raporu:
1. Darboğaz Analizi: Sorgunun neden yavaş çalıştığı (Full table scan, geçici tablolar, filesort vb.)
2. Önerilen İndeksler (B-Tree, Composite Index tanımları)
3. Yeniden Yazılmış Optimize SQL (Query Rewrite)
4. EXPLAIN Plan İnceleme Kılavuzu: Hangi satırların kontrol edilmesi gerektiği
5. Canlıya Alırken Dikkat Edilecek Kilitlenme (Locking) Riskleri.
Aşağıdaki yavaş çalışan SQL sorgusunu ve veritabanı şemasını optimize et:
Veritabanı Türü: [MYSQL_POSTGRESQL_ORACLE_MSSQL]
Sorgu:
```sql
[SQL_SORGU]
```
Tablo Boyutları ve Mevcut İndeksler: [TABLOLAR_INDEKSLER]
Optimizasyon Raporu:
1. Darboğaz Analizi: Sorgunun neden yavaş çalıştığı (Full table scan, geçici tablolar, filesort vb.)
2. Önerilen İndeksler (B-Tree, Composite Index tanımları)
3. Yeniden Yazılmış Optimize SQL (Query Rewrite)
4. EXPLAIN Plan İnceleme Kılavuzu: Hangi satırların kontrol edilmesi gerektiği
5. Canlıya Alırken Dikkat Edilecek Kilitlenme (Locking) Riskleri.
1. Darboğaz: `created_at` üzerinde indeks olmadığından 2 milyon satırlık `orders` tablosunda Full Table Scan yapılıyor.
2. İndeks Önerisi:
CREATE INDEX idx_orders_created_user ON orders(created_at, user_id);
3. Optimize SQL:
SELECT o.id, o.total_price, u.name
FROM orders o
INNER JOIN users u ON o.user_id = u.id
WHERE o.created_at >= '2026-01-01';
Kritik sistem güncellemeleri ve canlıya alma süreçleri öncesinde risk değerlendirmesi, test kontrol listesi ve geri alma planı oluşturmak.
Aşağıdaki yazılım değişikliği için canlıya çıkış (Production Deployment) risk analizi ve hazırlık kontrol listesi oluştur:
Değişiklik Kapsamı: [DEGISIKLIKLER_DATABASE_API_FRONTEND]
Etkilenen Sistemler: [SISTEMLER]
Planlanan Dağıtım Saati: [ZAMAN]
Çıktı Planı:
1. Risk Seviyesi Değerlendirmesi (Yüksek / Orta / Düşük ve nedenleri)
2. Dağıtım Öncesi Kontrol Listesi (Pre-deployment Checklist)
3. Dağıtım Adımları (Sıralı komutlar ve migration akışı)
4. Doğrulama ve Sağlık Kontrolleri (Smoke Test & Health Checks)
5. Geri Alma Planı (Rollback Strategy): Beklenmedik bir arıza durumunda veri kaybı olmadan eski sürüme dönüş adımları.
Aşağıdaki yazılım değişikliği için canlıya çıkış (Production Deployment) risk analizi ve hazırlık kontrol listesi oluştur:
Değişiklik Kapsamı: [DEGISIKLIKLER_DATABASE_API_FRONTEND]
Etkilenen Sistemler: [SISTEMLER]
Planlanan Dağıtım Saati: [ZAMAN]
Çıktı Planı:
1. Risk Seviyesi Değerlendirmesi (Yüksek / Orta / Düşük ve nedenleri)
2. Dağıtım Öncesi Kontrol Listesi (Pre-deployment Checklist)
3. Dağıtım Adımları (Sıralı komutlar ve migration akışı)
4. Doğrulama ve Sağlık Kontrolleri (Smoke Test & Health Checks)
5. Geri Alma Planı (Rollback Strategy): Beklenmedik bir arıza durumunda veri kaybı olmadan eski sürüme dönüş adımları.
1. Risk Seviyesi: YÜKSEK (Veritabanı şema değişikliği ve ödeme altyapısı içeriyor).
2. Dağıtım Öncesi:
- Tam veritabanı yedeği alındı mı?
- Staging ortamında test senaryoları geçti mi?
- API token ve gizli anahtarlar güncellendi mi?
3. Rollback Planı:
- Veritabanı için ters migration (down) scripti hazır.
- Önceki Docker imaj etiketi (image tag) hazır tutuluyor.
Toplam 11 içerikten 1 - 11 arası gösteriliyor
Görsel Çıktı
Prompt alanlarını doldurun
Değerler yalnız bu cihazda promptu hazırlamak için kullanılır.
