git

Theory…

Duluu (sekali) saya pernah menulis sedikiit (sekali) tentang cara pakai mercurial. Karena sekarang saya lebih sering pakai git di tempat kerja saya, maka saya menulis post ini dengan harapan agar tidak cepat lupa dengan perintah-perintah yang biasa dipakai di git dan kalaupun lupa cukup baca satu halaman ini saja biar cepat ingatnya. Tapi sebelum itu mungkin saya kasih sedikit cerita mengenai apa sih sebenarnya git itu?

Sebenarnya tujuan version control system (VCS) software seperti git dan kawan-kawannya itu intinya ada 2. Pertama untuk mengatasi masalah versioning. Dulu pasti pernah kan bikin laporan, terus diberi nama final di nama file-nya. Eh tapi tahunya dari dosennya disuruh ada revisi, yang ternyata tidak ada habis-habisnya, sehingga kita terpaksa membuat banyak file yang dinamai dengan “final rev1”, “final rev2”, “final final” dan seterusnya. Nah dengan VCS ini seharusnya kita cukup punya satu file saja, tapi seluruh sejarah revisi yang dilakukan tetap tersimpan sehingga kita bisa balik ke revisi yang sebelumnya kapan saja (Fitur ini juga ada sih di Microsoft Word, tapi kayaknya enggak banyak yang pakai).

meme
Kalau file dokumen atau kode tidak pakai version control system jadinya bisa seperti ini.

Problem kedua yang berusahan dipecahkan adalah tentang collaborative work. Misalkan kita dan teman kita mau menulis di file yang sama (tapi beda posisinya di dalam file, satu di bagian awal, dan satunya lagi di bagian akhir). Dengan VCS, hasil kerja kita akan digabung secara otomatis dengan kerjaan teman kita. Daripada saling kirim-kiriman email terus lupa file yang mana yang versi terbaru yang akibatnya kerjaan kita bisa hilang atau tertimpa dengan kerjaan teman kita. Salah satu kelemahan dari VCS mungkin adalah dia hanya men-support file dengan format text saja, tidak bisa binary seperti gambar atau video.

Zaman dahulu kala, VCS yang berkuasa adalah subversion. Ini saya pernah pakai waktu kerja praktik. Bedanya dengan git dan mercurial adalah sifatnya yang centralized. Artinya repository-nya sebenarnya hanya ada di satu server, dan setiap kita mau kerja, kita ambil semua file versi terbaru dari server. Ketika kita melakukan edit pada file dan ingin komit, maka kita juga harus mengirim commit-annya ke server tersebut. Akibatnya apabila server-nya mati, atau kita tidak ada akses ke sana (no internet), maka kita tidak bisa kerja sama sekali. Selain itu, menariknya adalah kalau kita mau commit, maka harus cepet-cepetan sama teman kita, karena kalau keduluan maka kita harus fetch, merge, terus commit lagi.

(Sedikit nostalgia. Dulu repository subversion tempat saya menaruh tugas kuliah itu di-host di Google Code yang sekarang sayangnya sudah tutup. Google memang suka resek, punya kebiasaan menutup service secara mendadak (halo Reader, Wave), . Jadi Jangan heran kalau 5 tahun lagi Google+ juga bisa saja ditutup.)

Git dan Mercurial sendiri tergolong ke distributed VCS. Ini artinya setiap kopi repository git merupakan exact copy dari yang ada di server. Kita bisa commit, checkout ke versi sebelumnya, dll, cukup dari repository lokal kita. Kelemahannya adalah di awal proses checkout (atau clone dalam istilah git) itu bisa lama sekali karena semua sejarah commit dari awal sampai akhir bakal dikopi. Untuk repository yang sudah punya sejarah panjang, ukurannya bisa mencapai Gigabyte!

Kalau git sama mercurial (hg) sendiri apa bedanya? Hmm, in general, keduanya memiliki kapabilitas yang sama.  Tinggal tergantung selera kita masing-masing, sama seperti banyak hal lain di komputer (vim vs emacs, tabs vs spasi, dll). Kalau dulu waktu kuliah saya sebenarnya sih lebih suka mercurial, karena repo-nya bisa diakses menggunakan http dari jaringan internet kampus (host di bitbucket) sedangkan git hanya bisa lewat ssh (host di github). Tapi sekarang git sudah bisa http, dan bitbucket sudah bisa host git. Jadi rasanya tidak ada perbedaan yang terlalu berarti.

…and Practice

Oke, kita langsung masuk saja ke cara menggunakan git, untuk basic workflow yang sederhana. Akan ada sedikit penjelasan untuk tiap command-nya biar enggak kayak komik di bawah ini. Sebenarnya untuk bisa berfungsi normal dalam kehidupan sehari-hari cuma sedikit kok command git yang harus dihafal dan dimengerti. Untuk kasus-kasus unik dan menantang bisa diselesaikan dengan bertanya di stackoverflow atau senior programmer di kantor masing-masing.

git
Classic xkcd. Tapi sarannya valid lho, ultimate solution-nya ya memang clone ulang dari awal.

> Pertama, ya instalasi. Kalau di ubuntu gampang tinggal jalanin ini di terminal:

sudo apt-get install git

Kalau Windows dan lainnya bisa lewat installer dari situs resminya https://git-scm.com/downloads.

> Kemudian, setup nama dan email. Cukup sekali di awal.

git config --global user.name "Muhammad Iqbal Tawakal"

git config --global user.email mit.iqi@gmail.com

Tentunya sesuaikan dengan nama dan email masing-masing ya.

> Setelah itu tinggal buat repository baru dari dalam sebuah folder

git init

Atau ambil dari repo yang sudah ada

git clone <repo_address> <target_directory>

> Commit time

Bisa dibilang ada beberapa tingkatan level file di dalam git. Pertama untracked files. Ini adalah file yang tidak di-track oleh git, namun ada di dalam direktori repository. Sebaiknya, semua file yang penting itu di-commit dan sisanya yang tidak penting (temporary files, output log) itu di-list di dalam file .gitignore. Gunakan git add <filename> untuk memasukkan untracked file ke staging area. Apabila file-nya sudah di-track, tapi isinya sudah diubah dari yang terakhir di-commit, itu termasuk ke uncommitted changes. Ini juga bisa dimasukkan ke staging area dengan perintah yang sama.

Semua file yang ada di staging area ini akan di commit ke dalam repository kalau kita menggunakan perintah git commit. Tambahkan parameter -m kalau kita ingin memberikan pesan komit dalam satu baris. Kalau tanpa -m maka git akan membuka text editor di terminal (seperti vim), terus kita harus memasukkan pesan kita di dalamnya. Save file untuk melanjutkan commit. Ilustrasinya bisa dilihat di bawah.

git stages 1
The many (faces) stages of git.

Nah gimana kalau kita berubah pikiran dan mau pindah dari stage atas ke bawah? Sebenarnya git akan memberikan petunjuk kalau kita ketik git status, tapi untuk gampangnya bisa dilihat di gambar berikut. Intinya reset dari staging ke uncommited, dan checkout dari uncommitted changes ke versi commit-annya yang terakhir.

git stages 2
Kebalikannya.

Kenapa modelnya seperti ini? Harus di-add setiap mau commit? Jadi sebuah commit itu sebaiknya adalah 1 self-contained logical changes. Jadi kalau misalkan banyak file yang berubah sejak commit terakhir, kita supervisi sendiri mana file yang akan di-commit dan mana yang tidak, atau nanti dimasukkan di commit yang berbeda. Ini menjaga agar kita tidak (secara tidak sengaja) memasukkan file yang tidak ada hubungannya dengan apa yang sebenarnya mau kita commit. (Di mercurial, setiap commit akan memasukkan semua file yang berubah dari sejak terakhir commit).

Selain itu sebaiknya tiap commit itu tidak mengandung error. Kalau hal terakhir ini sebenarnya bisa di-enforce dengan menggunakan static code analysis tools seperti linter atau dengan code-review dan automatic testing. Mungkin bisa dibahas di post-post berikutnya.

Sedikit tambahan lagi. Untuk melihat apa yang berubah antara files di uncommitted changes dengan versi originalnya di committed revision bisa dengan perintah git diff. Untuk melihat status dari setiap file (sedang berada di stage mana) bisa menggunakan git status. Untuk melihat daftar commit apa saja yang sudah diperbuat, gunakan perintah git log.

And that’s it! That’s all you ever need to know if you want to use git all by yourself on a single machine for versioning. Of course, git offers more features than just for this kind of usage. Keep reading if you’d like to indulge yourself more in the world of git.

> Branching

Branching, atau percabangan, adalah salah satu fitur andalan git agar proses development kita bisa lebih bersih lagi dari error. Gambar di bawah menunjukkan skema branching yang lazim dipakai untuk suatu proses development software. Ada satu branch utama, bernama master, yang berisi kode yang siap release ke production. Active development dilakukan di branch develop yang secara berkala akan di merge ke branch master ketika sudah siap.

branch
Typical development branch. Gambar dikopi dari slide tech talk Salestock.

Setiap kita hendak mengimplemen fitur baru, maka kita buat branch baru dengan nama fitur tersebut yang baru akan kita merge ketika implementasinya sudah selesai. Hal ini akan membuat proses development menjadi lebih rapi, karena semua logical changes dan commit yang memang khusus untuk fitur itu saja terisolasi di dalam satu branch, dan tidak mengganggu developer lain yang hendak mengimplementasi fitur lain.

Perintah git branch akan memunculkan semua nama branch yang ada di repo kita. Kalau kita mau buat branch baru, gunakan perintah git checkout <hash_commit/another_branch_name> -b <new_branch_name> atau hilangkan commit hash kalau kita mau bikin branch baru dari HEAD (HEAD ini menunjuk ke commit atau branch yang sedang aktif di workspace). Kalau mau berpindah-pindah branch, cukup ketik git checkout <branch_name>. Branch yang lama dapat dihapus dengan cara git branch -d <branch_name>.

> Collaborative Work

Sekrang kita akan membahas satu fitur terpenting lainnya dari VCS, yaitu untuk bekerja secara kolaborasi. Pejamkan mata Anda dan bayangkan skenario seperti berikut. Ada satu repository yang terletak di server origin, yang dulu dikerjakan oleh Misty, dan 2 orang developer baru, Ash dan Brock, yang akan melanjutkan pekerjaan yang dahulu sempat terhenti.

git awal
Phase 1: Fresh from the server.

Pertama, Ash dan Brock meng-clone repo tersebut ke laptop mereka masing-masing sehingga sekarang mereka mempunyai complete copy dari repository tersebut. Ash kemudian menambahkan fitur baru dan meng-commit-nya. Agar kerjaannya itu bisa dipakai orang lain, maka Ash melakukan push perubahannya kembali ke origin server dengan melakukan git push origin master.

git tengah
Phase 2: After push

Brock juga tak mau kalah dengan Ash dan juga menambah fitur baru yang berbeda. Namun ketika dia hendak mem-push commit-nya, server origin menolak karena Ash sudah lebih dulu melakukannya. Yang Brock harus lakukan adalah mengambil commit-nya si Ash dan menggabungkannya dengan commit-nya.

git tengah 2
Phase 3: Merging

Perintah yang digunakan untuk mengambil commit baru dari server adalah git fetch. Setelah fetch ada 2 opsi yang bisa dipilih, merge atau rebase. git merge akan menggabungkan 2 commit yang berbeda menjadi dengan membuat commit baru. Sedangkan git rebase akan meng-apply commit kita ke atas commit yang satunya. Sebenarnya ada shortcut yang bisa dipakai, untuk fetch+merge, bisa menggunakan git pull. Sedangkan untuk fetch+rebase bisa menggunakan git pull --rebase.

git akhir
Final phase: Teamwork is beautiful, isn’t it?

Setelah itu Brock bisa mencoba melakukan push lagi dan kali berhasil sehingga  Akhirnya server origin menjadi berisi commit dari 2 orang tersebut, dan siap untuk di-clone orang berikutnya yang akan melanjutkan pekerjaan mereka berdua.

> Tips and Trick

Untuk mempersingkat penulisan beberapa command yang sering dipakai, biar lebih menghemat keystroke dan juga umur, gunakanlah perintah alias. Hasilnya juga jadi lebih mirip command di hg. Misalkan untuk 2 perintah yang paling sering digunakan.

git config --global alias.ci commit

git config --global alias.st status

Kalau yang ini rekomendasi saya untuk dipakai melihat commit tree dalam bentuk grafik di dalam terminalnya langsung. Akan sangat memudahkan untuk mendapatkan mental image dari kondisi repositori sekarang. Apalagi kalau branch-nya sudah banyak dan rumit.

git config --global alias.tree "log --graph --decorate --oneline --all"

Untuk melihat semua shortcut (plus informasi lainnya) bisa dengan:

git config --list

Untuk dokumentasi yang lebih lengkap, dan berisi semua hal yang bisa diketahui dari git, bisa lewat buku progit yang kebetulan full version-nya dibuka di sini: https://git-scm.com/book/en/v2

Kalau butuh visualisasi lebih mendetail untuk operasi-operasi git lainnya, bisa ditilik di tautan berikut: http://marklodato.github.io/visual-git-guide/index-en.html

Wah, jadinya panjang juga. Demikianlah, semoga berguna.

Salam.

Tutorial Latex – Penulisan Skripsi UI Menggunakan Latex

Post kali ini akan membahas tutorial penggunaan Latex yang digunakan untuk menulis tugas akhir S1/S2/S3 di Universitas Indonesia

Kebetulan, pada tanggal 23 Maret dan 6 April penulis berkesempatan ditunjuk sebagai salah satu tutor untuk acara pelatihan Latex di Fasilkom UI yang diselenggarakan oleh Lembaga Asisten Fakultas Ilmu Komputer bersama Mas Ary Noviyanto.

Isi dari tutorial ini dimulai dari alasan penggunaan Latex, syntax dasar, penggunaan gambar, tabel, cross reference, penulisan matematika, penulisan referensi, dan presentasi.

Untuk masalah instalasi, silakan merujuk ke tutorial bagian satu.

Berikut slide presentasi dan template skripsi UI dalam Latex.

Salam, semoga berguna

UI Style

latex

GUI with Java without Netbeans

Biasanya kalau kita mau buat gui menggunakan Java, kita menggunakan ide Netbeans yang mempunyai fitur untuk membuat GUI dengan fasilitas drag and drop. Di satu sisi ini memudahkan penggunanya yang tidak ingin terintimidasi dengan detil yang mengerikan. Namun di sisi lain hal ini bisa dianggap overkill, apabila kita hanya ingin men-design GUI yang sederhana dan tidak begitu kompleks. Bahaya lainnya adalah apabila file .form yang digenerate oleh Netbeans hilang, kita tidak bisa mengubah GUI secara visual dan untuk mengubahnya secara manual lewat kode juga susah karena generated code untuk GUI dari Netbeans terkadang bloated dan sulit untuk dimengerti.

Karena itu kita perlu juga mengetahui bagaimana menyusun GUI melalui kode. Artikel berikut akan mencoba menjelaskan cara menyusun GUI yang paling sederhana dan cocok untuk yang ingin membuat GUI yang sederhana juga.

Ada dua cara untuk menyusun komponen GUI. Pertama dengan menggunakan layout manager atau dengan absolute position. Netbeans juga menggunakan layout manager untuk mendesain GUI-nya. Tapi yang akan dijelaskan di post ini adalah dengan menggunakan absolute position. Menggunakan layout manager memudahkan jika kita ingin menyusun GUI dengan praktis tanpa perlu mengetahui posisi pasti komponen yang akan ditaruh. Selain itu jika dilakukan resize terhadap komponen kontainernya, otomatis komponen yang dikandung didalamnya akan menyesuaikan dengan ukuran yang baru. Akan tetapi, jika kita ingin membuat GUI dengan ukuran yang sudah fixed, absolute position bisa memudahkan kita dalam mengatur posisi komponen dengan catatan kita harus sering mencoba untuk mendapatkan lokasi yang pas.

Oke, langsung buka editor favoritmu (Scite, geany, notepad++, eclipse, dlllll)
Hal pertama yang harus dilakukan adalah membuat kelas yang meng-extend JFrame

public class TestGUI extends JFrame

Jangan lupa import kelas JFrame

import javax.swing.JFrame;

kemudian di method main, kita cukup membuat objek dari kelas ini, dan menjalankan method setVisible agar GUI-nya bisa terlihat.

public static void main(String[] args) {
   TestGUI test = new TestGUI();
   test.setVisible(true);
}

Sampai saat ini, kita sudah membuat GUI yang fungsional, tapi begitu dikompail dan dijalankan kok GUI-nya tidak keliatan? Itu karena kita belum menspesifikasikan ukurannya. Jadi ukuran luasnya masih 0.
Inisialisasi ukuran GUI pada konstruktor

TestGUI() {
   setSize(600, 400);
}

parameter pada method setSize adalah panjang dan lebar dari JFrame tersebut.
Jangan lupa menambahkan kode berikut

TestGUI() {
   setDefaultCloseOperation(EXIT_ON_CLOSE);
}

agar ketika window-nya ditutup dengan menekan tombol x merah di pojok kanan atas, programnya benar-benar tertutup dan dimatikan dari JVM.
Posisi window tadi terletak di pojok kiri atas, bagaimana jika posisinya ingin ditengah?

TestGUI() {
   setLocationRelativeTo(null);
}

Maka posisi Windows akan berada di tengah.
Kalau mau Windows-nya tidak bisa diubah-ubah ukurannya, gunakan kode berikut

TestGUI() {
   setResizable(false);
}

Jika ingin memberi nama pada Windowsnya, panggil konstruktor parent Class dengan method super yang disertai argumen nama dari Windows dengan tipe String. Jangan lupa kalau super hanya bisa dipanggil di baris pertama pada konstruktor.

TestGUI() {
   super("Graphical User Interface for Test");
}

Setelah proses awal tersebut selesai, tahap berikutnya adalah tinggal layout untuk komponen-komponen yang kita butuhkan. Ada dua cara untuk layout dengan GUI di Java. Cara pertama adalah dengan menggunakan kelas LayoutManager untuk mengatur tata letak dari GUI kita. Cara ini juga yang dipakai oleh Netbeans untuk mendesain GUI. Kelebihan cara ini adalah kita tidak perlu khawatir apabila ukuran GUI berubah-rubah. Tampilan komponen akan mengikuti ukuran GUI yang sedang berlaku. Kekurangannya adalah ini bisa-bisa menjadi overkill, terutama untuk tampilan GUI sederhana dan tidak ada perubahan dari desain semula yang sudah disusun misalnya di kertas.

Karena itu saya memilih cara kedua, yaitu dengan absolute positioning. Dengan cara ini, desain awal yang sudah kita punya di kertas bisa langsung diterjemahkan ke dalam kode karena kita memiliki kuasa penuh terhadap letak dari komponen-komponennya.
Untuk memulai menggunakan absolute position, maka layout manager-nya harus di set null

TestGUI() {
   setLayout(false);
}

Berikutnya akan ditunjukkan bagaimana mengeset posisi komponen, misalnya sebuah textbox dan button

TestGUI() {
   JTextField tf1 = new JTextField();
   JButton btn1 = new JButton();

   tf1.setBounds(50, 50, 100, 20);
   btn1.setBounds(200, 50, 100, 20);

   add(tf1);
   add(btn1);
}

Dua baris pertama adalah instansiasi komponen TextField dan Button. Dua baris terakhir adalah cara menambahkan komponen ke dalam objek kontainer, dalam hal ini JFrame-nya sendiri. Kode yang berguna untuk mengatur letak adalah dua kode ditengah, yaitu method setBounds. Method setBounds memiliki empat buah parameter, dua parameter di depan adalah posisi secara sumbu x dan y untuk pojok kiri atas komponen yang bersangkutan. Dan jangan lupa juga, kalau sumbu x dan y posisi 0,0 untuk komputer juga dimulai dari pojok kiri atas. Dua parameter berikutnya adalah untuk panjang dan lebar dari komponen ini.
Tada, selesai. Sekarang Anda telah bisa membuat GUi serumit apapun tanpa membutuhkan bantuan dari Netbeans. Yang agak sulit dari pembuatan manual ini adalah harus sering dikompail untuk melihat posisi aslinya, karena ketika di code mungkin agak sulit untuk dibayangkannya.

Berikut potongan kode lengkapnya

import javax.swing.JButton;
import javax.swing.JFrame;
import javax.swing.JTextField;

public class TestGUI extends JFrame {
	
	TestGUI() {
		super("Graphical User Interface for Test");
		setSize(600, 400);
		setDefaultCloseOperation(EXIT_ON_CLOSE);
		setResizable(false);
		setLocationRelativeTo(null);
		
		setLayout(null);
		
		JTextField tf1 = new JTextField();
		JButton btn1 = new JButton();
		
		tf1.setBounds(50, 50, 100, 20);
		btn1.setBounds(200, 50, 100, 20);
		
		add(tf1);
		add(btn1);
	}
	
	public static void main(String[] args) {
		TestGUI test = new TestGUI();
		test.setVisible(true);
	}
}

Dan screenshot dari hasil akhir program
gui
Selamat mencoba, semoga bermanfaat