#Althea — Week 4&5 Report: Individual Review 3

(Warning: post ini sangat panjang. Terdiri dari 2 bagian utama: Week 4 dan Week 5. Week 4 berisi apa yang sudah dilakukan + penjelasannya, dan kendala yang sempat dihadapi. Week 5 berisi apa yang sudah dilakukan + penjelasannya)

Sprint 1, Week 4: The Real Sprint

Alokasi waktu total: 37–38 jam

Yang dilakukan di minggu ini:

  1. Mempelajari cara kerja git, gitlab, dan laravel dengan cara mengikuti tutorial dari Youtube
  2. Mempelajari cara kerja gitlab ci runner dari tutorial di scele
  3. Mengerjakan wister: membuat halaman archive dan document (termasuk master & home) yang terintegrasi dengan database
  4. Daily meeting, membuat catatan, dll

Berikut ini penjelasan dari poin 1, 2, dan 3:

  1. Tutorial Git, GitLab, dan GitLab CI Runner. Pertama, saya mulai dengan menonton video mengenai git dari Codemy di Youtube dan mencobanya langsung di laptop saya (link: https://www.youtube.com/watch?v=uUuTYDg9XoI&list=PLjQo0sojbbxVHcVN4h9DMu6U6spKk21uP). Dari sini akhirnya saya mulai mengerti tentang git. Ternyata, git adalah sebuah software yang terinstall di masing-masing PC (lokal) yang berfungsi sebagai version control application. Maksudnya adalah git mencatat setiap perubahan yang terjadi di repository git dan bisa membandingkannya dengan branch lain. Dan ternyata, untuk setiap branch yang berbeda, isi dari repository git juga berbeda. Jadi, ketika kita ada di branch A, isi dari folder kita bisa dibilang folder versi A. Lalu, jika kita checkout(pindah) ke branch lain, misalnya branch B, maka di folder yang sama, isinya akan berbeda, sebut saja folder versi B. Lantas kedua folder ini dapat disatukan dengan merge. Jika terdapat perubahan di file yang sama di kedua branch, maka akan terjadi conflict. Solusinya, salah satu harus pull ulang agar mendapatkan versi terbaru, lalu baru merge. Di sini juga akhirnya saya mengerti tentang perbedaan add dan commit. Add berarti kita menambahkan perubahan ke dalam “catatan” git, entah itu menambah file baru, mengubah file yang sudah ada, ataupun menghapus file. Lalu, ketika kita melakukan commit, seluruh perubahan itu (“catatan” itu) akan terbungkus ke dalam satu commit. Commit bisa diartikan juga kita menambah satu entry log ke dalam git kita. Sebaiknya, satu commit untuk satu fitur. Misal, kita menambah fitur A dan fitur B, maka sebaiknya setelah kita menyelesaikan fitur A, kita langsung commit “menambah fitur A”, baru setelah itu kita membuat fitur B dan melakukan commit “menambah fitur B” — bukan langsung menjadikannya satu commit “menambah fitur A dan B”. Setelah kita melakukan commit (bisa satu atau lebih), kita dapat melakukan push agar fitur/perubahan yang telah kita buat tersimpan ke dalam remote (GitLab) dan dapat dipull oleh anggota lain. Setelah mengetahui cara kerja Git dan Gitlab, saya mencoba mengikuti tutorial gitlab ci runner di scele. Dari sini, saya mulai mengerti sedikit mengenai testing di gitlab. Intinya, file .yml berisi kumpulan script yang ingin dijalankan untuk testing (biasanya dengan memanggil file lain). File yang dipanggil merupakan file yang mengatur parameter keberhasilan. Jika berhasil, maka di pipeline testing akan menghasilkan passed. Jika gagal, maka failed. Untuk setiap commit yang terjadi, runner akan menjalankan semua testing dari awal lagi. Jika ada commit yang hasil testnya failed, kita dapat melihat ke job untuk mengetahui test apa yang gagal dan kita dapat melihat runner(?)(intinya semacam shell di gitlab) untuk mengetahui di mana letak gagalnya (apa yang membuat gagal). Selain dari kedua tutorial di atas, saya juga membaca tutorial dari postnya Nadiyah (PPLC5). Dari sini, saya mulai mengetahui keberadaan .gitignore yang fungsinya baru saya pahami seiring berjalannya waktu.
  2. Tutorial Laravel. Setelah mengetahui tentang Git, saya menonton tutorial mengenai Laravel dari Sekolah Koding di Youtube dan mencobanya di laptop (link: https://www.youtube.com/watch?v=rJBoxq9UsLM&list=PLCZlgfAG0GXDlNd0Flz20xksNtJQZWywz). Dari sini, akhirnya saya mengerti tentang konsep dan alur MVC (Model, View, Controller) di Laravel. Pertama, kita dapat membuat tabel database yang terintegrasi dengan laravel dengan menggunakan fungsi migrate dari php artisan. Artisan adalah sebuah package untuk php yang membuat kita dapat melakukan banyak hal, termasuk auto generate file (artisan make:[something]) yang berfungsi membuat file migration, controller, model, dll. Lokasi dari file migrations ini terletak di database/migrations. Selanjutnya, kita dapat mengisi dan mengakses tabel tersebut dengan menggunakan fitur Eloquent. Salah satu tools yang dapat digunakan untuk mengisi dan mengakses tabel adalah Tinker (semacam bash untuk Eloquent). Cara kerja eloquent adalah dengan menggunakan model. Ketika kita membuat tabel plural (mis: Members), maka ketika kita membuat model Member, otomatis model tsb akan terintegrasi dengan tabel Members. Tapi, jika nama tabel dan model kita berbeda, kita dapat secara eksplisit mengaturnya dalam kelas model kita (protected $table= “Members”). Model ini dapat digambarkan sebagai sebuah super-array yang berisi banyak sub-array yang masing-masing sub-array tersebut adalah row dari tabel kita. Letak dari file model ini berada di folder app/. Selanjutnya, data di dalam tabel dapat diambil dengan menggunakan controller. Letak file controller ini berada di folder app/Http/Controllers. Di dalam controller ini, kita dapat menggunakan model yang sudah ada dengan cara membuat function. Kita dapat memanggil data secara single (satu row), selective (data dengan kriteria tertentu), ataupun semuanya. Data tersebut kemudian dapat langsung direturn di dalam function ataupun dilempar ke view. Umumnya adalah data akan dilempar ke view yang terdapat di dalam folder resources/views. Di view ini, kita dapat mengakses nilai dari data kita dengan memanfaatkan blade template dan mengatur tampilannya dengan menggunakan html. Selain untuk mengakses nilai dengan {{model->$element}}, blade template juga dapat dimanfaatkan untuk membuat master page (semacam interface). Nantinya, setiap page yang meng-extends master page ini akan memiliki atribut sesuai master page, misalnya judul, menu, dll, sehingga kita tidak perlu mengaturnya di setiap page. Hal ini tentunya akan memudahkan penyeragaman halaman. Cara untuk memanfaatkan master page ini: di dalam master page, buat sebuah section yang dapat diisi dengan cara menuliskan @yield(‘namasection’). Selanjutnya, di setiap page lain, kita tinggal menuliskan @extends (‘namafilemaster’) dan mengisi konten dengan cara menuliskan @section(‘namasection’) [isi section] @stop. Selain kedua hal di atas, blade tempate juga dapat dimanfaatkan untuk melakukan looping dan fungsi if di dalam html. Misalnya dari controller kita mendapatkan data members yang merupakan super-array berisi sub-array member. Kita dapat menggunakan @foreach ($members as $member) {@if (something) {do something} @endif} @endforeach. Artinya, untuk setiap sub-array member di dalam super-array members, if something terpenuhi, do something. Kita menggunakan “$” sebagai tanda bahwa kata yang akan dipanggil merupakan variabel, bukan string. Setelah kita selesai membuat view, selanjutnya kita mengatur route yang dapat mengatur address untuk menampilkan view kita. File untuk mengatur route ada di folder route/web.php. Di sini, kita dapat mengatur route dengan declare Route::[get/post](‘/address’) {return view (view_page)} atau Route::[get/post](‘/address’, Controller@function). Pada opsi pertama, kita langsung melempar ke view — artinya untuk address ini, tampilkan halaman itu. Sementara untuk opsi kedua, kita melempar ke suatu function di controller— artinya untuk address ini, jalankan function itu di controller ini, baru nantinya function di dalam controller yang akan melempar ke view.
  3. Membuat pages di Wister. Terdapat 4 halaman yang saya buat, yakni master page (berisi judul dan menu), home page (seadanya, hanya agar route “/”nya tetap), archive page, dan document page. Sebenarnya archive page saya hanya mengubah dummy-archive page yang sudah dibuat Bram agar menggunakan blade template sehingga dapat terintegrasi dengan database dan tinggal looping untuk membuat list dan dropdownnya.

Kendala:

  1. Tidak tahu cara akses branch yang ada di GitLab. Ketika saya pertama akses gitlab melalui git (cmd), otomatis saya masuk ke branch master. Saya tahu cara untuk pindah ke branch lain adalah dengan menggunakan git checkout. Tetapi, ketika saya menjalankan git branch, tidak ada opsi branch develop dll, hanya ada branch lokal saya. Saya baru bisa pindah branch yang terhubung ke gitlab setelah saya membuat branch baru dari git. Akhirnya, setelah saya bertanya kepada kelompok, keesokan harinya Syukri menyarankan untuk langsung melakukan git checkout (abaikan opsi yang tidak ada di git branch) dan kak Nabila mengonfirmasi bahwa memang harus checkout terlebih dahulu, baru opsinya muncul di git branch.
  2. Laravel yang berbeda. Setelah saya dapat melakukan checkout antar branch, saya mendapati bahwa isi folder laravel yang terdapat di branch develop (milik Helmi) berbeda dengan folder laravel yang ada di branch navigasi_archive (milik Bram), dan keduanya berbeda dengan folder laravel lokal saya. Perbedannya: laravelHelmi sizenya kecil karena tidak ada folder vendor, isinya ada banyak folder dan file; laravelBram sizenya besar karena ada vendor, tapi isinya sedikit, hanya ada sekitar 3 folder; laravelThea sizenya besar karena ada vendor, dan isinya ada banyak folder dan file. Akhirnya, setelah keesokan harinya saya bertanya pada Syukri, ia mengonfirmasi bahwa vendor memang tidak dimasukkan ke dalam gitlab karena akan memberatkan orang yang mau melakukan pull (memang waktu checkout ke navigasi_archive yang isinya laravelBram, lamanya keterlaluan). Saat itu saya belum mengetahui tentang .gitignore. Baru beberapa waktu kemudian saya mengetahui keterkaitan antara /vendor dengan .gitignore (intinya, .gitignore adalah list semua file yang tidak akan terdeteksi oleh git, sehingga tidak perlu diadd, commit, dan push. Salah satu listnya adalah /vendor).
  3. Versi laravel yang berbeda. Ada 3 cerita mengenai perbedaan versi laravel ini. Cerita pertama terjadi ketika saya mencoba pull develop dari navigasi_archive. Terdapat conflict yang intinya mengatakan filenya beda. Setelah dicek filenya, ternyata beda versi. Punya Bram v5.4.15, punya Helmi v5.4.16. Perbedaan versi ini menyebabkan isi beberapa file-yang-ga-ngerti-isinya-apa menjadi berbeda. Akhirnya, (kalau tidak salah) saya mengubah isi file laravelBram agar sama dengan file laravelHelmi secara manual. Selanjutnya, branch navigasi_archive tidak tersentuh sampai cerita kedua karena semua fitur dibuat di navigasi_dokumen (ini adalah sebuah kesalahan karena saya saat itu tidak berani mengotak-atik branch navigasi_archive sehingga semua dikerjakan di branch navigasi_dokumen). Cerita kedua terjadi saat semua fitur sudah selesai dikerjakan. Kasusnya sama seperti kasus pertama: mau pull develop dari navigasi_archive tapi tidak bisa karena banyak conflict. Setelah diselesaikan (diedit isinya secara manual agar sama) dan berhasil dipull, ternyata tidak bisa dijalankan karena ada masalah di file-entah-apalah, yang intinya lagi-lagi karena beda versi. Akhirnya, karena desperate, saya hapus semua file dari navigasi_archive (setelah dibackup tentunya), lalu mengisinya dengan file dari navigasi_dokumen. Barulah setelah itu branch navigasi_archive bisa dijalankan. Cerita ketiga terjadi saat Samyang mencoba menjalankan wister dari laptopnya. Terdapat error di file yang terdapat di dalam vendor, yang kemudian setelah dicek, isinya berbeda. Lagi-lagi karena beda versi. Akhirnya, saya mengupload folder vendor saya ke drive agar dapat didownload oleh Samyang. Setelah mengganti folder vendor (entah dari download atau update laravel), akhirnya aplikasi dapat dijalankan.
  4. Database di Heroku. Sebelumnya saya sudah tahu bahwa di Heroku, default database yang digunakan adalah PostgreSQL (dan saya sudah pernah menggunakannya saat menjalankan tutorial, sehingga sudah terbukti bisa jalan). Tapi saat itu kesepakatannya: kita tambah add-ons aja yang bisa menjalankan mySQL. Maka, saya mencoba mencari add-ons di Heroku untuk mySQL dan hanya ada satu: ClearDB. Namun, ketika saya coba install (yang paket free), dibilang katanya harus add data credit card dll. Akhirnya, karena tidak ada yang mengerti soal ini, masalah ini pun terlupakan dan kami fokus membuat aplikasinya terlebih dahulu.

Sprint 2, Week 5

Alokasi waktu total: 20 jam

Yang dilakukan di minggu ini:

  1. Mempelajari testing laravel dan code convention
  2. Menjalankan wister dengan PostgreSQL: install PostgreSQL, install phpPgAdmin, ubah settingan ini itu, ubah atribut kolom DB Wister jadi lowercase semua
  3. Mengerjakan wister: membuat fitur untuk menambah konten dokumen dan mengedit konten dokumen yang sudah ada
  4. Sprint planning, daily meeting, menulis blog, dll

Penjelasan:

Testing Laravel. Di laravel, semua testing file dimasukkan ke dalam folder /tests. Terdapat dua folder di dalam folder tests ini, yakni Feature dan Unit. Feature berisi testing yang berskala besar (misal beberapa file sekaligus), sementara unit berisi testing yang berskala kecil, seperti method/function. Untuk menjalankan test, script yang digunakan adalah phpunit. Di dalam laravel, file phpunit akan menjalankan semua test file yang berada di dalam folder /tests.

Code convention. Code convention adalah aturan penulisan kode. Contoh: penggunaan spasi/tab, jumlah karakter per baris, penggunaan tanda kurung, penggunaan comment, pengaturan nama, dll. Kegunaannya adalah agar penulisan kode rapi sehingga mudah dibaca dan dipahami oleh orang lain. Untuk PHP, code convention diatur dalam PSR (PHP Standard Recommendation). Berikut ini beberapa aturannya: untuk indenting, menggunakan 4 spasi, bukan tab. Satu baris sebaiknya <120 karakter, namun disarankan <80 karakter. Untuk name convention (aturan penamaan): class name menggunakan StudlyCaps. Class constant menggunakan UPPER_CASE kecuali true, false, null. Method menggunakan camelCase.

Mengerjakan Wister. Di sprint sebelumnya, metode yang digunakan hanya get, yakni mengambil dari server dan menampilkannya. Di sprint kali ini, saya membuat fitur dengan metode post, yakni membaca input dan memberikannya ke server (database). Masih dengan metode MVC, berikut ini alurnya:

  1. Add content. Pertama, buat link “add new content” yang akan mendirect user ke halaman form dengan alamat /address0{id_doc}, tambahkan di route jika /address0{id_doc} maka controller@function0. Controller@function0 ini akan melempar ke view dengan data $id_doc. Selanjutnya, buat halaman form tersebut di view. Atribut form diberi keterangan action= “./address1{id_doc}” sehingga ketika user melakukan submit, user akan dialihkan ke alamat /address1{id_doc}. Di bagian route, atur sehingga jika /address1{id_doc}, maka jalankan controller@function1. Di dalam controller, function1 akan meminta nilai (untuk sementara baru judul dan isi) dari input form (/address0) dan memasukkannya ke database di mana id_doc=$id_doc. Setelah itu, controller akan menampilkan “record inserted successfully”.
  2. Edit content. Pertama, buat link “edit content” yang akan mendirect user ke halaman edit (filled form) di alamat /address2{id_content}, tambahkan di route jika /address2{id_content} maka controller@function2. Controller@function2 ini akan melempar ke view dengan data $id_content. Selanjutnya, buat halaman edit, yakni form yang telah terisi sesuai isi konten. Atribut form tersebut diberi keterangan action= “./address3{id_content}” sehingga ketika user melakukan submit, user akan dialihkan ke alamat /address3{id_content}. Di bagian route, atur sehingga jika /address3{id_content}, maka jalankan controller@function3. Di function3, controller mengambil model dengan id_content=$id_content dan meminta nilai (untuk sementara baru judul dan isi) dari input form (/address2). Controller kemudian mengassign nilai baru ke dalam model (overwrite/update) dan menyimpannya ke database. Setelah itu, controller akan menampilkan “record edited successfully”.

Kendala: saya pribadi sejauh ini tidak ada. Namun, beberapa teman yang lain ada yang belum bisa menjalankan wister dengan menggunakan PostgreSQL (dan kami tidak tahu errornya di mana).

Tambahan: kelompok kami sepakat bahwa untuk penamaan variabel dan atribut tabel, akan menggunakan lower_case.

— Sekian laporan dari minggu ke 4 dan ke 5 —

Show your support

Clapping shows how much you appreciated Wiki Sister’s story.