Latest Posts



Halooo, beberapa minggu yang lalu Zahra, teman saya, telah menjelaskan tentang eight golden rules yang diterapkan pada design applikasi kita. Namun, ada beberapa yang belum selesai dijelaskan dan masih ada beberapa implementasi yang belum dibuat. Look below for my observation and opinion! :)

Strive for consistency

Hal ini ditujukan agar user lebih mudah mencapai tujuan mereka, selain itu hal ini juga membuat user familier dengan applikasi kita sehingga tetap merasa di jalur yang benar. Ini dapat dicapai dengan cara memberikan standard yang sama untuk melakukan sebuah aksi dan juga tampilan dari web itu sendiri. 

Pada design kami, kami memberikan hierarki yang jelas bagaimana penggunaan font, fungsi-fungsi dari sidebar, penggunaan option dan card, dll.





Namun bagaimana dengan implemenasinya? Oops, terdapat dua button yang memiliki style berbeda (satu dengan shadow, satu lebih terlihat glowing). Hal ini dapat membuat user sedikit bingung bagaimana perbedaan kedua tombol, padahal fungsi utamanya sama (melakukan sebuah aksi).




Updated.





Enable frequent users to use shortcuts.



Kami sudah memberikan menu sidebar untuk memudahkan user untuk bernavigasi, namun ada beberapa hal yang kurang yaitu sub-menu. Karena untuk melihat jadwal (bagi admin) akan banyak sekali pilihan, apakah mau melihat dari branch, atau dari penyuluh, atau mungkin secara keseluruhan; secara default kami memberikan jadwal keseluruhan di awal. Sehingga hal ini menyebabkan dibutuhkan beberapa (sekitar 3 sampai 4 klik tombol) untuk membuat admin dapat melihat apa yang ia inginkan.

Updated.

Setelah melakukan penelitian lapangan bersama teman-teman, kami memutuskan bahwa sidebar yang dipakai hanya akan memiliki tiga menu. Yaitu Home, Penyuluh, dan Data (yang utama), dan Profile juga Pengaturan; di mana pada tab penyuluh   kita akan memilih penyuluh mana yang ingin kita lihat rekomendasinya. 


Offer informative feedback

Hal yang simple namun berguna yaitu seperti memberikan efek untuk button yang dapat diklik. Atau pada sidebar, jika kita berada page/sub-page itu, maka menunya akan berwarna. 


Design dialogue to yield closure

Hal ini secara memberikan konfirmasi kepada user akan apa yang ia kerjakan dan bagaimana hasilnya, seperti memberikan notif error sederhana apabila halaman web yang dituju tidak ada. Namun, ada feedback dari backend yang tidak ditampilkan (hanya ada di console), sehingga apa bila ada error, user tidak mengetahui apa kesalahan yang ia lakukan.





Updated.

Sudah diberikan informasi sederhana untuk mengetahui apakah teradapat error atau progress yang sedang berjalan untuk suatu task.


Offer Simple Error Handling

Setiap applikasi harus dibangun sebaik mungkin agar pengguna tidak bisa merasakan eror atau adanya kesalahan alur pada saat menggunakan, tapi ada hal-hal yang tidak dapat dihindar. Dengan begitu, maka kita harus memberitahukan pengguna apa yang salah sehingga mereka tidak perlu menerka-nerka hal yang perlu diperbaiki. Salah satu contoh simple adalah sama bentuknya seperti di atas, di mana kita akan memberi tahu saad upload data apa yang kurang dan perlu diperbaharui.

Permit easy reversal of actions

Tidak jarang pengguna menekan tombol yang salah atau hal-hal yang tidak ia maksud, maka dengan begitu, sebagai developer kita harus memberikan jalan agar mereka mudah kembali ke state sebelumnya. Contoh seperti, karena hanya ada sedikit halaman yang berada dalam applikasi kami, maka ketika user salah menuju halaman dan ingin kembali ke halaman sebelumnya, maka ia bisa langsung menggunakan sidebar. Selain itu juga, apabila pengguna salah memilih file, file tidak akan langsung diupload dan dapt diganti terlebih dahulu.

Reduce Short Term Memory Load

Hanya terdapat beberapa icon yang berada di sidebar atau card yang (akan) ada pada dashboard. Hal ini ditujukan untuk highlighting hal yang paling penting untuk diingat oleh pengguna.



The update from me is done! See ya ;)

Halooo, kembali lagi bersama Bthari! :)

Setelah saya menjelaskan tentang CI/CD pada post-post sebelumnya, di sini saya akan menjelaskan secara garis besar bagaimana pipelines pada setiap environment dapat berbeda-beda. Pertama-tama, mari kita lihat terlebih dahulu bagaimana pipeline-nya:

coba_coba (dulu)


sit_uat & master & coba_coba (sekarang)



other branch


Bagaimana hal seperti ini bisa terjadi? Pada setiap branch akan memiliki .gitlab-ci.yml yang akan mengatur stages CI pada branch tersebut. 

Terdapat beberapa cara, misal pada setiap branch akan memiliki definisi stages apa saja yang perlu dilewati. Pada coba-coba yang dulu stages yang perlu dilewati diatur seperti


stages:
  - release
  - deploy

Sehingga branch coba_coba tidak akan melewati testing terlebih dahulu untuk di-deploy ke server.

Sementara untuk setiap branch lain maka ada tiga tahapan pada kode .yml, seperti: 


stages:
  - test
  - release
  - deploy

Dan, pada tahapan release dan deploy akan ditambahkan variable only yang mana menunjukkan nama-nama branch yang akan melewati tahapan release dan deploy, sehingga branch lain (working branch) tidak akan melalui tahapan tersebut.


release:
  stage: release
  image: docker:latest
  services:
    - docker:dind
  before_script:
    ...
  script:
    ...
  only:
    refs:
      - master
      - sit_uat
      - coba_coba

Sekian post saya, semoga bermanfaat! :)



Halo semuanya! Kali ini saya, Zahra, ingin menjelaskan mengenai CI / CD!

CI adalah singakatan dari Continuous Integration. CI adalah tentang kompilasi atau pembuatan perangkat lunak secara terus menerus sesuai dengan arti dari kata continuous integration tersebut. Dengan melakukan check-in pada setiap sistem yang memicu proses kompilasi, menjalankan unit test, dan pemeriksaan kualitas terkait otomatisasi.

Sedangkan CD adalah singkatan dari Continuous Delivery. Dalam Continuous Deployment, kita melangkah lebih jauh. Hal ini memungkinkan kita untuk benar-benar secara otomatis menyebarkan ke produksi. Perbedaannya hanya apakah ada atau tidak ada pemicu otomatis atau manual.

Nah, saya asumsikan kalian sudah mengerti ya :) sekarang kita akan menelusuri mengenai CI/CD pada allocateam.

Jadi, kami memanfaatkan fitur CI/CD yang diberikan oleh GitLab. GitLab dapat secara otomatis dikonfigurasikan CI-nya dengan hanya menuliskan konfigurasi dalam sebuah file bernama .gitlab-ci.yml dengan format YML dan diletakkan di root repository.

begini lah penampakan filenya:

CI pada GitLab didukung oleh penggunakan image docker sehingga cukup mudah bagi kami untuk melakukan setup karena stack kami juga menggunakan docker sebagai kontener.





Halo semuanya! :)

Kembali lagi pada post saya! Pada kangen gak nih sama salah satu hipster kesayangan allocateam ini? :) Kalo iya, Hi! hehehe.

Nah, kali ini saya mau bahas salah satu hal yang sangat penting bagi pengembangan yang dilakukan oleh allocateam nih! Pasti udah tau kan saya mau bahas apa? Betul! saya mau bahas Kubernetes, yuk disimak!

Jadi apa itu Kubernetes?

"Kubernetes is a portable, extensible open-source platform for managing containerized workloads and services, that facilitates both declarative configuration and automation. It has a large, rapidly growing ecosystem. Kubernetes services, support, and tools are widely available." - Kubernetes's Documentation
Nah kalau kalian sudah pernah baca post Wisnu yang ini dan ini, kalian pasti udah gak akan asing lagi dengan kubernetes. Apa itu kubernetes? seperti yang tertulis diatas, Kubernetes merupakan orchestrator yang dapat menjadwalkan dan menjalankan kontainer aplikasi pada kelompok mesin fisik atau virtual.  Disini Kubernetes digunakan untuk melakukan deployment pada docker container image yang kita miliki.


Pada allocateam, Kubernetes merupakan orchestrator yang berperan untuk melakukan deployment docker image kita ke dalam server AzureKonfigurasi pada kubernetes dituliskan dalam bentuk YML dan dikirimkan kepada Kubernetes yang terletak pada server azure menggunakan kubectl.

Mengapa kita menggunakan kubernetes? Kubernetes dapat menjadwalkan dan menjalankan kontainer aplikasi pada kelompok mesin fisik atau virtual. Namun, Kubernetes juga memungkinkan pengembang untuk ‘cut the cord’ ke mesin fisik dan virtual, bergerak dari infrastruktur host-sentris ke infrastruktur kontainer, yang memberikan keuntungan dan manfaat penuh yang melekat pada kontainer. Kubernetes menyediakan infrastruktur untuk membangun lingkungan pengembangan yang benar-benar kontainer-sentris.



Menurut saya juga salah satu alasan mengapa allocateam menggunakan kubernetes ialah karena banyaknya host yang perlu terhubung, dapat dilihat pada gambar dibawah, oleh karena itu sangat apabila kami cocok menggunakan kubernetes. 


Hello, allocaters! 
Ketemu Glory lagi nih :)

Di post kali ini, saya ingin membahas tentang hubungan antara Continous Integration (CI) dan 3 Environment PPL (coba_coba, sit_uat, master).

Nah, di sini, CI punya peran yang sangat penting dan helpful banget nih teman-teman. CI yang dirancang allocateam dev team, mengotomasikan proses integrasi ke masing-masing environment sesuai branch tempat developer melakukan push code-nya. 

Misal, saya sedang di story-branch, saya ingin test nih apakah code saya berjalan di server. Jadi saya pindah ke branch coba_coba, lalu saya pull code dari story-branch terkait, dan saya push ke coba_coba tersebut. Nah si CI ini akan menjalankan test dahulu (frontend dan backend), lalu akan memasuki tahap release, dan pada akhirnya akan di deploy ke environment coba_coba.

Kalau di environment sit_uat dan master, prosesnya seperti ini nih teman-teman. Kan kalau code untuk setiap story sudah selesai diimplementasikan, story-branch terkait akan di merge ke branch sit_uat. Apapun yang masuk ke sit_uat, CI akan langsung menjalankan test (frontend dan backend), lalu masuk ke tahap release, dan automatically deploy ke environment sit_uat. Begitupun master, code dari sit_uat yang di merge ke master, CI akan langsung menjalankan test (frontend dan backend), lalu masuk ke tahap release, dan automatically deploy ke environment master.

Untuk story branch, apabila push code ke story branch, CI hanya akan menjalankan test saja, tidak masuk ke tahap release dan deploy. Apabila story branch masuk ke coba_coba, baru CI akan menjalankan dua proses lainnya.

Dengan adanya CI, kita tidak perlu manually deploy ke environment tertentu, kita hanya tinggal set segala script di gitlabci.yml untuk melakukan integrasi sesuai yang kita harapkan, misal seperti deploy ke environment sesuai branch tempat developer push code. 

Ini gambaran integrasi yang dipakai oleh allocateam:

(1) Ini untuk coba_coba, sit_uat, dan master

(2) Ini untuk story-branch

Hebat bukan The Power of Continous Integration?
Sekian dulu post kali ini, semoga bermanfaat! :)


Halo teman-teman sekalian!
Jangan bosen-bosen yaah dengan post saya yang ternyata makin banyak :( hahaha

Nah, kali ini saya ingin membicarakan hal yang sangat penting di PPL, bisa dibilang, kalau gak ada benda ini, team developer (bahkan dosen) juga akan kewalahan dalam menjalankan pengembangan. Ya, sesuai judulnya, yang ingin saya bahas ialah mengenai Git dan segala Flownya yang sangat amazing!

GIT

Git diciptakan oleh Linus Torvalds yang juga merupakan pembuat Linux. Git digunakan oleh tim pengembang untuk menyimpan perubahan source code, yang disebut juga sistem version control. Git dapat digunakan sendiri maupun untuk kolaborasi dengan team. Tools ini menawarkan menulis kode bersama dalam sebuah tim secara offline lalu menyatukan source code tersebut secara online melalui metode push dan pull. Ada banyak sekali layanan Git server, dari yg komersial hingga yg gratis dipakai oleh umum. Sebagai contoh yang ialah yang digunakan oleh developer team di PPL yaitu layanan Git server gratis, Gitlab.

Istilah-Istilah di Git
repository : database yang menyimpan semua history atau riwayat perubahan. 
snapshot : potret kondisi file dan folder pada saat tertentu. 
commit : snapshot yang disimpan di repository. 
branch : serangkaian commit yang berkaitan sehingga kalau digambar seperti garis lurus berisi banyak commit. Satu repository bisa berisi banyak branch. 
master : nama branch default yang diberikan git pada waktu kita membuat repository. Branch master ini tidak istimewa. Dia bisa dihapus dan direname sesuka hati.
head : ujung branch, commit terbaru di dalam branch. 
HEAD : head yang sedang aktif. Walaupun satu repository bisa memiliki banyak branch, tapi cuma satu yang aktif. 
working folder : folder berisi file dan folder tempat kita bekerja. Biasanya working folder berisi banyak file source code untuk aplikasi yang sedang kita buat. Git memantau working folder ini, dan bisa mengetahui file dan folder mana yang sudah berbeda dari posisi commit terakhir. Perbedaan atau perubahan ini bisa disimpan menjadi commit baru, atau dikembalikan ke kondisi sebelum diubah.
staging area : snapshot dari working folder yang akan kita simpan pada saat commit. Ini adalah fitur unik Git yang tidak dimiliki version control lain. Dengan adanya staging area, kita bisa memilih perubahan mana yang akan di-commit dan mana yang tidak. 


Operasi - Operasi Dasar
Init : digunakan untuk inisiasi git. Biasanya inisiasi dilakukan oleh pemimpin proyek. Anggota lain akan melakukan clone setelah pemimpin proyek melakukan inisiasi repository. Init dapat digunakan di proyek baru (masih kosong) atau di proyek yang sudah dikerjakan (sudah ada file source code). 
Clone : digunakan untuk menyalin repository dari remote repository ke local repository. 
Add : digunakan untuk menambahkan file ke staging area
Commit : digunakan untuk menyimpan perubahan kode di repository local. 
Push : Perintah push digunakan untuk mengirim commit dari local repository ke remote server. 
Checkout : digunakan untuk berpindah dari satu branch ke branch lain. Checkout juga digunakan untuk mengembalikan file yang diubah tapi belum dicommit ke versi sebelum diedit. 
Fetch : digunakan untuk menyamakan keadaan remote repo dengan local repo (mengupdate local repo). 
Merge : digunakan untuk menggabungkan branch. 
Pull : digunakan untuk menarik commit dari remote server ke lokal. Aslinya, pull ini melakukan fetch yang diikuti merge secara otomatis.

Nah, ada hal-hal yang unik yang saya pelajari nih, yaitu Pull Request dan Merge Request. 

Pull Request : Pull requests let you tell others about changes you've pushed to a repository on GitHub. Once a pull request is opened, you can discuss and review the potential changes with collaborators and add follow-up commits before the changes are merged into the repository.

Merge Request : Merge requests are useful to integrate separate changes that you've made to a project, on different branches.

Karena saya bingung, saya juga melakukan pencarian pada internet dan menemukan hal yang menarik berikut: 
"Merge or pull requests are created in a git management application and ask an assigned person to merge two branches. Tools such as GitHub and Bitbucket choose the name pull request since the first manual action would be to pull the feature branch. Tools such as GitLab and Gitorious choose the name merge request since that is the final action that is requested of the assignee. In this article we'll refer to them as merge requests."


Image result for software architecture

Hello guys kembali lagi dengan hustler kalian aye,apa itu software architecture? kalo mau mengingatkan lagi nih dari blog saya sebelumnya software architecture adalah sebuah blueprint dan dokumentasi dari sebuah software yang ada nih teman,teman software architecture ini dibutuhkan supaya untuk kedepan nya tim development tau nih dokumentasi dan juga keranka dari software tersebut nah untuk arsitektur kami nih teman teman,blueprint nya sudah di buat nih dari hipster kita ya itu zahra saya paste juga di sini ya 
jadi teman teman jika kita liat graphic yang dibuat sangat baik oleh zahra, untuk blueprint kami sangat jelas kami memakai apa untuk menopang development team kami dan juga alur kerja yang ada dalam tim. Sekian dari saya terimakasih. Bisa di baca di graph zahra untuk menambahkan mungkin bisa di tambahkan lagi nanti dari tahap deployment ke user yang akan memakai yang belom ada di graphic tersebut.
Ini adalah flow gambar dari architecture kami yang dibuat oleh salah satu tim kami yaitu Zahra. 


Dapat dilihat secara garis besar bagaimana flow dari pengerjaan kita berjalan. Sebelum itu, saya akan menjelaskan architecture:

Ada kurbernetes yang dapat bekerja untuk melakukan deployment pada docker image kita. Flask sebagai framework backend kita, dan React untuk framework frontend. PostgreSQL untuk database.  Celery untuk menghandle pekerjaan yang memakan waktu yang lama, sehingga membutuhkan worker untuk program dapat bekerja secara paralel. Kemudian Redis untuk mengatur pengantrian tugas backend yang akan dikirim kepada worker. 

Flow yang bekerja pada tim kami adalah, kami akan melakukan pengkodean program dan melakukan push pada beberapa potong block kode (dengan TDD).  Kemudian program pada beberapa branch setiap kode tersebut akan dihandle oleh kuberneter, yang akan mengirimkan deployment redis, postgresql, mario, luigi, dan peach.

Kemudian ketika semua sudah deployed pada server masing-masing, maka kerjanya adalah peach akan mengirimkan API kepada backend untuk melakukan fungsi-fungsinya. Dan backend, apabila tugas sangat berat, tugas-tugas tersebut akan dibagi kepada worker.




  Source: http://www.air-conservice.com.sg/articles/7-most-common-mitsubishi-error-code.html

Halo semuanya!

Balik lagi nih sama saya, Zahra, salah satu hipster kesayangan allocaters semua kan :p

Nah kali ini saya ingin menjelaskan mengenai error code dan exception handling.

Intronya, kalian tahu kan bahwa saya adalah hipster. Mostly task yang saya ambil rata-rata front end. Nah, di front end ini saya tidak pernah mengimplementasikan error code ataupun exception handling.



Seperti yang sudah dijelaskan sebelumnya oleh Bthari, Error code adalah sebuah kode yang menyimbolkan sebuah status dari software, hal ini biasanya digunakan untuk mengetahui kesalahan pada sistem maupun input. 


Error code memiliki variasi yang sangat luas, tergantung dari software atau aplikasi mana yang mengimplementasikan error code tersebut. Misal, pada HTTP status terdapat 5 pengelompokkan untuk kode-kode error, 1xx (informational response), 2xx (success), 3xx (redirection), 4xx (client error), 5xx (server error). Berbagai macam hal mengimplemenrasikan error code tersendiri, dari libcurl hingga playstation.

Untuk exception handling saya juga belum mendapatkan kesempatan untuk mengimplementasikan hal tersebut pada PPL namun pernah pada matkul lain. Exception merupakan sebuah event yang akan menginterupsi program yang tidak berjalan normal / error, lebih mudahnya error handling merupakan penanganan error. Tidak semua penanganan error ditangani dengan exception, namun dapat mempermudah penanganan error.

Exception terdiri dari dua macam kelompok, yaitu : 
– Exception yang merupakan subclass RunTimeException 
– Exception yang bukan subclass RunTimeException

RunTime Exception biasanya disebabkan oleh kesalahan program atau pada desain program. Misalnya:

  • NullPointerException yang disebabkan oleh proses inisialisasi program yang tidak sempurna dan 
  • ArrayIndexOutOfBoundsException yang disebabkan akses array yang melebihi kapasitas array yang ada.
Sekian dari sayaaa, maaf kalau kurang informasi yang dapat dipelajari. Namun semoga bermanfaat!


-Xoxo