Curhat : Core dan Aplikasi

Bila di curhat lalu saya membahas CORE yang mengirim data, sekarang bahas Aplikasinya. Sebenarnya tidak ada masalah apabila CORE berjalan normal, apalagi mengembalikan sesuai status. Tapi apa yang terjadi bila terjadi hal yang tak terduga yang mana kamu juga tak kepikiran sampai disana.

RESPON YANG DIKEMBALIKAN TIDAK SESUAI

jangan langsung menuduh CORE error!! atau respon dari core bermasalah! bisa saja dari sisi koneksinya. Mari asumsikan kalau kamu punya core berada di internet dan tiba-tiba internet down saat mengirim data.. Jadi harusnya terkirim json/xml lengkap.. malah sampai ke kita ngak lengkap.
Error ini malah kita dengan muda menuduh pasti programer core update-update ngak jelas sampai begini. padahal kalau di check malah errornya terbaca

dns failed

maksudnya error bukan dari aplikasi / core tetapi dari koneksi yang menghubungi/perantara. Cara terbaik untuk melakukan check adalah.. check apakah yang dikirim adalah json/xml atau pesan lain/terpotong.

DEFAULT ERROR

Bila bisa kamu memiliki error default , gunakan apabila responnya tidak sempurna.. dan khusus aplikasi testing dapat memiliki kemampuan cetak lognya.

FORMAT DATA

Untuk format data, lebih baik menjadikan coding kamu apabila angka dan bisa dihitung sebagai integer dan format lain harap jadikan text saja. Terutama format date yang mungkin agak sensitif bentuknya

Alasan Jangan Membeli Zend part 2

Untuk menyingkat waktu, dengan dasar tulisan sebelumnya. Kita dapat mengetahui bahwa sekarang dengan adanya framework, rule yang tepat dan analisa. Kita dapat menghasilkan program dengan cepat. Saat ini bisa dibilang point utama dalam membuat program bukan pada alat yang kita gunakan, code yang kita gunakan.. bahkan hal-hal yang programer kerjakan. Tetapi lebih kepada hal pendukung yaitu analisa-analisa saat program berjalan

Alasan Jangan Membeli Zend part 1

kondisi net saat ini

Saat menulis ini, kondisi saya lagi kesulitan internet sehingga numpang di luar, selain kesulitan yang lain. Tetapi informasi ini harus disampaikan, daripada lupa.. Inti dari tulisan ini adalah menunjukkan beberapa fakta menarik sebelum anda memutuskan melirik Zend.. kemudian melanjutkan ke pembahasan Zend.
Kenapa menulis jangan membeli Zend? karena tidak mudah mengatakan jangan membeli Zend!! setelah mengetahui bahwa pradigma programing kita sudah mengalami ... peningkatan! Apakah tulisan ini menjatuhkan Zend? mungkin penilaian itu akan terlihat saat membaca 2 artikel tentang pembahasan Zend ini.

Klinik: memberi batasan akses

Untuk batasan akses, bentuk batasan akses saya dibilang cukup buruk. Tetapi metode ini sebenarnya tidak salah.. namun mengaplikasinya harus lebih diperbaiki.. Pertama saya buat satu rule dahulu yang berisi list apa aja haknya. contoh:
nama rule : Kasir
list hak : baca billing, lihat billing, tambah billing  ...
permasalah pada rule yang saya buat ini adalah.. list hak yang tidak fixed!! dimana saya menulis manual disana.. contoh:
billView
hal ini tidak bagus karena nama hak ini tidak terdokumentasi dengan baik? Lalu bagaimana cara terbaik untuk memberi batasan akses.

mari membuat program buat pemula

saya lulusan ekonomi tapi gemar belajar IT juga ada kah yg mau membimbing saya untuk berbagi ilmunya belajar membbuat program ?

dalam membuat prog..

• yg pertama adalah tampilan..
• kedua.. cari di internet program mockup free
• ketiga.. pelajari cara memakainya

---

saran lain kunjungi

• http://www.w3schools.com/
• http://www.codecademy.com/

fitur log aktivitas data

Permisi, saya sedang membuat App. sekarang ini saya sedang menambahkan fitur log aktivitas data (insert, update, dan delete) dan log aktivitas user login/logout. menurut rekan" disini enakan menggunakan DB atau file txt iy, mohon sarannya.

karena waktu baca" referensi kalau menggunakan DB akan memberatkan si DB juga gitu. kalau menggunakan file txt, bisa gak nanti ditampilakan seperti kalau di DB tinggal select.

terima kasih

jawaban:
1. bagus kl dah mikir githu
2. taro di db lain
3. kl pake text akan sulit untuk selectnya

---

perlu membuat DB lagi atau cuman membuat tabel history aja??
soalnya ini nanti App-nya untuk lokal saja.

bikin db lain.. krn asumsinya kl km dapet projek kedepannya dah gk kaget

random post

http://jsfiddle.net/r5vwwqrb/
pertama buka lah link tersebut.. dan ini penjelasannya

• klik angka yg tertera
• list akan muncul dibawah

 Sebenarnya yang jadi problem adalah pada posisi line 26.. bagaimana menentukan nama yang sesuai.. jujur saja kl saya pribadi tidak memakai nama
name=xxxx{angka}
tetapi
name=xxx[{angka}]
ketika di submit hasilnya akan lebih mudah di gunakan

Curhat Aplikasi Klinik : Data Pasien

Mari sedikit menjelajahi tentang data pasien di rumah sakit. Seperti yang kita ketahui bentuk table yang kita gunakan berasal dari form yang dibuat dari front desk, kertas status dan pendukungnya. Dalam klinik atau puskesmas, semuanya dibuat dalam 1 kertas.. Dari sinilah muncul asumsi bahwa hanya dibutuhkan 1 table untuk pasien dan pendapat itu tidak sepenuhnya salah. Kita harus mengakui beberapa hal dari gambar di atas yaitu:

• depan (Front desk) memberikan kertas status dan mengisi dengan detail pasien
• dokter menuliskan apa yang jadi masala pasien dalam kertas (status) 
• memberikan kertas pada depan
• ditagih. 

apakah itu benar? belum tentu. Metode di atas terdapat pada klinik 'kecil' yang mana pasien datang dan pergi 'sesuka hati' (ups).. maksudnya datang hari ini dan besok tidak datang kembali. Sehingga yang terjadi hanya diberikan 1 kertas dan selesai disimpan dalam kotak.. Nanti 3 bulan kemudian di musnahkan dan tidak di masukkan ke database. Dalam tulisan ini saya akan menjelaskan tentang merancang pasien yang sesuai.

Curhat: Membuat kode Kondisi Yang Tepat

Dalam Programing seperti PHP. Sangat wajar apabila kita membuat kondisi dalam code kita. Mengingat IF sendiri mampu memberi arahan kemana program kita akan berjalan

if(....){ ..... }

Perintah IF memiliki pendamping yaitu ELSE. Dalam kode yang sering kulihat sering tidak memasukkan ELSE sebagai pendampingnya.
Dalam pengerjaannya tidak ada yang salah bila menggunakan IF tanpa ELSE.. tetapi ketika sudah mengerjakan program yang rumit atau spesifik dalam data; ELSE wajib dimasukkan walaupun terlihat tidak berguna.

Sebuah kebiasaan baik apabila kita memutuskan membuat code kita lebih lengkap. Dalam hal ini memberikan else walaupun tidak terlihat kegunaannya.
Tapi berangkat dari pernyataan tidak terlihat kegunaannya, mari telaah bahwa kode yang baik adalah kode yang mampu menangani segala masalah tanpa menambah masalah.

CURHAT 2 : CORE DAN APLIKASI PART 1

Mari kita berfikir bagaimana site bekerja terutama saat menarik database. Normalnya site akan membuka koneksi ke database lalu menjalankan query. Dan kemudian hal sama terjadi berulang kali. Kali ini kita akan memanfaatkan Aplikasi non situs. Bayangkan apa yang kamu dapat bila aplikasi ini mampu akses database?!? bisa terjadi kebocoran!

Kebocoran ini salah satunya kita sebuah sebagai DoS.

Denial-of-service attack
In computing, a denial-of-service (DoS) or distributed denial-of-service (DDoS) attack is an attempt to make a machine or network resource unavailable to its intended users.

A DoS attack generally consists of efforts to temporarily or indefinitely interrupt or suspend services of a host connected to the Internet.

Bila yang melakukan request lebih dari 1 tempat (aplikasi), bayangkan bahayanya. Dari sinilah kita melihat sebuah fakta sederhana yaitu

"sebuah aplikasi butuh data untuk berjalan secara dinamis"

CURHAT PROGRAMER : MEMAKAI MYSQL

dalam keseharian saya biasa menggunakan mysql dalam program saya. Jadi sangat wajar apabila sangat inget sekali dengan perintah

• mysql_connect
• mysql_query
• dan mysql_ lainnya

Tetapi semua berubah saat diketahui perintah mysql_ kurang untuk database mysql yang memiliki kemampuan seperti transaksi. Pada mysql_ hanya memberikan fungsi dasar yang kurang untuk menggunakan kemampuan mysql terbaru. Untuk hal ini, akhirnya memutuskan mengganti dengan mysqli. Tapi menggunakan mysqli tidak semudah memakai perintah mysql_.