design application interfaces

Modul 2 · Aplikasi katalog React dengan pencarian, filter, formulir tervalidasi, dan tes

Pilih satu API publik yang datanya menarik bagi Anda. Bangun aplikasi katalog dengan React dan TypeScript: daftar, pencarian, filter, halaman rincian, favorit yang tersimpan, dan satu formulir (misalnya ulasan atau permintaan) dengan validasi. Tulis minimal 8 tes. Tahapan pengerjaan • Kerangka: API yang dipilih beserta alasannya, peta halaman, dan rancangan pohon komponen. • Draf: Alur utama berjalan dengan data nyata dari API: daftar, pencarian, dan rincian. • Revisi: Keadaan loading, galat, dan kosong tertangani; aksesibilitas diperbaiki; tes ditambahkan sesuai umpan balik reviewer. • Final: Aplikasi terbit, README menjelaskan keputusan teknis, dan laporan Lighthouse terlampir.

Yang diserahkan: Tautan aplikasi yang sudah terbit, tautan repositori dengan README berisi keputusan teknis (struktur komponen, pengelolaan state, alasan library), hasil tes, dan laporan Lighthouse.

• Fungsi dan penanganan keadaanbobot 30% · skor 0–4

  Seluruh fitur berjalan, dan keadaan loading, galat, serta kosong ditangani dengan jelas bagi pengguna.

• Struktur komponen dan statebobot 25% · skor 0–4

  Komponen terpecah masuk akal, state berada di tempat yang tepat, dan tipe TypeScript dipakai dengan benar.

• Pengujianbobot 20% · skor 0–4

  Minimal 8 tes yang menguji perilaku penting, bukan sekadar menambah jumlah.

• Aksesibilitas dan responsifbobot 15% · skor 0–4

  Bisa dipakai dengan papan ketik, kontras cukup, dan tampilan layak di ponsel.

• Keputusan teknis tertulisbobot 10% · skor 0–4

  README menjelaskan pilihan dan trade-off dengan jujur.

Modul 1 · Aplikasi pencatat keuangan pribadi berbasis web yang terbit di internet

Bangun aplikasi web pencatat keuangan pribadi dengan HTML, CSS, dan JavaScript murni (tanpa framework). Pengguna bisa menambah dan menghapus transaksi, melihat ringkasan pengeluaran per jenis, dan datanya tetap ada setelah halaman dimuat ulang. Seluruh pekerjaan dicatat di Git. Tahapan pengerjaan • Kerangka: Sketsa setiap layar, daftar fitur, dan struktur HTML awal di repositori GitHub. • Draf: Fitur tambah, hapus, dan ringkasan berjalan, dengan minimal 10 commit yang pesannya menjelaskan perubahan. • Revisi: Perbaikan dari umpan balik reviewer, tampilan ponsel, dan validasi masukan (nominal kosong atau negatif ditolak). • Final: Aplikasi terbit di GitHub Pages, README lengkap, dan video demo yang menjelaskan satu fungsi yang Anda tulis sendiri.

Yang diserahkan: Tautan aplikasi di GitHub Pages, tautan repositori dengan README (fitur dan cara menjalankan), dan video maksimal 3 menit yang menelusuri satu fungsi JavaScript buatan Anda baris demi baris.

• Fungsi sesuai spesifikasibobot 30% · skor 0–4

  Tambah, hapus, ringkasan, dan penyimpanan berjalan benar, termasuk saat data kosong.

• Kualitas kodebobot 25% · skor 0–4

  Nama variabel dan fungsi jelas, fungsi kecil dan berfokus, tanpa duplikasi yang tidak perlu.

• Responsif dan aksesibilitas dasarbobot 20% · skor 0–4

  Tampilan layak di ponsel dan desktop, kontras cukup, dan formulir punya label.

• Riwayat Git dan READMEbobot 15% · skor 0–4

  Commit bertahap dengan pesan yang bermakna; README cukup untuk orang lain menjalankan aplikasi.

• Pemahaman sendiribobot 10% · skor 0–4

  Video membuktikan Anda memahami kode yang Anda serahkan, bukan sekadar menyalin.

Modul 3 · REST API pemesanan jadwal untuk usaha jasa, teruji dan siap dijalankan dengan Docker

Bangun REST API pemesanan jadwal untuk satu jenis usaha jasa. Wajib ada: pendaftaran dan login, peran admin dan pelanggan, pengelolaan layanan dan jadwal oleh admin, pemesanan oleh pelanggan yang menolak jadwal bentrok, dokumentasi OpenAPI, tes otomatis, dan docker compose yang langsung jalan. Tahapan pengerjaan • Kerangka: Diagram model data (ERD), kontrak OpenAPI untuk seluruh endpoint, dan daftar aturan bisnis. • Draf: Endpoint inti berjalan dengan autentikasi dan migrasi basis data. • Revisi: Aturan jadwal bentrok, validasi masukan, tes integrasi, dan perbaikan keamanan sesuai umpan balik reviewer. • Final: Repositori lengkap, docker compose berjalan, koleksi uji, dan video demo.

Yang diserahkan: Tautan repositori dengan README (cara menjalankan, keputusan rancangan), berkas OpenAPI, koleksi uji (Postman atau sejenisnya), hasil tes, dan video demo maksimal 5 menit.

• Kebenaran aturan bisnisbobot 25% · skor 0–4

  Pemesanan bentrok ditolak, peran dihormati, dan kasus tepi diuji.

• Rancangan API dan databobot 25% · skor 0–4

  Endpoint, kode status, dan skema konsisten; kontrak OpenAPI sesuai implementasi.

• Keamananbobot 25% · skor 0–4

  Kata sandi di-hash, otorisasi diperiksa di setiap endpoint, masukan divalidasi, dan rahasia tidak ada di repositori.

• Pengujianbobot 15% · skor 0–4

  Tes mencakup aturan bisnis utama dan bisa dijalankan dengan satu perintah.

• Siap dijalankan orang lainbobot 10% · skor 0–4

  docker compose dan README cukup untuk menjalankan proyek tanpa bertanya.

Modul 5 · Aplikasi SaaS multi-tenant dengan fitur AI, isolasi tenant yang terbukti, dan kuota biaya AI

Bangun SaaS multi-tenant untuk satu kebutuhan bisnis yang Anda pilih. Minimal satu fitur AI harus menyelesaikan pekerjaan nyata pengguna, bukan sekadar kotak obrolan. Buktikan tenant A tidak bisa melihat data maupun pengetahuan AI tenant B, dan tunjukkan kuota AI per tenant ditegakkan. Tahapan pengerjaan • Kerangka: Masalah pengguna, model data, pilihan isolasi tenant beserta alternatif yang ditolak, desain API, dan wireframe. • Draf: Alur utama berjalan ujung ke ujung untuk dua tenant, termasuk autentikasi dan otorisasi. • Revisi: Fitur AI berjalan lewat antrean, tes isolasi tenant otomatis, CI/CD aktif, dan umpan balik reviewer ditindaklanjuti. • Final: Deploy yang bisa diakses reviewer, kuota biaya AI per tenant, dokumen keputusan arsitektur, dan video demo.

Yang diserahkan: Tautan aplikasi yang ter-deploy beserta akun uji untuk dua tenant, repositori, dokumen keputusan arsitektur maksimal 4 halaman, dan video demo maksimal 7 menit.

• Keputusan arsitekturbobot 25% · skor 0–4

  Pilihan isolasi tenant, pembagian sinkron dan asinkron, serta batas modul dibenarkan dan alternatifnya dibahas.

• Isolasi data tenantbobot 25% · skor 0–4

  Isolasi terbukti lewat tes otomatis, termasuk untuk pengetahuan AI; tidak ada jalur kebocoran yang ditemukan reviewer.

• Nilai fitur AIbobot 20% · skor 0–4

  Fitur AI menyelesaikan pekerjaan nyata, menangani kegagalan model dengan baik, dan biayanya terkendali.

• Kualitas rekayasabobot 20% · skor 0–4

  Kode rapi, tes bermakna, CI/CD berjalan, dan rahasia aman.

• Pengalaman penggunabobot 10% · skor 0–4

  Alur utama jelas dan status pekerjaan AI (sedang diproses, gagal) terkomunikasikan.

Modul 4 · Refactor terukur atas satu modul kode warisan open source dengan bantuan AI

Pilih satu modul dari proyek open source yang punya kode sulit dirawat (fungsi panjang, duplikasi, tanpa tes). Kunci perilakunya dengan tes, lalu refactor bertahap dengan bantuan asisten coding AI. Setiap usulan AI yang Anda terima, ubah, atau tolak harus tercatat beserta alasannya. Tahapan pengerjaan • Kerangka: Modul yang dipilih, peta masalahnya (dengan metrik sederhana seperti panjang fungsi atau duplikasi), dan rencana langkah refactor. • Draf: Tes karakterisasi yang lulus terhadap kode asli, ditambah separuh langkah refactor dalam commit-commit kecil. • Revisi: Refactor selesai dengan perbaikan dari umpan balik reviewer. Log keputusan AI: minimal 10 usulan beserta keputusan Anda. • Final: Metrik sebelum dan sesudah, catatan bug yang Anda temukan dari usulan AI, dan pedoman penggunaan AI satu halaman untuk tim.

Yang diserahkan: Tautan fork repositori dengan riwayat commit, log keputusan AI (tabel usulan, keputusan, alasan), dan dokumen ringkas maksimal 3 halaman berisi metrik sebelum dan sesudah serta pedoman tim.

• Perilaku tetap terjagabobot 30% · skor 0–4

  Tes karakterisasi mencakup jalur penting dan tetap lulus setelah refactor; tidak ada perubahan perilaku yang tidak disengaja.

• Kualitas refactorbobot 25% · skor 0–4

  Struktur kode benar-benar lebih mudah dirawat dan metriknya membaik; commit kecil dan bisa di-review.

• Review kritis terhadap usulan AIbobot 30% · skor 0–4

  Usulan yang salah atau berisiko dikenali dan ditolak dengan alasan teknis yang tepat.

• Pedoman timbobot 15% · skor 0–4

  Pedoman penggunaan AI praktis, spesifik, dan bisa langsung diterapkan.

REST API pemesanan jadwal untuk usaha jasa, teruji dan siap dijalankan dengan Docker

Bangun REST API pemesanan jadwal untuk satu jenis usaha jasa. Wajib ada: pendaftaran dan login, peran admin dan pelanggan, pengelolaan layanan dan jadwal oleh admin, pemesanan oleh pelanggan yang menolak jadwal bentrok, dokumentasi OpenAPI, tes otomatis, dan docker compose yang langsung jalan. Tahapan pengerjaan • Kerangka: Diagram model data (ERD), kontrak OpenAPI untuk seluruh endpoint, dan daftar aturan bisnis. • Draf: Endpoint inti berjalan dengan autentikasi dan migrasi basis data. • Revisi: Aturan jadwal bentrok, validasi masukan, tes integrasi, dan perbaikan keamanan sesuai umpan balik reviewer. • Final: Repositori lengkap, docker compose berjalan, koleksi uji, dan video demo.

Yang diserahkan: Tautan repositori dengan README (cara menjalankan, keputusan rancangan), berkas OpenAPI, koleksi uji (Postman atau sejenisnya), hasil tes, dan video demo maksimal 5 menit.

• Kebenaran aturan bisnisbobot 25% · skor 0–4

  Pemesanan bentrok ditolak, peran dihormati, dan kasus tepi diuji.

• Rancangan API dan databobot 25% · skor 0–4

  Endpoint, kode status, dan skema konsisten; kontrak OpenAPI sesuai implementasi.

• Keamananbobot 25% · skor 0–4

  Kata sandi di-hash, otorisasi diperiksa di setiap endpoint, masukan divalidasi, dan rahasia tidak ada di repositori.

• Pengujianbobot 15% · skor 0–4

  Tes mencakup aturan bisnis utama dan bisa dijalankan dengan satu perintah.

• Siap dijalankan orang lainbobot 10% · skor 0–4

  docker compose dan README cukup untuk menjalankan proyek tanpa bertanya.

Aplikasi SaaS multi-tenant dengan fitur AI, isolasi tenant yang terbukti, dan kuota biaya AI

Bangun SaaS multi-tenant untuk satu kebutuhan bisnis yang Anda pilih. Minimal satu fitur AI harus menyelesaikan pekerjaan nyata pengguna, bukan sekadar kotak obrolan. Buktikan tenant A tidak bisa melihat data maupun pengetahuan AI tenant B, dan tunjukkan kuota AI per tenant ditegakkan. Tahapan pengerjaan • Kerangka: Masalah pengguna, model data, pilihan isolasi tenant beserta alternatif yang ditolak, desain API, dan wireframe. • Draf: Alur utama berjalan ujung ke ujung untuk dua tenant, termasuk autentikasi dan otorisasi. • Revisi: Fitur AI berjalan lewat antrean, tes isolasi tenant otomatis, CI/CD aktif, dan umpan balik reviewer ditindaklanjuti. • Final: Deploy yang bisa diakses reviewer, kuota biaya AI per tenant, dokumen keputusan arsitektur, dan video demo.

Yang diserahkan: Tautan aplikasi yang ter-deploy beserta akun uji untuk dua tenant, repositori, dokumen keputusan arsitektur maksimal 4 halaman, dan video demo maksimal 7 menit.

• Keputusan arsitekturbobot 25% · skor 0–4

  Pilihan isolasi tenant, pembagian sinkron dan asinkron, serta batas modul dibenarkan dan alternatifnya dibahas.

• Isolasi data tenantbobot 25% · skor 0–4

  Isolasi terbukti lewat tes otomatis, termasuk untuk pengetahuan AI; tidak ada jalur kebocoran yang ditemukan reviewer.

• Nilai fitur AIbobot 20% · skor 0–4

  Fitur AI menyelesaikan pekerjaan nyata, menangani kegagalan model dengan baik, dan biayanya terkendali.

• Kualitas rekayasabobot 20% · skor 0–4

  Kode rapi, tes bermakna, CI/CD berjalan, dan rahasia aman.

• Pengalaman penggunabobot 10% · skor 0–4

  Alur utama jelas dan status pekerjaan AI (sedang diproses, gagal) terkomunikasikan.

Asisten pengetahuan RAG untuk satu kumpulan dokumen nyata, lengkap dengan set uji

Pilih satu kumpulan dokumen nyata yang boleh Anda pakai (minimal 30 dokumen, boleh dokumen publik seperti peraturan atau dokumentasi produk open source). Bangun asisten tanya-jawab di atasnya dan buktikan kualitasnya dengan angka. Tahapan pengerjaan • Kerangka: Dokumen yang dipilih dan alasannya, 20 pertanyaan uji beserta jawaban yang benar (termasuk minimal 5 pertanyaan yang jawabannya TIDAK ada di dokumen), dan rancangan arsitektur satu halaman. • Draf: Pipeline berjalan ujung ke ujung: ingest, embedding, pengambilan, jawaban dengan kutipan. Hasil pertama terhadap 20 pertanyaan uji. • Revisi: Perbaikan berdasarkan umpan balik reviewer dan hasil uji: strategi chunking, pengambilan gabungan, atau prompt. Tunjukkan angka sebelum dan sesudah. • Final: Repositori lengkap, video demo maksimal 5 menit, dan laporan evaluasi akhir termasuk satu skenario pembatasan akses dokumen.

Yang diserahkan: Tautan repositori Git (README berisi cara menjalankan), laporan evaluasi PDF maksimal 4 halaman berisi tabel hasil 20 pertanyaan uji, dan tautan video demo maksimal 5 menit.

• Ketepatan dan pembumian jawabanbobot 30% · skor 0–4

  Jawaban benar menurut dokumen, setiap klaim punya kutipan sumber yang bisa dicek, dan pertanyaan di luar dokumen dijawab 'tidak ditemukan' alih-alih dikarang.

• Kualitas pengambilanbobot 25% · skor 0–4

  Strategi chunking dan pengambilan dipilih dengan alasan, dan perbaikannya terukur antara draf dan final.

• Evaluasi yang jujurbobot 20% · skor 0–4

  Set uji mencakup kasus sulit dan kasus tanpa jawaban; angka dilaporkan apa adanya termasuk kegagalan.

• Keamanan akses dokumenbobot 15% · skor 0–4

  Pengguna tidak bisa mendapatkan isi dokumen yang bukan haknya lewat pertanyaan apa pun yang diuji.

• Kerapian rekayasabobot 10% · skor 0–4

  Kode bisa dijalankan orang lain dari README, kunci API tidak ada di repositori, biaya per pertanyaan diperkirakan.