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 ๐Ÿ™‚

Pentingnya bagi seorang designer mobile app. memahami “design pattern” dan guidelines desain aplikasi

Waaah…. desainer baru…. begitu dilihat pengalamannya ternyata basic-nya adalah desainer web yang sudah bekerja selama 5 tahun lebih.

Tiba-tiba kebutuhan akan aplikasi mobile begitu tinggi, alhasil beberapa desainer web beralih profesi mengerjakan desain-desain antarmuka aplikasi mobile.

Nah, ada kesalahan fatal yang terjadi, menyebabkan potensi kesalahan di dalam pengembangan, ntah itu timeline menjadi tambah panjang, developer yang menjadi sulit mengimplementasikan desain yang diberikan, dan sebagainya.

Siapapun yang menjadi desainer aplikasi mobile, dimohon jangan samain seperti mendesain website yah..hehe
Desain aplikasi platform apapun itu, baik itu iOS, Android, Windows Phone, Blackberry, ada prinsip-prinsip desain yang harus dipahami, ada guidelines yang harus dipatuhi. Setiap OS mobile punya pattern desain sendiri yang mesti diikuti. Tidak bisa “semau gue, menurut gue itu keren”.

Seorang designer antarmuka aplikasi mobile mesti mendalami pengetahuan seputar perangkat OS platform tersebut, mindset-nya juga harus diubah. Sama seperti pada waktu seorang designer web mendapatkan job dari perusahaan ternama (pernah saya alami di BNI, Jakarta), mereka (BNI…yg saya tau) punya guidelines terhadap website mereka. Misal : Warna tema website mereka.. di guidelines-nya dijelasin hexa codenya apa, logo web-nya pakai yang mana, resolusi “width height“-nya berapa, ukuran hurufnya berapa, pake typeface apa, dan sebagainya..maka terjadilah konsistensi desain di web yang dimiliki perusahaan ternama tersebut.

Begitu juga dengann platform mobile. Antarmuka di aplikasi mobile punya konsistensi, ketika mendesain layout, peletakan menu slalu di sebelah mana, icon aplikasi bentuknya seperti apa, di hape layar kecil resolusinya berapa, di hape layar besar resolusinya berapa, kalo bikin tab taruh di mana, default typeface pake apa, dan sebagainya.

Saya rasa tantangan yg mereka (designer web) hadapi ketika menjadi designer apps adalah bagaimana caranya agar menguasai design interaksi dan UX-nya.

Untuk mengubah sebuah tampilan website menjadi tampilan aplikasi yg mungil, layar terbatas, jangkauan pengguna ketika menyentuh layar bagaimana, dan hal-hal lain yang perlu diperhatikan… bukanlah sebuah pekerjaan yang mudah. Sebagai contoh : ketika mengatur ukuran huruf yang nyaman dibaca pengguna aplikasi, mengatur komponen apa aja yang dapat dijangkau pengguna aplikasi ketika menyentuh layar, dan dari langkah tersebut, desainer masih dibuat pusing lagi ketika menguji hasil karya antar mukanya.

Si desainer sudah merasa yakin mendesain aplikasi di hape layar besar (di atas 5 inch), ternyata di hape layar kecil membuat pengguna kurang nyaman, terkadang mengalami masalah komponen layout-nya oversize di hape layar kecil, terkadang ukuran hurufnya kegedean diterapkan di hape layar kecil, dan masih banyak lagi masalah-masalah yang mungkin terjadi. Dan akhirnya si desainer aplikasiย  mencoba mengatur ulang layout-nya.

Dengan kata lain, mau tidak mau si desainer harus menyiapkan beberapa layout design untuk beberapa jenis ukuran layar smartphone maupun tablet (dari ldpi, mdpi, hdpi, xhdpi, sampai dengan xxhdpi).

Seperti yang sudah saya jelaskan, masing-masing perangkat mobile, baik itu smartphone maupun tablet punya UX berbeda. Apalagi beda platform, tentu User Experience di tiap platform berbeda. Pengguna device Android sudah terbiasa melihat menu dengan slide ke kanan atau tap pada pojok kiri dan kanan, sedangkan pengguna device iOS terbiasa dengan menu slide di bawah ke atas, dan berbeda lagi dengan pengguna WindowsPhone, menu disajikan per tab dengan label yang besar di atasnya, tidak ada menu pojok seperti di Android ataupun menu bawah seperti di iOS. Setiap platform punya guidelines-nya bagaimana meletakkan komponen design, seperti yang saya sampaikan yaitu menu, slide menu, tombol, tab, tabel, dan komponen lainnya.

Biasanya, seorang desainer itu melakukan coret2 dulu di wireframe (wireframing), diskusikan dengan tim (ntah dengan desainer web ataupun aplikasi mobile yang lain ataupun dengan developer dan system analyst) apa yang telah di-wireframing sudah pas atau belum, kemudian periksa guidelines di docs platform tersebut apakah sudah sesuai pattern OS tersebut atau belum, kemudian UX-nya bagaimana.. apakah sudah sesuai dengan kebiasaan pengguna di platform tersebut atau belum, setelah itu baru memulai perbaiki designnya agar menjadi tampilan antarmuka aplikasi yang ideal yang siap diimplementasikan ke dalam aplikasi.

Bagi teman-teman yang belum mengetahui guidelines atau panduan mendesain di masing-masing platform mobile, bisa merujuk ke link berikut ini :
Semua udah ditulis lengkap, resmi dan terstruktur, tinggal kitanya mau belajar dengan tekun atau tidak.
iOS : https://developer.apple.com/โ€ฆ/UserExpโ€ฆ/Conceptual/MobileHIG/
Android : http://developer.android.com/deโ€ฆ/get-started/principles.html
WP : https://dev.windows.com/en-us/design

Sekian ๐Ÿ™‚

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 ^_^

Tips Seputar Menulis Laporan Penelitian atau Tugas Akhir

Tugas akhir menjadi bagian yang tidak terpisahkan bagi mahasiswa yang ingin melengkapi langkahnya menuju Sarjana. Berikut ada beberapa tips sederhana seputar menulis laporan penelitian yang setidaknya bisa membantu teman-teman dalam menyelesaikan tugas akhir. Dan untuk menghindari banyak revisi dalam hal tulisan.

Pahami dahulu setiap bagian dari tugas akhir, misal pada BAB I Pendahuluan yang umumnya berisi :

  • latarbelakang masalah,
  • rumusan masalah,
  • batasan masalah,
  • keaslian penelitian,
  • tujuan penelitian,
  • manfaat penelitian,
  • sistematika penulisan.

Biasanya mahasiswa sering kali menuliskan latarbelakang yang tidak berhubungan dengan topik Tugas Akhir yang ia akan jalankan. Latarbelakang haruslah menjadi bagian pengantar yang mendasari mengapa Tugas Akhir tersebut harus dilakukan.

Kemudian pada bagian rumusan masalah semestinya harus mengungkapkan sesuatu yang penting yang menuntun pada penyelesaian masalah. Bagian ini kadang-kadang berupa suatu pertanyaan yang akan dijawab melalui penelitian. Bentuk kalimat Rumusan masalah adalah kalimat deklaratif (problem statement), bukan kalimat tanya (research question). Sedangkan pertanyaan harus ditempatkan di bagian pertanyaan Tugas Akhir.

Untuk bagian batasan masalah, harus diperhatikan dengan cermat oleh si mahasiswa, karena bagian ini membantu mahasiswa agar penelitian atau Tugas Akhir yang ia lakukan, lebih mudah dalam penarikan kesimpulan serta menjaga agar mencerminkan permasalahan yang dihadapi. (Dengan kata lain, agar permasalahan dan cakupan masalah yang dihadapi di dalam Tugas Akhir tidak melebar atau keluar jalur)

Untuk bagian tujuan dan manfaat, mahasiswa sering kali terbalik mengungkapkan tujuan dan manfaat. Tujuan tidak sama dengan manfaat. Tujuan itu mengungkapkan target apa yang hendak dicapai oleh mahasiswa dalam penelitian atau Tugas Akhirnya tersebut. Tujuan penelitian juga tidak bersifat pribadi, jadi harus dihindari tujuan dari sisi mahasiswa, tetapi tujuan mengapa penelitian itu harus dilakukan.
Sedangkan manfaat, menekankan pada manfaat apa yang didapat diperoleh dari hasil penelitian tersebut (lebih kepada perkiraan apabila tujuan penelitian tercapai), dan lagi-lagi tidak secara pribadi, namun umum, misal manfaat untuk user yang menggunakan software yang sudah dikembangkan, dan sebagainya.

Dan terakhir, sistematika tulisan ini mengungkapan setiap urutan bab yang terdapat dalam Tugas Akhir yang disertakan penjelasan singkat dari masing-masing bab tersebut.

Ada hal lain juga yang harus diperhatikan mahasiswa Tugas Akhir, yaitu :

  • penggunaan kata-kata dalam bahasa indonesia yang baku, penulisan kalimat sesuai standar kalimat : SPOK (Subjek Predikat Objek Keterangan), dan apabila terdapat istilah asing, harus dicetak miring (italic);
  • hindari penggunaan kata yang tidak perlu, atau bila perlu hapus saja agar menjadi kalimat yang sederhana. Biasanya sering dijumpai, mahasiswa menuliskan kalimatnya memiliki kata yang berulang seperti kata : agar, supaya, namun, tetapi, dll. Yang tidak pas apabila dibaca;
  • pahami perbedaan imbuhan di- dan kata depan di. Sering kali dijumpai mahasiswa tidak mengerti apakah di yang dipakai adalah imbuhan atau kata depan yang menerangkan tempat. kata “diatas” adalah keliru, karena kata tersebut menunjukan arah/tempat, berarti bukan memakai imbuhan di-, tetapi kata depan di. Sehingga, kalimat yang benar adalah “di atas”. Kata “di mulai” juga keliru, yang benar adalah dimulai, karena mulai bukan menunjukan tempat, melainkan kata kerja. Dan masih banyak contoh lain, jadi harap diperhatikan ya ๐Ÿ™‚
  • hal lain adalah menuliskan kata yang kurang pas. Seperti : “data-data yang dipakai”, padahal data adalah kata jamak.ย  Jadi yang benar adalah : “data yang dipakai”
  • apabila ada dua kata : tanggung jawab bertemu awalan dan akhiran, misal : di- dan -kan. Yang benar adalah dua kalimat tersebut melebur menjadi : dipertanggungjawabkan, bukan dipertanggung jawabkan. Dan masih banyak contoh lain ๐Ÿ˜€
  • apabila ada dua kata dalam kata bahasa asing yang ternyata terdiri dari satu kata atau sebaliknya, misal : database. Yang benar adalah : basisdata, bukan basis data. Ada pula contoh lain, remote : yang benar adalah : jarak-jauh, bukan jarak jauh.
  • Biasakan ketika sudah menyusun satu bab dalam laporan Tugas Akhir, dicetak, kemudian jangan langsung dibaca. ๐Ÿ˜€ Coba jalan-jalan santai sejenak, refreshing atau melakukan aktivitas lain, kemudian ketika pikiran santai. Coba baca kembali bab laporan Tugas Akhir yang sudah kamu cetak, biasanya akan menjadikan si mahasiswa menyadari bahwa kalimat atau paragraf yang ia susun itu keliru, nah dari situ, tandai setiap kekeliruan dalam penulisan, lalu lakukan corat-coret untuk me-revisi laporan Tugas Akhirmu. Jika sudah, coba dibaca lagi, apakah sudah pas susunan kata dan kalimatnya di dalam paragraf, apakah satu paragraf dengan paragraf yang lain berhubungan atau tidak. Dan baru deh, menghadap dosenmu dengan yakin dan percaya diri. ๐Ÿ™‚

Semoga tips-tips ini dapat membantu.

Sumber dari semua ini adalah dari perkuliahan Metodologi Penelitian oleh Pak Abdul Kadir dan Pak Insap Santosa, dosen-dosen JTETI UGM. Tidak sepenuhnya ditulis, namun disampaikan seadanya. Apabila ada kekeliruan di dalam penulisan artikel ini, itu murni kekeliruan penulis. Penulis mencoba menyampaikan dengan bahasa yang santai agar mudah dibaca, insyaAllah. ๐Ÿ™‚

Terima kasih.

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! ๐Ÿ˜€