Vertical Center dengan Tailwind CSS

Form berada di tengah-tengah layar

Saya sering sekali lupa cara untuk membuat vertical center di Tailwind CSS. Alhasil menghabiskan waktu beberapa menit untuk mencari solusinya melalui Google. Jadi saya coba tulis di sini agar lebih mudah mengingat dan mencari solusinya. Dan mungkin juga bisa membantu orang lain yang mampir ke blog ini.

Bagi yang ingin mencoba langsung bisa mampir ke https://tailwind.run

Jadi ada dua solusi yang saya temukan untuk vertical center. Yang pertama menggunakan items-center:

<div class="flex h-screen">
  <div class="flex items-center justify-center">

    <div class="p-8 bg-blue-500 text-white">
      I am at the center of page
    </div>

  </div>
</div>

Yang kedua menggunakan m-auto:

<div class="flex h-screen">
  <div class="m-auto">

    <div class="p-8 bg-blue-500 text-white">
      I am at the center of page
    </div>

  </div>
</div>

Silahkan Request Tutorial

Halo semuanya… di manapun Anda berada, semoga sehat selalu dan terhindar dari efek negatif pandemi COVID-19 ini. Baik dari segi kesehatan, ekonomi, semangat, asmara, maupun rasa bosan.

Belakangan ini saya ingin mencoba untuk lebih sering menambahkan post baru, tapi sering bingung mau membahas apa. Kalau topik yang random, sudah saya bahas sehari-hari di Facebook pribadi dan Grup Sebelah 😅

Jadi, saya mengajak kalian para membaca untuk request sesuatu. Boleh itu tutorial ataupun hal-hal lainnya di kolom komentar. Jika saya bisa, akan saya tulis. Bila tidak bisa, akan saya coba pelajari. Kalau gak bisa juga, yaa gak ditulis 😐

Saya kira cukup jelas sih. Jadi langsung saja mas bero atau mba sis, ditulis di kolom komentar 😜

Satu Detik Yang Krusial

Operasional sistem komputer sangat bergantung terhadap waktu, terutama untuk sistem yang bersifat real-time. Permasalahan waktu bukan lagi pada satuan detik, namun sudah mencapai level milidetik. Saat ini, Coordinated Universal Time (UTC) adalah standar waktu yang digunakan oleh seluruh sistem komputer di dunia. Standar waktu ini dihitung berdasarkan dua komponen, yaitu International Atomic Time (TAI) dan Universal Time (UT1). TAI mengatur laju pergantian detik, sedangkan UT1 menghitung durasi aktual rotasi bumi.

Kecepatan rotasi bumi yang tidak konstan tentu akan menghasilkan selisih antara UTC dengan mean solar time (waktu berdasarkan pergerakan harian matahari). Oleh karena itu, TAI dan UT1 harus selalu dibandingkan satu sama lain untuk memastikan selisih antara mean solar time dengan UTC tidak terlalu signifikan. Sebelum selisih antara TAI dan UT1 mencapai 0,9 detik, satu detik ditambahkan ke dalam UTC. Satu detik itulah yang disebut sebagai detik kabisat (leap second). Tidak seperti tahun kabisat, penambahan detik kabisat terjadi secara bersamaan di seluruh dunia. Sebagai contoh, untuk di Indonesia, detik kabisat yang terjadi pada 31 Desember 2016 23:59:60 UTC, terjadi pada 1 Januari 2017 06:59:60 WIB (UTC +7).

Dalam rentang tahun 1972 hingga 2017, telah terjadi penambahan 27 detik ke dalam perhitungan UTC. Artinya, hingga saat ini fenomena detik kabisat telah terjadi sebanyak 27 kali. Pada titik ini, Anda mungkin berpikir bahwa jika fenomena ini sudah terjadi sejak 45 tahun yang lalu, seharusnya detik kabisat tidak menimbulkan masalah atau dampak yang signifikan. Asumsi ini cukup logis mengingat detik kabisat bukanlah suatu fenomena yang baru sehingga orang-orang seharusnya mampu menangani anomali ini. Namun, anggapan tersebut salah, khususnya untuk semua hal yang terkait dengan sistem komputer. Sejumlah organisasi melaporkan bahwa sistem mereka bermasalah karena dampak detik kabisat pada 30 Juni 2012. Beberapa diantara organisasi tersebut adalah Reddit dan Mozilla. Pada umumnya, laporan tersebut berasal dari organisasi yang menggunakan sistem berbasis Linux. Setelah diselidiki, diketahui bahwa beberapa versi Linux belum menangani detik kabisat.

Lalu, pertanyaan selanjutnya adalah bagaimana detik kabisat mempengaruhi sistem komputer? Di awal telah disebutkan bahwa sistem komputer bergantung terhadap waktu. Dalam konteks ini, waktu yang digunakan oleh sistem selalu bergerak maju. Ketika detik kabisat terjadi, komputer akan menganggap waktu bergerak mundur. Kesalahan ini terjadi karena sistem komputer tidak mengenal detik ke-60. Singkatnya, dapat dikatakan bahwa detik kabisat mengubah perhitungan waktu dalam sistem komputer. Kemudian, CPU menganggap perubahan tersebut sebagai error. Hal ini juga berlaku untuk sistem Linux yang disebutkan pada contoh kasus di atas.

Linux memiliki sebuah subsistem bernama hrtimer. Subsistem ini digunakan ketika sebuah aplikasi dalam status ‘sleep‘, menunggu sistem operasi untuk menyelesaikan task lainnya. Dalam beberapa kasus, hrtimer menyimpan sejenis alarm ke dalam setiap ‘sleeping application‘. Alarm tersebut akan membangunkan aplikasi ketika sistem operasi terlalu lama mengerjakan task lain. Saat detik kabisat terjadi, secara tiba-tiba hrtimer menjadi satu detik lebih cepat dari sistem operasi. Dengan perbedaan tersebut, hrtimer menganggap waktu pemrosesan yang dilakukan lebih lama dari yang seharusnya. Akibatnya, hrtimer mengaktifkan alarm tersebut dan membangunkan sejumlah ‘sleeping application‘ dalam waktu yang bersamaan. Hal ini tentu saja akan membuat CPU menjadi overload sehingga dapat mengakibatkan sistem error. Kondisi inilah yang diduga menjadi penyebab error dalam beberapa versi Linux.

Peristiwa detik kabisat pada tahun 2012 memberi pukulan yang cukup besar untuk dunia teknologi informasi. Untuk mengantisipasi agar hal ini tidak kembali terjadi, setidaknya ada dua solusi yang dapat dilakukan. Pertama, memberikan notifikasi kepada sistem operasi ketika detik kabisat terjadi. Notifikasi tersebut diperlukan agar detik ke-60 bisa ditambahkan ke dalam sistem. Kedua, menggunakan teknik leap smear. Teknik ini diperkenalkan oleh Google pada September 2011. Ide dasar dari teknik ini adalah melakukan penambahan waktu dalam skala milidetik secara kontinu hingga detik kabisat selanjutnya terjadi. Dengan kata lain, detik kabisat dimasukkan secara bertahap ke dalam sistem, sehingga pada saat detik kabisat terjadi, sistem akan tetap berjalan normal karena tidak menyadari bahwa detik kabisat telah terjadi.

Dampak yang ditimbulkan oleh detik kabisat meninggalkan sebuah pelajaran yang berharga. Sebagai seorang programmer, Anda harus memikirkan semua ancaman yang berpotensi membuat sistem Anda down. Meskipun kemungkinan terjadinya sangat kecil, ancaman tersebut harus tetap diperhitungkan. Seorang programmer yang baik, harus mempunyai cara untuk mengatasi setiap ancaman yang mungkin menyerang sistemnya. Apa yang terjadi terhadap sistem operasi Linux sebagai akibat dari detik kabisat hanyalah salahsatu contoh kasus yang terdeteksi. Di masa yang akan datang, bukannya tidak mungkin apabila detik kabisat akan kembali menimbulkan bencana bagi dunia teknologi.

Tulisan ini aslinya ditulis oleh Rafi Ramadhan pada 20 Juli 2017 untuk blog di website Refactory

Mengenal Notasi Big O

Programmer yang baik harus mampu memprediksi jumlah sumber daya yang akan ‘dihabiskan’ oleh kode yang ditulisnya. Untuk dapat mengukur hal tersebut, seorang programmer harus mengetahui seberapa efisien algoritma yang telah dia tulis. Efisiensi algoritma dapat diukur dengan sebuah notasi yang bernama Big O. Big O adalah sebuah metrik yang digunakan untuk mengukur kompleksitas suatu algoritma. Kompleksitas dalam konteks ini berkaitan dengan efisiensi kode. Semakin rendah kompleksitasnya, semakin efisien pula kode tersebut.

Notasi Big O mengukur kompleksitas algoritma dalam dimensi waktu. Selain Big O, ada dua notasi lain yang dapat digunakan untuk mengukur kompleksitas waktu sebuah algoritma, yaitu Big Theta dan Big Omega. Konsep Big Omega mirip dengan Big O. Perbedaan kedua konsep tersebut terletak pada semantiknya. Nilai Big Omega menunjukkan batas bawah kompleksitas waktu suatu algoritma, sedangkan Big O sebaliknya. Apabila sebuah algoritma memiliki nilai batas atas dan batas bawah yang sama, algoritma tersebut dikatakan memenuhi konsep Big Theta.

Jika Anda seorang programmer, Anda tidak perlu memahami semua notasi yang ada. Notasi Big O, Big Omega, dan Big Theta lebih sering digunakan oleh para akademisi. Dalam praktiknya di industri teknologi, orang-orang menganggap Big O dan Big Theta sebagai satu konsep yang sama. Di samping itu, notasi Big Omega sangat jarang digunakan. Alasannya cukup sederhana. Sebagian besar orang cenderung lebih tertarik untuk mengetahui waktu eksekusi paling lama yang mungkin terjadi. Dengan kata lain, konsep Big O saja sudah cukup untuk keperluan analisis algoritma seorang programmer.

Sebagai sesuatu yang abstrak, konsep Big O dapat lebih mudah dipahami dengan menggunakan sebuah analogi. Bayangkan Anda memiliki sebuah hard drive berisi data penting yang perlu diberikan kepada teman Anda di luar kota secepatnya. Dalam kasus ini, ada dua alternatif yang dapat dilakukan. Anda bisa melakukan transfer data secara digital atau memberikan hard drive tersebut kepada teman Anda. Dengan alasan efisiensi waktu, tentu saja Anda akan memilih alternatif pertama karena mengirimkan hard drive dapat memakan waktu 3 hingga 5 jam. Namun, bagaimana jika data yang harus dikirimkan sangat besar, misalnya 1 TB? Dengan kecepatan rata-rata internet saat ini (16 Mbps), diperlukan waktu lebih dari satu hari untuk menyelesaikan pengiriman data. Dengan kondisi tersebut, alternatif kedua tentunya menjadi pilihan.

Dalam analogi di atas, proses transfer data mewakili waktu eksekusi (runtime) algoritma. Dalam notasi Big O, proses tersebut dapat dideskripsikan sebagai berikut.

  1. Transfer digital: O(n), di mana n adalah ukuran data. Notasi tersebut menunjukkan bahwa waktu yang diperlukan untuk transfer data akan bertambah secara linear mengikuti besar ukuran data.
  2. Transfer fisik: O(1), di mana 1 adalah suatu konstanta. Nilai konstan dalam notasi tersebut menunjukkan bahwa ukuran data tidak memengaruhi waktu transfer data. Artinya, data akan selalu sampai dalam rentang waktu 3 – 5 jam, tidak peduli seberapa besar data yang dikirimkan

Selain O(n) dan O(1), masih banyak variasi runtime lainnya. Beberapa jenis runtime yang umum ditemui adalah O(log n), O(n log n), O(n^2), O(2^n), dan O(n!). Grafik di bawah ini menunjukkan perbandingan setiap runtime tersebut.

Grafik perbandingan runtime

Sebuah runtime mungkin saja memiliki lebih dari satu variabel. Sebagai contoh, Anda ingin mengecat dinding kamar. Apabila dinding tersebut memiliki lebar l dan memerlukan n lapis cat, waktu total yang diperlukan dapat dirumuskan sebagai O(ln). Penjelasan lebih detil terkait penentuan nilai kompleksitas dari sebuah algoritma akan dijelaskan dalam artikel berikutnya.

Kompleksitas algoritma adalah hal mendasar yang seharusnya dipahami oleh programmer. Pemahaman yang kurang terhadap hal tersebut dapat menimbulkan kerugian. Sebagai seorang programmer, Anda tidak bisa menilai dalam kasus apa algoritma Anda berjalan lebih cepat atau lebih lambat. Selain itu, ketidakmampuan tersebut mungkin saja akan berujung pada kritik dan penilaian buruk terhadap kinerja Anda. Oleh karena itu, menguasai konsep Big O adalah suatu kewajiban jika Anda ingin menjadi programmer yang unggul.

Tulisan ini aslinya ditulis oleh Rafi Ramadhan pada 12 Juli 2017 untuk blog di website Refactory