Author Topic: [TIPS] Membuat aplikasi sebagai profesi (secara profesional)  (Read 16414 times)

0 Members and 1 Guest are viewing this topic.

Offline foxy

  • Fox-id M.V.P
  • Hero Member
  • *
  • Posts: 3.011
    • Foxy Land
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« on: February 23, 2006, 09:08:01 AM »
Hi guys,

Beberapa waktu yang lalu saya dapat proyek baru. To make a story short, setelah proses pengumpulan informasi, tawar-tawaran, deal, pembuatan program, dan lain-lain, akhirnya program itu pun jadi. Pada waktu final delivery, si owner meminta saya untuk menginstall program itu di komputer dia (komputer lama, PII-350). Waktu saya periksa komputernya, ternyata di dalam sistem komputernya ada TIGA program untuk business dia:
- Yang satu aplikasi web based yang dibuat dengan PHP dengan database MySQL (belum selesai - masih banyak yang script error)
- lalu juga ada aplikasi yang dibuat dengan VFP7 (!!! - karena penasaran saya decompile, dan  dari base classes-nya saya mendapati bahwa programnya menggunakan base forms dari aplikasi sample tastrade. Program yang ini sudah hampir selesai, tapi sayang, kelihatannya si programmer bingung dengan kompleksitas frameworknya, dan business process  bener-bener di integrasikan sampai ke level user interface. Akibatnya dengan hanya sedikit perubahan pada business si owner (dalam kasus ini adalah nama jasa yang dijual atau penambahan jasa baru), program ini sudah tidak terpakai dan harus di bongkar mulai dari struktur database, sampai user interface (form design) ).
- Program ketiga dibuat dengan Microsoft Access. Ini adalah program yang paling lumayan di antara ketiga program yang ada. Tapi kelihatannya si pembuat mendapat masalah yang sama dengan kasus VFP7. Business process-nya di masukin semua di form. Ini masih ditambah dengan masalah database yang banyak redundancy. Akibatnya report yang dihasilkan jadi nggak konsisten.

Anyway, waktu saya tanya owner apakah semua program lama ini mau dihapus, dia dengan tegas menjawab 'ya' dan 'sedikit' bercerita mengenai sejarah program-program itu. Saya tidak akan menceritakan mengenai bagaimana ceritanya, tapi setelah mendengar cerita dia dan melihat ketiga aplikasi itu, saya jadi ingin sedikit berbagi untuk foxer-foxer indonesia --- terutama untuk independent software developer (saya lebih seneng pakai istilah itu daripada istilah 'programmer freelance' - yang terakhir kesannya kok cheap banget ;) ).

Saya sama sekali tidak bermaksud mengajari, juga tidak bermaksud sombong dan mengatakan bahwa saya sudah berhasil. Bukan begitu. Saya hanya ingin berbagi. Tujuan saya supaya profesi kita ini lebih dihargai. Kalau profesi kita ini lebih dihargai, saya yakin, kita semua bisa memetik buahnya.

Nah, yang akan saya berikan sekarang adalah tips-tips ringan mengenai membuat aplikasi. Point-point-nya mungkin tidak tersusun rapi (karena saya tidak akan ada waktu untuk mengedit ulang post ini), tapi inilah point-point itu:

1. Pastikan Anda telah mengumpulkan informasi yang cukup sebelum Anda mulai membuat program.
Informasi apa saja yang perlu Anda kumpulkan? Yang pasti pertama kali Anda harus tau business process-nya. Bagaimana alur datanya. Apa saja entitas yang terlibat. Dan jangan lupa, bagaimana report yang sekarang sudah berjalan dan bagaimana report yang diharapkan oleh user (yang dengan sistem yang ada sekarang masih merupakan angan-angan). Cara mendapatkan informasi adalah dengan komunikasi. Cobalah untuk ngobrol dengan owner, dan dengan semua orang yang akan terlibat dengan sistem. Setiap orang akan punya pengharapan-pengharapan dan keperluan tertentu. Tampunglah semua requirement itu. Semakin besar sebuah sistem, semakin banyak requirement yang harus dikumpulkan. Ada banyak metode untuk menampung dan mendokumentasikan informasi ini. Yang paling sering saya gunakan adalah metode CRC (Class-Responsibiliy-Collaborator). Untuk menggunakan metode ini, buatlah kartu ukuran 1/4 kertas A4 seperti ini:
Code: [Select]

+-----------------------------------+
|              CLASS                |
+----------------+------------------+
| Responsibility |   Collaborator   |
+----------------+------------------+
|                |                  |
|                |                  |
|                |                  |
|                |                  |
|                |                  |
|                |                  |
+----------------+------------------+

Contoh kartu CRC:
Code: [Select]

+----------------------------------------------------------+
|                        Head PPIC                         |
+-----------------------------+----------------------------+
|       Responsibility        |   Collaborator             |
+-----------------------------+----------------------------+
| Membuat planning produksi   | Owner (preference)         |
|                             | Marketing (sales data)     |
|                             | Kondisi buffer stock (gdg) |
+-----------------------------+----------------------------+

CRC Card akan sangat membantu dalam mengorganisir pengumpulan data pada level lapangan.

2. Kalau Anda adalah desiner sistem, setelah informasi terkumpul, jangan langsung buru-buru menjalankan VFP dan membuat form. Gunakan buku. Sekali lagi: gunakan buku - bukan kertas lembaran. Kalau Anda senang menggunakan kertas, pastikan Anda menggunakan kertas yang mudah dibinder (seperti kertas loose leaf seperti jaman kulihan dulu). Setelah digunakan, kertas itu harus langsung di-binder. Kalau tidak kertas itu akan jadi lost leaf. Pokoknya gini deh, kalau Anda punya banyak kertas-kertas penting tapi menurut orang rumah itu adalah 'susuh tikus' berarti Anda perlu buku!

3. Next point: apa yang harus Anda isi di buku itu? Well. Semua pikiran Anda. Usul saya, mulailah dengan membuat DFD level 0 (a.k.a context diagram). DFD level 0 hanya berisi satu proses (yaitu proses dengan nama Sistem Informasi Bikinan Anda) dan entitas-entitas yang terlibat. Membuat DFD level 0 ini mudah sekali. Harusnya Anda hanya butuh paling lama 5 menit untuk membuatnya. Biarpun ini mudah dan sederhana, tapi DFD Level-0 harus dibuat. Karena dengan membuat DFD level 0, secara psikologis akan membentuk benteng-benteng batasan di pikiran kita. Jadi kita tidak berpikir di luar masalah yang ada.
Setelah itu buat juga DFD level 1-nya. Cara membuat DFD level-1: kumpulkan CRC card yang sudah diisi, lalu susun di atas meja yang cukup luas. Nah, dari sana, anda akan dengan mudah membuat DFD level-1. Kalau prosesnya masih kompleks, bisa juga dibuat level 2. Tapi saya rasa sampai level 2 cukup. Saya pribadi jarang sampai ke level-3.

Setelah draft DFD, bisa diteruskan dengan database design. Saat database design ada satu tips untuk para pemula: JANGAN TAKUT DENGAN TABEL YANG BANYAK. Tiga aplikasi yang saya ceritakan di awal post ini, hanya menggunakan tabel yang sangat sedikit. Yang aplikasi VFP7, malah hanya menggunakan tiga tabel dan 5 view. Banyak pemula yang mendesain database dengan tabel yang sedikit. Yah, nggak bisa disalahkan. Kalau kita lihat bahan kuliahan sistem database (basis data), biasanya pada contoh kasus atau (bahkan) ujian paling mentok 4 tabel. Lima aja jarang. Nah, apa minusnya tabel sedikit? Kalau tabel-nya sedikit, hampir pasti design database tidak memenuhi kaidah normalisasi database. Misalnya aplikasi VFP yang saya ceritakan barusan; ada satu tabel yang mempunyai 50 field dan 40 field-nya bernama seperti ini: absenKB1, absenKB2, absenKB3, absenKB4, absenKB5, absenDRP1, absenDRP2, absenDRP3, absenGOR1, dst. Nah, Anda bisa bayangkan bagaimana strukturnya?

Jumlah tabel yang banyak adalah hal yang umum di aplikasi-aplikasi bisnis. Angka 80 tabel atau 120 tabel bukan hal yang aneh. Kalau business rule dan authentication di aplikasikan ke database juga (misalnya untuk db SQL Server), maka view yang digunakan bisa dua kali lipat jumlah tabel. Itu juga jumlah yang umum. Jadi sekali lagi: jangan takut melakukan desain dengan jumlah tabel yang banyak - tentu saja kalau memang diperlukan.

Selanjutnya mengenai normalisasi: Saya punya aturan untuk menormalisasi tabel sampai N3. Apabila tabel itu: a) hanya akan berupa lookup tabel, b) relasi hanya dengan satu tabel lain - tidak lebih; dan c) relatif tidak ada insertion selama operasional harian aplikasi; maka saya akan men-denormalisasi ke N2. Tapi bukan berhenti di N2. Normalisasi semua tabel sampai N3, lalu untuk beberapa tabel yang memenuhi tiga aturan di atas, denormalisasi-kan ke N2. Kalau misalnya Anda bertanya; 'apa perlunya normalisasi database?' - berarti Anda perlu membaca lebih banyak mengenai normalisasi. Silahkan search google. Dari sana banyak sekali link artikel mengenai normalisasi.

Sedikit tambahan mengenai primary key; sebaiknya setiap tabel mempunyai surrogate primary key. Artinya primary key yang tidak dapat dilihat oleh user dan tidak mempunyai arti oleh user. Jadi, jangan gunakan nomor order atau kode customer, atau no transaksi, atau sejenisnya sebagai primary key. Gunakan satu kolom (field) khusus misalnya nama tabel adalah sales; maka nama primary key-nya sales_PK. Bisa digunakan tipe integer atau Long Integer (atau boleh juga menggunakan GUID kalau database Anda terdistribusi). Mungkin Anda berargumen; "Tapi kode customer yang saya gunakan pasti unik. Tidak mungkin tidak unik", atau mungkin: "Tapi nomor order saya di generate otomatis dengan lookup table - jadi nggak mungkin ada yang double - berarti bisa dipakai PK!". OK. Whatever argument anda, jawaban saya: "OK. Tetap gunakan surrogate primary key". Anda bisa punya banyak candidate key di tabel Anda. Tapi hanya gunakan satu kolom (field) untuk primary key.

Fiuh. Artikel ini jadi panjang. Repot juga ya? Gini deh, artikel ini masih akan bersambung. Tapi sambungannya lain kali ya...

Kalau ada yang mau ditanyakan, silahkan.

Disclaimer:
Artikel ini adalah berdasarkan pengalaman saya dan bersumber dari pilihan/preference saya berdasarkan buku, artikel, dan post-post dari komunitas foxpro yang saya baca. Saya percaya bahwa setiap profesional mempunyai preference dan pemikiran tersendiri. Jadi artikel ini bukan aturan baku.

hth,
Foxy
This post is provided as is. Feel free to use all the codes and information, however understand that I don't have any obligations to fix any bug(s) or follow up this subject.

Offline mztolo

  • Fox-id M.V.P
  • Hero Member
  • *
  • Posts: 2.039
  • ~0("-")o~
    • http://www.irenk.com
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #1 on: February 23, 2006, 09:45:22 AM »
Bagus sekali papa foxy....
Terima kasih sekali..... kita tunggu tulisan/artikel berikutnya....

Semoga berguna ntuk kami2 yg lagi tumbuh dan berkembang....amien

Salam hangat.NSL
**pak taz bisa taruh di artikel agar terus bisa di baca di fox-id ini....

Offline sensaribar

  • Junior Member
  • *
  • Posts: 179
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #2 on: February 23, 2006, 10:47:03 AM »
terima kasih banyak papa foxy...

infonya saya yakin sangat bermanfaat buat foxer fox-id.
saya sendiri seperti mendapat durian runtuh.
meskipun saat ini saya masih bekerja di kantoran, ada keinginan juga untuk menjadi seperti papa foxy, menjadi independent software developer.

bisa gak ya ???  :oops:

ok deh, kita tunggu post berikutnya.

sekali lagi terima kasih papa foxy, infonya PASTI BERMANFAAT.

rgds

Offline tejos

  • SET STUDY ON
  • Global Moderator
  • Hero Member
  • *
  • Posts: 1.678
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #3 on: February 23, 2006, 12:19:01 PM »
Terima kasih papa Foxy...
Masukkan yang amat berharga buat pemula seperti saya ini....
Yang "baru-mulai-akan" merangkak menjadi meniti profesi ini "Independent Software Developer".
Ada janji yang indah untuk profesi ini meski saat ini aku masih duduk asik di kantor ber-AC dan dibayari...
Thank you.....
http://www.isa-tech.com
http://cc.domaindlx.com/isakom/

Salam,
***BTGL - Belajar Terus Gitu Lhoh.....***

Offline didin_irawan

  • Newbie
  • *
  • Posts: 9
    • http://sman1jts.com
foxy
« Reply #4 on: February 23, 2006, 12:38:49 PM »
terima kasih eyang foxy..
atas pencerahan tentang buat programnya..
maklum yang di atas aja sudah papa...
berarti foxy buat saya adalah  
eyang...

Offline leosan88

  • Senior Member
  • *
  • Posts: 544
    • http://elchan-consulting.tripod.com
Salah Melangkah Fatal Akibatnya
« Reply #5 on: February 23, 2006, 02:57:04 PM »
Saya setuju dengan post yg dikirim oleh Foxy

Dari Penjelasan Foxy berarti Client salah memilih Programmer

Memang Aplikasi yg kita jual sesuai dengan Harga
- Harga murah yah itu hasilnya juga tidak sesuai dengan yang diharapkan

Yang saya tekankan jangan kita asal mengambil Class bawaan dari VFP seperti yg Foxy postkan Class dari Trastade sebelum kita mengusai 100% class tersebut dan akhirnya terjebak dalam jaring2 yg kita susun sendiri

Lebih aman pake Class buatan sendiri dan untuk design system tidak selalu pake DFD juga gak apa2 yg penting kita harus menggambarkan FlowChart- Kalau saya lebih senang pake Flowchart Schema ketimbang DFD

Sekali lagi tergantung dari Professional masing2 programmer


Gitu saja tanggapan dari saya


Salam Damai


Leosan
-----------------------------------------------
++ NeVer Give Up - VFP is Rock Tool ++
+ Visual Foxpro Still My Best Tool ++

Offline Sunariyo

  • Newbie
  • *
  • Posts: 32
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #6 on: February 23, 2006, 03:01:36 PM »
SIP lah Artikelnya............

Ikut nimbrung ni............

Setuju sekali deh dengan ulasan TIP yang bang foxy ulas, emang sih banyak programmer mau ambil praktisnya aja..........apalagi programer tersebut sebagai programer dan analist systemnya sendiri, kadang langsung buat program tanpa mau pusing2 konsep design sistemnya, akibatnya programnya tambal sulam sana sini setelah di sodorkan ke owner....untung2 kalo programnya diminta diperbaiki.........kalo diminta dibuang atau dihapus aja seperti ulasan diatas.......wah sia2 dong kerja kita..........mending kalo udah dibayar, kalo gak dibayar...wah berabe deh.

Konsep DFD harusnya mutlak dibuat sebagai dokumen dasar yang membatasi ruang lingkup project yang dibuat, yang sangat membantu bagi system analist, programmer dan owner, dimana dengan DFD tersebut kita dapat menyamakan persepsi dan membatasi ruang lingkup sistem.........sehingga konsep awalnya sesuai dengan yang diharapkan owner..........karena kalo tanpa pembatas.......wah pikiran manusia itu khan bisa berubah-ubah setiap detiknya........bisa gawat program berkembang tanpa batas.....jadi project gak rampung2....bisa jadi project seumur hidup.....yang sia2.

Emang kadang owner sendiri ada yang gak mau ambil pusing dengan DFD yang kita design..........tapi DFD itu sangat mendukung dalam pengembangan program yang profesional dalam penyamaan persepsi dan sebagai dokumentasi sistem yang kita buat.......dan enak juga buat kita untuk mengenal lingkup sistem itu secara utuh......apalagi sistem yang kita kembangkan udah banyak.......dan jika ada masalah sistem tersebut kita bisa lihat dokumentasi sistem itu kembali tanpa harus melototin alur programnya satu2........so sangat membantu next timenya.

Dan jangan lupa juga kalo udah selesai programnya perlu dibuat juga dokumentasi akhir dari program tersebut....sebagai dokumentasi akhir......biar enak maintenance program kedepannya.

So.........Maju terus buat Programmer Indonesia.


Tks,


Naryo

Offline armen_sakti

  • Fox-id M.V.P
  • Hero Member
  • *
  • Posts: 1.252
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #7 on: February 23, 2006, 03:24:40 PM »
Memang benar apa yang dialami mas Foxy, dari beberapa client yang saya dapat, pernah 3 owner yang ganti-ganti programmer, dan saya yang akhirnya menyelesaikan. Kata lainnya (maaf bukan menonjolkan diri) saya menjual jasa setelah Programmer lain tidak berjasa. Dimana kelemahannya? jawabannya sudah diuraikan panjang lebar oleh mas Foxy, juga rekan lainnya. Pada awal saya menerima Job th 1999, belum kenal yang namanya DFD, Flowchart, IPOChart dan segala macamnya. Tulisan mas Foxy itu saya dapat saat semester 5 di kuliahan dulu, Kalo ga salah materinya RSI(Rekayasa Sistim Informasi). That's very good post.

Apa kabar pak RW? :wink:  PM nya udah saya baca

Offline mas_sonny

  • Junior Member
  • *
  • Posts: 338
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #8 on: February 23, 2006, 04:01:49 PM »
soal DFD saya kurang paham secara teori.. maklum.. sekolahnya juga cetek.. hehhee... yang penting bagi saya penguasaan normalisasi data harus matang dan teknik programmingnya harus tepat. Trus.. untuk teori bikin aplikasi profesional ala "independent software developer" dari mas Foxy.. it's good idea, thanks bro :mrgreen:
Happy Coding because Coding is Fun :thumbsup:

Offline taz

  • Administrator
  • Hero Member
  • *
  • Posts: 2.515
  • Do SEARCH berfore post guys!
    • http://fox-id.com
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #9 on: February 24, 2006, 11:26:19 AM »
STICKY!!!!
thaks bro for da tips!   :idea:  :idea:  :idea:
- Fox-id.org is KiOSS Project exclusive member -


Offline ~teguh~

  • Fox-id M.V.P
  • Hero Member
  • *
  • Posts: 1.046
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #10 on: February 24, 2006, 11:29:27 AM »
Quote from: "foxy"

Sedikit tambahan mengenai primary key; sebaiknya setiap tabel mempunyai surrogate primary key. Artinya primary key yang tidak dapat dilihat oleh user dan tidak mempunyai arti oleh user. Jadi, jangan gunakan nomor order atau kode customer, atau no transaksi, atau sejenisnya sebagai primary key. Gunakan satu kolom (field) khusus misalnya nama tabel adalah sales; maka nama primary key-nya sales_PK. Bisa digunakan tipe integer atau Long Integer (atau boleh juga menggunakan GUID kalau database Anda terdistribusi). Mungkin Anda berargumen; "Tapi kode customer yang saya gunakan pasti unik. Tidak mungkin tidak unik", atau mungkin: "Tapi nomor order saya di generate otomatis dengan lookup table - jadi nggak mungkin ada yang double - berarti bisa dipakai PK!". OK. Whatever argument anda, jawaban saya: "OK. Tetap gunakan surrogate primary key". Anda bisa punya banyak candidate key di tabel Anda. Tapi hanya gunakan satu kolom (field) untuk primary key.



Ini argument yg baru bagi aku, walo sebenernya akupun juga kadang2 tidak memakai Primary Key di table.
Tapi tetap saja untuk table2 spt transaksi,tbl customer dsb , aku memakai nomor order/kode customer/no transaksi sebagai Primary Key dan bukan cuma sekadar candidat key.

Tips dari papa Foxy diatas itu seolah2 menyatakan "Primary Key tidak perlu dipakai di semua tabel!"
(maaf kalo kesimpulan saya salah .. :wink: ) .

Yang ingin saya tanyakan.. Kenapa? apa kebaikannya?

Dan kalo memang kita ingin membuat primary key 'yang tidak dapat dilihat oleh user dan tidak mempunyai arti oleh user',
bisakah nomor yg kita generate otomatis dgn AutoIncrement dijadikan 'surrogate Primary Key'?

Maaf, aku bukannya hendak berdebat,krn sama dgn papa foxy,
akupun percaya tiap2 programmer punya style dan caranya  sendiri.
Aku hanya sekadar ingin membuka pemikiran baru buat aku pribadi.
Bila memang ternyata cara papa foxy ttg primary key tsb cukup efektif dan bagus,
maka aku ngga' akan segan2 untuk menirunya .. :-D
Karena kebetulan juga, aku sedang dlm tahap awal bikin project baru,
 kali2 aja cara papa foxy tsb bisa aku terapin di project tsb...

anyway, Thanks for the Tips, papa foxy ......


salam

~teguh~
FoxPro -- Learn it, love it and live with it

Offline taz

  • Administrator
  • Hero Member
  • *
  • Posts: 2.515
  • Do SEARCH berfore post guys!
    • http://fox-id.com
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #11 on: February 24, 2006, 12:24:45 PM »
manurut saya, PK tetep harus ada. bukannya dengan PK tidak bakalan ada value (dari field PK tersebut) yang dobel? tentang sorgurot....whatever (maklum...nggak pernah kena ilmu IT  :P )...saya sering kali memakai di satu tabel (yang ada PK-nya) yang saya gunakan utk pencarian data (baikk lookup dari tabel yang lain atau hanya utuk proses indek). berdasar teori rushmore sih seharusnya itu mempercepat database enggine untk melakukan proses pencarian data. tapi sayang teori itu saya terapkan (baik di mySQL, MSSQL, NATIVE DBF ataupun di ORACLE) tanda saya benchmark terlebih dahulu (JANGAN DITIRU YAH......) karena dari beberapa dokumentasi SQL (setau saya di MSSQL sqn mySQL) pengguakan key tersebut akan mempercepat proses pencarian data.
eniwei, VOTE buat PK (selalu ada di tabel yang butuh dicari dengan data dinamis, nggak perlu banget di tabel yang statis, misalnya tabel TIPE IDENTIFIKASI, yang isinya cuman PASPOR,KTP,SIM dll)
- Fox-id.org is KiOSS Project exclusive member -


Kemploe

  • Guest
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #12 on: February 24, 2006, 04:20:43 PM »
:lol:
Artikel yg menarik pakde, ditunggu utk artikel selanjutnya..

!==

Offline sensaribar

  • Junior Member
  • *
  • Posts: 179
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #13 on: February 24, 2006, 04:57:32 PM »
saya sudah menerapkan surrogate key seperti saran papa foxy hampir setahun ini, dan ternyata memang ampuh sekali. benar-benar tidak pernah terpikirkan sama sekali.

silahkan dicoba sendiri... dan anda akan tercengang....

rgds,

Offline leosan88

  • Senior Member
  • *
  • Posts: 544
    • http://elchan-consulting.tripod.com
[TIPS] Membuat aplikasi sebagai profesi (secara profesional)
« Reply #14 on: February 25, 2006, 09:23:29 AM »
Surrogate Key pakai Long integer

Gimana kalau aplikasi banyak sekali misal 1 hari bisa 1 juta record
atau 1 juta transaksi yang dipakai misal seperti Giant Market
berarti pasti ada duplicate data dong

Kita harus mikir kedepan dan kode PK harus unix

Oke tetapi sekali lagi tergantung dari masing2 programmer yang mempunyai style berbeda2

Memang sih kelemahannya kalau misalnya kode diganti2 kalau pake surrogate key gak masalah cuma untuk jangka panjang surrogate key pasti ada masalah dalam hitungan Tahun


Sory nih jangan tersinggung yah, Sekedar Masukan saja bukan mau debat :lol:


Salam



Leosan
+ Visual Foxpro Still My Best Tool ++