Hal yang butuh banyak repetisi seharusnya lebih dipercayakan kepada mesin.
Sedikit flashback ke tahun 2005, aku mencoba melakukan upgrade terhadap versi Gnome bawaan Debian-ku yang lama (Woody 3.0r1). Kalau tidak salah saat itu butuh lebih dari ratusan paket source code tarball terpisah (sudah termasuk dependencies yang aku-lupa-berapa banyaknya). Pada saat itu kalau mau ngenet harus pergi ke warnet terdekat sekitar kost, jadi tidak ada istilah:
$ sudo apt-get install xxx
atau semacamnya, apalagi sebenarnya paket .deb Gnome 2.10 dan komponen-komponennya untuk Woody tidak ada pada saat itu. Belum lagi kebetulan saat itu media installasi Debian-ku hanya berupa 1 CD installasi (bukan beberapa DVD atau file .iso installasi).
Kalau berada dalam situasi seperti itu, mau tidak mau beginilah kira-kira secara garis besar langkah-langkah yang perlu diambil (seharusnya pakai flowchart, tapi ya sudahlah) pada saat itu:
Pergi ke warnet.
Unduh paket A.
Pulang.
Coba lakukan kompilasi terhadap paket A.
Langkah kompilasi tadi mungkin menimbulkan error. Misalnya: masalah dependency, gagal kompilasi, dan lain-lain: termasuk listrik mati, space di harddisk kurang banyak untuk sebuah kompilasi sempurna, dan semacamnya.
Kalau proses dari langkah 4 (kompilasi) menghasilkan kesalahan (garis besarnya): "lib A butuh lib A_dep", terpaksa ulangi langkah 1-4 terhadap paket A_dep. Belum lagi kalau paket A_dep butuh paket A_d33psh1t (pardon my language) dan seterusnya.
Kalau misalnya gagal kompilasi karena kesalahan pada kode sumber, coba cek apanya atau dimananya yang salah (coba perbaiki). Kalau yang ini paling cuman di 3-4 paket saja & bukan suatu kesalahan yang luar biasa pada waktu itu.
Kemudian lanjut ke paket berikutnya & begitu seterusnya.
Mungkin langkah-langkah diatas kelihatan sederhana, tapi dibalik itu dibutuh sebuah determinasi (#halah) yang lumayan besar. Boleh dicoba :-D BTW, versi Gnome bawaan Woody 3.0r1 (1.4?) terpaut sekitar 4 tahun dengan Gnome 2.10
Setelah bolak-balik ke warnet lebih dari 3 kali (masalah nested-dependency tadi, karena ternyata nggak semua paket berserta ketergantungannya terunduh pada waktu itu. Atau mungkin karena versi lib bawaan Debian versinya lebih rendah dan semacamnya), pada suatu hari aku melakukan "manuver spektakuler" alias memilih untuk mengunduh semua paket [beserta nesteddependencynya] yang sebenarnya dibutuhkan oleh Gnome (versi 2.10 saat itu) agar dapat terpasang sedikit-banyak sempurnalah di Woody. Jadi waktu itu terkadang di warnet aku mencoba mengekstrak dulu paketnya untuk membaca file README untuk mencari tahu kira-kira paket ini butuh paket apa lagi? Dan seterusnya.
Butuh waktu berhari-hari untuk bisa mengunduh semuanya (bolak-balik warnet). Jadi saat itu aku punya checklist paket-paket yang sudah diunduh dan akan diunduh besok harinya (maklum, warnet itu bukan tempat penampungan). Setelah "manuver" tersebut, yang tersisa tinggal langkah kompilasi. Tapi repetisi pada langkah inipun terasa sangat membosankan:
$ ./configure --blahblahblah
$ make
$ sudo make install
Melakukan langkah-langkah itu untuk 4 sampai 5 paket mungkin masih bisa diterima. Coba bayangin kalau puluhan atau ratusan paket. Jadi yang kulakukan saat itu adalah membuat sebuah shellscript sederhana untuk melakukan langkah-langkah berikut(secara garis besar):
Loopinglist berikut (harus berurut karena nesteddependency tadi)
ektrak paket_n dalam list
masuk direktori hasil ekstraksi (paket_n)
build paket_n
keluar direktori paket_n
Ternyata tidak selancar yang dibayangkan. Kadang ada paket tertentu yang gagal di build, jadi harus ada campur tangan manual karena sudah pasti proses tadi berhenti ditengah jalan. Tapi beban bisa lebih ringan karena hanya terjadi di 3 atau 4 paket saja, meskipun tetap harus sesekali memonitor layar monitor. Untunglah berakhir dengan happy ending.
Sebenarnya cuman sedikit hubungannya dengan cerita diatas, tapi ada kalanya proses releasebeta sebuah project dalam sebuah tim pun bisa lebih otomatis. Ada kalanya kita membutuhkan sebuah sistem yang bisa melakukan otomasi terhadap proses-proses: melakukan update working copy atau clean checkout dari repository -> build release (termasuk proses konfigurasi, patching dan semacamnya) -> kirim release. Dengan demikian kesalahan-kesalahan yang bersifat manusiawi bisa diminimalisasi/dihilangkan apalagi kalau semua proses tersebut hanya dipercayakan kepada satu orang saja. Bisa jadi ada faktor X yang menyebabkan timbulnya kesalahan apalagi setiap orang pasti punya workingcopy tersendiri padahal yang diinginkan adalah hasil build yang sesuai dengan revisi tertentu pada trunk & bukan hasil build dari workingcopy tertentu. Untuk itulah jenkins sangat dibutuhkan pada saat-saat seperti ini.
Sebenarnya cuman mau ngomongin ada software yang bernama jenkins, tapi foreplay-nya terlalu lama :-D
Setelah melakukan beberapa kali penundaan, akhirnya hari ini resmi memakai Debian GNU/Linux 6.0.3. Penundaan-penundaan itu biasanya karena sudah terlalu nyaman dengan apa yang sudah didapat sebelumnya. Dengan demikian, hari ini resmi pula berakhirnya masa tugas Lenny. Kali ini ada beberapa hal yang menjadi hal yang pertama:
Pertama kali melakukan installasi melalui media usb. Biasanya melalui media CD atau DVD.
Pertama kali melakukan installasi paket melalui Internet (netinstall). Biasanya melalui set CD/DVD yang lumayan banyak.
Pertama kali menggunakan Debian versi 64 bit. Yay, akhirnya!
marisi@czx64:~$ uname -a
Linux czx64 2.6.32-5-amd64 #1 SMP Thu Nov 3 03:41:26 UTC 2011 x86_64 GNU/Linux
Untuk sementara, sensasi yang didapat selain proses booting yang jauh lebih cepat, proses kompilasi pun lebih cepat pula. Tapi sayang, software-software (versi binary) yang dulunya 32 bit harus didownload ulang versi 64 bit-nya. Memori pun sepertinya harus ditambah juga sedikit agar lebih sempurna sensasinya :-D
Selain installasi driver kartu grafis, konfigurasi fetchmail, mutt & Exim, belum ada konfigurasi-konfigurasi lain yang dilakukan.
Ketika ditanya dulu, aku kurang yakin apakah aku menjawabnya dengan benar atau tidak (mungkin benar 60%-70%? Entahlah karena dulunya lebih fokus bermain-main dengan jari-jari lingkaran saja). Dulu menjawabnya pakai C seadanya. Jadi ceritanya ada 2 buah lingkaran. Yang jadi pertanyaan, apakah 2 buah lingkaran tersebut bersentuhan [atau mungkin beririsan?]. Ya, semacam collision detection. Bedanya, dalam hal ini, lingkarannya tidak bergerak. Jadi belum bisa dikatakan collision detection. Setelah lihat-lihat lagi, Internet menyediakan beberapa solusi dan referensi (nanti linknya ada dibawah). Melalui tulisan kali ini, aku menulisnya [kembali] dengan Python. Kali ini hanya sekedar konversi sedikit. Entahlah, mungkin itu cara termudah bagiku untuk belajar suatu bahasa pemrograman yang baru disela-sela waktuku _yang berharga_ .
#!/opt/sw/bin/python
import math
class Point2D(object):
def __init__(self, x, y):
self.x = float(x)
self.y = float(y)
class Circle(object):
def __init__(self, point2d, radius):
self.midpoint = point2d
self.radius = float(radius)
def intersectionStatus(self, circle):
dx = float(self.midpoint.x - circle.midpoint.x)
dy = float(self.midpoint.y - circle.midpoint.y)
d = math.sqrt((dy * dy) + (dx * dx)) # distance between midpoints of circle0 and circle1
# d = math.sqrt((math.pow(dy, 2)) + (math.pow(dx, 2)))
if d > self.radius + circle.radius or d < math.fabs(self.radius - circle.radius):
print 'Nope! Not Intersecting nor Touching. Maybe, Overlapping.'
else:
# x = (d^2 - r^2 + R^2) / (2d)
x = (math.pow(self.radius, 2) - math.pow(circle.radius, 2) + math.pow(d, 2)) / (2.0 * d)
# point 3
ix3 = self.midpoint.x + (dx * (x/d))
iy3 = self.midpoint.y + (dy * (x/d))
# y^2 = R^2 - x^2
y = math.sqrt(math.pow(self.radius, 2)) - (math.pow(x, 2))
rx = -dy * (y/d)
ry = dx * (y/d)
ix1 = ix3 + rx
iy1 = iy3 + ry
ix2 = ix3 - rx
iy2 = iy3 - ry
if math.fabs(ix1 - ix2) + math.fabs(iy1 - iy2) < 1e-4:
print 'Touching!'
else:
print 'Intersecting!'
# TODO: Test...