Mục Vấn Ðáp Frequently Asked Questions (Faq) là những câu hỏi
thường được đặt ra trong Visual Basic. Trong phần này chúng
tôi sẽ đăng tất cả những câu hỏi thường được học viên đặt ra
trong lớp học Visual Basic của Vovisoft.
Tại
trụ sở Vovisoft có những hoạt động thường xuyên nào?
Hiện giờ mỗi tuần có những hoạt động sau:
-
Tối Thứ Ba:
Từ 7:30 đến 10:30 là Lớp VB6 căn bản do Thầy Tài phụ trách.
-
Tối Thứ Tư:
Các Sư huynh trong VoviKungFu Luyện Nội Công và Khí Công từ 10 giờ 30 tối đến 2 giờ khuya.
-
Tối Thứ Năm:
Từ 7:30 đến 10:30 là VB6
trung cấp do Thầy Hồng phụ trách.
-
Chiều Thứ Bảy:
từ 12
giờ trưa đến 3 giờ là Lớp
MCSE Windows2000- Server do thầy Tín
phụ trách.
-
Chiều Thứ Bảy:
Từ
3:30 giờ đến 5:30 giờ là Lớp
English for the Professionals do thầy Giác phụ trách.
-
Chiều Thứ Bảy:
Từ 5:30 đến 7:30 là MCSE Windows2000- Server Workshop do thầy
Tín
phụ trách.
-
Chiều Chúa Nhật:
Từ 4:00 đến 6:30 là lớp MSOffice2000 do thầy
Bình
phụ trách.
Liên
hệ của VoviSoft với Vovikungfu như thế nào?
Hai nhóm có những hoạt
động nào chung không?
Vovisoft phát xuất từ Vovikungfu. Bây giờ hai nhóm
là hai nhánh của VoviLearned Society (Hội Hàn Lâm Vô Vi), đứng đầu là
Ðại Sư Huynh Trần Công Sơn. Võ sư Lý Hồng Tuấn, xuất thân từ môn
phái Thiếu Lâm La Phù Sơn Hồng Gia Quyền, là người sáng lập
Vovikungfu. (Xem thêm chi tiết trong các trang Tin Tức Vô Vi). Võ sư Lý
Hồng Tuấn khích lệ Thầy Hồng mở lớp dạy thão chương. Từ khi bắt
đầu hoạt động Vovisoft, luôn luôn nhận được sự ủng hộ hết mình
của nhóm Vovikungfu. Các tài sản đầu tiên của Vovisoft đều do
VoviKungfu mua tặng.
Hằng năm hai nhóm có tổ chức chung tiệc Giáng sinh, Picnic Phục Sinh,
Giỗ Sư Phụ (đầu tháng sáu) và Picnic Mùa Xuân (đầu tháng Chín) .
Ngoài ra Vovikungfu vẫn luôn luôn hoan nghênh các anh chị em trong nhóm
Vovisoft thụ giáo Hồng Gia Quyền để thêm sức khỏe. Cứ vài tháng là
hai nhóm có ra tờ Tin Tức Vô Vi, do Tiến Sĩ Lý Gia Nhẫn làm chủ bút.
Tiến Sĩ Nhẫn là Hội Trưởng Hội AVAPS ( Hội cựu sinh viên Colombo du
học tại Úc). Ông là đệ tử Hồng Gia Quyền (nhóm Vovikungfu) và cűng
là người giúp về tổ chức cho các khóa huấn luyện của Vovisoft.
Theo
học với Vovisoft phải đóng tiền gì?
Nếu bạn tự học thão chương từ Website của
Vovisoft thì không tốn gì cả. Cứ tự tiện lấy bài vở từ các mục bài
mẫu, mẹo vặt, hỏi đáp mà học. Ước ao của anh em Vovisoft là làm một
Website hữu ích hiệu lực để trợ giúp người Việt học thão chương.
Lần lượt chúng tôi sẽ cho lên Web các source code để các bạn dùng
trong các trường hợp thực tiển trong nghề tin học của mình.
Nếu bạn theo học ở trụ sở của Vovisoft tại Sydney thì đóng một lần
$50 khi tham gia. Sau đó nếu còn theo học thì mỗi tuần đóng $5 để
giúp trang trải các chi phí như tiền mướn trụ sở, Internet, điện điều
hòa không khí, trà, cà phê, mì gói, bia, nước ngọt .v.v. Số tiền dư
ra ta sẽ dành vào việc mua thêm computer và software.
Theo lời nhắn nhủ của Sư Phụ Lý Hồng Tuấn, tất cả các hoạt động của
Vovikungfu/ Vovisoft để giúp đở đồng bào đều hoàn toàn bất vụ lợi.
Các huấn luyện viên của Vovikungfu cűng như các giảng viên Vovisoft đều
tự nguyện. Các học viên võ học hay thão chương đều được
khuyến khích dùng điều mình đã học được chỉ dẫn lại hay giúp
đở đồng hương, không cần phải dấu nghề vì chúng ta sẽ cùng nhau
trau giồi nghề mình càng lúc càng tinh xão hơn.
Bao giờ sẽ có các khóa
học mới?
Hiện tại hai khóa Visual Basic 6 sẽ kéo dài đến
cuối năm 2000.
Cuối tháng 12, trong ba ngày 26-28/12/2000 sẽ có lớp Visual Basic 6 mới.
Học viên cần phải ghi danh qua Internet kể từ tháng
10/2000 khi mẫu
đơn được phổ biến trên Web.
Có người hỏi về khóa Oracle 8 và Developer 2000. Hiện nay Vovisoft chưa
có kế hoạch rõ ràng cho việc nầy. Khi nào Thầy Nguyễn Ðức Huy và
Thầy Hồng sắp xếp được thì giờ để dạy thì sẽ thông báo.
Ngoài ra thỉnh thoãng Vovisoft có mở các Khóa Học Bỏ Túi, chừng nữa
ngày hay một ngày để dạy về Network, Windows
CE ...vv. Chúng tôi sẽ
thông báo kịp thời trong tương lai.
Tôi
muốn học lập trình (Programming) Visual Basic , nhưng không biết bắt
đầu từ đâu, và cần gì?
Muốn học Visual Basic trước nhất bạn phải có
chút căn bản kiến thức về Windows 95/ 98 và MS Office 97. Do đó nếu
bạn mới mẻ với Computer thì hãy làm quen với máy điện toán trước.
Khi ta viết VB program sẽ thường dùng những từ chuyên môn của MS
Windows và Office 97. Bạn có thể mua những dĩa CD hay băng Video tự
học về MS Windows và Office 97.
Hiện ta học Visual Basic 6 do đó bạn nên có Visual Basic 6 Professional
(Student Version cűng y hệt và rẽ hơn). Nó gồm một CD cho VB6 và 2CD là
cẩm nang của những người thão chương dùng nhu liệu của Microsoft,
gọi là MSDN (Microsoft Developver Network) Nếu máy bạn đã cű và chạy
chậm quá hãy đầu tư vào một máy mới, nhanh hơn và có ít nhất 4GB
disk. Hiện nay hardware rất rẽ và thời giờ bạn quí hơn vì bạn sẽ ngồi
trước máy ít nhất 20 tiếng một tuần nên $1000 không phải là một điều
xa xí.
Trình độ nào cűng học VB được miễn là bạn thích học, nhưng
nếu trước đây bạn có bằng Tú Tài I trở lên thì tốt quá. Hầu
hết các tài liệu đều nằm trong các dĩa CD của Microsoft. Bạn sẽ lấy
thêm các tài liệu từ Vovisoft Website để phụ thêm như bài tập, các
mẹo vặt .v.v..
Nếu ở Sydney, Úc Ðại Lợi, bạn có thể ghi danh để học tại Sào
huyệt của Vovisoft. Mỗi tuần có hai lớp tối: một lớp căn bản tối thứ
ba (7-10pm), một lớp cao hơn tối thứ năm (7:30 - 10:30). Lớp tối thứ năm
nhắm vào những sinh viên đã tốt nghiệp TAFE, Ðại Học nhưng chưa có
việc làm. Tuy nhiên bạn được hoan nghênh tham dự cả hai lớp (buy one,
get one free). Các lớp học nhấn mạnh về các mánh lới nhà nghề và
kinh nghiệm thực tiễn để khi học viên đã tốt nghiệp khi đi làm là
hữu dụng ngay trong ngày đầu vào sở.
Tôi
muốn mua một quyễn sách để học thêm về VB, không biết nên mua của
tác giả nào?
Tốt nhất bạn ra tiệm sách đọc thử mấy quyễn
họ chưng trên kệ để xem quyễn nào vừa ý. Nhất là đây là lần
đầu tiên bạn đọc sách về VB. Hãy chọn sách nào bạn thấy đọc dễ
hiễu nhất, mặc dầu chưa chắc đó là quyễn hay nhất. Vì điểm quan
trọng là bạn tiếp thu những điều căn bản trước đã. Sau khi đã có
căn bản rồi, bạn sẽ không còn bở ngỡ trước cách viết của những tác
giã khác. Chừng đó việc chọn sách sẽ dễ hơn.
Làm
sao tôi nộp bài cho giảng viên?
Bạn học lớp nào thì gởi bài cho thầy lớp
đó. Trong Window Explorer chọn tất cả các files trong một VB Project
rồi Zip nó thành một file. Ðính kèm Zip File đó trong một Email với
lời giới thiệu hay giải thích mình đang làm gì thì gặp khó khăn.
Nếu Program té (crash), bạn có thể bắt hình màn ảnh (capture the
screen) bằng cách bấm nút PrintScreen (nằm phía trên nút Insert) để
copy hình ấy vào Clipboard, mở Winword ra, Paste hình ấy vào một Winword
document rồi chứa vào trong Project Folder để Zip chung với các File
khác gởi đi. Nếu không có Zip file thì download Winzip từ Internet
(Search for Winzip).
Một File đã được Add vào trong Project nhưng
sao không thấy nằm trong Project Folder?
Sau khi bạn dùng menu Command Project | Add File ..
để cho một File ( Form hay Module) vào trong Project, Project biết lấy
File ấy từ đâu nhưng không tạo ra một bản sao (copy) của File ấy
trong Project Folder. Nếu bạn muốn có một copy của File ấy trong Project
Folder bạn phải dùng File | Save As .. để chứa File ấy trong một File
trùng tên hay có tên mới trong Project Folder.
Nhớ là có khi bạn muốn giữ chỉ một bản của một Basic Module tại một
chỗ và dùng nó trong nhiều Project. Mỗi lần muốn dùng nó trong một
Project mới bạn chỉ cần Add File nó vào trong Project nhưng không muốn
làm một bản sao của nó trong Project Folder. Lợi điểm của cách nầy là
khi cần sữa một Sub trong Basic Module bạn chỉ cần sữa một bản thôi,
chớ không cần phải vô từng Project Folder để sữa.
SetUp
hay Package & Deployment là gì?
SetUp là công việc
gói ghém tất cả những gì cần để chạy nhu liệu áp dụng (application
software) của bạn rồi sau đó đem cài đặt lên một computer khác.
Ngày xưa trong thời
Operating System DOS, để chạy một nhu liệu áp dụng ta chỉ cần một
"exe" file của nhu liệu đó và mấy cái data files. Do đó chỉ
cần sao (copy) những files ấy vào một folder trên computer khác là chạy
được ngay.
Một nhu liệu VB bạn
vừa viết xong thì cần nhiều thứ lỉnh kỉnh mới chạy được.
Ít nhất nó cần những VB Components ta dùng từ Toolbox và những
Library cho database ..vv..
Hầu hết các files
yểm trợ nầy cần phải được đặt vào folder C:\Windows\System của
computer kia. File "exe" của nhu liệu áp dụng, Help file và các
data file khác thì có thể được đặt vào một folder theo sự lựa
chọn của user. Thí dụ như C:\MyProgram.
Ngoài ra một số các
VB ActiveX components cần phải được đăng ký vào Registry của Windows,
và các tin tức về ODBC cűng cần được setup nữa.
Microsoft có cho ta
nhu liệu Package & Deployment Wizard để giúp ta cho vào (include) những
files nào ta cần trước khi nó bắt đầu công việc nén (compress) các
files lại thành những "cab" files (file có extension là
"cab") và sanh ra một SetUp.exe file với một SetUp.lst file.
Ta cần chạy file SetUp.exe ở computer kia để nó làm ba chuyện:
1.
Giản (uncompress) các Cab files ra thành những file rời.
2.
Copy các files ấy vào C:\Windows\System,
C:\MyProgram và những folder nhánh của C:\MyProgram nếu cần (td:
C:\MyProgra\images, C:\MyProgra\sound ..)
3.
Ðăng ký những VB ActiveX vào Registry
4.
Tạo ra Data Source Name (DSN) file
cho ODBC nếu bạn đang dùng.
Bạn có thể dùng
Notepad để mở SetUp.lst ra xem cho biết.
Nó chứa những dữ kiện cần thiết cho việc setup. Khi chạy setup
xong trên computer kia bạn sẽ thấy nó sanh ra một file mới tên
"st6unst.log" nằm trong cùng folder với nhu liệu áp dụng.
Sau nầy nếu bạn
muốn uninstall (lấy nhu liệu ra khỏi computer) thì vô Control Panel và
click Add/Remove Programs. Khi
dialog hiện ra với Tab Install/Uninstall chọn nhu liệu bạn muốn uninstall
rồi click nút Add/Remove. Windows
sẽ dựa vào st6unst.log để biết cần delete những files nào, ở đâu và
xóa tên các VB ActiveX trong Registry (deregister).
Thường thường các
"cab" files vừa vặn cở của dĩa floppy 1.44MB. Những nhu liệu VB
nhỏ chiếm ít nhất 4 dĩa floppy. Nếu
bạn chạy setup từ CD có khi thấy các file original hoặc không bị
compress hoặc được compress vào một cab file duy nhất rất lớn thay vì
nhiều cab files cở 1.44MB.
Lưu ý vài điểm
sau:
- Package
& Deployment của Microsoft có khi không register ActiveX component của
các công ty khác (third party software companies) khi ta chạy setup.
Bạn có thể thử tự register (manually) một ActiveX tên
"theVBActiveX.ocx" bằng
cách dùng Start | Run :
regsvr32
c:\Windows\System\theVBActiveX.ocx
- Nếu
Package & Deployment không register được các third party ActiveX như
Crystal Report, PDQComm, TrueDBGrid .vv.. thì thử dùng Wise Installation
hay InstallShield cho việc setup.
Trong khi Package & Deployment
của Microsoft dựa vào Project file để biết bạn cần những
ActiveX components nào thì Wise Installation có thể "watch" bạn
chạy thử nhu liệu áp dụng để biết bạn cần những thứ gì? Nó bắt
những Windows messages để biết việc đó, giống như công an xét
giấy những người đi vào một chỗ để biết có ai trong nhà.
Trong trường hợp nầy có khi nó bắt gặp cả Antivirus ActiveX
luôn, nên bạn nhớ delete component đó.
- Khi
InstallShield uninstall một nhu liệu nó vô ý remove tất cả các
ActiveX components mà lúc bạn register quên tuyên bố là
"shared" (được dùng
chung cho các nhu liệu khác). Có
thể các Components đó đã hiện diện và được register từ khuya rồi.
Nhưng khi InstallShield register chúng lại không nói là
"shared" nên sau nầy lúc uninstall hậu quả tai hại vô cùng.
- Khi
install một version mới của nhu liệu áp dụng của bạn hãy coi chừng
overwrite Access database file trên computer kia.
Lần đầu tiên khi bạn setup thì đặt một database trống, nhưng
sau đó khách hàng bắt đầu dùng và
cho nhiều dữ kiện vào database rồi.
Có khi nhu liệu SetUp cho bạn option là chỉ copy một file vào
khi nó chưa hiện hữu (exist).
- Nên
chạy nhu liệu áp dụng viết bằng VB6 trên WindowsNT hay Windows98
thay vì Windows95.
Debug một nhu liệu
Debug là sữa các lỗi lầm trong code sao cho nhu
liệu xử lý OK theo ý muốn không quá chậm hay té lên, té xuống.
Cách dễ nhất để loại trừ Bugs là ra siêu thị mua một lon thuốc hiệu
Bagon hay Mortein đem về xịt lên code.
Nói cho cùng, debug chẳng qua là giai đoạn sau cùng của công tác thảo
chương mà thôi. Do đó, để công việc debug được nhẹ nhàng ta phải
lưu ý đến cả những giai đoạn trước đó trong chu kỳ phát triển
nhu liệu.
Trước hết, giả sử ta biết rõ và chính xác mình
cần phải làm gì (Requirements Specification).
Trong giai đoạn thiết kế phải đặt ngay kế hoạch sẽ thử code cách
nào, khi nào và ở đâu. Lưu ý là hể ta bỏ qua việc kiểm soát
chỗ nào, nhu liệu sẽ té (crash) ở chỗ đó. Không có gì ngao ngán bằng
sở đánh thức mình nửa đêm vì nhu liệu thiết yếu phải chạy 24 trên
24 tiếng của ta vừa mới té một cái ạch. Dĩ nhiên, không ai dám nổi
nóng với chúng ta vì họ tùy thuộc vào mình, nhưng làm việc dưới
áp lực như thế ta cần phải tránh càng nhiều càng tốt.
Có một số lề lối căn bản (basic guideline) về
debug:
1. Ðặt kế hoạch Test thật chI tiết. Nghĩ đến mọi trường hợp như
user không biết cách dùng, hoặc dữ kiện bị hư (invalid) .vv.. Nếu cần
thử Propotype ( mẫu) thì nên thực hiện càng sớm càng tốt để yên tâm
là sau nầy code sẽ đạt đúng tiêu chuẩn thiết kế.
2. Sau khi code xong lần đầu, nhớ kiểm lại bằng cách đọc từng dòng
(gọi là Desk Check). Ðừng xem Clean Compilation (compile không bị Syntax
error) là hay ho gì rồi lập tức chạy thử ngay. Tốt nhất là cắt nghĩa
cho một partner hiểu code mình viết (gọi là Walk through). Desk Check là
cách chu đáo nhất để kiểm Logic, vì nhiều khi ta không thể nào khám
phá ra một lỗi trong logic bằng cách thử bình thường.
3. Giữ cho code gọn gàng, dễ hiểu và chú thích rõ ràng. Hãy nhớ rằng
trong tương lai người bảo trì code sẽ rủa bạn nếu code bạn viết quá
bí hiểm mà không giải thích. Mỗi Variable đều cần phải được đặt
tên hợp lý, cẩn thận. Ở đầu mỗi Sub hay Function giải thích mục
đích của routine, Input là gì, Output là gì, có dùng kỹ thuật lập trình
đặt biệt gì không. Bên trong Sub /Function giải thích từng bước việc
xử lý trừ khi quá hiển nhiên. Mỗi Logical Test Condition đều phải
được thử, chớ bỏ qua câu nào vì nghĩ rằng nó quá đơn giản. Ðể
breakpoint ở những chỗ ấy để kiểm value của các variables xem đó
đúng như đã định không.
4. Luôn luôn dùng Option Explicit trong mỗi Form/Module và tránh Declare
Variables bừa bãi. Giảm thiểu việc dùng Global Variables để ít bị ngạc
nhiên không biết process nào đã thay đổi value của variable bạn đang
dùng. Nếu phải làm đi làm lại một chuyện thì có lẽ bạn có thể
thay thế nó bằng một Sub/Function. Nếu hai Objects làm nhiều chuyện tương
tự thì xem có thể gói các Sub/Functions và Data Variables thành một
Class không.
5. Trong mỗi Sub/Function đều nên có Error Handler để khám phá ngay bất
trắc. Chỉ nên để câu 'On Error Resume Next' sau khi đã debug xong xuôi
và biết chắc có thể bỏ qua trường hợp gặp error trong tương lai.
6. Nếu phần code bạn viết sẽ được ráp vào một phần khác thì test
chỗ ráp nhau (interface) bằng cách kiểm các Output Values của code bạn
và Emulate (giả bộ cho vào) Input Values từ phần code kia. Nếu cần làm
Stress Test (cho nhiều chuyện xãy ra xem code có chạy nhanh đủ và đúng
không) thì nên thực hiện càng sớm càng tốt.
7. Test nhu liệu trên một computer với MSWindows vừa cài đặt và không
có gì khác, ngay cả Antivirus, để khỏi phải nhức đầu vô lý khi
nguyên nhân code gặp khó khăn là vì mất Windows DLL hay bị nhu liệu
Antivirus can thiệp.
Và sau cùng, giữ bình tỉnh, đừng nổi nóng với chính bạn hay với ai
khác. Hãy nhớ rằng bạn là một Professional, thả lỏng (relax) và giữ
đầu óc mình minh mẩn. Nếu hoàn cảnh bi đát quá thì hãy bắt chước
tôi - cầu nguyện xin Chúa giúp đở.
Các giai đoạn trong chu kỳ phát
triển một nhu liệu (Development Cycle)
Ðại khái các giai đoạn chính của chu kỳ phát triển một nhu liệu là:
1. Muốn làm gì? (Requirement Specifications): Giai đoạn nầy khách
hàng bàn với software consultant để bài tỏ nguyện vọng của mình. Khách
hàng chỉ nói tổng quát, consultant phải phỏng vấn nhiều người trong sở
để có một hình ảnh đầy đủ về vấn đề.
2. Thiết kế (Design) : Từ Requirement Specifications bước qua giai
đoạn Thiết kế. Lúc nầy sẽ thấy có nhiều điểm không được nêu
rõ trong Requirement Specifications nên cần làm cho sáng tỏ
(clarification). Công việc nầy do Systems Analyst thực hiện. Nếu dự án
lớn thì có Software Architect thiết kế tổng quát trước khi chia ra các
Team Leaders ( thường thường là Systems Analysts). Trong giai đoạn nầy có
khi phải làm Prototype (thử mô hình mẫu) để biết chắc kỹ thuật mình
dùng có đủ khả năng và thích hợp với nhu cầu dự án không.
Thiết kế là giai đoạn quan trọng nhất trong chu kỳ phát triển một
nhu liệu. Chẳng những ta nghĩ cách xây dựng nhu liệu, mà còn kế hoạch
chi tiết cách thử lúc nào, ở đâu trong code. Ta phải tưởng tượng
mọi cảnh huống bất thường (unusual scenarios) nhưng có thể xãy ra để
liệu cách đối phó.
3. Thảo chương (Coding hay Implementation): Ðây là giai đoạn thảo
chương và debug. Trong phần Debug thì có Unit Test (thử từng bộ phận)
và Integration Test (thử chung). Mỗi khi có sữa đổi một chút thì phải
thử lại nhiều thứ nên nếu có thể viết Test Script để tự động hóa
công việc thử nầy ( gọi là Regression Test) thì tiết kiệm rất nhiều
thì giờ. Nếu nhu liệu phải phản ứng nhanh chóng (good response) trong
khi chạy Real-time thì phải thử nó trong hoàn cảnh phải giải quyết
nhiều thỉnh cầu cùng một lúc (gọi là Stress Test).
4. Chạy thử (Acceptance Test): Ở tại sở của khách hàng, Software
consultant chứng kiến các giai đoạn chạy thử để xem nhu liệu xử lý
mọi chuyện đúng như liệt kê trước đây. Các công chuyện xử lý chạy
có nhanh đủ không, nhất là trong trường hợp nhu liệu phải giải
quyết rất nhiều thỉnh cầu cùng một lúc. Trong những hoàn cảnh bất bình
thường, nhu liệu có đứng vững không. Nếu dự án lớn, trước
Acceptance Test còn có thêm một giai đoạn gọi là Factory Test khi
Software Consultant đến tận công ty ta để chứng kiến ta chạy thử.
5. Cho dùng (Commissioning, Roll-Out): Khi cho dùng rồi là bắt đầu
giai đoạn Bảo đảm (Warranty) và Bảo trì (Maintenance). Bảo trì là thăm
viếng lại nhu liệu để chửa trị Bug (fixing bugs) hay sữa đổi
(modification) hay làm thêm (enhancement). Lúc bấy giờ bạn sẽ thấy giá
trị của một nhu liệu được chú thích tỉ mĩ. Thường thường nhu liệu
ta bảo trì là do người khác viết hoặc do chính mình viết từ lâu rồi,
không còn nhớ nữa, nên nếu nó có documentation và được chú thích
rõ thì sẽ dễ dàng cho công việc rất nhiều.
Khi lảnh một Job nhỏ, có khi ta không chú ý nhiều đến giai đoạn
Requirement Specifications. Sau nầy lúc đã viết code rồi mới khám phá
ra việc mình làm không đúng như điều khách hàng muốn thì rất phiền.
Nếu Specifications đã viết rõ ràng thì ta có thể xin thêm tiền
thay đổi (variation), nhưng có khi khách hàng vẫn trách là ta không
chuyên nghiệp (professional) và có thể mình mất khách trong tương
lai.
|