#1 enaknya sapa ya..
yah dimana ada sinyal handphone..

[ Jumat, 16-07-2010 15:50 WIB ]

yah saya tidak akan berkomentar banyak.. yang namanya hidup tuh sering terjadi kesalahan maupun kesalahpahaman..

Kepada pihak GT : yah mungkin dari hal ini bisa digunakan sebagai saran dan kritik yang membangun sehingga kedepannya dapat memberikan produk yang lebih baik dalam segala bidang yang telah dibuat.

Kepada Admin : jika anda tidak terima ya sudah anda usul saja ke bagian akademik maupun perpus untuk membuat web portal yang sesuai dengan keinginan anda.. kalo anda tidak suka dengan apa yang sudah ada itu juga sah-sah saja.. jadi ya saya sarankan anda membuat yang sesuai dengan keinginan anda kemudian usulkan saja ke universitas sapa tau diterima.. ekekekeke..

yang saya tekankan disini adalah terkadang adakalanya menurut kita itu yang terbaik buat klien. namun, ada kalanya klien yang meminta sesuatu yang menurut kita cukup buruk. Dan di dunia BISNIS bukan dunia PROGRAMMING, pembeli adalah rajanya.. bukan bermaksud ingin membenarkan pihak GT.. namun adakalanya begitulah jika kita memasuki dunia bisnis.. jadi lebih baik saling melengkapi antara satu dengan yang lain..

hidup ada salah dan ada benar.. mungkin di satu sisi benar.. namun disisi lain salah, alangkah baiknya jika hal tersebut dirundingkan untuk dicari penyelesaiannya bukan dicari kesalahan masing2..

note: jika admin kurang puas dengan tim GT silahkan beri kritik dan saran, Namun sebelum memberi kritik dan saran yang sekiranya nantinya bisa manyinggung, tolong diklarifikasi dulu ke pihak klien..

terimakasih..

BROWSER: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100504 Firefox/3.5.10 | IP: 125.163.252.14

#2 enaknya sapa ya..
yah dimana ada sinyal handphone..

[ Jumat, 16-07-2010 15:46 WIB ]

yah saya tidak akan berkomentar banyak.. yang namanya hidup tuh sering terjadi kesalahan maupun kesalahpahaman..

Kepada pihak GT : yah mungkin dari hal ini bisa digunakan sebagai saran dan kritik yang membangun sehingga kedepannya dapat memberikan produk yang lebih baik dalam segala bidang yang telah dibuat.

Kepada Admin : jika anda tidak terima ya sudah anda usul saja ke bagian akademik maupun perpus untuk membuat web portal yang sesuai dengan keinginan anda.. kalo anda tidak suka dengan apa yang sudah ada itu juga sah-sah saja.. jadi ya saya sarankan anda membuat yang sesuai dengan keinginan anda kemudian usulkan saja ke universitas sapa tau diterima.. ekekekeke..

yang saya tekankan disini adalah terkadang adakalanya menurut kita itu yang terbaik buat klien. namun, ada kalanya klien yang meminta sesuatu yang menurut kita cukup buruk. Dan di dunia BISNIS bukan dunia PROGRAMMING, pembeli adalah rajanya.. bukan bermaksud ingin membenarkan pihak GT.. namun adakalanya begitulah jika kita memasuki dunia bisnis.. jadi lebih baik saling melengkapi antara satu dengan yang lain..

hidup ada salah dan ada benar.. mungkin di satu sisi benar.. namun disisi lain salah, alangkah baiknya jika hal tersebut dirundingkan untuk dicari penyelesaiannya bukan dicari kesalahan masing2..

note: jika admin kurang puas dengan tim GT silahkan beri kritik dan saran, Namun sebelum memberi kritik dan saran yang sekiranya nantinya bisa manyinggung, tolong diklarifikasi dulu ke pihak klien..

terimakasih..

BROWSER: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.10) Gecko/20100504 Firefox/3.5.10 | IP: 125.163.252.14

#3 Putut
Jgj

[ Selasa, 23-02-2010 03:26 WIB ]

Kenapa field penerbit di digilib tidak dinormalisasi oleh developer?
Sebelum meng-hakimi benar/salah, parah/tidak bisa ditanyakan alasannya ke developernya.
Tentunya developer punya alasan kenpa field penerbit tidak dibuat table master. Masalah perlu atau tidak penerbit punya table master itu relatif dan punya konsekuensi lebih dan kurangnya.
Misalnya data yg masuk digilib dikonversi dari db yg sudah ada (dbase) dan data sudah tidak beraturan dg berbagai macam sebab. Sedangkan user tidak mau entri data lagi krn jml data ribuan. Kalo dibuat table master penerbit bisa jadi data tidak valid juga. Otomatis akan ada 2 master penerbit 'andi offset' dan 'andi ofset'
Apa krn user gag mau memperbaiki data agar bisa dibuat table master terus developer yg harus menanggung dosa.... (kacian deh jd developer...)

Kalo memang UNP butuh master penerbit agar tidak salah ketik dan bisa membuat lapoaran jml buku tiap penerbit, kenapa tidak diminta sejak awal shg bisa dilakukan kustomisasi. Mungkin UNP tidak butuh tbl master penerbit (bisa ditanyakan ke pengelola sipus dan tim IT UNP).

Kalo memang dikehendaki normalisasi bisa saja dilakukan saat ini, toh itu hanya master penerbit, mungkin hanya table buku saja yg reference ke tbl master penerbit. Cuman perlu ditanya apa user mau memperbaiki data2 yg tidak valid lebih dulu.. hik hik itu dah bukan tugas developer tentunya..

Maaf, sebelum mencela ada baiknya konfirmasi terlebih dulu ke pihak2 terkait shg informasi yang ditulis itu baik dan bersifat membangun.

Maaf jika tidak berkenan

BROWSER: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0. Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) | IP: 114.58.220.65

hahaha....seharusnya developer lebih kritis...sama aja klo disuruh terjun jurang...ya terjun dulu baru pikir akibatnya...hahahaha....developer kan bisa kasih saran sama user...
masa disuruh bikin barang tapi ga ditanya2 dulu dan klo dapat dikasih saran seperti apa bagus barang yang akan dibikin...
yang namanya user...ya jelaslah ga tau teknis2 kayak gitu...yang penting bagi user...bisa melakukan searching aja ya udah...nah sekarang itukan tanggung jawab moral developer, sebagai developer kan ngerti prinsip2 perancangan yang baik...
klo user mana ngerti...
dasar...hahahaha...

reply to

#4 Putut
Jogja

[ Jumat, 19-02-2010 15:53 WIB ]

mbah e digilib pada komen semua..

dikuliah pasti diajari normalisasi
tp sepertinya tidak pernah diajari tentang teknik Full Text Search.

Ada baiknya pak/bu dosen juga diminta ngasih kuliah ttg Full Text Search, jangan terlalu men-dewa-kan normalisasi krn tidak semua desain table harus normal.

Digilib UNP menghasilkan output spt itu krn model pencariannya pakai Full Text Search dan gag pakai like '%%'.

Coba masukkan keyword judul 'kina', rasakan bedanya kalo dicari diperpustakaan ternama di Indonesia

BROWSER: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0. Gecko/2009032609 Firefox/3.0.8 (.NET CLR 3.5.30729) | IP: 125.163.236.131

#5 nyate ngisor ringin
jogja

[ Jumat, 19-02-2010 15:22 WIB ]

yg nggak bisa tuh opertor-nya, masak ngentri data aja bisa gonta ganti...

BROWSER: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1. Gecko/20100202 Firefox/3.5.8 | IP: 118.97.48.162

#6 nyate ngisor ringin
jogja

[ Jumat, 19-02-2010 15:20 WIB ]

yg nggak bisa tuh opertor-nya, masak ngentri data aja bisa gonta ganti...

BROWSER: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1. Gecko/20100202 Firefox/3.5.8 | IP: 118.97.48.162

ngomong bertanggung jawab yah.. tersinggung ntar yang ngentri, anda bisa ngentri data buku ribuan pas ngetik penerbit itu-itu aja, gak salah-salah? apa gak bete tuh ngetik itu-itu trus ratusan bahkan ribuan kali kan mending combo box

#7 sugry
jogja

[ Jumat, 19-02-2010 11:44 WIB ]

normalisasi bisa juga dilakukan pada basis data yang sudah jadi karena ada perkembangan bisnis proses dalam organisasi pemakai aplikasi.
jadi menurut saya kasus informasi penerbit ini bkn masalah fatal, bisa saja kalau mau dilakukan pemisahan informasi penerbit dalam tabel baru.

penerbit adalah salah satu atribut dari buku,
sehingga informasi ini melekat pada entitas buku artinya tidak ada informasi penerbit kalau tidak ada data buku.
masalahnya sekarang seberapa penting informasi penerbit dalam bisnis proses perpustakaan,
kalau informasi penerbit dianggap penting sehingga keberadaanya secara tunggal(tidak melekat pada entitas buku) itu penting,
menurut saya perlu dibuatkan tabel terpisah(bukan hanya sekedar atribut yang menempel dibuku).
perlu ada pengelolaan informasi terpisah terhadap penerbit barangkali karena ada kerja perpustakaan dengan penerbit dalam proses pengadaan buku,
sehingga tanpa ada informasi buku yang diterbitkan oleh suatu penerbit penerbit itu perlu didata.karena perpustakaan membutuhkan informasinya.

cmiw!

BROWSER: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3) Gecko/20091020 Ubuntu/9.10 (karmic) Firefox/3.5.3 | IP: 118.97.8.22

menambahkan tabel penerbit di akhir wah pasti njelimet mas. dalam desain database kan gak pake "kalau kalau nanti" itulah makanya di normalisasi karena untuk pengembangan nanti memudahkan. misal untuk di pake sendiri di pc rumah tapi kalau di klien?

bukan mendewakan normalisasi tapi konsepnya kan memang gitu. kalau untuk memudahkan searching kan bs pake cara tambah kolom atau tabel baru bantuan. gak harus melanggar konsep trus nanti kesusahan merubah di tengah jalan.kalu gak di normalisasi ya bukan database pake 1 tabel aja heheh mudah

#8 Heribertus
Jogja

[ Jumat, 19-02-2010 11:39 WIB ]

Setuju dengan pendapat pak Urip, isi data sama sekali tidak ada sangkut pautnya dengan NORMALISASI.

Normalisasi berhubungan erat dengan masalah struktur tabel (field, constraint, key, dll). Sedangkan kasus yang dihadari UNP ini adalah ke-TIDAK-KONSISTEN-an dalam proses entri DATA (bukan STRUKTUR TABEL sekali lagi).

Untuk menjaga konsistensi data memang bisa dipaksakan dengan model entri ComboBox, tetapi disisi lain kadang ada komentar dari calon user "WAH kalau pakai ComboBox harus pakai mouse, lambat Pak"

Oya, kalau mau dicek apakah database tersebut 1NF, 2NF, 3NF silakan dilihat DFDnya
Bisa kan?!?

BROWSER: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1. Gecko/20100202 Firefox/3.5.8 (.NET CLR 3.5.30729) | IP: 202.169.56.98

tujuan NORMALISASI adalah mencegah REDUDANSI DATA, Mencegah INKONSISTENSI DATA dll. tuh kan gak ada hubungannya...

Gimana tukang entri mau KONSISTEN, wong yang mau di entrikan RIBUAN buku (38703) berapa kali coba dia ngetik "andi offset" gimana gak offset tuh jarinya hehehehe

ComboBox lama? mana lebih cepat ngetik "Elex Media Komputindo" dari ketik E di kibor trus pilih "Elex Media Komputindo" hayooo... lagian kan sekarang ada AUTO SUGGEST(pake AJAX gitu lho)

tidak bisa mas DFD itu DATA FLOW DIAGRAM mungkin maksudnya ERD yah ENTITY RELATIONSHIP DIAGRAM hehehe
baru bisaaa...

#9 paydjo.Net
-

[ Kamis, 18-02-2010 15:27 WIB ]

apakah normalisasi itu segalanya ?
mungkin pak dosen disuruh menjelaskan denormalisasi

yang menggelitik kalimat "tadi juga sempat cek file css nya ada copyleft Herman Saksono, Gamatechno 2006. sekarang sudah 2010"

apa hubungan antara program dengan css?
misal cssnya selalu menunjukkan NOW() apa trus programnya up2date ?

bisa jadi programnya baru tetapi memanfaatkan tampilan sebelumnya, bisa jadi programmernya lupa belum mengupdate informasi file

lagian kalo blogger.com (yg jelas2 punya google) template css-nya sejak 2005 apa ya trus kita mikir google tuh cemen banget ?

BROWSER: Mozilla/5.0 (X11; U; Linux i686; en-US) AppleWebKit/532.9 (KHTML, like Gecko) Chrome/5.0.307.7 Safari/532.9 | IP: 202.43.95.34

Denormalisasi? dah saya posting tuh.kl gak dinormalisasi enakan pake MS excel aja

pake NOW() wah hebat CSS bisa pake NOW() ajarin yah mas tak buat semua CSS saya DATETIME ama sekon2nya sekalian

soal tahun ya kalo liat itu kesimpulanya cssnya pake yg lama. ya minimal kan kalo ada klien baru dibuatkan dunk tampilan baru, walaupun DB sama yg lain masih pake yg lama

tahun lama maksudnya bukan cemen tapi komen di css ga dirubah kan terlalu gimanaaa... gitu . GT kan bukan pemain baru dah professional dah nasional mungkin internasional. komen teman2 unp sama unand kan cuman beda template doank hehehe

#10 urip
jogja

[ Kamis, 18-02-2010 07:43 WIB ]

maaf... sebelumnya ini hanya pendapat pribadi saya. menurut saya itu bukan masalah normalisasi database. Dalam proses development sering kita dihadapkan pada masalah fleksibilitas yang diminta oleh client.

dalam hal ini perlu di cek dalam form input, apakah berupa inputan teks atau tinggal pilih (drop down). untuk teks jelas pengisian tergantung yang mengisi. kalau dalam bentuk pilihan pun pengisian data referensi tergantung kejelian dari yang mengisi.jadi menurut saya tidak tepat menilai normal atau tidaknya database dari data yang tertampil.

normalisasi lebih tepat dilihat dari struktur dan relasi antar tabel-nya. duplikasi data bisa dihindari dengan penggunaan id yang unik mis. nim atau nip atau nidn. tanpa id unik tersebut tentu data bisa duplikat karena database tidak bisa menangkap misal antara Andi dan andi adalah sesuatu yang sama. Dan dalam proses development suatu program belum tentu database yang normal adalah baik, karena sering bersinggungan dengan kecepatan akses data. untuk itu perlu kombinasi teknik pemrograman dengan desain database yang optimal (lebih ke optimal bukan normal he..he...).

demikian pendapat saya, mohon maaf kalau ada yang tidak berkenan...

BROWSER: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1.7) Gecko/20091221 Firefox/3.5.7 | IP: 125.163.241.252

yup benar juga saya juga sering mengalaminya tapi gini dalam pembuatan database sederhana perpustakaan saja field2 yang akan ditulis berulang2 akan di pecah menjadi tabel baru dan menempatkan foreign id nya di tabel utama.

masalah kecepatan tentu saja karena akan mengqueri nama ke tabel master penerbit. tapi apakah ini memberatkan sistem?gak terlalu lah. query dan script bisa di optimalkan termasuk mysqlnya .

kalau ditanya pun klien pasti suka memilih penerbit dari pada mengetikkannya lagian jumlah penerbit kan gak sebanyak buku hal lain mengakalainya... database penerbit kan ada? ada ikatan atau persatuannya. toh ntar itu-itu juga penerbitnya. dalam sebulan gak akan sampe ratusan penerbit baru. jadi sebeanrnya ini memudahkan dan rapi. kalau kita mengorbankan database demi kemudahan otomatis untuk pengembangan kita telah menutupnya. akan sangat susah nantinya mengubah tabel2 lagi setelah database terisi jutaan entri.

karena kalau dalam hal buku yang sering ditanya adalah?

#berapa buku terbitan penerbit ini?
#berapa buku yg ditulis orang ini?
#berapa buku terbitan ini dan ditulis orang ini
dll(laporan gitulah..)

tapi kalau tujuannya hanya cari judul buku saja sekedar informasi judul2 buku gpp, accepted

kalkulasi data akan bagus. kalau sekarang tentu kalau mau mencari hal di atas pake query LIKE:
... WHERE penerbit LIKE %"andi"% gimana kalau ada penerbit anditama, andika, kickandi srikandi andia andie dll?(penerbit andi jadi ngiklan neh hehehe)

apakah hasilnya nanti dapat di percaya?

saya juga diatas pendapat pribadi. kalau ada yang salah mohon pencerahan. bukankah untuk masalah kandungan kita percaya doker kandungan... bukan tukang bangunan piss