Sedot yukkk
Cheat Point Blank Terbaru 2012
Fitures+Keys:
[-]Fires speed Effect
- Brutal ALLWeapon
- SG brytal
- AWP brust Dragown Now
- M speed auto ON
[-]Speed Hack | Cheat LAri(F11 On|F12 Off)
[-]Aimbot Headshot Datar|Beta(F6 On|F7 Off)
[-]Invisible Kill , Bisa Bunuh Musuh Saat bru respon(Auto ON)
[-]Pasbom 1 Hit : Insert
[-]Bullet : Peluru jadi Dewa Gak kelihatan sama musuh sama sekali(Insert)
(darah habis tapi kayak gak ada yang nembak)
Cheat Dengan PKL injection V1/Injector Buatan pertama saya pada tahun 2010, base dari bang Erge
Tutorial pakai Cheat+Injector Pertama Saya :
[-]Buka PB launcher yah,,
[-]Buka Injection nya (Biasanya tekan 2x)
(Yang peertama First,,,/sedang mempersiapkan) buka yg ke dua ok ok saja
[-]start pb
[-]Nunggu Inject bergetar ke pojok kanan atas monitor
[-]tekan DLL select For Inject
[-]Cari DLLnya
[-]Lalu tekan inject
[-]Resume
Auto headshot
[-]Capslock On | Shift Off
1.On Kan di Dalam Room , setelah loe respon
2.Off kan saat mati
3.Jangan pakai kekeran |Incaran (biasanya sih Klik kanan) >> settingan manual pertama kali main pb , ntar layarnya Hitam
NB :
[-]Kalau BT coba gunakan metode Flashdisk
[-]Harus install Net Framework danVcredist_x86
[-]Download D3DX9_38.dll
[-]Sebelum menggunakan cheat sebaiknya scan dulu gan
Cheat Point Blank 8 Januari 2012 Headshot + Damage 70% Up + All Weapon Cheat PB 08012012 [download]
Sabtu, 07 Januari 2012
Rabu, 04 Januari 2012
Graffiti Itu Apa Sich + Contohnya Di game gta iv
TAu Gak Graffitti itu apa ??
----Ini Contohnya Di Game GTA IV
AKU KASIH TAU YACH GRAFFITTI ITU APA
GRAFFITI ITU : Dinding-dinding di sepanjang Jalan Tamblong yang semula putih bersih, kini sedikit berwarna. Kini, selain dipenuhi oleh “flyers” dan poster yang ditempel sembarangan, coretan-coretan jahil yang dibuat dengan cat semprot, juga mulai memenuhi dinding-dinding tersebut. Bikin mata orang-orang yang lalu lalang, mau nggak mau seperti tersihir untuk melihat atau sekadar melirik. Katanya sih, itu adalah graffiti, coretan yang dibuat untuk mengekspresikan kebebasan.
----Ini Contohnya Di Game GTA IV
AKU KASIH TAU YACH GRAFFITTI ITU APA
GRAFFITI ITU : Dinding-dinding di sepanjang Jalan Tamblong yang semula putih bersih, kini sedikit berwarna. Kini, selain dipenuhi oleh “flyers” dan poster yang ditempel sembarangan, coretan-coretan jahil yang dibuat dengan cat semprot, juga mulai memenuhi dinding-dinding tersebut. Bikin mata orang-orang yang lalu lalang, mau nggak mau seperti tersihir untuk melihat atau sekadar melirik. Katanya sih, itu adalah graffiti, coretan yang dibuat untuk mengekspresikan kebebasan.
Graffiti yang berasal dari bahasa Yunani “graphein” (menuliskan), diartikan oleh wikipedia.org sebagai coretan pada dinding atau permukaan di tempat-tempat umum, atau tempat pribadi. Coretan tersebut, bentuknya bisa berupa seni, gambar, atau hanya berupa kata-kata.
Penggunaan cat semprot untuk bikin sebuah graffiti, sudah mulai dikenal di New York, akhir tahun 60-an. Coretan pertama dengan cat semprot, dilakukan pada sebuah kereta subway. Seorang bernama Taki yang tinggal di 183rd Street Washington Heights, selalu menuliskan namanya, entah itu di dalam kereta subway, atau di bagian luar dan dalam bis. Taki183, gitu bunyi tulisan yang ia buat menggunakan spidol. Taki ini seperti ingin nunjukkin identitas dirinya. 183 yang ia tulis setelah namanya, nunjukkin tempat tinggalnya.
Gara-gara coretannya tersebut, orang-orang di seluruh kota jadi kenal dengan Taki, lewat coretan-coretan misteriusnya. Di tahun 1971, mister Taki ini diinterview oleh sebuah majalah terbitan New York. Dari situlah, kepopuleran Taki diikuti oleh anak-anak seluruh New York. Anak-anak ini tertarik karena kepopuleran bisa diperoleh dengan hanya menuliskan identitas mereka –disebut juga tagging– pada bus atau kereta yang melewati seluruh kota. Semakin banyak nama atau identitas seorang anak, sudah pasti ia akan semakin populer.
Setelah spidol, media yang kemudian biasa digunakan adalah cat semprot, yang dipakai untuk nge-bomb (istilah untuk menyemprot) bagian luar kereta. Karena semakin banyaknya orang-orang yang bikin tagging, nggak heran kalau setiap writers, pengen punya style sendiri. Dari situ, mereka nambahin warna-warna yang eyecatching, efek-efek khusus, bahkan mereka mencoba untuk menuliskan namanya lebih besar. Dengan bantuan cat semprot, pengerjaan graffiti ini lebih cepet beres.
Makanya, untuk mengantisipasi tagging yang mulai mewabah, pihak kepolisian setempat sampai melarang penjualan cat semprot pada anak-anak di bawah umur. Saking banyaknya pelaku graffiti, di Meksiko pun diberlakukan aturan serupa. Bahkan, setiap pembeli cat semprot harus menunjukkan identitas yang jelas dan menyertakan alasan untuk apa cat semprot itu digunakan.
“Bikin graffiti di public space itu seperti punya gengsi sendiri. Selain itu adrenalin bakal terpacu, karena takut dikejar polisi atau gangster,” kenang Roy, yang pernah ke-gap sama gangster pas bikin graffiti di public space. Yup. Selalu public space yang menjadi sasaran para seniman jalanan ini untuk berkreasi. “Sebagian orang ada yang nganggep graffiti sebagai karya seni, tapi nggak sedikit juga yang bilang kalau coretan-coretan itu malah ngerusak,” kata Radi, seorang mahasiswa seni lukis Fakultas Seni Rupa dan Desain (FSRD) ITB.
Jika graffiti ini dilakukan tanpa seizin pemilik tempat, perbuatan ini dapat dikategorikan sebagai tindakan vandal. Mungkin banyak di antara Belia yang belum tau apa itu arti vandalisme. Vandalisme bisa diartikan sebagai tindakan yang merusak properti orang lain. It means, graffiti atau mural yang dilakukan tanpa izin di tempat-tempat umum, bisa dikategorikan sebagai vandalisme. Sementara, banyak orang yang berpendapat, kalau graffiti di dinding-dinding jalan, masih lebih baik daripada dinding-dinding tersebut kotor, tidak terawat, dan penuh dengan tempelan flyers atau brosur-brosur yang nggak penting.
Kalau Belia lewat Jalan Siliwangi, mata terasa lebih segar karena ngeliat mural di sepanjang dinding jalan, pasti setuju kalau karya seni yang seperti itu bukan termasuk perbuatan vandal. “Iyalah. Soalnya mural di Siliwangi itu legal kok. Pihak Pemda, sekitar dua tahun lalu, pernah ngasih proyek itu buat kita,” kata Yogie, yang bareng Radi, jadi konseptor pembuatan mural tersebut.
Mural yang berarti lukisan pada permukaan yang lebar, memang terasa lebih legal dibandingkan dengan graffiti yang berkesan liar. “Bedanya sih, mungkin hanya pada medianya aja ya. Kalau graffiti banyak pake cat semprot, sementara mural make cat tembok. Kalau nyeni atau nggaknya ya, tergantung yang liat. Nggak ada parameter khusus,” lanjut Yogie.
Senada dengan Yogie, Roy pun bilang kalau bagus atau jelek itu relatif. “Susah sih, kalau mau bilang bagus atau jelek. Isi tulisan-tulisannya, mungkin dibilang jelek tapi malah keinget terus sama yang baca. Tapi graffiti di film Alexandria saya bilang butut, sementara orang lain mungkin bilang itu bagus,” tandas Roy sembari memberi contoh.
Legal atau nggaknya sebuah karya di jalanan, bagi Roy yang juga lulusan FSRD ini, tetap dinilai sebagai sebuah karya. “Di Jogja, graffiti dan mural malah dilegalkan. Pemerintah setempat ngebolehin, bahkan menyediakan lahan untuk para street art berkarya. Sementara di Bandung, belum ada pelegalan seperti itu. Beda ceritanya kalau lu punya duit,” katanya sedikit berapi-api.
Alih-alih sebagai tindakan vandal, graffiti, mural, tagging, dan sebagainya adalah merupakan kebebasan berekspresi. Tetapi, kebebasan berekspresi saat ini masih didominasi oleh kaum berduit, yang mampu membeli tempat untuk menumpahkan kreativitasnya. Sementara para seniman jalanan, mesti sembunyi-sembunyi atau malah kejar-kejaran dengan pihak aparat hanya untuk berkreasi. “Seniman yang jelas-jelas bikin karya di privat place aja sempat dibakar aparat, apalagi street art yang berkarya di public space,” lanjut Roy.
Setiap seniman punya style masing-masing untuk mengekspresikan karyanya. Makanya, tidak sedikit seniman yang malah “bersaing” untuk bisa menciptakan karya bagus di tempat yang lebih lebar, misalnya, atau untuk meraih kepopuleran. Selain saingan, ada juga proses pembelajaran yang diturunkan dari seniman yang tergolong kelas senior kepada juniornya. “Yang baru belajar biasanya jadi kenek dulu. Kerjaannya masih sebatas ngewarnain, atau bantuin yang gampang. Seniornya, yang bikin sketsa di kertas dan di dinding,” ujar Roy.
Proses bikin graffiti atau mural kurang lebih sama. Pertama, sketsa dibuat pada kertas, lalu kemudian sketsa tersebut dipindahkan ke dinding. “Yang lebih gampang sih, si sketsa udah “ditembakkin” pake proyektor, jadi nggak perlu bikin sketsa di tembok. Tapi, ya, gengsinya mungkin lebih turun kalau dibantu pake proyektor,” kata Roy lagi.
Nggak sedikit duit yang dikeluarin untuk bikin satu graffiti atau mural. “Untuk bikin gambar di tembok yang berukuran sedang, bisa habis kira-kira dua puluh kaleng cat semprot. Sementara ini (garasi distro yang sedang dibuat graffiti-red) abis 40an kaleng,” jelas Roy.
Sayang banget kan kalau hanya ngabisin cat semprot untuk tulisan-tulisan yang nggak ada maknanya, atau malah bikin sebel orang yang liat. Radi dan Yogie pun punya pendapat serupa. “Kalau mau bikin graffiti atau mural, mending sekalian yang edun, daripada hanya tulisan atau gambar yang teu kaharti.”katanya.
Graffiti sampai kapan pun mungkin bakal jadi kontroversi. Di satu pihak bakal bilang kalau graffiti itu perbuatan vandal, tapi pihak yang lain mengartikan seni, kebebasan berekspresi. Lain halnya di Yogyakarta, yang setiap seniman bebas berkarya, pihak pemerintah pun nggak perlu repot-repot ngejar-ngejar seniman yang bandel. Karya yang nggak bikin sakit mata, lebih-lebih sakit hati, tentu bakal diapresiasi dengan baik oleh masyarakat. Kebebasan berekspresi bisa saja diredam, tapi nggak bisa dihentikan
dari berbagai sumber
Sumber Gambar : Google
Cheat GTA IV
The cheat GTA IV
Bisa Nya Di Gta IV
Ketik Di Ponsel Niko
Full armor & Health : 362-555-0100
Full armor & Health & Senjata : 482-555-0100
Lagu Cheat Disimpan (Gratis) : 948-555-0100
Tambah Wanted Level : 267-555-0150
Hapus Wanted Level : 267-555-0100
----------------------------------------------
( Cheat Kendaraan______________)
Spawn Helikopter Polisi : 359-555-0100
Spawn Burrito : 2826-555-0150
Spawn Cosgo
noscenti : 227-555-0142Spawn Comet : 227-555-0175
Spawn Double T : 242-555-0125
Spawn : FBI Bufallo : 227-555-0100
Spawn Hakuchou : 242-555-0199
Spawn Hexer : 242-555-0150
Spawn Innovation : 242-555-0100
Spawn Jetmax (Kapal Laut) : 938-555-0100
_____________________________
(_________SENJATA_______)
Senjata Tier 1 : 486-555-0100Isi Senjata Tier 1 : bisbol, pistol, shotgun, MP5, M4,sniper, RPG, dan granat.
Senjata Tier 2 : 486-555-0150
Isi Senjata Tier 2 : pisau, bom APi, pistol, shotgun, Uzi, AK47,sniper, dan RPG.
ayoooo sedot GTA IV INDONESIA MOD
SEDooooTTT yukkk Link nya
1.GTA IV INDONESIA MONEY
AKu Cinta Rupiah hahahahah
Download : DISINI
2.Pertamina Mod (BETA)
hahahaha ayo isi bensinmu disini
LINK: DISINI
3.indonesia High School Skin
hohohohoh ada juga yach baju sekolah di gta iv
LINK: DISINI
4.Gayus Bellic Ver.2
hahahaha sampai ada juga di game (gta iv) koruptor (Gayus) hahahah
LINK: DISINI
5.bom buku V.2
Download DISINI
Kalo mau download Warung BURJO (Bubur Kacang Ijo) DISINI
Dan kalo yang mau download Telkomsel Van DISINI
Dan kalo mau download Polisi indonesia (Bukan Mobil Tapi Orang) DISINI
Dan kalo mau download Ford F150 DISINI
UDAH SEGITU DOANG DAN KLO INDONESIA MOD (BANYAK) DISINI
Kalo Mau Di web GTA GAMING DISINI
Kalo mau Di web GTA 4-MODS DISINI
CUMA SEGITU TAPI BANYAK SUSAH CARI NYA
Terima Kasih
1.GTA IV INDONESIA MONEY
AKu Cinta Rupiah hahahahah
Download : DISINI
2.Pertamina Mod (BETA)hahahaha ayo isi bensinmu disini
LINK: DISINI
3.indonesia High School Skinhohohohoh ada juga yach baju sekolah di gta iv
LINK: DISINI
4.Gayus Bellic Ver.2hahahaha sampai ada juga di game (gta iv) koruptor (Gayus) hahahah
LINK: DISINI
5.bom buku V.2Download DISINI
Kalo mau download Warung BURJO (Bubur Kacang Ijo) DISINI
Dan kalo yang mau download Telkomsel Van DISINI
Dan kalo mau download Polisi indonesia (Bukan Mobil Tapi Orang) DISINI
Dan kalo mau download Ford F150 DISINI
UDAH SEGITU DOANG DAN KLO INDONESIA MOD (BANYAK) DISINI
Kalo Mau Di web GTA GAMING DISINI
Kalo mau Di web GTA 4-MODS DISINI
CUMA SEGITU TAPI BANYAK SUSAH CARI NYA
Terima Kasih
Cheat Uang The Sims 3
CHEAT UANG THE SIMS 3
Pencet Dulu [Ctrl]+[Shift]+[C]
Dan ketik motherlode => Dapat uang 50,000 Simoleons
Atau shazaam => Dapat uang 2,500 Simoleons
Atau kaching => Dapat uang 1,000 Simoleons
*ENJOY* *ENJOY* *ENJOY* *ENJOY*
bug di GTA IV
bug gta IV 1.Niko tidak ada kepalanya hahahahaha lucu yachhhh xD bug ke-2.motor NRG 500 gak ada ban nya memang di game mah ada bug nya misal niko gak ada kepala dan motor gak ada ban nya tapi kalo di game itu yang namanya banyak bug disebut "BETA" BETA itu game nya itu belum sempurna tapi kalo di game yang bukan BETA mah jarang atuhh kalo ada bug............
nanti aku tambah lagi yach bug nya
THANK YOU :)
Minggu, 01 Januari 2012
Download GTA IV MOD
Permisi numpang bagi link Gta IV Mod Mobil Link: Kalo mau di web GTA GAMING Link:http://www.gtagaming.com/downloads/gta
-iv/vehicle-mods kalo mau di web GTA 4 MODS link:http://www.gta4-mods.com/vehicles kalo mau di web GTA INSIDE Link:http://www.gtainside.com/en/download.php?do=cat&id=341 yang web GTA INSIDE tinggal pilih mau yang mana Pilih mod mobil nya udh cma segitu doang heheheheh THANKS :)
-iv/vehicle-mods kalo mau di web GTA 4 MODS link:http://www.gta4-mods.com/vehicles kalo mau di web GTA INSIDE Link:http://www.gtainside.com/en/download.php?do=cat&id=341 yang web GTA INSIDE tinggal pilih mau yang mana Pilih mod mobil nya udh cma segitu doang heheheheh THANKS :)
Apa itu Bug? Di game
Sebuah bug adalah istilah umum yang digunakan untuk menggambarkan kesalahan, cacat, kesalahan, kegagalan, atau kesalahan dalam sebuah program komputer atau sistem yang menghasilkan hasil yang benar atau tidak diharapkan, atau menyebabkan
ia berperilaku dengan cara yang tidak disengaja. Kebanyakan bug timbul dari kesalahan dan kesalahan yang dibuat oleh orang-orang baik dalam kode sumber program atau desain, dan beberapa disebabkan oleh kompiler menghasilkan kode yang salah. Sebuah program yang berisi sejumlah besar bug, dan / atau bug yang serius mengganggu fungsi-nya , dikatakan buggy. Laporan merinci bug di program yang biasa dikenal sebagai laporan bug, laporan kesalahan, laporan masalah, laporan masalah, perubahan permintaan, dan sebagainyaEfek
Bugs memicu Tipe I dan tipe II error yang pada gilirannya dapat memiliki berbagai efek riak, dengan berbagai tingkat ketidak nyamanan kepada pengguna program.Beberapa bug hanya memiliki efek halus pada fungsionalitas program, dan dengan demikian dapat berbohong tidak terdeteksi untuk waktu yang lama. Lebih bug serius dapat menyebabkan program untuk crash atau membekukan mengarah kepenolakan layanan. Lainnya memenuhi syarat sebagai bug keamanan dan mungkin misalnya memungkinkan pengguna jahat untuk mlewati kontrol akses untuk mendapatkan hak istimewa yang tidak sah.
Hasil bug mungkin sangat serius. Bug di kode mengendalikan Therac-25 mesinterapi radiasi secara langsung bertanggung jawab atas beberapa kematian pasienpada 1980-an. Pada tahun 1996 menjadi $ 1 milyar prototipe Badan Antariksa Eropa AS Ariane 5 roket hancur kurang dari satu menit setelah peluncuran, karenabug dalam program komputer bimbingan on-board. Pada bulan Juni 1994, sebuahRoyal Air Force Chinook jatuh ke dalam Mull of Kintyre, membunuh 29. Ini awalnya dianggap sebagai kesalahan pilot, tetapi sebuah investigasi oleh Komputer Weekly menemukan bukti yang cukup untuk meyakinkan House of Lords penyelidikan yang mungkin telah disebabkan oleh system bug dalam komputer kontrol mesin pesawat.
Pada tahun 2002, sebuah studi yang diprakarsai oleh Departemen Perdagangan AS 'Institut Nasional Standar dan Teknologi menyimpulkan bahwa software bug,atau kesalahan, sangat lazim dan begitu merugikan bahwa biaya mereka ekonomi AS sekitar $ 59 miliar per tahun, atau sekitar 0,6 persen dari produk domestik bruto
Pencegahan
Bugs adalah konsekuensi dari sifat faktor manusia dalam tugas pemrograman.Mereka timbul dari kelalaian atau kesalahpahaman saling dilakukan oleh tim software selama spesifikasi, desain, coding, entri data dan dokumentasi. Sebagai contoh: Dalam membuat sebuah program yang relatif sederhana untuk mengurutkan daftar kata ke dalam urutan abjad, desain seseorang mungkin gagal untuk mempertimbangkan apa yang harus terjadi ketika kata mengandung tanda hubung. Mungkin, ketika mengubah desain abstrak ke dalam bahasa pemrograman yang dipilih, satu tidak sengaja dapat membuat off-per-satu kesalahan dan gagal untuk mengurutkan kata terakhir dalam daftar. Akhirnya, saat mengetik program yang dihasilkan ke dalam komputer, orang mungkin sengaja tipe '<' where '>' yang dimaksudkan, mungkin mengakibatkan kata-kata yang disortir ke dalam urutan abjad mundur. Lebih bug kompleks dapat timbul dari interaksi yang tidak diinginkan antara bagian-bagian berbeda dari sebuah program komputer. Hal ini sering terjadi karena program komputer dapat menjadi kompleks-jutaan baris panjang dalam beberapa kasus-sering yang telah diprogram oleh banyak orang lebih panjang besar waktu, sehingga programmer tidak dapat mental melacak setiap cara yang mungkin di mana bagian dapat berinteraksi. Kategori lain bug disebut kondisi lomba datang tentang baik ketika proses berjalan di lebih dari satu thread atau dua atau lebih proses berjalan secara bersamaan, dan urutan yang tepat dari pelaksanaan urutan kritis kode belum benar disinkronkan.Industri perangkat lunak telah menempatkan banyak usaha dalam menemukan metode untuk mencegah programmer dari secara tidak sengaja memperkenalkan bug saat menulis perangkat lunak Ini termasuk.:Pemrograman gayaSementara kesalahan ketik pada kode program yang sering tertangkap oleh compiler, bug biasanya muncul ketika programmer membuat kesalahan logika.Berbagai inovasi dalam gaya pemrograman dan pemrograman defensif dirancang untuk membuat bug kurang mungkin, atau lebih mudah untuk spot. Dalam beberapa bahasa pemrograman, kesalahan ketik apa yang disebut, terutama dari simbol atau operator logika / matematika, sebenarnya merupakan kesalahan logika, karena konstruksi mistyped diterima oleh compiler dengan arti lain daripada yang dimaksudkan programmer.Teknik pemrogramanBugs sering membuat inkonsistensi dalam data internal program yang berjalan.Program dapat ditulis untuk memeriksa konsistensi data internal mereka sendiri sambil berlari. Jika ketidakkonsistenan ditemui, program ini dapat segera menghentikan, sehingga bug dapat ditemukan dan tetap. Atau, program ini hanya dapat menginformasikan kepada user, upaya untuk memperbaiki inkonsistensi, dan terus berjalan.Pengembangan metodologiAda beberapa skema untuk mengelola aktivitas programmer, sehingga lebih sedikit bug yang dihasilkan. Banyak dari ini jatuh di bawah disiplin rekayasa perangkat lunak (yang membahas masalah-masalah software desain juga).Sebagai contoh, spesifikasi program yang formal digunakan untuk menyatakan perilaku yang tepat dari program, sehingga bug desain dapat dihilangkan.Sayangnya, spesifikasi formal tidak praktis atau tidak mungkin untuk apa pun tetapi program terpendek, karena masalah ledakan kombinatorial dan ketidakpastian.Dukungan bahasa pemrogramanBahasa pemrograman sering termasuk fitur yang membantu programmer mencegah bug, seperti sistem jenis statis, ruang nama terbatas dan pemrograman modular, antara lain. Sebagai contoh, ketika seorang programmer menulis (pseudocode) LET REAL_VALUE PI = "THREE AND A BIT", walaupun ini mungkin sintaksis benar, kode tersebut gagal cek tipe. Tergantung pada bahasa dan pelaksanaan, ini mungkin ditangkap oleh kompilator atau pada saat runtime.Selain itu, bahasa yang baru saja ditemukan banyak sengaja tidak termasuk fitur yang dapat dengan mudah menimbulkan kesalahan, pada biaya pembuatan kode lebih lambat daripada perlu: prinsip umum adalah bahwa, karena hukum Moore, komputer bisa lebih cepat dan insinyur perangkat lunak mendapatkan lebih lambat, ini hampir selalu lebih baik untuk menulis kode sederhana, lebih lambat dari kode "pintar", bisa ditebak, terutama mengingat bahwa biaya pemeliharaan yang besar.Sebagai contoh, bahasa pemrograman Java tidak mendukung aritmetik pointer; implementasi dari beberapa bahasa seperti Pascal dan bahasa scripting sering memiliki batasan pemeriksaan runtime array, paling tidak dalam debugging membangun.Kode analisisAlat untuk analisis kode membantu pengembang dengan memeriksa teks program luar kemampuan compiler untuk menemukan masalah potensial. Meskipun secara umum masalah menemukan kesalahan pemrograman semua diberikan spesifikasi tidak dipecahkan (lihat menghentikan masalah), alat ini memanfaatkan fakta bahwa programmer manusia cenderung membuat jenis yang sama kesalahan saat menulis perangkat lunak.InstrumentasiAlat untuk memantau kinerja perangkat lunak seperti yang sedang berjalan, baik khusus untuk menemukan masalah seperti kemacetan atau memberikan jaminan untuk benar bekerja, dapat tertanam dalam kode eksplisit (mungkin yang sederhana seperti PRINT pernyataan yang mengatakan "Aku Disini"), atau disediakan sebagai alat. Ini sering merupakan kejutan untuk menemukan di mana sebagian besar waktu diambil oleh sepotong kode, dan ini penghapusan asumsi dapat menyebabkan kode yang akan ditulis ulang.
Debugging
Menemukan dan memperbaiki bug, atau "debugging", telah selalu menjadi bagian utama dari pemrograman komputer. Maurice Wilkes, seorang pelopor komputasi awal, dijelaskan realisasi di akhir 1940-an bahwa banyak dari sisa hidupnya akan dihabiskan menemukan kesalahan dalam program-program sendiri Sebagaimana program komputer tumbuh. Lebih kompleks, bug menjadi lebih umum dan sulit untuk memperbaiki. Seringkali programmer menghabiskan lebih banyak waktu dan usaha menemukan dan memperbaiki bug daripada menulis kode baru. Software penguji profesional tugas utamanya adalah menemukan bug, atau menulis kode untuk mendukung pengujian. Pada beberapa proyek, sumber daya lebih dapat digunakan untuk pengujian daripada dalam mengembangkan program.Biasanya, bagian paling sulit debugging adalah menemukan bug dalam kode sumber. Setelah ditemukan, mengoreksi biasanya relatif mudah. Program yang dikenal sebagai debugger ada untuk membantu programmer menemukan bug dengan mengeksekusi baris demi baris kode, menonton nilai-nilai variabel, dan fitur lainnya untuk mengamati perilaku program. Tanpa debugger, kode dapat ditambahkan sehingga pesan atau nilai-nilai dapat ditulis ke konsol (misalnya dengan printf dalam bahasa pemrograman C) atau ke file jendela atau log untuk melacak nilai-nilai pelaksanaan program atau show.Namun, bahkan dengan bantuan debugger, menemukan bug adalah sesuatu yang seni. Hal ini tidak biasa bagi sebuah bug dalam salah satu bagian dari program untuk menyebabkan kegagalan dalam bagian yang sama sekali berbeda, sehingga membuatnya sangat sulit untuk melacak (misalnya, kesalahan dalam grafis rendering menyebabkan rutin file I / O rutin gagal) , dalam bagian tampaknya tidak terkait dari sistem.Kadang-kadang, sebuah bug bukan cacat terisolasi, tetapi merupakan kesalahan dari pemikiran atau perencanaan pada bagian programmer. kesalahan logika seperti ini membutuhkan suatu bagian dari program yang akan dirombak atau ditulis ulang. Sebagai bagian dari proses review Code, melangkah melalui kode pemodelan proses eksekusi di kepala seseorang atau di atas kertas sering dapat menemukan kesalahan tanpa pernah perlu untuk mereproduksi bug seperti itu, jika dapat ditunjukkan ada beberapa logika yang salah dalam pelaksanaannya.Tapi lebih biasanya, langkah pertama dalam menemukan sebuah bug untuk mereproduksi itu andal. Setelah bug tersebut telah direproduksi, programmer dapat menggunakan debugger atau alat lain untuk memantau pelaksanaan program di daerah yang salah, dan menemukan titik di mana program sesat.Hal ini tidak selalu mudah untuk mereproduksi bug. Ada yang dipicu oleh masukan kepada program yang mungkin sulit bagi programmer untuk menciptakan kembali.Salah satu penyebab kematian mesin-25 radiasi Therac adalah bug (khusus, kondisi lomba) yang terjadi hanya ketika operator mesin yang sangat cepat memasuki rencana pengobatan, itu mengambil hari praktek untuk menjadi mampu melakukan hal ini, maka bug itu tidak terwujud dalam pengujian atau ketika produsen berusaha untuk duplikat. bug lain mungkin hilang ketika program tersebut dijalankan dengan debugger, ini adalah heisenbugs (bercanda dinamai prinsip ketidakpastian Heisenberg.)Debugging masih merupakan tugas yang membosankan memerlukan upaya yang cukup. Sejak 1990-an, terutama setelah bencana Ariane 5 Penerbangan 501, telah terjadi minat baru dalam pengembangan alat bantu otomatis yang efektif untuk debugging. Sebagai contoh, metode analisis kode statis dengan interpretasi abstrak telah membuat prestasi signifikan, sementara masih tersisa banyak pekerjaan yang sedang berjalan.Seperti tindakan kreatif, kadang-kadang flash inspirasi akan menunjukkan solusi, tapi ini jarang dan, menurut definisi, tidak dapat diandalkan.Ada juga kelas bug yang tidak ada hubungannya dengan kode itu sendiri. Jika, misalnya, satu mengandalkan dokumentasi yang salah atau perangkat keras, kode dapat ditulis sempurna dengan benar untuk apa dokumentasi kata, tetapi bug yang benar-benar terletak pada dokumentasi atau perangkat keras, tidak kode. Namun, adalah umum untuk mengubah kode bukan bagian lain dari sistem itu, karena biaya dan waktu untuk mengubahnya umumnya kurang. Embedded sistem sering memiliki workarounds untuk bug perangkat keras, karena untuk membuat versi baru dari ROM adalah jauh lebih murah daripada remanufaktur perangkat keras, terutama jika mereka item komoditas.
Bug Management
Ini adalah praktek yang umum untuk perangkat lunak akan dirilis dengan bug diketahui yang dianggap non-kritis, yaitu, yang tidak mempengaruhi pengalaman utama sebagian besar pengguna dengan produk. Sementara produk perangkat lunak mungkin, menurut definisi, mengandung sejumlah bug yang tidak diketahui, pengukuran selama pengujian dapat memberikan perkiraan jumlah kemungkinan bug yang tersisa; ini menjadi lebih handal semakin lama suatu produk diuji dan dikembangkan ("jika kita memiliki 200 bug terakhir minggu, kita harus memiliki 100 minggu ini "). Kebanyakan proyek software besar mempertahankan dua daftar "bug dikenal" - yang dikenal untuk tim perangkat lunak, dan mereka yang diberitahu kepada pengguna. Ini bukan penipuan, namun pengguna tidak peduli dengan cara kerja internal produk. Daftar kedua menginformasikan pengguna tentang bug yang tidak tetap dalam rilis saat ini, atau tidak tetap sama sekali, dan solusi yang dapat ditawarkan.Ada berbagai alasan untuk tidak memperbaiki bugs:Para pengembang sering tidak punya waktu atau tidak ekonomis untuk memperbaiki semua bug tidak parah.Bug dapat diperbaiki dalam versi baru atau patch yang belum dirilis.Perubahan pada kode yang diperlukan untuk memperbaiki bug bisa menjadi besar, mahal, atau menunda penyelesaian proyek.Bahkan tampaknya sederhana membawa perbaikan kesempatan memperkenalkan bug baru yang tidak diketahui ke dalam sistem. Pada akhir tes / siklus memperbaiki beberapa manajer hanya dapat mengizinkan bug paling kritis yang harus diperbaiki.Pengguna mungkin bergantung pada perilaku, tidak berdokumen buggy, terutama jika script atau macro mengandalkan perilaku, hal itu mungkin memperkenalkan perubahan melanggar.Ini "bukan bug". Sebuah kesalahpahaman telah timbul antara perilaku yang diharapkan dan diberikanDiberikan di atas, sering dianggap tidak mungkin untuk menulis sepenuhnya perangkat lunak bug-bebas dari kerumitan nyata. Jadi bug dikategorikan oleh keparahan, dan rendah-beratnya bug non-kritis ditoleransi, karena mereka tidak mempengaruhi operasi yang tepat dari sistem bagi kebanyakan pengguna. NASA SATC berhasil mengurangi jumlah kesalahan untuk kurang dari 0,1 per 1000 baris kode (SLOC) Tetapi ini tidak dirasakan layak untuk proyek-proyek dunia nyata.Tingkat keparahan sebuah bug tidak sama pentingnya untuk memperbaiki, dan dua harus diukur dan dikelola secara terpisah. Pada sistem Windows Microsoft layar biru kematian agak berat, tetapi jika hanya terjadi dalam keadaan ekstrim, terutama jika mereka juga didiagnosis dan dihindari, mungkin kurang penting untuk memperbaiki dari ikon tidak mewakili fungsi dengan baik, yang meskipunmurni estetika dapat membingungkan ribuan pengguna setiap hari. Keseimbangan ini, tentu saja, tergantung pada banyak faktor; pengguna ahli memiliki harapan yang berbeda dari pemula, ceruk pasar berbeda dari pasar konsumen umum, dan sebagainya. Untuk lebih mencapai keseimbangan ini, beberapa pengembang perangkat lunak menggunakan proses triage bug diformalkan (meminjam istilah medis), di mana setiap bug baru diberi prioritas berdasarkan, frekuensi keparahan risiko, dan faktor-faktor yang telah ditentukan lain.Sebuah sekolah pemikiran dipopulerkan oleh Eric S. Raymond sebagai Hukum Linus mengatakan bahwa populer software open-source memiliki lebih banyak kesempatan untuk memiliki beberapa bug atau tidak dari perangkat lunak lain, karena "bola mata cukup diberikan, semua bug yang dangkal". Pernyataan initelah diperdebatkan, namun: spesialis keamanan komputer Elias Levy menulis bahwa "mudah untuk menyembunyikan kerentanan di kompleks, kurang dipahami dan kode sumber yang tidak berdokumen," karena, "bahkan jika orang meninjau kode, itu tidak berarti mereka memenuhi syarat untuk melakukannya ".Seperti bagian lain dari manajemen teknik, manajemen bug harus dilakukan dengan hati-hati dan cerdas karena "apa yang diukur akan dilakukan" dan mengelola murni dengan jumlah bug dapat memiliki konsekuensi yang tidak diinginkan. Jika, misalnya, pengembang dihargai dengan jumlah bug yang mereka memperbaiki, mereka alami akan memperbaiki bug termudah pertama meninggalkan yang paling sulit, dan mungkin paling berisiko atau kritis, untuk saat-saat terakhir mungkin ("Saya hanya punya satu bug pada saya daftar tetapi mengatakan "Membuat matahari terbit di Barat"). Jika etos manajemen adalah pahala jumlah bug tetap, maka beberapa pengembang cepat dapat menulis kode ceroboh mengetahui bahwa mereka dapat memperbaiki bug nanti dan diberi hadiah untuk itu, sedangkan hati-hati, mungkin "lambat" pengembang tidak mendapatkan imbalan atas bug yang pernah ada.
Menemukan dan memperbaiki bug, atau "debugging", telah selalu menjadi bagian utama dari pemrograman komputer. Maurice Wilkes, seorang pelopor komputasi awal, dijelaskan realisasi di akhir 1940-an bahwa banyak dari sisa hidupnya akan dihabiskan menemukan kesalahan dalam program-program sendiri Sebagaimana program komputer tumbuh. Lebih kompleks, bug menjadi lebih umum dan sulit untuk memperbaiki. Seringkali programmer menghabiskan lebih banyak waktu dan usaha menemukan dan memperbaiki bug daripada menulis kode baru. Software penguji profesional tugas utamanya adalah menemukan bug, atau menulis kode untuk mendukung pengujian. Pada beberapa proyek, sumber daya lebih dapat digunakan untuk pengujian daripada dalam mengembangkan program.Biasanya, bagian paling sulit debugging adalah menemukan bug dalam kode sumber. Setelah ditemukan, mengoreksi biasanya relatif mudah. Program yang dikenal sebagai debugger ada untuk membantu programmer menemukan bug dengan mengeksekusi baris demi baris kode, menonton nilai-nilai variabel, dan fitur lainnya untuk mengamati perilaku program. Tanpa debugger, kode dapat ditambahkan sehingga pesan atau nilai-nilai dapat ditulis ke konsol (misalnya dengan printf dalam bahasa pemrograman C) atau ke file jendela atau log untuk melacak nilai-nilai pelaksanaan program atau show.Namun, bahkan dengan bantuan debugger, menemukan bug adalah sesuatu yang seni. Hal ini tidak biasa bagi sebuah bug dalam salah satu bagian dari program untuk menyebabkan kegagalan dalam bagian yang sama sekali berbeda, sehingga membuatnya sangat sulit untuk melacak (misalnya, kesalahan dalam grafis rendering menyebabkan rutin file I / O rutin gagal) , dalam bagian tampaknya tidak terkait dari sistem.Kadang-kadang, sebuah bug bukan cacat terisolasi, tetapi merupakan kesalahan dari pemikiran atau perencanaan pada bagian programmer. kesalahan logika seperti ini membutuhkan suatu bagian dari program yang akan dirombak atau ditulis ulang. Sebagai bagian dari proses review Code, melangkah melalui kode pemodelan proses eksekusi di kepala seseorang atau di atas kertas sering dapat menemukan kesalahan tanpa pernah perlu untuk mereproduksi bug seperti itu, jika dapat ditunjukkan ada beberapa logika yang salah dalam pelaksanaannya.Tapi lebih biasanya, langkah pertama dalam menemukan sebuah bug untuk mereproduksi itu andal. Setelah bug tersebut telah direproduksi, programmer dapat menggunakan debugger atau alat lain untuk memantau pelaksanaan program di daerah yang salah, dan menemukan titik di mana program sesat.Hal ini tidak selalu mudah untuk mereproduksi bug. Ada yang dipicu oleh masukan kepada program yang mungkin sulit bagi programmer untuk menciptakan kembali.Salah satu penyebab kematian mesin-25 radiasi Therac adalah bug (khusus, kondisi lomba) yang terjadi hanya ketika operator mesin yang sangat cepat memasuki rencana pengobatan, itu mengambil hari praktek untuk menjadi mampu melakukan hal ini, maka bug itu tidak terwujud dalam pengujian atau ketika produsen berusaha untuk duplikat. bug lain mungkin hilang ketika program tersebut dijalankan dengan debugger, ini adalah heisenbugs (bercanda dinamai prinsip ketidakpastian Heisenberg.)Debugging masih merupakan tugas yang membosankan memerlukan upaya yang cukup. Sejak 1990-an, terutama setelah bencana Ariane 5 Penerbangan 501, telah terjadi minat baru dalam pengembangan alat bantu otomatis yang efektif untuk debugging. Sebagai contoh, metode analisis kode statis dengan interpretasi abstrak telah membuat prestasi signifikan, sementara masih tersisa banyak pekerjaan yang sedang berjalan.Seperti tindakan kreatif, kadang-kadang flash inspirasi akan menunjukkan solusi, tapi ini jarang dan, menurut definisi, tidak dapat diandalkan.Ada juga kelas bug yang tidak ada hubungannya dengan kode itu sendiri. Jika, misalnya, satu mengandalkan dokumentasi yang salah atau perangkat keras, kode dapat ditulis sempurna dengan benar untuk apa dokumentasi kata, tetapi bug yang benar-benar terletak pada dokumentasi atau perangkat keras, tidak kode. Namun, adalah umum untuk mengubah kode bukan bagian lain dari sistem itu, karena biaya dan waktu untuk mengubahnya umumnya kurang. Embedded sistem sering memiliki workarounds untuk bug perangkat keras, karena untuk membuat versi baru dari ROM adalah jauh lebih murah daripada remanufaktur perangkat keras, terutama jika mereka item komoditas.
Bug Management
Ini adalah praktek yang umum untuk perangkat lunak akan dirilis dengan bug diketahui yang dianggap non-kritis, yaitu, yang tidak mempengaruhi pengalaman utama sebagian besar pengguna dengan produk. Sementara produk perangkat lunak mungkin, menurut definisi, mengandung sejumlah bug yang tidak diketahui, pengukuran selama pengujian dapat memberikan perkiraan jumlah kemungkinan bug yang tersisa; ini menjadi lebih handal semakin lama suatu produk diuji dan dikembangkan ("jika kita memiliki 200 bug terakhir minggu, kita harus memiliki 100 minggu ini "). Kebanyakan proyek software besar mempertahankan dua daftar "bug dikenal" - yang dikenal untuk tim perangkat lunak, dan mereka yang diberitahu kepada pengguna. Ini bukan penipuan, namun pengguna tidak peduli dengan cara kerja internal produk. Daftar kedua menginformasikan pengguna tentang bug yang tidak tetap dalam rilis saat ini, atau tidak tetap sama sekali, dan solusi yang dapat ditawarkan.Ada berbagai alasan untuk tidak memperbaiki bugs:Para pengembang sering tidak punya waktu atau tidak ekonomis untuk memperbaiki semua bug tidak parah.Bug dapat diperbaiki dalam versi baru atau patch yang belum dirilis.Perubahan pada kode yang diperlukan untuk memperbaiki bug bisa menjadi besar, mahal, atau menunda penyelesaian proyek.Bahkan tampaknya sederhana membawa perbaikan kesempatan memperkenalkan bug baru yang tidak diketahui ke dalam sistem. Pada akhir tes / siklus memperbaiki beberapa manajer hanya dapat mengizinkan bug paling kritis yang harus diperbaiki.Pengguna mungkin bergantung pada perilaku, tidak berdokumen buggy, terutama jika script atau macro mengandalkan perilaku, hal itu mungkin memperkenalkan perubahan melanggar.Ini "bukan bug". Sebuah kesalahpahaman telah timbul antara perilaku yang diharapkan dan diberikanDiberikan di atas, sering dianggap tidak mungkin untuk menulis sepenuhnya perangkat lunak bug-bebas dari kerumitan nyata. Jadi bug dikategorikan oleh keparahan, dan rendah-beratnya bug non-kritis ditoleransi, karena mereka tidak mempengaruhi operasi yang tepat dari sistem bagi kebanyakan pengguna. NASA SATC berhasil mengurangi jumlah kesalahan untuk kurang dari 0,1 per 1000 baris kode (SLOC) Tetapi ini tidak dirasakan layak untuk proyek-proyek dunia nyata.Tingkat keparahan sebuah bug tidak sama pentingnya untuk memperbaiki, dan dua harus diukur dan dikelola secara terpisah. Pada sistem Windows Microsoft layar biru kematian agak berat, tetapi jika hanya terjadi dalam keadaan ekstrim, terutama jika mereka juga didiagnosis dan dihindari, mungkin kurang penting untuk memperbaiki dari ikon tidak mewakili fungsi dengan baik, yang meskipunmurni estetika dapat membingungkan ribuan pengguna setiap hari. Keseimbangan ini, tentu saja, tergantung pada banyak faktor; pengguna ahli memiliki harapan yang berbeda dari pemula, ceruk pasar berbeda dari pasar konsumen umum, dan sebagainya. Untuk lebih mencapai keseimbangan ini, beberapa pengembang perangkat lunak menggunakan proses triage bug diformalkan (meminjam istilah medis), di mana setiap bug baru diberi prioritas berdasarkan, frekuensi keparahan risiko, dan faktor-faktor yang telah ditentukan lain.Sebuah sekolah pemikiran dipopulerkan oleh Eric S. Raymond sebagai Hukum Linus mengatakan bahwa populer software open-source memiliki lebih banyak kesempatan untuk memiliki beberapa bug atau tidak dari perangkat lunak lain, karena "bola mata cukup diberikan, semua bug yang dangkal". Pernyataan initelah diperdebatkan, namun: spesialis keamanan komputer Elias Levy menulis bahwa "mudah untuk menyembunyikan kerentanan di kompleks, kurang dipahami dan kode sumber yang tidak berdokumen," karena, "bahkan jika orang meninjau kode, itu tidak berarti mereka memenuhi syarat untuk melakukannya ".Seperti bagian lain dari manajemen teknik, manajemen bug harus dilakukan dengan hati-hati dan cerdas karena "apa yang diukur akan dilakukan" dan mengelola murni dengan jumlah bug dapat memiliki konsekuensi yang tidak diinginkan. Jika, misalnya, pengembang dihargai dengan jumlah bug yang mereka memperbaiki, mereka alami akan memperbaiki bug termudah pertama meninggalkan yang paling sulit, dan mungkin paling berisiko atau kritis, untuk saat-saat terakhir mungkin ("Saya hanya punya satu bug pada saya daftar tetapi mengatakan "Membuat matahari terbit di Barat"). Jika etos manajemen adalah pahala jumlah bug tetap, maka beberapa pengembang cepat dapat menulis kode ceroboh mengetahui bahwa mereka dapat memperbaiki bug nanti dan diberi hadiah untuk itu, sedangkan hati-hati, mungkin "lambat" pengembang tidak mendapatkan imbalan atas bug yang pernah ada.
Langganan:
Postingan (Atom)