Cara mudah install/update gradle di Mac

Mungkin masih ada yang bingung bagaimana cara mengupdate gradle secara manual, atau terlalu pusing dengan banyaknya step di internet. Nah, di mac ada cara mudah dan cepat untuk meng-install atau meng-update gradle. Lakukanlah langkah-langkah berikut.

Di mac, buka terminal, kemudian ketik perintah berikut untuk menginstall SDKMan:

curl -s https://get.sdkman.io | bash

Setelah selesai, lanjut ketikkan perintah berikut:

$ sdk install gradle 3.5

Setelah selesai install gradle, cek di Android Studio apakah gradlenya sudah versi 3.5 atau belum, dengan cara masuk ke Terminal-nya Android Studio, kemudian ketik perintah berikut:

Gradle --version

Jika berhasil, maka hasilnya seperti pada gambar di bawah ini:

Screen Shot 2017-04-30 at 8.53.56 PM

Selesai 😀

Mempercepat proses gradle build

Masalah yang sering dihadapi seorang developer Android adalah berhadapan dengan IDE Android Studio. IDE ini memang dikenal memakan banyak resource RAM dan harddisk, bahkan RAM yang disarankan cukup besar 8 GB. Jika di bawah itu ya, siap-siap saja menunggu lama compile aplikasi sambil ditinggal tidur, ngopi dan makan.

Jika sudah memenuhi spesifikasi install Android Studio, namun dirasa masih cukup lambat, terutama ketika melakukan “build” aplikasi menggunakan gradle, ada baiknya mencoba tips berikut:

  1. Update versi gradle ke versi terbaru. Saat ini (April 2017) versi terbarunya adalah versi 3.5 (https://docs.gradle.org/current/release-notes.html)
    Cara updatenya bisa ikuti di tutorial berikut: https://gradle.org/install
  2. Buat file baru dengan nama gradle.properties, taruh di lokasi berikut:
    /home/<username>/.gradle/ (Linux)
    /Users/<username>/.gradle/ (Mac)
    C:\Users\<username>\.gradle (Windows)

    Setelah itu copas teks berikut ke gradle.properties:

    org.gradle.daemon=true
    org.gradle.parallel=true
    org.gradle.jvmargs=-Xmx2048M   

    Untuk org.gradle.jvmargs, apabila RAM yang dimiliki sekitar 4 GB, cukup set di angka 2048M, namun jika lebih ya lebih bagus, bisa diset di angka 8192 bagi yang memiliki RAM sekitar 16 GB.
    Jika sudah, save, dan lanjut ke bagian android Studio. Buka Preferences/Settings Android Studio, masuk ke bagian “Build, Execution, Deployment”, pilih “Gradle” dan beri centang pada “Offline Work” seperti pada gambar di bawah ini, dan set directory-nya ke lokasi gradle.properties yang sudah dibuat tadi.
    lseqd

  3. Beri parameter –offline pada Compiler seperti pada gambar di bawah ini:
    gjrrv
  4. Masuk ke Aplikasi yang sedang dibuat di Android Studio, klik build.gradle.
    Setelah itu tambahkan line berikut di dalam tag android:
    Screen Shot 2017-04-30 at 6.00.47 PM

    dexOptions {
        incremental true
        javaMaxHeapSize "4g"
    }

    beri angka “4g” apabila RAM yang dimiliki 4GB, dan beri angka 8g bila RAM yang dimiliki 8GB. Dokumentasinya ada di sini: google.github.io/android-gradle-dsl/current/

  5. Perbesar heapsize untuk mempercepat build di gradle.properties dengan menambahkan parameter berikut:
    # Specifies the JVM arguments used for the daemon process.
    # The setting is particularly useful for tweaking memory settings.
    # Default value: -Xmx10248m -XX:MaxPermSize=256m
    org.gradle.jvmargs=-Xmx2048m -XX:MaxPermSize=512m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8

    *peringatan: memperbesar heapsize beresiko membuat software lain yang dibuka menjadi lambat. Karena RAM akan terfokus ke gradle Android Studio.

  6. Done, selamat mencoba 😀

Testing app di Android Studio menggunakan device Android via Wifi

Bagi yang ribet menggunakan kabel untuk melakukan pengujian aplikasi ke device/hardware Android, anda dapat mengikuti cara mudah berikut ini. Di artikel ini diberikan 2 opsi melakukan pengujian aplikasi dari Android Studio ke device Android dengan perantara nirkabel/wifi.

Metode Pertama.

  • Nyalakan debugging mode di Pengaturan HP/device Android.
  • Koneksikan kabel usb dari laptop/PC ke HP Android (ini untuk inisialisasi saja, seterusnya tidak diperlukan lagi)
  • Gunakan command prompt/terminal yang sudah bisa menggunakan perintah “adb” (atau ya kalau belum paham, tinggal arahkan saja ke path lokasi SDK Android dan masuk ke directory sdk/platform-tools/ di dalamnya ada batch file adb)
  • Ketik:
    adb tcpip 5555[enter]
  • setelah itu cek IP Address HP/device Android dengan cara ketik:
    adb shell netcfg
  • Setelah anda mengetahui IP Address dari device/HP anda, dicatat/diingat, kemudian ketikkan perintah dengan format berikut:
    adb connect [IP_Address_device]:5555
    Contoh: adb connect 192.168.1.6:5555[enter]
    nanti akan muncul response:

    “connected to 192.168.1.6:5555” (ini tidak perlu diketik ya..ini akan muncul kalau anda berhasil menghubungkan HP/device android ke laptop via IPaddress secara wireless)

  • Setelah itu lepas kabel usb dari HP/device Android dan laptop/PC anda.
  • Dan selamat menikmati, Android Studio anda sudah bisa melakukan testing ke device/HP Android tanpa terhubung dengan kabel usb.
  • Bila anda sudah selesai melakukan testing aplikasi, anda dapat menutup koneksi wireless dari HP ke laptop anda dengan perintah berikut:
    adb -s [IP_address_device]:5555 usb [enter]

Cukup ribet ya cara di atas? atau masih ada yang gagal mencoba? Move-on dong..mari coba metode ke-dua.

Metode Kedua.

  1. Dari Android Studio kamu, masuk ke Preferences, dengan cara:
    Android Studio: Preferences/Settings->Plugins->Browse Repositories
  2. Install Plugins dengan mengetikkan: “Android WiFi ADB” dan pilih install sesuai petunjuk di layar.
  3. Setelah selesai Install, apabila diminta restart, pilih “restart”
  4. Selamat, plugins Android WiFi ADB berhasil diinstall. Sekarang bagaimana cara menggunakannya ya? Lanjut ke step ke-5.
  5. Mau testing di device Android, tentu jangan lupa nyalakan DEBUGGING mode (pokoknya wajib, masih belum ngerti? bisa bertanya atau cari diinternet, seharusnya developer Android tau langkah mudah mengaktifkan debugging mode ini)
  6.  

    Cari opsi “DEBUG OVER TCP/NETWORK” di dalam Menu Pengaturan/Settings device/HP android kamu>Developer Options.

  7.  

    Pasang kabel USB dari HP ke Laptop/PC, dan pastikan keduanya (PC dan HP) menggunakan jaringan internet yang sama (ntah hotspot ataupun wifi)

  8.  

    Pilih icon ANDROID Wifi ADB di Android Studio.

  9.  

    Setelah itu, device/hp kamu akan terdeteksi di situ, dan siap digunakan untuk testing (jangan lupa cabut kabel USBnya yah pas menggunakan plugins Android Wifi ADB ini)

Selamat mencoba.

 

“Adaptive Design” di Aplikasi Android

Salah satu bentuk tantangan tersendiri di dalam pengembangan aplikasi Android adalah, membuat aplikasi yang well designed secara antarmuka, apalagi ada banyak keberagaman jenis device Android, baik dari ukuran layar (3 inci, 4 inci, 5 inci sampai 10 inci) maupun density (Android menggunakan satuan dp (pixel density) bukan pixel, ini mengacu pada konsentrasi pixel pada layar tertentu, diukur dalam pixel per inch (ppi). Kerapatan pixel (dp) ini dihitung dengan membagi resolusi pixel diagonal layar dengan ukuran diagonal).

Ngomong-ngomong soal pixel density. Bisa dicek di tabel berikut bagaimana acuannya untuk beberapa resolusi dalam satuan pixel ke density pixel:

---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------
Device                          Inches  ResolutionPX    Density         DPI     ResolutionDP    AspectRatios        SysNavYorN  ContentResolutionDP
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------                                                          
Galaxy Y                                 320 x  240     ldpi    0.75    120      427 x 320      4:3     1.3333                   427 x 320
?                                        400 x  240     ldpi    0.75    120      533 x 320      5:3     1.6667                   533 x 320
?                                        432 x  240     ldpi    0.75    120      576 x 320      9:5     1.8000                   576 x 320
Galaxy Ace                               480 x  320     mdpi    1       160      480 x 320      3:2     1.5000                   480 x 320
Nexus S                                  800 x  480     hdpi    1.5     240      533 x 320      5:3     1.6667                   533 x 320
"Galaxy SIII    Mini"                    800 x  480     hdpi    1.5     240      533 x 320      5:3     1.6667                   533 x 320
?                                        854 x  480     hdpi    1.5     240      569 x 320      427:240 1.7792                   569 x 320

Galaxy SIII                             1280 x  720     xhdpi   2       320      640 x 360      16:9    1.7778                   640 x 360
Galaxy Nexus                            1280 x  720     xhdpi   2       320      640 x 360      16:9    1.7778                   640 x 360
HTC One X                       4.7"    1280 x  720     xhdpi   2       320      640 x 360      16:9    1.7778                   640 x 360
Nexus 5                         5"      1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778      YES          592 x 360
Galaxy S4                       5"      1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778                   640 x 360
HTC One                         5"      1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778                   640 x 360
Galaxy Note III                 5.7"    1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778                   640 x 360
HTC One Max                     5.9"    1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778                   640 x 360
Galaxy Note II                  5.6"    1280 x  720     xhdpi   2       320      640 x 360      16:9    1.7778                   640 x 360
Nexus 4                         4.4"    1200 x  768     xhdpi   2       320      600 x 384      25:16   1.5625      YES          552 x 384
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------
Device                          Inches  ResolutionPX    Density         DPI     ResolutionDP    AspectRatios        SysNavYorN  ContentResolutionDP
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------
?                                        800 x  480     mdpi    1       160      800 x 480      5:3     1.6667                   800 x 480
?                                        854 x  480     mdpi    1       160      854 x 480      427:240 1.7792                   854 x 480
Galaxy Mega                     6.3"    1280 x  720     hdpi    1.5     240      853 x 480      16:9    1.7778                   853 x 480
Kindle Fire HD                  7"      1280 x  800     hdpi    1.5     240      853 x 533      8:5     1.6000                   853 x 533
Galaxy Mega                     5.8"     960 x  540     tvdpi   1.33333 213.333  720 x 405      16:9    1.7778                   720 x 405
Sony Xperia Z Ultra             6.4"    1920 x 1080     xhdpi   2       320      960 x 540      16:9    1.7778                   960 x 540

Kindle Fire (1st & 2nd gen)     7"      1024 x  600     mdpi    1       160     1024 x 600      128:75  1.7067                  1024 x 600
Tesco Hudl                      7"      1400 x  900     hdpi    1.5     240      933 x 600      14:9    1.5556                   933 x 600
Nexus 7 (1st gen/2012)          7"      1280 x  800     tvdpi   1.33333 213.333  960 x 600      8:5     1.6000      YES          912 x 600
Nexus 7 (2nd gen/2013)          7"      1824 x 1200     xhdpi   2       320      912 x 600      38:25   1.5200      YES          864 x 600
Kindle Fire HDX                 7"      1920 x 1200     xhdpi   2       320      960 x 600      8:5     1.6000                   960 x 600
?                                        800 x  480     ldpi    0.75    120     1067 x 640      5:3     1.6667                  1067 x 640
?                                        854 x  480     ldpi    0.75    120     1139 x 640      427:240 1.7792                  1139 x 640

Kindle Fire HD                  8.9"    1920 x 1200     hdpi    1.5     240     1280 x 800      8:5     1.6000                  1280 x 800
Kindle Fire HDX                 8.9"    2560 x 1600     xhdpi   2       320     1280 x 800      8:5     1.6000                  1280 x 800
Galaxy Tab 2                    10"     1280 x  800     mdpi    1       160     1280 x 800      8:5     1.6000                  1280 x 800
Galaxy Tab 3                    10"     1280 x  800     mdpi    1       160     1280 x 800      8:5     1.6000                  1280 x 800
ASUS Transformer                10"     1280 x  800     mdpi    1       160     1280 x 800      8:5     1.6000                  1280 x 800
ASUS Transformer 2              10"     1920 x 1200     hdpi    1.5     240     1280 x 800      8:5     1.6000                  1280 x 800
Nexus 10                        10"     2560 x  1600    xhdpi   2       320     1280 x 800      8:5     1.6000                  1280 x 800
Galaxy Note 10.1                10"     2560 x  1600    xhdpi   2       320     1280 x 800      8:5     1.6000                  1280 x 800
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------
Device                          Inches  ResolutionPX    Density         DPI     ResolutionDP    AspectRatios        SysNavYorN  ContentResolutionDP
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------

Dan dokumentasi lengkapnya bisa dilihat di sini: https://developer.android.com/guide/practices/screens_support.html#testing

Itulah mengapa di dalam Resources Project di Android Application terdapat drawable dan layout dengan kategori ldpi (low-dpi), mdpi (medium-dpi), hdpi (high-dpi), xhdpi (extra high-dpi), xxhdpi, dan xxxhdpi.
Masing-masing kategori folder tersebut merujuk ke DPI layar device.
Jadi ketika ingin menerapkan aplikasi yang disupport di ukuran layar 3 inch (dengan dpi 160) dan 4 inch (dengan dpi 240), maka harus dicek di tabel di atas, bahwa dpi 160 itu adalah mdpi, so desain yang kamu siapkan mesti ditaruh di folder drawable/drawable-mdpi dan layoutnya di folder layout/layout-mdpi, begitu juga dengan DPI lainnya.

screen-shot-2017-01-13-at-4-07-46-pm

Lalu bagaimana caranya biar satu slicing desain saya bisa pas ditaruh di masing-masing folder tersebut (ldpi, mdpi, hdpi, dll) tanpa perlu repot?

Ada banyak cara loh! Caranya gak pake ribet, ada yang cara online dan ada yang cara offline.

Untuk membuat 1 komponen desain agar bisa diterapkan di masing-masing folder dpi tersebut dapat menggunakan generator, salah satunya 9-patch generator yang bisa dicoba secara online di sini. Dan untuk cara offline-nya, bisa dicoba langsung dari Android Studio dengan cara:

Install plugin “Drawable Importer” dengan cara masuk ke Preferences di Android Studio.

Setelah itu masuk ke bagian Editor\Plugins dan pilih Browse Repositories. Masukkan keyword “Android Drawable Importer” lalu klik “Install Plugin”, seperti pada gambar di bawah ini:

drawable_importer-1

Setelah itu tinggal digunakan dengan cara klik kanan file drawablenya dan pilih New\Scaled drawable. Dan ikutilah petunjuknya di layar.

Dengan mempersiapkan slicing komponen desain dengan berbagai ukuran layar, kita bisa membuat aplikasi tersebut menjadi adaptive design, tanpa khawatir aplikasi tersebut tidak cocok di berbagai ukuran layar.

Project Hunter wanna be

Kemarin ada teman yang berdiskusi mengenai proyek, teman saya ini dari pegawai kantoran yang akhirnya berhenti dan memilih membangun usaha sendiri dan menjadi project-hunter.
Diskusi panjang lebar.. hingga 2 hari tetap dilanjut dari chat sampai telpon.
Dari diskusi ini saya mendapati beberapa yang mesti dikoreksi, dan smoga menjadi pelajaran bersama..

  1. Jangan pernah membawa perkara teknis pengembangan ke klien (apalagi kalau kliennya gaptek). Cukuplah internal saja yang mengetahui perkara teknisnya bagaimana. Kecuali, si klien memang punya tim engineer yang bakal turut campur di dalam proyek ini, dan mereka harus mengetahui hal tersebut atau emang si klien mengerti soal teknologi dan ingin mengetahui teknologi apa yang nantinya diterapkan di produk software yang ia minta, dan biasanya si klien duluan yang buka omongan teknis, ya kita sebagai vendor TI menjawab pertanyaan tersebut dengan baik dan benar.
    Terkadang salahnya di sini, pas meeting, kita yang merasa sudah jago develop aplikasi. malah menyampaikan hal-hal teknis dari A sampai Z di software yang ingin ia bangun, kalau yang seperti ini yang ada klien cm “angguk-angguk” padahal ya bingung (masuk kuping kanan keluar kuping kiri). Kesan ke kliennya tidak kita dapatkan sama sekali, malahan maksud hati ingin meyakinkan klien dengan cara menjelaskan teknis pengembangan, mulai dari bikin flow diagram/flowchart, bikin pake framework apa, codenya seperti apa, versi berapa, terus nanti pakai web service apa, dan lain-lain, eh malah tidak berkesan.
    Ada baiknya sampaikan presentasi yang bagus dalam bentuk gambar, flow aplikasinya sudah dlm bentuk tampilan antarmuka software, dan kita jelaskan tiap step-nya dari login sampe logout di gambar tampilan antarmuka tersebut, sehingga si klien sudah dapat gambaran, seperti apa nantinya tampilan software tersebut, dan ini lebih meyakinkan daripada kita bawa-bawa hal teknis pengembangan. Dan di situ juga diharapkan klien memberi feedback, kira-kira dari gambar yang disajikan adakah yang kurang pas menurut pengguna, misal warna, susunan menu, dan sebagainya. Atau syukur-syukur kita sudah punya contoh dari prototype/portofolio yang kita punya.
  2. Kebanyakan klien tidak mengetahui apa yang mereka butuhkan, mereka mengikuti trend atau dari apa yang ia ketahui saja. Misal : dia tau Windows itu mudah dipakai, karena memang ia taunya cuma OS itu, dan belum coba Linux atau OSX. Ketika dikasih lihat Linux, mereka bingung, belum terbiasa. Nah sama kasusnya ketika disuruh memilih server, kita menyarankan menggunakan Linux CentOS, si klien lebih memilih OS Windows 10, padahal kebutuhannya si klien ini tidak cocok diimplementasikan di OS tersebut. (ini cuma contoh kecil, ada banyak lagi contoh lain, seperti keinginan klien supaya tampilan softwarenya seperti Facebook, ingin akses message-nya secepat Whatsapp/telegram, padahal si klien belum memahami kebutuhannya seperti apa, ketersediaan resourcenya bagaimana, budgetnya seberapa, jatuhnya kebanyakan keinginan yang tidak tepat sasaran)
    Maka dari itu, coba tawarkan solusi alternatif, misal ketika kita mendapat order membuat aplikasi mobile. untuk broadcast SMS, coba tawarkan alternatif, tulis di proposal dan ketika meeting, sampaikan yg anda tawarkan tersebut yg mungkin bisa menjadi solusi bagi klien: “pak, bagaimana kalo broadcastnya mirip bbm/wa, ntar muncul di smartphone konsumen, promonya apa aja..kalo sms takutnya regulasinya panjang, apalagi sekali broadcast terbatas, dan mungkin ada kendala delay”..syukur-syukur klien angkut dua tawaran yang kita sampaikan, proyek sms broadcast dapet, ditambah proyek messanger jg dapet.
  3. Buang sedikit ego, ketika harga proyek ditawar klien terlalu menyakitkan, cobalah sedikit tenang, berpikir apa yang bisa kita coba agar tetap goal mendapatkan proyek tersebut.
    Dengan berpikir tenang, kita coba koreksi apa saja bagian yang bisa kita kurangi standarnya (tanpa mengurangi esensi pemenuhan kebutuhan klien), misal harga desainnya dikurangi, nego lagi dengan designer, kira-kira apabila harga dikurangi segini bakal dapet seperti apa, dan sebagainya..atau ditambah waktunya, biasanya semakin tipis timeline, harga tentu semakin tinggi, karena jam kerja/hari tentu menjadi tinggi, mungkin dengan melebarkan timeline (misal ditawarkan waktu pengerjaan 3 bulan, kita tawarkan menjadi 5 bulan), mengurangi “beban” kerja dan tentu harganya bisa dikurangi. Atau tawarkan alternatif harga modular : “bapak, silahkan dilihat list harga dari kami, ini kami pasang per module : “Bapak bisa cek untuk kebutuhan yang bapak minta standar harganya segini, namun karena bapak meminta kami mengerjakan bagian X, Y, Z, saya coba tawarkan harganya per module, sehingga bapak bisa pilih yang mana yang akan bapak ambil saat ini dan yang mana bapak pending. Dan apabila nanti ingin melanjutkan kerjasama ini, siapa tau ke depannya, bapak meminta kami mengembangkan modul-modul yang bapak belum kesampean karena terbatasnya budget di penawaran berikutnya.”

Kira-kira seperti itu tips hari ini.
Sekian dan terima kasih 🙂

Menentukan harga jasa untuk programmer dan desainer

Setelah pernah dibahas mengenai menentukan harga project TI khususnya mobile apps. yang ingin kita bahas adalah bagaimana menentukan harga jasa untuk programmer atau desainer mobile apps (mungkin bisa dipakai untuk developer software secara global)

Begini, akhir-akhir ini saya sering ditanya mahasiswa : “mas, bagaimana cara menentukan harga desain saya? saya ragu mau pasang harga”

Kalau menghendaki harga yang pantas dan ideal, itu subjektif, silahkan tentukan berdasarkan usaha yang akan dikeluarkan dan alokasi waktunya. Dan pasang harganya. Yang penting berani dan sudah mengukur sendiri harga yang pantas. Jangan sampai, kamu pasang harga 3 juta rupiah, namun, ternyata uang yang dikeluarkan untuk usaha begadang, internet dan ngemil serta ngopi sambil bekerja itu ngepas 3jt, atau mepet 3juta, alhasil tekor dan gak ada untungnya.

Namun, beberapa programmer/desainer software junior, masih bingung, harga jasa saya berapa?

Mari kita perhatikan 5 hal yang mempengaruhi harga jasa kamu di dunia software engineering sebagai berikut :

  1. Scope pekerjaan.
    Scope adalah segala hal yang ada di dalam produk software/produk dari project TI dan segala proses di dalamnya.
    Mendefinisikan apa yang diminta, apa yang mesti dikerjakan, dibagi step-stepnya (rencana->rancangan) sampe menjadi rangkaian berurut apa saja yang dikerjakan. Dengan demikian, dapat diestimasi jadwal dan waktu pengerjaannya.
    Contoh, ketika saya dari tidur pengen berangkat ke sekolah :

    1. Saya bangun tidur (15 menit), kemudian
    2. saya mandi (15 menit), kemudian
    3. saya sarapan (30 menit), kemudian
    4. saya berangkat ke sekolah (20 menit).
  2. Proses pengerjaan,
    Sulit kah? mudah kah? simple kah? kompleks kah?
    Terus bagaimana proses yang mesti saya ikuti? banyak kah? tentu mesti memperhatikan, jika ternyata proses untuk mengerjakan codingannya ataupun desainnya, bisa memakan waktu berjam-jam.
    Mulai dari :

    1. memahami klien kemudian menganalisis kehendak si klien;
    2. brainstorming, berguna untuk mendefinisikan semua kebutuhan biar bisa dikerjakan menjadi karya kita;
    3. inisialisasi, mulai dari kamu corat-coret desain/coba-coba code init/awal sampe jadi prototyping;
    4. prototyping, membuat karyamu sampe dengan prototype;
    5. development/design, mulai deh ngembangin sampe memroses semua kebutuhan menjadi produk
    6. revisi, mesti ketemu bagian ini, kadang ada saja bagian yang tidak sesuai kehendak klien, nah ini mesti diperhitungkan;
    7. final version, ketika sudah direvisi, dipoles, dibungkus, terus diserahin deh ke klien.

    panjang kan prosesnya? 😀 Makanya perlu diperhatiin betul, jangan sampe harga yang kamu pasang gak sesuai.
    Nah, ada beberapa hal itu bisa dikerjakan bebarengan, serentak (jika kamu ngerjainnya berdua atau lebih sama teman), tentu ada beberapa proses bisa dihemat waktunya. Coba lihat ilustrasi berikut :

    Critical Chain Project Schedule
    Critical Chain Project Schedule

    Kalo dilihat dari gambar di atas, tentu kita bisa memperkirakan, task apa saja yang bisa dikerjakan dalam 1 waktu bersamaan, dan mana yang tidak bisa. Jika tidak bisa, terus taruh di mana prosesnya..apa dikerjakan duluan, apa dikerjakan belakangan? tentu kalau ingin mengerjakan sesuatu, kerjakan dari yang paling mendasar.

  3. Standar harga per jam kerja (hourly rate)
    Kalo bagian ini, gak bisa sembarangan ditentuin. Kamu mesti sadari gaji/rate bayaran kamu berapa yang pernah kamu terima? terus itu dikerjakan berapa lama?
    Misal :
    Kamu pernah kerja 2 minggu (10 hari kerja, minus sabtu-minggu) dibayar Rp 3.000.000
    Sehari kerja dari jam 09:00 – 12:00, dilanjut ishoma, terus jam 13:00 – 16:00, berarti kalo ditotal : 6 jam kerja.
    Dan jika kita konversi menjadi perjam, rumusnya: Harga / total jam kerja / total hari
    Rp. 3.000.000 / 6 / 10 = Rp 50.000
    Berarti kamu dibayar Rp50.000,- per jam. Rate ini selalu naik seiring pengalaman, tentunya bila dinamika perubahannya naik, dalam artian, kamu sudah mengalami pengalaman yang banyak, yang dulunya sulit, jadi gampang, skill bertambah, dan beberapa project kamu jadi terbiasa garap (pengalaman). Semakin tinggi pengalaman, rate tentu semakin tinggi juga.
    Apalagi dibarengi skill yang makin tinggi pula (semakin banyak pengalaman, mestinya semakin beragam pula soft skill yang dikuasai). Bila kamu sudah 10 kali project dalam 2 tahun dengan hourly rate Rp 50.000,-… pas tahun ke-3, ya naikin lagi hourly rate jadi Rp 75.000,- atau Rp 100.000,-.Apalagi dalam 2 tahun itu kamu sudah belajar banyak, ditambah sekolah lagi, bisa berkali-kali lipat.Dan lagi-lagi, perhatiin juga standar gaji di dunia saat ini. (coba googling : salary guide [tahun], contoh : salary guide 2014, saya gak akan jelasin ini, cari di google dan baca sendiri sesuai posisi kamu di pekerjaan, bila orang kerja dibayar per bulan (20 hari kerja) sekian rupiah, tentu bisa dihitung per jamnya). Tentunya jika kamu di tahun kedua pernah mendapatkan proyek membuat sistem informasi perkantoran dengan harga Rp 60.000.000,-, kemudian di tahun ke empat jangan pasang 60jt lagi, tapi dinaikin. Berapa besar kenaikannya? kalau masih kesulitan menentukan, kembali ke pembahasan kita di atas yang baru kita bahas dan perhatikan di salary guide untuk profesi kita di tahun ke-4 besar gaji/rate-nya berapa.

    Berikut ini contoh hourly rate di beberapa negara

    Screen Shot 2017-03-31 at 2.21.26 PM

    Mahal ya? iya, di sana dihargai lebih. Kalo rate di atas diterapkan di indonesia, tentu gak pas 😀 makanya tadi saya sampaikan cek salary guide untuk Indonesia. Contohnya di sini: Salary Guide 2016. Cek profesimu sebagai developer apa. terus cek berapa tahun pengalaman kerjanya. Jika sudah dapat, ya tinggal konversi ke per jam.

  4. Investasi
    Seluruh hal yang berhubungan dengan proses yang dikerjakan di atas, dan biaya yang keluar karena hal tersebut. Seperti yang saya jelaskan di atas.

    1. Saya bangun tidur (15 menit) -> gratis
    2. saya mandi (15 menit) -> sabun : Rp 2000, sampoo Rp 1000, pasta gigi+sikat giginya : Rp 8000
    3. saya sarapan (30 menit) -> sarapan ketoprak : Rp 6000, jalan kaki ke TKP
    4. saya berangkat ke sekolah (20 menit) -> berangkat naik motor, bensin Rp 6500

    Terus, kalo ditotalin : makan waktu 1 jam 20 menit (1,33 jam), dan biaya : Rp 82.000 (2000+1000+….+6500)

    Rumusnya : hourly rate x total proses kerja
    Jadi, ketika hourly rate kamu Rp 50000, berarti :

    Rp 50000 x 1,33 jam + Rp 82.000 = Rp 148666,66 (mari kita bulatkan ke atas :p Rp 149000)

    Ya nilai dari project ini : Rp 149.000,-

    Contoh di atas mungkin sedikit membingungkan, pada intinya saja ya. Jadi kalau kamu dapat proyek dalam waktu 1 bulan, ya dikonversi saja dalam satuan hari. 1 bulan = 20 hari kerja, 1 hari = 8 jam kerja. 20*8=160 jam.

    Misal hourly rate kamu adalah Rp 250.000,- dengan pengalaman sudah 3 tahun. Ya untuk proyek dengan waktu 1 bulan…tinggal dikalikan saja: Rp 250.000*160 jam= Rp 40.000.000

    Nilai 40 juta ini bukanlah nilai mutlak, jadi ada nilai resiko juga di dalam proyek, nah ini kita bahas di poin nomor 5 di bawah.

  5. Resiko
    Segala hal tentu ada resiko, nah jangan sampe resiko ini terjadi dan menimpa kamu. Resiko mungkin bisa dihindari, tapi jika terjadi, pikirkan dampaknya dan apa antisipasinya.
    Resiko besar yang biasanya terjadi itu : project diberhentikan di tengah jalan (bahaya dong, ntar ketabrak), requirements berubah (nah ini dia yang biasanya bikin jengkel, udah bikin capek-capek, gak dipake, mesti diganti)
    Resiko kecil : perubahan minor aplikasi/software, jadi menyita waktu juga walaupun perubahannya dikit-dikit.
    Resiko juga mesti diklasifikasikan berdasarkan :

    1. kesempatan terjadi
    2. potensi yang diakibatkan (parah apa nggak?)
    3. kesulitan mendeteksi resiko supaya bisa dihindari

    Contoh : bugs di aplikasi
    Kesempatan terjadi : menengah lah, gak sedikit juga, gak banyak juga kesempatannya.
    Potensi yang diakibatkan : tinggi, kadang 1 bugs, bisa bikin aplikasi gagal jalan sebagaimana mestinya
    Kesulitan mendeteksi : tinggi, kadang bugs itu sulit banget dicari >.<

    contoh lain : server kebanjiran
    Kesempatan terjadi : kecil, ini sih kesempatan langka banget sampe-sampe server kebanjiran, kecuali kamu taruh servernya di pinggir kali ciliwung.
    Potensi yang diakibatkan : tinggi, server tenggelam, nangislah kliennya. Kamu juga mesti ikutan nangis!
    Kesulitan mendeteksi : kecil, lah wong hujan deres, knapa gak disingkirin tuh server ke tempat yang tinggi.

    Nah, resiko-resiko seperti ini yang mesti diperhitungkan. Terutama ya bayaran kamu. Misal kalo kejadian macem-macem, bayaran kamu telat, bagaimana?. Atau kamunya yang telat ngumpul kerjaan bagaimana?

    Dari sisi developer, pas di kontrak kerja, jangan lupa cantumkan aturan-aturan untuk klien (biasanya klien bikin aturan-aturan juga di poin proposal proyek (misal: apabila kamu telat mengumpulkan progress, atau progress tidak sesuai apa yang diharapkan klien, biasanya klien punya hak mengurangi harga proyek), nah, di sini kamu juga perlu membuat aturan-aturan atau klausa yang memperjelas batasan kamu selaku developer, misal: masalah konfigurasi server ataupun backend bukan tanggungjawab kamu yang seorang developer mobile app, masalah akun PlayStore tanggungjawab klien dan harus menggunakan data dari klien, atau apabila ada permintaan tambahan di luar scope pekerjaan yang telah disepakati, maka klien harus di-charge bayaran baru. Itu harus ada klause kerjasama tambahan yang menyatakan poin-poin apa saja tambahannya dan berapa besar biayanya. Nah yang model ini, developer sering luput, lalai, klien menghendaki revisi ini itu, tambahan ini-itu, tapi nilai proyeksi investasinya tetap. Jatuhnya kita yang rugi. 🙂
    Berikut ini ada gambar ilustrasi bagaimana harga sebuah proyek apabila dideliver ke klien lebih awal, tepat waktu atau terlambat. Dan berapa harga yang diharapkan. Dari sini bisa kamu kenali kalau untuk deliver sebuah progress pekerjaan ada resiko pinalty dari klien. Dan itu seharusnya kamu sudah antisipasi.

    Decision Trees
    Decision Trees

Sekian dulu yang dapat saya sampaikan, kurang lebih mohon maaf dan mohon dikoreksi 🙂

Terima kasih.

Pengembangan perangkat lunak dari sisi realita disiplin ilmu TI

X : “mas, aku pgn buat kyk gini, tp kalo aku pake software A, katanya mesti convert ke XML atau pake software B”
saya : “ya, kalo sy memang lebih ringan pake XML, pak, ntar ditaruh di project app.nya”
X : “kalo sy pake software A ini, mas, gimana? saya tuh pengennya kayak aplikasi yg di d*** atau di *****, tau kan mas?”
saya : “yup, pernah pake, pak, install juga kok, malah sy nemu yg lebih bagus lg, smooth di iOS dan Android, tp ya itu tetap saja enakan pake XML atau pake file tambahan dr Adobe AIR (SWF), pak”

Well, sebagai developer, jangan terpaku pada satu tools/software/teknologi saja, ingat, teknologi bisa kadaluarsa, bakal ada terus teknologi2 baru, dan sepantasnya memang kita masih harus terus belajar, biar bisa bersaing.

Ada pernah kejadian : “mas, knapa web servicenya pake rest, pdhal ada SOAP di sini” | “krn rest sdh terbukti lebih ringan, pak” | “lah, kata siapa? teman saya pake SOAP dgn php lancar-lancar aja”
beda case, pak, kalo itu kan infrastukturnya kyk gitu, sedangkan punya kita sekarang terlalu boros kalo pake SOAP. Banyak javascript di sini, kalo pake SOAP, ntar definisiin lg strukturnya di XML dll.. sementara timeline yang ada 3 bulan, pak.”

Nah, satu pelajaran lg, gk bisa kita generalisir satu masalah itu sama dgn masalah lain. Kasus lain, kamu bisa kerjain satu aplikasi dlm 1 malam, liat dulu skala aplikasinya.. krn sejatinya, permasalahan di dalam TI itu beda-beda, tidak bisa semua app itu bisa dalam 1 malam. Maka dari itu, banyaklah bergaul dgn sesama profesional TI, rajin berdiskusi (tidak sekedar bertanya, kadang orang lain jengkel kalo ditanya-tanya terus), dan kembangkan (sambil latihan terus).

Seseorang ingin dibuatkan aplikasi dgn metode re-use, kalau developer sebelumnya rapih dalam mengerjakan dan terstandar, enak, developer lain yg melanjutkan tidak akan keteteran, apalagi kalo dokumentasinya jelas dan lengkap. Tapi kalo yg sebelumnya develop gk selesai, ditinggal programmernya, terus developer yg baru disuruh gantiin dan lanjutin, apalagi tidak ada dokumentasi, dan mesti baca-baca codingan developer sebelumnya yg berantakan, apa gk stress tuh developernya? 

Kalo yang pernah saya hadapi di bank-bank (dulu kebetulan jd developer asp.net di Plasmedia kliennya bank kabeh | loh knapa skrg jd dev. Android? gk laku y? | klo sy skrg msh jd dev. asp.net, mungkin sy msh jomblo, mas soalnya hidupnya kost-kantor-mall-kost-kantor-mall, pas ramadhan aja, terawih gk pernah sempat, buka puasa sering di jalan/di kantor, makanya pas ada kesempatan S2, sy beraniin diri resign dan nyambi2 di jogja, eh alhamdulillah, salah satu klien sy, dr Pusat Kajian Hadis Jakarta menarik sy, skrg bs kenal ust. Lutfi, ust. YM, ust. Arifin Ilham, dll, sambil belajar agama dr beliau2 tsb), mereka (tiap bank) sudah punya core sistemnya, mereka tidak akan mengganti core sistem dan itu tetap berjalan (bahkan ada upgrade core sistem berkala), ketika ada penambahan aplikasi/software, ya biasanya tinggal re-use dengan beberapa penambahan modul dan desain sesuai pakem (guide book) yang sudah diberikan mereka. Dan itu bisa cepat selesai, bahkan untuk aplikasi besar, bisa 1-2 bulan kelar (bukan satu malam/2 minggu, krn birokrasi, kesiapan database, server, sampai konfigurasinya, dsb juga butuh waktu). Tapi gak tau juga ya kalo di tempat lain, pernah sm temen-temen grup PPP di DepKeu, denger-denger sampe ada debat internal antar pejabat dirjen. Itupun ngurusin database sampe cronnya juga njelimet di birokrasi. Syukur PMnya mental baja bisa ngadepin mereka. Dan 3 orang developernya : mas Mulia, Radita dan Nur Hidayat juga handal dalam development app.

“halah banyak ngomong, yg penting ngerjain!” |  “nah iya, yg penting kerjain, anda sudah pernah ngerjain yg kyk gitu belum? mengerjakan sesuatu itu harus rapih, tdk bisa asal jadi, tepat sasaran untuk stakeholdernya, tepat guna dalam fungsi, teknologi dan biaya. Karena sejatinya, software itu mesti memiliki prinsip : useful, usable dan beautiful. Dengan proses bisnis yang tertata dan metodologi yang tepat sehingga siklus pengembangannya berjalan sesuai rencana”

Satu lagi..software personal jelas beda dgn software pemerintahan. software setipe front-end jelas beda dengan setipe backend.
Satu teknologi di satu tempat itu cepat, belum tentu di tempat lain jg cepat. Ada beberapa karakteristik dan parameter yg mendukung/menghalangi hal tsb. untuk bisa dikatakan itu cepat/lambat.

Ada kalanya kita sbg. developer sudah berbuat sesuatu utk klien, tp kurang puas dgn hasil kerja keras sendiri krn terkendala waktu yang diberikan sedikit, ada kalanya kita nemu kelompok developer yang diberikan waktu banyak, tp ngerjainnya asal-asalan, yang penting duitnya turun..alhasil tidak dipakai dan merepotkan user. Dan banyak kejadian-kejadian dengan plot twist yang dihadapi developer. “Kalo ketemu klien yg awam TI, minta cepet, ya garap aja, kalo ntar klien ngerasa tidak puas atau kurang pas, tinggal buka penawaran baru” 

Yang jelas, teruslah berusaha sebaik mungkin, jangan pesimis, kalo ada orang berusaha menjatuhkan, coba gerak terus saja. Dan satu hal, tidak ada salahnya mendengar dan belajar dari yang sudah berpengalaman/ahli biar makin meningkat ilmu yang kita pelajari, dan tentunya jadi bermanfaat lebih luas hasil yang kita kerjakan.