Fakultas Ilmu Komputer UI

Commit 05975053 authored by Usama's avatar Usama
Browse files

Add string for photos

parents 2569cdee 8f25c0e0
Pipeline #11352 passed with stages
in 1 minute and 57 seconds
---
layout: post
title: APT
date: 2019-04-02 9.58.58 +0700
author: yogi
---
Pada blog minggu ini, saya akan menceritakan pengalaman saya mengenai APT, bukan Advanced Package Tool, melainkan:
<!--more-->
Agile, Persona, dan TDD(lagi).
Seperti yang telah dipelajari di mata kuliah Rekayasa Perangkat Lunak, terdapat 4 Agile Manifesto,
berikut adalah pengalaman saya terhadap penerapan Agile di kelompok:
**Individuals and interactions over processes and tools**
Ketika kami menemukan sebuah permasalahan, seperti terdapat conflict ketika akan menge-push sesuatu,
kami akan bertanya langsung kepada individu yang bersangkutan secara tatap muka ketimbang melalui personal computer.
Hal ini menunjukkan bahwa walaupun kami menggunakan peralatan dan teknologi yang canggih, namun hubungan antar insan masih lebih penting.
**Working software over comprehensive documentation**
Secara historis, sejumlah besar waktu dihabiskan untuk mendokumentasikan produk untuk pengembangan dan pengiriman akhir.
Daftar ini luas dan merupakan penyebab keterlambatan panjang dalam pengembangan.
Agile tidak menghilangkan dokumentasi, tetapi merampingkannya dalam bentuk yang memberikan pengembang apa yang diperlukan untuk melakukan pekerjaan tanpa terjebak dalam hal-hal kecil.
Saat membangun kode, kami selalu berusaha agar kode yang dihasilkan dapat dipahami oleh orang lain sehingga tidak membutuhkan banyak dokumentasi.
Hal ini menunjukkan bahwa walaupun dokumentasi merupakan hal yang esensial, namun software yang bekerja lebih krusial.
**Customer collaboration over contract negotiation**
Dalam pengembangan proyek, kami sering berinteraksi dengan Product Owner kami, yaitu BPPT baik ketika memulai proyek maupun ketika sprint review.
Bahkan kami juga pernah bertamu ke sana untuk menanyakan beberapa hal yang masih kurang jelas.
Kami juga memiliki sebuah group whastapp agar dapat mengetahui keinginan dari klien.
Hal ini menunjukkan bahwa walaupun kami terikat, namun kooperasi dengan klient lebih berarti.
**Responding to change over following a plan**
Beberapa perubahan telah kami lakukan ketika mengerjakan proyek kali ini.
Dimulai dari ingin menggunakan bahasa go untuk pengimplementasian back-end hingga penggunaan elastic search yang diperkenalkan Pak Adin.
Hal ini menunjukkan bahwa walaupun terdapat perencanaan yang matang, namun perubahan yang lebih fleksibel akan jauh lebih berharga.
Kesimpulan dari manifesto ini adalah yang mana walau terdapat nilai di sebelah kanan, kita lebih menghargai yang di sebelah kiri.
Sesudah mencerna apa itu Persona, saya akan menjelaskan kaitannya dengan proyek kami:
Tujuan situs kami adalah untuk mendeteksi serangan terhadap website yang ada di BPPT
Goal situs kami adalah dapat menemukan serangan dan menyaringnya berdasarkan kategori
Terdapat 3 orang yang menjadi sasaran dari pengguna website kami, yaitu kepala balai, sekretaris, dan staf.
Setelah membaca-baca mengenai TDD, terutama manfaatnya, saya mempelajari beberapa hal, yaitu:
Bagi tester, TDD dapat mengurangi kebutuhan untuk pengecekan secara manual.
Bagi developer, TDD dapat meminimalisir jumlah bug dan cost of change
Bagi product owner, TDD dapat mengurangi pengeluaran untuk hal-hal yang dirasa tidak penting.
Salah satu penyebab utama dari lambatnya pengembangan adalah miskomunikasi antara PO dan developer.
Dengan menerjemahkan kebutuhan bisnis ke dalam spec sebelum menulis kode, kita dapat menjamin apa yang kita inginkan adalah yang akan dibangun.
Selain itu, TDD dapat dijadikan acuan, sehingga apabila tim pengembang berganti, perubahan dapat dilakukan dengan mudah dan tim QA akan menghadapi lebih sedikit regresi.
---
layout: post
title: Focused Code
date: 2019-04-02 08.51.23 +0700
author: abi
---
Salah satu indicator dari clean code adalah setiap class, function, dan module memiliki tujuan dan cakupan yang jelas.
Di tulisan ini saya akan mencontohkan apa yang sudah kami lakukan di tim PPL kami.
<!--more-->
**Focused Class**
Tim kami menerapkan pattern satu higher order component untuk setiap halaman di frontend. Component ini bertanggung jawab untuk memanggil component dan module lain yang dibutuhkan di halaman itu.
**Focused Function**
Fungsi yang memiliki satu tujuan akan lebih mudah dibuat modular dibanding fungsi yang memiliki banyak side effect. Contohnya di kode kami adalah fungsi showToaster untuk menampilkan toaster dengan message dan intent tertentu. Fungsi ini bisa digunakan di dalam fungsi lain yang memerlukan toaster untuk ditampilkan dengan sangat mudah. Dengan begitu kita dapat menghindari menulis duplicate code
Fungsi showToaster
```
const showToaster = (messages, intent) => {
if (typeof messages === "string") messages = [messages];
messages.forEach(message => {
CoolToaster.DefaultToaster.show({ message, intent, timeout: 3000 });
});
};
```
Contoh penggunaannya di fungsi lain
```
handleSubmit(event) {
event.preventDefault();
let valid = true;
if (this.state.password.length === 0) {
CoolToaster.showDanger("Password can't be blank");
valid = false;
}
if (this.state.username.length === 0) {
CoolToaster.showDanger("Username can't be blank");
valid = false;
}
if (valid) {
this.setState({ loading: true });
this.props.login(
this.state.username,
this.state.password,
this.props.callback
);
}
}
```
**Focused Module**
Untuk berkomunikasi dengan backend, kami membuat sebuah module api yang bertanggung jawab untuk mengirimkan request dan menerima response dari backend. Contoh lainnya adalah module Auth yang digunakan untuk autentikasi client-side.
Contoh fungsi di module auth
```
static isLoggedIn() {
const user = JSON.parse(localStorage.getItem("loggedUser"));
if (user && user.role !== "guest") {
return true;
}
return false;
}
```
---
layout: post
title: Monorepo
date: 2019-04-02 07.46.05 +0700
author: abi
---
Ada 2 tipe _repository_ yang saat ini sering diperdebatkan di industri. _Monolithic Repository_ (Monorepo) dan _Multiple Repository_ (Multirepo).
Di tulisan ini saya akan mencoba untuk membahas kelebihan dan kekurangan dari sistem monorepo.
<!--more-->
Monorepo adalah sebuah strategi dalam _software development_ dimana kode dari berbagai _project_ disimpan di satu _repository_ yang sama.
Ada beberapa kelebihan yang didapatkan dengan menggunakan metode ini, diantaranya yang paling sering menjadi argumen untuk menggunakan monorepo adalah:
**Ease of code reuse**
_Class_ atau _function_ yang memiliki kemiripan dapat dijadikan abstraksi di _shared library_ yang di _include_ masing-masing _project_ tanpa menggunakan _package manager_.
**Simplified dependency management**
Di sistem multirepo dimana ada beberapa _project_ yang membutuhkan _dependency_ _third party_ yang sama, _dependency_ tersebut seringkali di _download_ atau _build_ berulang kali di masing-masing _project_. Dengan menggunakan monorepo, semua _project_ dapat menggunakan _dependency_ yang sama tanpa perlu mengulang untuk setiap _project_.
**Large-scale code refactoring**
Karena developer memiliki akses ke semua _project_, ketika melakukan _refactor_ akan bisa dilakukan _test_ menyeluruh kepada semua _project_ untuk memastikan semua tetap berjalan.
**Collaboration across teams**
Sebuah tim dapat mengembangkan fitur dari _project_ tim lain dengan mudah.
Meskipun begitu ada beberapa kelemahan yang sering ditemukan ketika menggunakan monorepo, yaitu:
**Code Ownership**
Dengan monorepo, kemampuan untuk melakukan limitasi akses kode tidak didapatkan secara _out of the box_.
**CI/CD**
Diperlukan waktu _build_ yang lebih lama dengan monorepo. Perlu _build tool_ tambahan untuk melakukan perbaikan _build time_. (Google Bazel, Facebook Buck, Twitter Pants)
**Collaboration is a lie**
Dengan menggunakan multirepo, komunikasi antar developer tentang suatu fitur menjadi kejadian sehari-hari. Dengan monorepo, developer akan cenderung untuk membaca kode dibanding bertanya kepada tim yang bertanggungjawab.
**Coupling**
Karena semua orang bisa mengakses dan mengedit semua fitur. Akan mudah terjadi _coupling_ dan kode kehilangan modularitasnya.
Dalam pengalaman PPL kami, sistem monorepo yang diterapkan sekarang masih sesuai dengan cara kerja tim kami. Karena hanya terdiri dari 2 _project_ (_frontend_ dan _backend_) maka development menjadi lebih cepat dan versinya akurat.
---
layout: post
title: Persona
date: 2019-04-02 09.27.10 +0700
author: abi
---
Persona merupakan cara untuk menggeneralisir segmen pengguna aplikasi yang kita buat dengan membuat karakter fiktif yang mewakilkan segmen tersebut.
Di tulisan ini saya akan menjelaskan persona yang ada pada aplikasi SIMLOMANKEJAP.
<!--more-->
**Atasan BPPT, Pak Obama**
![si bos](/assets/images/2019-04-02-persona/boss-persona.jpg)
Obama umurnya sudah 51 tahun, menjabat sebagai kepala BPPT semenjak 4 tahun lalu.
Obama memiliki jadwal sibuk karena banyak urusan BPPT yang harus ditangani.
Ia ingin agar segala informasi dapat disampaikan secara tepat dan cepat.
Karena dasar pendidikannya bukan fokus di jaringan, Obama tidak terlalu fasih akan isi dari request dan lebih tertarik melihat laporan dari serangan terhadap server saja.
Pengelihatan Obama juga sudah mulai menurun karena usianya, ia sudah sulit melihat tulisan kecil di layar laptopnya.
**Security Analyst, Pak Snowden**
![si analyst](/assets/images/2019-04-02-persona/analyst-persona.jpg)
Snowden berumur 29 tahun, menjabat sebagai security analyst di BPPT semenjak 2 tahun lalu.
Snowden memiliki latar belakang pendidikan ilmu komputer dan tertarik di bidang security.
Ia paham akan isi dari suatu request dan berbagai macam jenis serangan.
Snowden ingin agar ia bisa melihat apa isi dari serangan dengan jelas.
Ia juga ingin agar bisa melakukan pencarian log dengan mudah agar bisa melakukan analisis dengan lebih baik.
Supports Markdown
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment