Sunday, September 18, 2016

Reflux , a Flux Javascript Library

Apa itu flux? Flux adalah suatu pattern yang digunakan oleh facebook untuk membangun sebuah client-side web application. Flux merupakan unidirectional data flow ( data flow searah ) pattern . Lebih jelas nya bisa di lihat disini Berikut ini ilustrasi dari flux pattern


Lalu apa itu Reflux ?

Reflux adalah suatu javascript library yang terinspirasi dari Flux Architecture. Pada dasarnya reflux memangkas flow yang ada dari flux pattern. Reflux terdiri dari dua komponen besar yaitu action dan store dimana action di panggil dari view , berikut ilustrasi gambar data flow reflux :


Dari gambar di atas , kita lihat komponen apa yang di hilangkan dari flux pattern, hal ini lebih mempermudah kita dalam mengimplementasikannya .

Berikut ini contoh pengaplikasian reflux pada suatu web , disini saya menggunakan react sebagai View Component.

Pertama kita membuat sebuah suatu class action sebagai berikut :

import Reflux from 'reflux';

const LovActions = Reflux.createActions([
     {'loadCity': {children: ['completed', 'failed']}},
     {'loadDistrict': {children: ['completed', 'failed']}}
]);

LovActions.loadCity.listenAndPromise(function(){
    return $.ajax({
        type: "GET",
        url: "https://sayurbox.firebaseio.com/areas/DKI%20Jakarta.json"
    });

});



Lalu store sebagai tempat untuk memaintain state dan application logic

import Reflux from 'reflux';
import LovActions from '../actions/lovActions.jsx';

const LovStore = Reflux.createStore({
    listenables: LovActions,

    init() {

    },

    onLoadCity() {
        this.trigger({
            city : {
                loading : true
            }
        });
    },

    onLoadCityCompleted(data) {
        this.trigger({
            city : {
                data   : data,
                loading : true
            }
        });
    },

    onLoadCityFailed(error){
        this.trigger({
            city : {
            error : error,
            loading: false,
            hasError : true
            }
        });
    },


Nah setelah action dan store kita buat , kita panggil action dari view component , contoh (dengan menggunakan react ):

componentDidMount(){
  this.unsubscribe = LovStore.listen(this.onCityChange.bind(this));
  console.log("componentDidMount {}");
  LovActions.loadCity();
 }
onCityChange(data){
  if(typeof data.city != 'undefined' && !data.city.loading){
   console.log("onCityChange if {}",data.city.data);
   this.setState({
    city:data.city.data
   });
  }else if(typeof data.district != 'undefined' && !data.district.loading){
   console.log("onCityChange if {}",data.district.data);
   this.setState({
    district:data.district.data
   });
  }
 }


Di method componentDidMount() , kita daftarin method yang bakal me-listen jika ada sesuatu yang dilempar dari LovStore .

Lalu Bagaimanakah flow Reflux berjalan ? Di componentDidMount() kita lihat syntaks LovActions.loadCity() , artinya , dari React Component ini , dia memanggil action LovAction dan menjalankan loadCity(). Di action, loadCity memanggil API dengan menggunakan jQuery ajax.

Store yang me-listen LovAction (disini LovStore) akan menjalankan method yg sesuai, jika complete, store akan men trigger data yang akan dilempar ke semua view yang me-listen store tersebut ( bisa dilihat di componentDidMount() bahwa komponen ini me-listen LovStore dan method tersebut adalah onCityChange ) , setelah store men-trigger , make onCityChange akan jalan. Demikian tutorial singkat mengenai reflux dari saya , have a nice day :D
Untuk code lebih lengkap bisa dilihat di repo taufik

Sumber

https://github.com/reflux/refluxjs
http://blog.mojotech.com/react-and-reflux-in-5-minutes/
http://blog.andrewray.me/flux-for-stupid-people/

Oracle Fusion Middleware Enterprise Deployment Guide 11g vs 12c

Pada tahun 2013, saya mulai mengaplikasikan Oracle Enterprise Deployment Guide [1][2][3][4] untuk beberapa produk Oracle Fusion Middleware 11g di salah satu perusahaan telekomunikasi di Indonesia dan di salah satu badan pemerintahan DKI Jakarta. Pada saat itu saya berkesempatan mengimplementasikan topologi high availability yang direkomendasikan Oracle untuk kali pertamanya pada produk Oracle SOA Suite, Oracle WebCenter Suite, dan Oracle Access Management. Cukup berat pertama kali mempelajarinya karena jumlah halaman yang mencapai ratusan dan navigasi khas Oracle yang "lompat-lompat", namun kondisi obsessive compulsive disorder (OCD) yang saya miliki membuat saya terus ingin berusaha mempelajari setiap halaman dari guide tersebut dan mencoba untuk mengimplementasikannya dengan benar. Ketika salah satu dokumentasi sudah dipahami, ternyata dokumentasi untuk produk yang lain tidak jauh berbeda polanya sehingga dapat lebih cepat dipahami.

Kurang lebih 3 tahun telah berlalu, dan kali ini saya diberi kesempatan lagi untuk mengimplementasikan high availability architecture pada produk Oracle SOA Suite dan Oracle WebCenter Suite namun kali ini di rilisnya yang terbaru yaitu rilis 12c di salah satu instansi pemerintah yang besar. Kebetulan dokumentasi untuk rilis 12c juga sudah terbit bersamaan dengan jalannya project. Walaupun ada juga seperti WebCenter Portal yang statusnya masih beta dokumentasinya. Tidak seperti 3 tahun  yang lalu, kali ini saya merasa lebih mudah untuk mempelajari dokumentasinya. Saya melihat ada beberapa perkembangan dari sisi teknologi dan konvensi direktori yang digunakan. Berikut ini beberapa perbedaan yang cukup signifikan yang saya amati di antara kedua rilis, yang akan saya coba jelaskan detilnya di paragraf-paragraf selanjutnya:

  1. Directory conventions
  2. Coherence configuration
  3. Web Tier standalone domain
  4. Simplified RCU
  5. Server groups
  6. Virtual IP
  7. Per ost NodeManager
  8. WSM Policy Manager cluster

Directory Conventions


Baik rilis 11g maupun rilis 12c, Oracle menerapkan pemisahan antara ASERVER_HOME dengan MSERVER_HOME. Namun pada rilis 11g konvensi direktori yang diberlakukan cukup kompleks dan membingungkan terutama untuk implementor yang baru pertama kali mengimplementasikan topologi high availability. Pada 11g lokasi konfigurasi domain untuk AdminServer (ASERVER_HOME) berada di:

 /u01/app/oracle/admin/domain_name/aserver/domain_name

Di sini ada 2 kali pengulangan nama domain yang sangat membingungkan. Sedangkan untuk konfigurasi domain untuk Managed Server (MSERVER_HOME) berada di:

/u02/app/oracle/admin/domain_name/mserver/domain_name

Jika dibandingkan dengan konvensi pada rilis 12c, lokasi direktori menjadi lebih mudah dan singkat, yaitu ASERVER_HOME menjadi:

/u01/oracle/config/domains/domain_name

dan MSERVER_HOME menjadi:

/u02/oracle/config/domains/domain_name 

Selain itu konvensi untuk lokasi lainnya pada rilis 12c secara umum lebih mudah dan lebih logis untuk diimplemementasikan.

Coherence Configuration


Pada rilis 11g, deployment SOA Composite terkadang sangat bergantung pada benar tidaknya konfigurasi Coherence yang perlu dilakukan pada server startup argument menggunakan tangosol.coherence.wka<n>. Argumen tersebut perlu ditambahkan di setiap Managed Server yang termasuk di dalam SOA cluster. Pada rilis 12c, ketika initial domain creation secara otomatis akan terbuat sebuah defaultCoherenceCluster yang akan menangani hal ini. Sehingga tidak diperlukan lagi penambahan argumen Tangosol seperti dulu.

Web Tier Role and Standalone Domain


Pada rilis 11g, saya dulu sempat mempertanyakan sebetulnya fungsi dari Web Tier (Oracle HTTP Server) ini apa selain untuk mengakomodasi Single Sign-On (SSO) solution dari Oracle Access Management. Ternyata di dokumentasi rilis 12c lebih dijelaskan fungsi dasar dari Web Tier ini apa dan bagaimana opsional-nya untuk mendeploy-nya di high availability topology. Menurut saya Web Tier ini tetap diperlukan untuk reverse proxy dan mempermudah deployment ketika nantinya akan diintegrasikan dengan load balancer, karena cukup 1 rule saja yang perlu didaftarkan ke load balancer yaitu ke Web Tier.

Selain itu pada rilis 12c ini, memungkinkan untuk memisahkan deployment dari Web Tier menjadi domain yang terpisah dari WebLogic Domain yang menjadi target reverse proxy. Keuntungan dari pendekatan ini adalah kita dapat menempatkan konfigurasi Web Tier di mesin yang terpisah menjauhi application tier dan bisa digunakan untuk me-reverse proxy lebih dari 1 WebLogic Domain.

Simplified RCU


Repository Creation Utility pada rilis 11g merupakan komponen yang di-download secara terpisah dari installer yang lainnya. Namun pada rilis 12c merupakan kesatuan dari produk yang akan diinstall. Misalnya ketika akan meng-install Oracle SOA Suite, maka RCU-nya yang diperlukan sudah termasuk di dalam folder soa. Pendekatan ini memudahkan komponen yang harus di-download dan juga memudahkan proses instalasi. Selain itu ketika akan membuat skema database, RCU 12c membuat sebuah skema khusus yang berisi metadata RCU, biasanya memiliki sufiks STB. Skema STB ini memiliki peran untuk menyimpan informasi skema-skema lainnya yang memiliki prefiks yang sama. Sehingga ketika proses pembuatan database Middleware tidak perlu lagi sysadmin mengetikkan satu per satu prefiks dan password-nya seperti pada rilis 11g.

Server Groups


Salah satu aspek yang paling kompleks ketika mengkonfigurasi high availability topology adalah pada bagian custom deployment target, misalnya ketika ingin memisahkan WSM pada cluster tersendiri. Pada 12c proses tersebut menjadi dimudahkan dengan adanya fitur Server Groups. Di mana Server Groups ini merupakan deployment set yang dapat di-deploy secara kesatuan dan merepresentasikan sebuah fungsi. Pendekatan ini dapat mengurangi tingkat error yang dilakukan ketika memilih deployment yang akan ditargetkan.

Virtual IP


Virtual IP digunakan untuk mem-failover sebuah proses seperti misalnya proses AdminServer dari node yang aktif ke node yang pasif karena kegagalan node aktif. Selain itu virtual IP pada rilis 11g juga dimanfaatkan untuk proses whole server migration yang bisa dilakukan oleh Oracle SOA server. Sehingga WLS_SOA1 misalnya dapat sepenuhnya pindah ke SOAHOST2, ketika SOAHOST1 gagal. Sehingga pada suatu ketika SOAHOST2 berisi WLS_SOA1 dan WLS_SOA2.

Pada rilis 12c virtual IP yang diperlukan hanya untuk AdminServer, karena Oracle SOA Suite 12c sudah mendukung fitur Automatic Service Migration, di mana yang dipindahkan adalah pada level service-nya. Sehingga migrasi penuh WebLogic Managed Server dari SOAHOST1 ke SOAHOST2 tidak diperlukan.

Per Host Node Manager


Pada rilis 11g, tidak secara detil dijelaskan bagaimana sebenarnya konfigurasi yang benar untuk NodeManager. Penempatan direktori dan perintah yang digunakan juga masih tidak jelas. Hingga akhirnya waktu itu saya mencari-cari cara sendiri untuk mempermudah proses startup dan shutdown dari NodeManager dari berbagai sumber hingga menghasilkan how to versi saya yang saya sempat share di [5].

Pada rilis 12c, walaupun masih belum jelas seperti yang saya harapkan. Namun setidaknya sudah terlihat bahwa ada 2 alternatif konfigurasi yaitu per domain NodeManager atau per host NodeManager. Masing-masing alternatif dijelaskan keuntungan dan kekurangannya, namun masih disarankan untuk membuat per host NodeManager.

WSM Policy Manager Cluster


Sejak rilis 11g saya sudah mempertanyakan alasan sebetulnya kenapa WSM Policy Manager dipisahkan ke 1 cluster khusus, yaitu WSM-PM_Cluster. Saya sempat mempertanyakan juga ke Oracle Support mengenai hal ini, namun jawaban yang mereka berikan tidak memuaskan. Pada rilis 12c dijelaskan secara lebih detil bahwa dengan alasan kinerja secara keseluruhan lebih baik jika WSM Policy Manager dipisahkan deployment-nya ke cluster khusus.


Demikian sedikit ulasan saya mengenai dokumentasi Oracle. Semoga bermanfaat.


Daftar referensi:
[1] Fusion Middleware Enterprise Deployment Guide for Oracle SOA Suite
[2] Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Portal
[3] Fusion Middleware Enterprise Deployment Guide for Oracle WebCenter Content
[4] Fusion Middleware Enterprise Deployment Guide for Oracle Identity Management
[5] Simplified NodeManager Setup

PopUp List Of View in AngularJs

Membuat Popup atau pada angularjs menyebutnya Modal, memang menjadi daya tarik sendiri selain untuk mempercantik pada tampilan tapi juga dapat menyesuaikan kebutuhan, sehingga tidak harus selalu membuka page baru untuk data yang sifatnya tidak terlalu banyak. Blog kali ini akan membahas tentang Popup List Of View, dimana Popup tersebut akan menampilkan list data Provinsi dan data Kab / Kota yang berada di Provinsi tersebut.

Seperti membuat modal pada umumnya, di mulai dari file HTML


di mana kita membuat form input yang di sertai button untuk memanggil fungsi pada controller yang akan menampilkan modal dengan list dari provinsi. Pada form input kab / kota, di bagian ng-click kita juga mengirimkan id dari provinsi supaya ketika kita memilih provinsi tersebut, kita dapat melihat kab / kota yang ada dalam provinsi tersebut.


Lihat kembali HTML, ng-click dari provinsi akan memanggil function cariNama3 dan di kab / kota akan memanggil function cariNama4. Ada sedikit perbedaan dari 2 function tersebut, yaitu pada data yang akan di kirim ke controller modal. Di dalam 2 function tersebut ada yang namanya modalParam. ModalParam fungsi nya untuk menampung data yang di kirim dari file HTML tadi dan akan di kirimkan ke controller modal sebagai parameter untuk mengambil data dari backend.
Bingung ya..??? Begini kira - kira flow nya

Nah saatnya ke controller modal,


di sini parameter id prov yang di kirim dari controller view (function kab / kota ) di kenali sebagai seacrh_idProv dalam function lovKab. 2 Function di atas lah yang bertugas mengambil data dari backend. Berikut penampakan dari modal provinsi dan kab / kota



Selesai sudah membuat modal provinsi dan kab / kota, semoga blog ini bermanfaat dan selamat mencoba dan menerapkan pada kasus - kasus berikutnya. :D


Optimal Memory Partitioning with Linux Explicit Huge Pages

Salah satu tantangan yang saya rasakan ketika membuat sebuah platform virtualisasi adalah bagaimana secara efektif platform tersebut dapat mengalokasikan memori untuk virtual machine secara fleksibel dan handal. Seringkali ketika kita tidak memikirkan hal tersebut, memori yang tersedia di hypervisor tidak selalu sepenuhnya tersedia secara efektif. Ketika memori diperlukan untuk menghidupkan sebuah virtual machine, bisa jadi memori yang tersedia sudah dipegang oleh mekanisme Linux Page Cache atau proses di hypervisor yang lain. Sehingga memori yang bebas digunakan oleh virtual machine sulit untuk diperoleh angka persisnya berapa. Terkadang kita tidak menyadari bahwa sebetulnya memori yang bebas itu sudah menipis sehingga ketika menghidupkan virtual machine tambahan, hypervisor harus melakukan swapping sehingga kinerja keseluruhan menjadi turun.

Hypervisor pun sebetulnya juga membutuhkan resource komputasi yang cukup untuk melakukan aktivitasnya. Sebuah hypervisor berkapasitas 128 GB memori, tentu bukan berarti kita dapat menghidupkan 16 virtual machine berkapasitas 8 GB. Kita harus memikirkan juga untuk menyisakan sebagian memori dari 128 GB tersebut khusus untuk dikonsumsi oleh hyperivisor. Pendekatan yang dilakukan oleh cloud provider besar seperti Google Cloud Platform dan Microsoft Azure, adalah dengan menyediakan paket-paket sizing virtual machine yang sedikit dikurangi kapasitas memorinya dari kapasitas yang umum. 

Skema Sizing Microsoft Azure

Pada skema Microsoft Azure di atas, terlihat bahwa untuk setiap tipe virtual machine yang ditawarkan besar kapasitas memori adalah sedikit di bawah angka standar dari deret eksponensial 2 (1 GB, 2 GB, 4 GB, 8 GB, 16 GB, 32 GB, 64 GB, 128 GB). Semakin besar memori yang akan dialokasikan ke sebuah virtual machine, semakin besar pula selisihnya dengan angka umum.

Skema Sizing Google Cloud Platform

Skema yang serupa ternyata juga terlihat pada skema ukuran virtual machine yang disediakan di Google Cloud Platform. Walaupun tidak seagresif pengalokasian pada Microsoft Azure, Google Cloud Platform juga terlihat menyediakan sebagian memori yang seharusnya dialokasikan mengikuti deret eksponensial 2.

Kedua contoh tersebut dapat diaplikasikan pada cloud provider besar seperti Microsoft Azure dan Google Cloud Platform karena jumlah hypervisor node yang mereka miliki juga sangat banyak. Namun bagaimana pada kasus topologi yang sederhana. Misalnya saja pada server development di Nostratech, bernama Arjuna, yang hanya memiliki kapasitas memori 96 GB. Pengalokasian seperti model tersebut selain cukup menyulitkan dalam perhitungan, dalam jumlah virtual machine yang banyak juga akan sangat banyak memori yang tidak termanfaatkan dengan baik.

Sebagai latar belakang, Arjuna merupakan development platform di Nostratech yang saya rancang dengan menggunakan teknologi Linux KVM sebagai hypervisor dan OpenZFS sebagai storage management layer-nya. Kedua teknologi tersebut bisa dikatakan banyak menggunakan memori sehingga saya merasa cukup tertantang ketika merancang Arjuna. Saya tidak pernah suka dengan swap space, karena menurut saya ketika sudah terjadi swapping proses apapun juga akan menjadi lambat dan tidak efektif lagi. Sehingga saya tidak mengalokasikan swap space sama sekali pada Arjuna. Berikut adalah pembagian memori yang saya lakukan pada Arjuna:


Pada skema tersebut terlihat dengan jelas pembagian 96 GB memori ke masing-masing pemetaannya. Linux Page Cache merupakan mekanisme caching pada Linux dan untuk mengaturnya membutuhkan parameter yang cukup kompleks dan tidak secara eksplisit terlihat berapa penggunakan maksimumnya. Untuk itulah pendekatan yang saya lakukan terbalik. Saya merancang untuk mengalokasikan 8 GB untuk OpenZFS ARC caching, dan 80 GB untuk virtual machine. Sehingga sisa 8 GB dapat secara bebas dimanfaatkan oleh Linux Page Cache. Namun bagaimana saya dapat menjamin saya dapat mengalokasikan 80 GB untuk virtual machine? Di sinilah saya memanfaatkan teknologi explicit huge pages pada Linux.

Linux mengakses memori dalam bentuk satuan kecil yang bernama pages. Besaran asli dari pages adalah sekitar 4 kB. Huge pages [1][2] merupakan terobosan selanjutnya yang memungkinkan besaran dari pages ditingkatkan menjadi 2 MB hingga 1 GB. Sehingga pengalokasian memori dapat lebih efektif karena jumlah call yang diperlukan menjadi lebih sedikit untuk jumlah pengalokasian memori yang sama.

Linux memiliki 2 tipe huge pages, transparent huge pages dan explicit huge pages. Perbedaan dari keduanya adalah pada transparent huge pages kernel Linux sendiri yang melakukan pengaturan proses apa dan menggunakan page size yang mana yang tepat. Sedangkan pada explicit huge pages sejak dari awal boot, kernel sudah melakukan alokasi partisi memori sehingga menjamin keseinambungan dari memori yang dialokasikan. Arjuna menggunakan explicit huge pages, sehingga setiap kali boot Arjuna memiliki pemetaan memori seperti gambar sebelumnya.

Untuk konfigurasi yang perlu dilakukan adalah cukup dengan menambahkan kernel boot parameter berikut ini:
transparent_hugepage=never default_hugepagesz=2M hugepagesz=2M hugepages=40960

Sedangkan untuk melihat berapa sisa kapasitas memori dari partisi explicit huge pages dapat menggunakan perintah berikut ini:
grep Huge /proc/meminfo

Agar Linux KVM dapat memanfaatkan partisi memori huge pages tersebut, perlu disisipkan sedikit konfigurasi pada QEMU command line-nya:
-mem-path /dev/hugepages

Jika menggunakan libvirt XML, maka perlu menambahkan:
<memoryBacking>
<hugepages/>
</memoryBacking>

Selamat mencoba!

[1] https://www.kernel.org/doc/Documentation/vm/hugetlbpage.txt
[2] https://wiki.debian.org/Hugepages




Springboot + Java Robot

Pada kesempatan sebelumnya saya pernah membahas mengenai java.awt.Robot di artikel ini.
Dan saat itu saya menganggap bahwa ini library menarik, karena bisa melakukan/menggantikan input dari keyboard dan mouse. 

Pada dasarnya java robot ini memang ditujukan untuk automation seperti yang di jelaskan pada java doc:
This class is used to generate native system input events for the purposes of test automation, self-running demos, and other applications where control of the mouse and keyboard is needed. The primary purpose of Robot is to facilitate automated testing of Java platform implementations.
Untuk input mouse menggunakan java.awt.event.InputEvent yang sudah dibahas pada post sebelum nya. Sedangkan untuk input keyboard menggunakan java.awt.event.KeyEvent. Pada kali ini yg akan kita gunakan adalah input keyboard, berikut contohnya:
 
try {
    Robot robot = new Robot();

    // untuk melakukan aksi menekan tombol enter 
    robot.keyPress(KeyEvent.VK_ENTER);
    // untuk melakukan aksi melepas tombol enter
    robot.keyRelease(KeyEvent.VK_ENTER);

    // untuk melakukan aksi menekan tombol tab 
    robot.keyPress(KeyEvent.VK_TAB);
    // untuk melakukan aksi melepas tombol tab
    robot.keyRelease(KeyEvent.VK_TAB);

} catch (AWTException e) {
    e.printStackTrace();
}
 

Springboot & Headless Mode

Dan ternyata java Robot ini bisa di kombinasikan dengan Springboot. Library ini ternyata bisa digunakan/running dalam springboot yang merupakan sebuah application server dengan menambahkan sedikit code, yaitu konfigurasi system headless. Beberapa library java secara default berasumsi bahwa UI atau Display Monitor dan juga keyboard terpasang. Application server tidak memiliki UI atau Display Monitor yang terpasang, dan ini disebut mode Headless.

Tetapi karena Springboot merupakan sebuah standalone yang bisa juga kita running pada laptop/PC, jadi bisa kita mengeset mode Headless ini menjadi false. Berikut baris code tambahan untuk melakukan setting mode headless :
 
System.setProperty("java.awt.headless", "false");
 

Implementasi

Jadi ide kali ini bertujuan akhir untuk bisa menginput aksi tombol arrow ke kanan dan kiri keyboard.
Sehingga bisa membantu kita saat melakukan presentasi dan berposisi jauh dari laptop.

Untuk spring boot yang digunakan adalah gs-rest-service bisa di dapatkan dari github springboot rest.
Buatlah sebuah API baru seperti berikut:
 
@RequestMapping("/right")
public void right(){
    try {
        System.setProperty("java.awt.headless", "false");

        Robot robot = new Robot();
        robot.keyPress(KeyEvent.VK_RIGHT);
        robot.keyRelease(KeyEvent.VK_RIGHT);
    } catch (AWTException e) {
        e.printStackTrace();
    }
}
 

Setelah kita running springboot tersebut dan mengakses API yang baru saja kita buat, maka laptop/komputer akan mendapatkan aksi tombol arrow ke kanan.
 
http://localhost:8080/right
 
API ini bisa di call melalui perangkat lain yang satu jaringan dengan laptop ini. Misalnya laptop lain yang terkonek pada Access Point/WiFi yang sama, atau perangkat mobile yang bisa mengakses url API tersebut.

Kita tinggal mengemasnya menjadi sebuah aplikasi mobile yang memudahkan pengguna untuk mengakses method-method baru yang kita buat. Dimana di dalam method-method baru itu mungkin berisi logic dari sebuah kombinasi aktivitas keyboard dan mouse yang sudah kita tentukan sendiri.