Weekly Report #12 — Niken

Ken Nabila Setya
May 15, 2016 · 8 min read

Hari Senin malam, RedPanda melakukan sprint planning. Kita membagi-bagi backlog untuk 2 minggu ke depan. Saya mengambil beberapa backlog:

  • Set up continuous integration: testing task
  • Membuat representasi grafik untuk trend threshold
  • Role Management (melajutkan yang minggu lalu)

Dalam sprint ini, saya juga menargetkan untuk melakukan improvement pada backlog sebelumnya yang saya kerjakan (OOS rate trend).

Elicitation, Analysis, Specification

Pada Rabu malam, saya mempelajari kembali yang dimaksud dengan elicitaion, analysis, dan specification.

Elicitation : proses requirement gathering dari stakeholder maupun sumber lain yang dapat dilakukan dengan beberapa cara seperti JAD, interview, focous group, observasi dll.RedPanda melakukan elicitation dengan cara interview. Saya ingat sekali saat di awal-awal kedatangan RedPanda ke HF, kita sering melakukan wawancara kepada beberapa orang penting yag mengerti tentang permasalahan OOS. 
Wawancara pertama dilakukan bersama kedua mentor kita (Mas Faren dan Mas Boy) dan Pak Fajar (CTO). Kemudian kita juga mewawancarai orang operasional Mas Aldea, Mas Ikhwan, dan Mas Ipul.
Analysis : proses memecah-mecah permasalah yang didapat setelah elicitation menjadi lebih dalam dan detil serta memilah dan menentukan requirement mana yang dpt dilakukan atau tdk. Pada tahap analysis, kita mencari tahu dan mengkait-kaitan apa saja hal-hal yang diceritakan oleh narasumber kita saat interview. Kita mencoba mencari tahu apa penyebab OOS terjadi dari sisi operasional (terutama), seperti sisi supermarket, sisi customer, dan sisi kebijakan HF juga mempertimbangkan mana saja requirement yang dpt dilakukan, tidak semua requirement kita analysisSpecification : mengubah representasi user story menjadi bentuk yang lebih mudah dilihat/dikomunikasikan kepada stakeholder, kemudian dokumen tersebut nantinya akan di-verifikasi dan validasi oleh stakeholder.RedPanda melakukan specification dengan cara membuat dokumen UCS & UCD, functional & non functional requirement.

Teamwork Procedure & Git Repository Manager

Saya akan menjelaskan bagaimana teamwork procedure yang digunakan oleh RedPanda. Berikut adalah urutan prosedurnya:

1. Setiap orang di RedPanda tidak boleh ngoding langsung di master Mula-mula, kita harus membuat branch di lokal masing-masing dengan format penamaan [nama]-[backlog yang dikerjakan]. Contoh branch yang sudah pernah saya buat:
niken-oos-rate
niken-oost-rate-trend
niken-database
niken-threhold-trend
niken-role-management
2. Setelah ngoding di branch lokal masing-masing. Kode tersebut di-add, di-commit, dan di-push (lihat disini lebih lanjut tentang git: https://medium.com/red-panda/weekly-report-2-niken-aabbf4d2c750#.cpsgvs28y)3. Setelah di-push, branch akan masuk di halaman branch di gitlab. Kemudian lakukan merge request. Kemudian, saya assign salah satu dari RedPanda untuk mereview kode tersebut. Jika, kode belum beres maka merge request akan tetap di-open hingga kodenya diperbaiki. Yang di-assign untuk mereview akan mengomentari merge request tersebut.4. Jika kode belum diterima, saya akan kembali memperbaiki di branch lokal saya dan akan mengulangi langkah kedua hingga merge request di-accept.
Setelah accept lansgung hapus brach-nya
5. Semua merge request yang diterima sebaiknya dihapus dari daftar branch dan lokal si pembuat.
prosedur git-nya

Saya juga mecoba meng-explore gitlab. Saya mencari tahu apa saja kegunaan dari fitur2 di gitlab.com. Saya mencari tahu bagaimana melihat network di gitlab, melihat commit-an yang sudah diterima, branch yang sudah di-push, branch yang sedang open (merged request),sudah di-merge atau bahkan di-close. Saya juga tahu bagaimana progress pekerjaan teman-teman lain dengan melihat grafik kontribusinya. Saya bisa setting profile saya sendiri. Saya bisa melihat profile saya dan orang lain juga, dan masih banyak lagi.

Bug/Ticket Fixing

Ada beberapa bug yang ditemukan dan saya selesaikan ada minggu ini:

  • Saat mau spint review di HF, saya menemukan error bahwa ketika threshold baru terdata pada hari itu, data threshold tidak masuk ke dalam grafik. Kemudian saya mencari tahu segera penyebab bug tersebut pada saat itu juga. Saya menemukan kekeliruan di kode saya (logic error). Tampak pada gambar dibawahm iterasi dilakukan hingga tanggal threshold terakhir, namun nilai last baru diupdate setelah 1 hari setelahnya:
sebelum diperbaiki
Kode setelah diperbaiki
  • Lalu, di bagian role management masih ada error yaitu ketika membuat user baru, admin yang semula login akan login ke akun user baru tersebut.
Mulanya akun berada di Shyll@live.com kemudian setelah membuat akun kennabilas@gmail,com, akun berpindah
bug diatas diperbaiki dengan cukup comment kode untuk ganti session user

Backlog & Improvement (Framework Ruby on Rails)

Dari beberapa backlog minggu ini saya memilih melakukan fitur role management dan threshold trend terlebih dahulu. Selain itu saya juga melakukan improvement dan bug fixing pada backlog saya sebelumnya yaitu OOS Rate Trend.

Threshold trend saya implementasikan seperti OOS Rate trend namun ada 1 filter tambahan yaitu berdasarkan lokasi. Karena sebelumnya sudah pernah melakukan hal yang sama jadi saya tidak terlalu berat menegrjakannya.

Untuk improvement, yang saya lakukan adalah dengan menambahkan teknik ajax dalam kedua kode trend tersebut.Saya memepelajari teknik Ajax rails dari link berikut: http://stackoverflow.com/questions/26808696/rails-4-rendering-a-partial-with-ajax-jquery-remote-true-and-respond-to. Caranya sangat sederhana:

  • Add a :remote => true flag to the triggering element. Disini triggering element nya adalah form filter yang akan dipilih oleh user (ada di halaman HTML utama-nya)
  • Add “respond_to :html, :js” at the top of the controller. Tambahkan kode berikut di awal script Controller-nya.
  • Route the http verb to your controller’s method. Tambahkan di routes.rb
  • Create the partial view. Buat partial view dengan nama yang sama dengan halaman view utama namun tambahkan “_” didepannya, misal halaman html utamnya: index.html.erb maka partial view: _index.html.erb. Lalu siapkan sebuah div di index.html.erb yang merender partial view tersebut
  • Create the JQuery file

Berikut adalah hasil dari Threshold Trend:

Role management

Saya melanjutkan backlog role management yang tidak selesai pada sprint lalu. Saya menambahkan kode dimana hanya admin yang bisa melakukan create, show, edit, dan destroy user. Saya memblock halaman, tombol, link yang tidak menjadi hak user non-admin. Kemudian saya juga memperbaiki bug di role management seperti yang dijelaskan sebelumnya.

Algorithm & Data Structure

Data structure yang paling sering saya pakai adalah Active Record, yaitu sebuat struktur data yang dapat merepresentasikan relational database di rails. Saya menggunakannya sejak fitur pertama yang saya kerjakan yaitu OOS Rate. Active Record memiliki class/model dan object. Contoh class adalah: SpreeInventoryUnit, SpreeStockItem, dll.. Sedangkan contoh object adalah data masing-masing tuple di tabel database. Berikut adalah beberapa method yang sering saya pakai dan return type nya:

[collection of objects].all — mengembalikan collection of objects 
[collection of objects].find(:id) — mengembalikan sebuah objects
[collection of objects].where(condition) — mengembalikan collection of objects
[collection of objects].reverse — mengembalikan collection of objects[collection of objects].first — mengembalikan sebuah object

Saya membuat algoritma sendiri yang digunakan untuk mengambil data dari tabel dan membuatnya menjadi data utuk grafik D3 js. Grafik D3 js menerima data dengan format array, sehingga saya perlu mengubah bentuk dari active record menjadi array.

Pada mula saya membuat, data menunjukan bahwa rate tumbuh secara perlahan, padahal seharusnya rate berganti per hari/pesat.

Ilustrasi data & grafik mula-mula
Ilustrasi data dan grafik yang benar

Berikut ini adalah contoh algoritma yang saya buat untuk OOS Rate(untuk threshold kurang lebih sama) :

array_data_d3 = {}month = dipilih user dari menu dropdown 
year = dipilih user dari menu dropdown
rates = ambil semua object OOS rate di tabel yang created_at berada di month dan year start_date = tanggal pertama di month, year
end_date
= tanggal terakhir (yang bukan tanggal akan datang) di month, year
last
= 0
foreach rate in rates
for date in start_date..(rate.created_at - 1.days)
//
tambahkan tuple [date, last] ke array_data_d3
end
last = rate.oosRate
start_date
= rate.created_at
end
for date in start_date..end_date
//
tambahkan tuple [date, last] ke array_data_d3
end

Walaupun algoritma diatas memiliki looping di dalam looping, namun eksekusi perinta menambahkan tuple ke array data untuk grafik d3 tidak akan lebih banyak dari jumlah hari dari start_date hingga end_date.

Refactoring

Refactoring adalah sebuah teknik untuk mengubah bagian dalam program dan stuktur nya tanpa mengubah perilaku luar program tersebut (refactoring.com). Saya melakukan beberapa refactoring untuk kode yang saya buat sendiri, yaitu:

  • Saat membuat kode untuk OOS Rate, saya sempat menggunakan syntax break karena saat itu saya buru-buru dan kalau tidak salah saya membutuhkan sebuah syntax/function untuk mengubah dari [OOSRateObject].created_at yang berupa timestamp ke date (padahal tinggal googling wkwk), sehingga kode saya mula-mula adalah seperti ini
array_data_d3 = {}month = dipilih user dari menu dropdown 
year = dipilih user dari menu dropdown
rates = ambil semua object OOS rate di tabel yang created_at berada di month dan yearstart_date = tanggal pertama di month, year
end_date
= tanggal terakhir (yang bukan tanggal akan datang) di month, year
last
= 0
foreach rate in rates
for date in start_date..end_date
if (end_date == rate.created_at)
//
tambahkan tuple [date, last] ke array_data_d3
last = rate.oosRate
start_date
= rate.created_at
break
end
end
end
for date in start_date..end_date
//
tambahkan tuple [date, last] ke array_data_d3
end

Yang saya ketahui saat bekajar di DDP dan SDA, sebisa mungkin hindari syntax break karena tidak terlihat elegan wkwkw.

  • Saat membuat kode untuk Role Management, Pada method show, edit, create, destroy di UsersController saya menambahkan kondisi, seperti berikut:
def [nama_method]
if current_user.role == "Admin"
//perintah method ini
else
redirect_to settings_url
end
end

cara tersebut tidak efisien karena saya harus ketik berulang-ulang di setiap method. Kemudian, saya mengganti dengan cara lain yaitu dengan cara berikut:

before_filter :admin_only, only: [:show, :create, :edit, :update, :destroy].....private
def admin_only
if current_user.role != “Admin”
redirect_to settings_url
end
end

Next..

Selanjutnya minggu kedua sprint ini, saya akan melakukan Set up continuous integration: testing task dan mencoba membuat living documentation yang benar. Saya juga akan membantu teman-teman lain yang kesulitan dalam mengerjakan backlognya.

Sejauh ini saya sudah membaca-baca sedikit tentang apa itu Continuous Integration (CI). CI adalah upaya dalam pengembangan sistem dimana hasil kerja masing-masing developer dijadikan dalam satu wadah dan diintegrasi secara rutin. Wadah yang dimaksud seperti repository yang sedang RedPanda pakai skrg di GitLab. Pada PPL kali ini, CI yang dimaksud adalah adanya auto CI, sehingga integrasi antara kode masing2 developer bisa dilakukan sesering mungkin. Di Gitlab, CI dapat dilakukan pada setiap push yg dilakukan oleh setiap developer. Setelah dipush, kode akan langsung dijalankan oleh sebuah Runners ke dalam 3 tahap: Build, Test (nanti ini yang akan saya kerjakan), Deploy. Ketika ketiga tahap tersebut selesai dijalankan dan berhasil, maka di project happystock akan ada tanda contreng berwarna hijau.

Kalau di GitLab, berikut adalah langkap umum melakukan CI:

  1. membuat file .gitlab-ci.yml -> sudah ada file ini di happystock
  2. membuat script Runners

Saat ini di happystock status build script-nya masih failed

Belum banyak yang saya ketahui tentan CI. Semoga kedepannya semakin banyak ilmu yang saya dapat. AMINNNN!

Red Panda

We are @firza_pratama, @idadidut, @irfan3, @kennabila, @pnteresa, and @shylla working on a challenging Software Engineering project at HappyFresh. Here, we share our stories.

Ken Nabila Setya

Written by

Red Panda

Red Panda

We are @firza_pratama, @idadidut, @irfan3, @kennabila, @pnteresa, and @shylla working on a challenging Software Engineering project at HappyFresh. Here, we share our stories.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade