RSS

Tag Archives: cara

“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.

 
Leave a comment

Posted by on January 15, 2017 in Android, Celoteh, Programming

 

Tags: , , , , , , , , , , , ,

Memasang harga untuk sebuah aplikasi

Kekeliruan yg pernah saya alami dan jg bbrp tmn2 developer yg terjun ke dunia proyek aplikasi mobile (kebetulan sy blm pernah ngalamin yg model bisnis berjualan, tetapi model request by user/client dan donasi) adalah terlalu cepat menyimpulkan, terkadang tanpa disadari, memberikan layanan ke klien/user dengan kurang cermat.

Menerapkan performa dan kualitas yang sempurna itu hampir mustahil dilakukan, semestinya itu disadari bersama, baik developer maupun user, karena segala yang sudah besar seperti facebook app, dll. Itu dilakukan melalui riset yang panjang dan bekerja bertahap mengikuti kebiasaan pengguna (dan lagi-lagi ini menyangkut User Experience ataupun kebiasaan pengguna)

Ide yang solid dibarengi dengan potensi pasar yang siap dieksekusi adalah kuncinya. Namun, dapet ide yang orisinil juga bukan sesuatu yang mudah (dan ide itu mahal, jadi kalo ada orang yg share status : “kalo temen2 minta dibuatkan aplikasi di OS blabla..apa yg pgn temen2 inginkan?” berarti orang tsb lg kekurangan ide hehehe), mungkin wajar bagi kita selaku developer untuk meniru. Tapi yang perlu digarisbawahi adalah, hindari godaan untuk sukses dengan instant. Lebih baik sedikit demi sedikit berjalan, tidak apa pas launching app masih sederhana, tetapi lambat laun terus diriset, dikembangkan, mendengar tanggapan dari user, ditampung dan ditelusuri lebih lanjut sehingga tercipta gagasan baru untuk membuat aplikasi tersebut bertahap menjadi besar.

Membangun aplikasi bukan serta merta untuk mencari duit, perlu di-explore juga jenis aplikasi apa yang bisa/boleh dijadikan uang. Ada beberapa kategori yang semestinya tidak boleh dijadikan lahan uang.

Aplikasi kategori sosial : jejaring, messaging, religi dan app yg hits yang mencakup semua kalangan pengguna, konten beragam, tapi biasanya harga rendah bahkan gratis (loh kok bisa? gk rugi tuh?). Mereka berani memasang harga rendah karena cakupan pasarnya luas, campaignnya mudah (ntah dengan viral, memasarkan via iklan di jejaring, dsb), dan semua orang bisa pakai. Contoh : chat macem WA yang menarik pembayaran tiap tahunnya dengan harga murah (dan tentu target download sudah lebih dari 1000 pengguna)

Sedangkan yang harga tinggi biasanya menargetkan konsumen yang serius/tertentu. Sebagai contoh app. multimedia/office, biasanya harganya mahal, bahkan sampai mencapai $100, seperti : photoshop, fruity loops, officetogo, dll.

Dan ada yang model premium, konten besar, profit yang didapat besar juga dari per penggunanya. Biasanya model ini lebih sedikit dibandingkan 2 jenis sebelumnya. Dan terkadang menerapkan sistem berlangganan per tahun. Sebagai contoh : game karaoke yang tiap lagunya harus berlangganan, microsoft office, aplikasi kolaborasi, dll.

Dan beberapa kegagalan yang sering terjadi adalah developer tidak memahami target penggunanya, memasang harga yang tidak pas.

 
Leave a comment

Posted by on May 7, 2015 in Celoteh, Internet

 

Tags: , , , , , , ,

Panduan untuk developer dalam menyusun Kontrak Kerjasama dengan klien

Tulisan saya kali ini mencoba menjabarkan apa saja komponen yang harus ada di dalam menyusun berkas Kontrak Kerja antara developer (vendor software) dengan klien.

Mengapa saya tidak menyertakan contoh kontrak kerja?
Karena tidak ada yang instant di dunia ini, semuanya berproses, begitu juga apabila teman-teman developer menggarap kontrak kerja, tentu tiap kerjasama ada pelajaran yang berarti yang dapat membuat teman-teman developer sadar bahwa ada komponen yang tertinggal di kontrak kerja dan jadi pelajaran bahwa teman-teman harus menyertakan komponen tersebut di kontrak kerja berikutnya.

Ditambah, kontrak kerja itu bersifat rahasia, tidak bisa bebas dibeberkan ke publik. Dan setiap teman-teman punya ciri khas dalam menulis kontrak kerja yang menjadi nilai tambah mengapa klien memilih anda dalam kerjasama pengembangan software.

Ok, kita mulai bahas satu per satu apa saja komponen yang harus ada di dalam kontrak kerja kerjasama dengan klien.

Komponen-komponen yang sebaiknya ada di kontrak kerja :

  1. Yang bertanda tangan, tuliskan diawali dengan tanggal, kemudian disertai nama lengkap, alamat lengkap, no.telepon pihak pertama dan pihak kedua. Di dokumen pertama ini saya tuliskan bahwa pihak pertama adalah klien dan pihak kedua adalah developer.
  2. Pasal-pasal :
    • Bentuk Kerjasama
      Kerjasamanya dijelaskan seperti apa dari pihak pertama ke pihak kedua, dan dari pihak kedua ke pihak pertama.
      Karena di sini tidak satu arah.
      Tidak hanya developer yang punya tugas/peranan, tapi juga Klien punya peranan.
      Nah dijelaskan saja satu per satu. Masing-masing tugasnya (bukan menjelaskan apa saja yang dibuat tapi lebih general, karena kalau membicarakan apa yang dikerjakan itu masuk ke proposal dan laporan pekerjaan bukan kontrak kerja)
      Contoh :
      Pihak Pertama memberikan pekerjaan kepada pihak kedua yaitu ….

      Pekerjaan yang dilaksanakan adalah : a. …. b. …. c….

      Pekerjaan tersebut dilaksanakan pihak kedua.

      Sedangkan untuk pihak pertama sebagai penanggungjawab proyek mempunyai peranan sebagai : a… b… c….

    • Jangka Waktu Pelaksanaan
      Tulis jangka waktu pelaksanaannya, dituliskan dengan jelas, tanggal mulai dan tanggal berakhirnya proyek, terus jangka waktu dijelaskan masing-masing tahap.
      contoh :
      kontrak kerja tanggal …
      pengumpulan data yang dibutuhkan tanggal …
      setup server tanggal …
      development tanggal….
      testing dan review tanggal …
      bugs fixing tanggal…
      maintenance tanggal..
      penutupan proyek tanggal…
    • Hak dan Kewajiban
      Setiap pihak, baik itu pihak pertama maupun pihak kedua, memiliki hak dan kewajiban, maka dari itu tulislah semua hak dan kewajiban tersebut sampai bagian terkecil, jangan sampai ada yang terlewat, mengapa? karena pekerjaan yang kita lakukan bukan hal cuma-cuma, ya jasa developer dipakai tentu dibayar, jangan sampai developer mengerjakan sesuatu yang bukan kewajibannya. Semakin spesifik detail hak dan kewajiban di kontrak kerja, maka makin bagus. Tentunya menguntungkan kedua belah pihak menghindarkan pihak pertama menuntuk pekerjaan kepada pihak kedua yang bukan kewajiban pihak kedua (sayangnya sering terjadi yang seperti ini, karena pihak kedua/developer kurang spesifik menuliskan kewajiban-kewajibannya) Dan setiap hak masing-masing pihak dipenuhi oleh pihak lain sesuai waktu dan kapasitas yang telah dirumuskan bersama.
    • Nilai Kontrak dan Sistem Pembayaran
      Nilai kontrak dituliskan dengan jelas beserta mekanisme pembayarannya seperti apa.
      misal, pihak kedua dibayar 4x cicilan, yaitu di waktu : awal kontrak (DP), pada saat alpha testing (atau pada waktu masa development berakhir sebelum masuk masa review/bugs fixing), pada saat mulai tahap bugs fixing / beta testing, dan terakhir ketika proyek dinyatakan selesai/penutupan proyek. Biasanya dibuat dalam persentase..atau bisa juga ditentukan porsinya masing-masing tahap tersebut. Dan masing-masing waktu pembayaran yang diamanahkan ke pihak pertama ada masa jatuh tempo dituliskan supaya jelas dan menghindarkan dari hal klien terlambat melakukan  pembayaran (sering kejadian). Misalnya : jatuh tempo 1 minggu dari tanggal invoice diberikan ke pihak pertama (klien).
    • Denda Keterlambatan (development, testing, reviewing, payment)
      Denda harus ditentukan dengan hati-hati. Developer/pihak kedua biasanya dikenakan denda apabila terlambat di dalam menyelesaikan pekerjaannya, ntah itu denda per hari atau per minggu, nominalnya mesti dibicarakan bersama antara kedua belah pihak. Jangan sampai ada yang dirugikan. Denda telat testing atau telat review dan telat pembayaran jg mesti dibahas bersama.
    • Perselisihan
      Perselisihan terkadang dapat saja terjadi, baik itu perselisihan kecil ataupun yang sudah membesar karena permasalahan yang kompleks. Nah di sini diatur pasal mengenai perselisihan tersebut, tulislah keterangan akan diselesaikan di mana perselisihan tersebut, dan dengan cara seperti apa? misalnya : apabila masalahnya dapat diselesaikan secara musyawarah mufakat, maka ini menjadi prioritas, namun apabila memang tidak ada titik temu, ya melalui jalur hukum di pengadilan, maka dari itu tuliskan nama pengadilan dan alamatnya.
    • Aturan lain-lain
      Aturan tambahan disertakan di bab pasal ini, apapun itu pasalnya, contohnya : klien berkeinginan mengubah fitur di tengah jalan development, aturannya mainnya seperti apa jika klien ingin mengubah fitur yang sudah disepakati? maka dari itu tulislah tata cara/aturan mainnya. Jika nanti memang harus ada bentuk kerjasama tambahan, mekanismenya seperti apa dicantumkan di pasal ini. Pasal penting di bab kali ini juga harus menyertakan ketentuan perubahan dari bentuk kerjasama, misalkan klien ingin mengajukan perubahan fitur, maka harus diajukan ke developer paling tidak 2 minggu sebelum fitur itu dikerjakan (disesuaikan dengan jadwal), jika sudah dikerjakan dan minta diubah, maka harus ada aturan yang mengatur tentang ini, apakah klien dikenakan denda atau biaya tambahan, atau perubahan tersebut dikerjakan di akhir proyek dengan kontrak kerja baru. Dan jangan lupa cantumkan batas waktunya berapa lama untuk merumuskan dan pengajuan (menghindari masalah jangan sampai dadakan yg dapat merugikan developer).
    • Ketentuan Penutupan Kontrak
      Mulai berlakunya kontrak kerja, ketentuan kontrak kerja, dan tanda kalau kontrak kerja berakhir itu seperti apa nantinya, dicantumkan di bab ini. Dengan penutupan bab ini, menandakan tidak ada aturan baru yang terjadi. Jikalau memang ada aturan baru, maka akan berlaku adendum. Adendum adalah dokumen yang berisi perubahan kontrak kerja tanpa ada penambahan ataupun pengurangan klausa kontrak yang telah disepakati.
  3. Tanda tangan pihak pertama dan pihak kedua di atas materai. Masing-masing pihak memegang surat kontrak kerja dan 1 materai yang ditandatangani kedua belah pihak.

Beberapa catatan :

  • Berkas Kontrak kerja dipegang masing-masing pihak dan kedua berkas tersebut telah ditandatangani dan dibubuhi materai.
    Kontrak kerja yang dipegang developer itu, pihak pertamanya adalah developer, sedangkan pihak keduanya klien (aktif).
    Sedangkan untuk kontrak kerja yang dipegang klien, pihak pertamanya klien, pihak keduanya developer (pasif).
  • Isinya kontrak kerja yang dipegang masing-masing pihak dapat dibuat sama, tapi perlakuannya beda. Atau Kontrak Kerja masing-masing pihak itu dibuat sama persis, dengan ketentuan pihak pertama klien, pihak kedua developer.
  • Ada alasan mengapa terkadang kontrak kerja pihak pertama dan pihak kedua dibuat berbeda, biasanya dengan kondisi pasal-pasal untuk developer dan untuk klien banyak perbedaan dan lebih spesifik.
  • Kemudian, apabila ada tulisan angka, baik itu tanggal, nominal pembayaran, denda, jumlah hari, dll, dituliskan dengan angka dan dieja (ditulis dengan huruf).

Semoga bermanfaat. Jika ada tambahan..silahkan ^_^

 
Leave a comment

Posted by on April 9, 2015 in Celoteh, Internet, Workit

 

Tags: , , , , , , , , , , , , , ,

Menentukan harga jasa untuk programmer dan desainer

Setelah pernah dibahas mengenai menentukan harga project TI khususnya mobile apps. Kini saya mau berbagi info mengenai bagaimana menentukan harga jasa untuk programmer dan desainer mobile apps (mungkin bisa dipakai untuk develop 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/honor kamu berapa yang pernah kamu terima? terus itu dikerjakan berapa lama?
    Misal :
    Kamu pernah kerja 2 minggu (10 hari kerja, minus sabtu-minggu) dibayar 3juta
    Sehari kerja dari jam 09:00 – 12:00, dilanjut ishoma, terus jam 13:00 – 16:00, berarti kalo ditotal : 6 jam kerja.
    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.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)
  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, dan biaya : Rp 82.000 (2000+1000+….+6500)

    Rumusnya : hourly rate x total proses kerja + investasi

    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 investasi dari project ini (project? emang ke sekolah bisa jadi project? ngawur, ini kan cuma contoh!) : Rp 149.000,-

  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, buat rules juga (biasanya klien bikin rules, kalo kamu telat ngumpul, atau tidak sesuai apa yang diharapkan klien, harga dikurangi), kamu buat rules, misal masalah server bukan tanggungjawab kamu, atau apabila klien telat bayar, mesti denda juga :p ya pinter-pinter kamu menyiasati perkara ini.

    Decision Trees

    Decision Trees

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

Terima kasih.

 
Leave a comment

Posted by on August 16, 2014 in Celoteh, Hobby, Internet, Programming, Workit

 

Tags: , , , , , , , , , , , , , , , , , ,

Seni membaca error log di logcat (DDMS) Android

Ketika saya coba bekerjasama dengan 1 developer Android yang sudah punya produk di PlayStore kemudian komunikasi kami menjadi sedikit missmatch karena ternyata saya baru ngeh kalau developer yang mengajak kerjasama meningkatkan fitur produknya, belum paham membaca error log dan log cat. Dan sering saya dapati komunikasi kami via e-mail dan google docs menjadi tidak harmonis (halah) ketika mengisi waktu kerja proyekan apps android di luar kerjaan kantor, di PKH, Jakarta.

Dan begitu juga pas ngisi workshop, peserta masih bingung membaca error log yang tampil di DDMS yang ter-attached di Eclipse IDE.
Alhasil tempo hari menyisihkan waktu satu jam-an tentang seni membaca error ataupun force close aplikasi dan menemukan bugs dengan cara debugging, error handling ataupun dengan membaca error log.

Mengenai seni trace dan membaca log, perhatikanlah artikel singkat di stackoverflow ini

Mengenai seni dalam mengetahui force close secara langsung dari aplikasi, dapat mencoba cara ini.

Mengenai seni error handling dalam java, bisa baca artikel ini dan khusus Android ada di sini.

Kalau mengecek error di tool DDMS bawaan android SDK/Tools, perlu diketahui, ketika aplikasi berjalan, log yang nampil itu bukan hanya error, jangan dikira kalau ada pesan di log berarti error.
teks warna hijau : seputar tips dan informasi,
teks warna biru : bagian yang diselect, biasanya diisi to-do-list oleh developer,
teks warna orange : ini sebagai peringatan, bisa jadi potensi masalah (namun saat ini belum jadi masalah)
Dan..
teks merah : ini error, dan harus dianalisa masalahnya biar tidak menimbulkan gangguan di aplikasi.

Dan ketika nampak teks warna merah di logcat, sebagai contoh :
02-12 17:50:21.541: E/com.wd.radiodakwahislam.controller.StreamingMediaPlayer(10294): Error updating to newly loaded content.
02-12 17:50:21.541: E/com.wd.radiodakwahislam.controller.StreamingMediaPlayer(10294): java.lang.NullPointerException
02-12 17:50:21.541: E/com.wd.radiodakwahislam.controller.StreamingMediaPlayer(10294): at com.wd.radiodakwahislam.controller.StreamingMediaPlayer.transferBufferToMediaPlayer(StreamingMediaPlayer.java:285)

Di atas, terlihat bahwa ada tulisan : “…(StreamingMediaPlayer.java:285)
artinya, error tersebut terjadi di baris 285 pada class StreamingMediaPlayer.java. So, fokuslah ke class tersebut, dan lihat pada baris 285 terdapat kekeliruan atau tidak (lihat dari editor Eclipse-nya).

Nah, kalau bingung, di awal teks merah tersebut di logcat, copy teks-nya (dengan pilih teks error-nya di logcat, terus tekan ctrl+c), dan buang tanggal dan nama class-nya sehingga yang ter-copy hanya teks error saja : error updating to newly loaded content.
Copy dan paste ke google search di internet browser di PC (bila perlu ditambahkan keyword : Android di akhirnya), terus enter dan lihat di result google, biasanya result 3 besar berisi link stackoverflow, klik salah satunya dan cari apa penyebabnya dari jawaban-jawaban yang ada di stackoverflow.

Pas awal kerja di PKH secara remote, saya langsung ngomong ke team via basecamp, agar coba menerapkan sebuah rules dalam melaporkan bugs dan error dari aplikasi yang dikembangkan kepada teman-teman team yang developer web dan UI designer.

Rules itu berisi :

  • Ketika melaporkan bugs, harap sertakan device apa yang dipakai dan versi OS android-nya.
  • Bila terdapat bugs/masalah UI tolong sertakan screenshotnya, bila masalah fungsional tolong sertakan logcatnya (dengan mengunduh tools berikut) /** saya sertakan link download zipnya yang berisi tool DDMS dan Android SDK beserta doc singkat cara pakainya **/
  • Sebaikny pakai filtering ketika menjalankan logcat di DDMS, jangan semua proses dicantumkan di logcat, demi memudahkan menelusuri masalahnya
  • DDMS bisa filter logcat aplikasi saja, jadi tidak semua log dari proses di device tercatat, caranya dengan masukan nama project di bagian kolom filter. Nama project sesuai yang saya cantumkan ketika saya upload progress (nama project dapat dilihat di file manifest.xml)
  • Kenapa penting bagi developer untuk tahu itu? Supaya gampang mengetahui errornya
    Jangan dikira ketika aplikasi jalan di device developer maka digeneralisir kalau aplikasi tersebut jalan di device SEMUA users. Bahkan yang terjadi di kantor tempat saya kerja, error itu justru sangat kemungkinan besar terjadi mengingat para teman-teman memakai device Android berbagai merek dan ukuran layar dan versi OS.
    Makanya ada conditional yang diterapkan dicode : IF(SDK version < 10) pake codingan A, IF(SDK version > 14) pake codingan B, dll.
  • Oleh karena itu, penting adanya public testing sebelum melepas ke GooglePlay.
    Dan media yang bagus untuk melakukan public testing gratis ya jejaring sosial facebook dll.
  • Beda ukuran layar beda lagi UInya, makanya ketika saya bekerjasama dengan designer UI ada beberapa rules yang harus dipatuhi bersama agar bisa diterapkan di layout dan mencakup ukuran layar low, mid, high, (ponsel dr ukuran kecil sampe besar) extra (tablet 7″ atau HD) dan double extra (tablet 10″ atau yg full HD). Untuk guidelines buat para designer UI Android, bisa patuhi prinsip-prinsip designnya di sini dan lengkapnya ada di sini untuk setiap bagian design-nya.

Sekian dan terima kasih 😀

 
4 Comments

Posted by on February 13, 2014 in Android

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Harga pengembangan aplikasi mobile yang dipasang, kemahalan atau kemurahan kah?

Mari kita berhitung harga aplikasi mobile. 🙂 Bila ada yg beranggapan harga 4-7jt itu kemahalan untuk membuat aplikasi bisnis berbasis mobile (android, iOS, BB) artinya temen-temen perlu membaca ini.

Ini dikerjakan secara profesional, bukan dikerjakan oleh mahasiswa tingkat akhir yang dipekerjakan (sadis, gan!) :p

Dan jangan dianggap, karena aplikasi yang dikembangkan itu cuma seukuran layar HP dan lebih kecil “keliatannya” tampilan daripada di website, bukan berarti harganya pasti lebih murah daripada mengembangkan versi web. Itu salah kaprah. Karena, bisa jadi kerumitannya lebih rumit daripada pengembangan website. Dan bisa jadi lebih mahal daripada pengembangan versi websitenya. Walau tampilannya keliatan kecil, tetapi di situ ada banyak kerumitan dalam hal UI, fungsionalitas, pemodelan, user-behavior aspect/user experience design, resources, dll. Hampir mirip saat mengembangkan website.

Dari hasil diskusi saya dengan beberapa teman project TI yang sudah 2 tahun mendalami pengembangan aplikasi mobile dan project TI di bidang mobile apps. Dan pengalaman pribadi yang mendalami project programming Android di beberapa tempat sejak memiliki HP Android di juni 2010.

Dan ini berlaku hampir di semua client dan client/perusahaan pun rata-rata mematok harga segitu.

Ok, kebanyakan aplikasi mobile itu faktanya, dikembangkan dalam jangka waktu paling tidak 6 bulan, dengan jam kerja full-time (mengikuti jam kerja) dan berkisar di harga 10 sampai 50 juta.

Eits, tetapi tidak serta merta semua begitu, mari kita buat lebih spesifik. Pertama, perlu kita perhatikan adalah tipe aplikasi yang akan dikembangkan. Kita berhadapan dengan klien, ngobrol panjang lebar dengan orangnya apa yang ia inginkan (user stories) dan mencatatnya untuk dianalisa setiap kebutuhan supaya menjadi milestone pekerjaan (per task, per man-days, per man-power, per period) dalam jangka waktu (timeline) yang sudah disepakati.

Kita bagi dalam dahulu menjadi 2 kategori :

A. Untuk digunakan konsumen (umum)

  1. Aplikasi dasar, yang memiliki fungsi-fungsi dasar android. Sekedar menampilkan teks, diinputkan, diproses ditampilkan secara sederhana. Seperti : aplikasi maps sederhana yang menampilkan petunjuk jalan lokasi penjualan produk, aplikasi alarm, jam, dsb..yang tidak menampilkan fitur-fitur selain itu.
  2. Aplikasi Native, yang menyediakan berbagai tipe konten (gambar, tulisan, suara, dll), dengan logika matematika yang kompleks dan arsitektur software yang terdiri dari beberapa level. Dan biasanya menggunakan framework tertentu atau library tertentu, dan database tertentu (mysql, sqlite, sql server, dsb)
  3. Games, dari berbagai info saja, aplikasi games Angry Birds seharga $125k-180k hanya untuk biaya coding saja. Dan games sama saja mencakup beberapa hal, seperti : rendering 2d/3d graphics, logika ilmu matematika, ilmu fisika, dll. Belum lagi nanti ada sound artist, artwork design, dll. Makin mahal.

B. Untuk digunakan perusahaan (bisnis/internal)

  1. Aplikasi enterprise kecil
  2. Aplikasi enterprise sedang
  3. Aplikasi enterpise besar

Mengenai kecil, sedang, dan besarnya ditentukan dari banyaknya scope-pekerjaan, timeline yang diberikan, dan kompleksitas masalah (apakah nanti cross-platform kah? artinya perlu menyediakan web-services, database-support library, Share Capabilities  dengan apps lain, dsb)

Ok, soal harga, berapa?

Menentukan harga itu harus ditambahkan juga dengan biaya penyediaan resources (tools/software/IDE) dan biaya produksi (publishing) jika memang semua diusahakan oleh pihak pengembang.

Begini, ketika kita akan mengembangkan apps. games dengan menggunakan Game Maker Studio seharga $299 dolar, artinya itu masuk hitungan nilai investasi kita, kecuali sudah disediakan oleh pihak client, kalau tidak? masa’ kita yang membeli sendiri? Kalau sudah punyapun, harus dihitung lagi. Karena secara profesional, semuanya disediakan oleh client, kecuali ada hitam di atas putih yang menyatakan kita ikhlas menyediakannya [yaoming.jpg] 🙂

Jika menggunakan tools yang gratisan ya jangan hehe..

Begitu juga biaya publishing ke PlayStore ataupun AppsStore, itu ya biaya pendaftaran akun untuk publishing-nya ya dihitung juga.

Dan untuk masalah harga yang berlaku, bisa dicek di sini :

  1. Aplikasi dasar seperti pada poin A.1 di atas : berkisar 2-5jt (di luar sana berkisar $1,000)
  2. Aplikasi native, seperti pada poin A.2 di atas : berkisar 6-50jt (di luar sana berkisar $8,000-$50,000)
  3. Aplikasi games, seperti pada poin A.3 di atas : berkisar 8-150jt (di luar sana berkisar $10,000-$250,000)
  1. Enterprise kecil, seperti pada poin B.1 di atas : berkisar 20jt (sekedar ekstrak data dari database, kemudian ditampilkan)
  2. Enterprise sedang, seperti pada poin B.2 di atas : berkisar 20-50jt (sudah mencakup masalah seperti : client-server apps, cache data, penggunaan library native, hardware support)
  3. Enterprise besar, seperti pada poin B.3 di atas : berkisar 80-300jt (full-scale enterprise, office automation, enterprise financial monitoring, mobile apps. banking, dsb)

Apalagi akan ada continuing cost setelah masa development, guarantee, maintenance, dll.

Harap diperhatikan juga, besar kecilnya harga yang ditawarkan itu bisa bergeser karena dipengaruhi banyak faktor. Ketersediaan SDM, Ide, Waktu, Budget, Fungsionalitas, Layout Design, dan negosiasi.  🙂

Apakah harga segitu wajar?

Jelas wajar, dilihat dari lifecycle development-nya, benefit dari pemanfaatan aplikasi mobile kepada user (yang jelas lebih mudah dipakai di manapun, kapanpun, tanpa perlu membawa laptop), promosi (iklan) produk dan monitoring (untuk keperluan survey statistik penggunaan) juga dapat dimanfaatkan dengan mudah melalui apps yang dikembangkan dan di-publish, demi memperhatikan konsumen dan mencari aspek penting buat menentukan kebijakan perusahaan. Dengan rata-rata per sekali publish, dalam seminggu bisa sampai 100-500 yang downloads, tentunya akan meningkatkan keuntungan bagi pihak client. Apalagi trend sekarang ini adalah mobile apps.

NB : tulisan ini mix teori (minim) dan hasil praktek, bukan money-oriented tanpa dasar, tetapi supaya kita juga paham memasang harga pengembangan aplikasi biar tidak dirugikan. :p Newbie belajar nulis.

 
2 Comments

Posted by on October 10, 2013 in Uncategorized

 

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,

Install Git Server di VPS berbasis Linux – CentOS

Di sini akan dicoba langkah-demi-langkah tutorial mengenai instalasi Git Server di VPS (Virtual Private Server) yang menggunakan OS CentOS.

Perlu diketahui, ketika kita menyewa sebuah lingkungan virtual, VPS, kita tentunya akan mendapatkan IP Address VPSmu, akun akses control panelnya (biasanya pakai Lxadmin), atau yang disediakan oleh hostingnya dengan menginputkan username dan password. Biasanya di dalam control panel tersebut disediakan menu : remote access dan ssh remote. Nah, inilah yang akan kita pakai dalam tutorial kali ini. Di sini saya mencoba meremote VPS yang saya sewa menggunakan putty dengan Connection Type : SSH.

Akses VPSmu, menggunakan Putty. Masukkan hostname (atau IP Address VPSmu), dengan port standard : 22.

Ketika sudah masuk ke session VPSmu, silahkan login dengan memakai superuser : root. Dan masukkan password yang telah diberikan oleh hosting tempat kamu menyewa VPS.

Ok, jika sudah, silahkan ikuti petunjuk di bawah ini :

Cek DAG Repository, Webtatic repo untuk Git Server yang akan kita install di VPS, dengan mengetik :

– Untuk Red Hat Enterprise Linux 5 / i386 :

rpm -Uhv http://apt.sw.be/redhat/el5/en/i386/rpmforge/RPMS/rpmforge-release-0.3.6-1.el5.rf.i386.rpm

– Untuk Red Hat Enterprise Linux 5 / x86_64:

rpm -Uhv http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS//rpmforge-release-0.3.6-1.el5.rf.x86_64.rpm

Ok, tunggu sampai proses selesai, setelah itu dilanjutkan dengan perintah install Git server :

yum -y install git

Tunggu sampai proses install selesai.

Ketika installasi selesai, saatnya membuat repository.

Membuat repository itu mudah! sederhana, tinggal buat folder untuk reponya, terus diinit, perintahnya sebagai berikut :

mkdir newrepo [diasumsikan nama foldernya newrepo, tapi bebas, terserah kamu namanya]
cd newrepo
git init

Setelah repo sudah dibuat, kita dapat menduplikat atau membuat file-file proyek kita (bisa pakai SVN import) dan lakukan langkah berikut :

git add .
git commit

Nah, repo sudah dibuat nih, kamu mungkin ingin membagi repo mu ke temen-temen. Ini berarti orang lain dapat pull dan push file-file mereka ke repomu dan mengubahnya. Ada banyak cara sharing untuk SVN repository.
Tapi cara yang sederhana adalah menggunakan Git Daemon. Ini akan mengizinkan orang lain push+pull, share, dengan menggunakan perintah berikut :

git daemon --reuseaddr --base-path=/path/to/repos --export-all --verbose --enable=receive-pack

Perintah di atas akan mengizinkan repo untuk dishare melalui folder repo yang kita buat di atas (ex : newrepo). Ketika sudah membuat repo tersebut dapat dishare. Dan tentunya client atau user lain, dapat melakukan clone Git repo kamu. Dengan syntax :

git clone git://remote.computer.hostname/newrepo

Atau via Github atau via Tortoise SVN. 😀

Kamu bisa menggunakan gitolite atau Gitosis untuk integrasi ke Redmine (software project management) dan tentunya tercentral, private, sehingga aman dari ancaman dari luar dan mudah ter-manage

Selamat mencoba dan sukses! 😀

 
Leave a comment

Posted by on November 24, 2011 in Computer, Programming

 

Tags: , , , , , , , , , ,