Privasi Anda penting bagi kami. Merupakan kebijakan Kodelokus untuk menghormati privasi Anda terkait informasi apa pun yang mungkin kami kumpulkan dari Anda melalui aplikasi kami.
Kami hanya meminta informasi pribadi ketika kami benar-benar membutuhkannya untuk memberikan layanan kepada Anda. Kami mengumpulkannya dengan cara yang adil dan sah, dengan sepengetahuan dan persetujuan Anda. Kami juga memberi tahu Anda mengapa kami mengumpulkannya dan bagaimana penggunaannya.
Kami hanya menyimpan informasi yang dikumpulkan selama diperlukan untuk menyediakan layanan yang Anda minta. Data apa yang kami simpan, akan kami lindungi dalam cara yang dapat diterima secara komersial untuk mencegah kehilangan dan pencurian, serta akses, pengungkapan, penyalinan, penggunaan, atau modifikasi yang tidak sah.
Kami tidak membagikan informasi identitas pribadi apa pun secara publik atau dengan pihak ketiga, kecuali jika diwajibkan oleh hukum.
Kami menggunakan Google Ads untuk memonetisasi aplikasi kami. Anda mungkin melihat beberapa iklan yang dipersonalisasi berdasarkan id iklan Anda. Anda dapat merujuk ke kebijakan privasi Google Ads (https://policies.google.com/privacy?hl=id-ID) untuk mengetahui bagaimana mereka menangani data Anda.
Aplikasi kami dapat ditautkan ke situs eksternal yang tidak dioperasikan oleh kami. Perlu diketahui bahwa kami tidak memiliki kendali atas konten dan praktik situs-situs ini, dan tidak dapat menerima tanggung jawab atau kewajiban untuk kebijakan privasi masing-masing.
Anda bebas untuk menolak permintaan kami atas informasi pribadi Anda, dengan pemahaman bahwa kami mungkin tidak dapat memberi Anda beberapa layanan yang Anda inginkan.
Penggunaan berkelanjutan Anda atas aplikasi kami akan dianggap sebagai penerimaan praktik kami seputar privasi dan informasi pribadi. Jika Anda memiliki pertanyaan tentang bagaimana kami menangani data pengguna dan informasi pribadi, jangan ragu untuk menghubungi kami.
Your privacy is important to us. It is Kodelokus’ policy to respect your privacy regarding any information we may collect from you through our apps.
We only ask for personal information when we truly need it to provide a service to you. We collect it by fair and lawful means, with your knowledge and consent. We also let you know why we’re collecting it and how it will be used.
We only retain collected information for as long as necessary to provide you with your requested service. What data we store, we’ll protect within commercially acceptable means to prevent loss and theft, as well as unauthorized access, disclosure, copying, use or modification.
We don’t share any personally identifying information publicly or with third-parties, except when required to by law.
We are using Google Ads to monetize our app. You may see some personalized ads based on your advertising id. You can refer to Google Ads privacy policy (https://policies.google.com/privacy?hl=en-US) to know how they handle your data.
Our app may link to external sites that are not operated by us. Please be aware that we have no control over the content and practices of these sites, and cannot accept responsibility or liability for their respective privacy policies.
You are free to refuse our request for your personal information, with the understanding that we may be unable to provide you with some of your desired services.
Your continued use of our app will be regarded as acceptance of our practices around privacy and personal information. If you have any questions about how we handle user data and personal information, feel free to contact us.
Yang pertama akan kita bahas yaitu boolean, ini merupakan tipe data yang paling sederhana. Boolean mengekspresikan nilai kebenaran, nilainya bisa TRUE atau FALSE.
Untuk memberikan value pada sebuah variable boolean, yaitu dengan kontanta true atau false, keduanya case sensitive.
var foo = true; // assign value TRUE untuk foo
bool foo = false; // assign value false untuk foo
Biasanya hasil dari operator boolean digunakan dalam if conditions. Contoh:
// == adalah operator yang menguji kesetaraan dan mengembalikan boolean
if (foo == "show_version") {
print("The version is 1.23");
}
// ini tidak perlu
if (foo == TRUE) {
print( "<hr>\n");
}
// ...karena ini dapat dipakai sama persis dengan ini:
if (foo) {
print( "<hr>\n");
}
Berikutnya kita akan bahas mengenai tipe data integer. Integer adalah angka dari set ℤ = {…, -2, -1, 0, 1, 2, …}. Contoh:
int angka = 3;
var angkaMin = -7;
Yang perlu digarisbawahi adalah dalam C#, penjumlahan NULL dengan integer berapapun hasilnya selalu 0. Untuk itu jika melakukan operasi penjumlahan dengan value yang memungkinkan bernilai NULL, jangan lupa untuk dikonversi ke 0 terlebih dahulu sebelum dijumlahkan.
Next akan kita bahas tipe data float dan string di artikel berikutnya ya… stay tune
Your privacy is important to us. It is Kodelokus’ policy to respect your privacy regarding any information we may collect from you through our app, Prayer Times.
We only ask for personal information when we truly need it to provide a service to you. We collect it by fair and lawful means, with your knowledge and consent. We also let you know why we’re collecting it and how it will be used.
We only retain collected information for as long as necessary to provide you with your requested service. What data we store, we’ll protect within commercially acceptable means to prevent loss and theft, as well as unauthorized access, disclosure, copying, use or modification.
We don’t share any personally identifying information publicly or with third-parties, except when required to by law.
We are using Google Ads to monetize our app. You may see some personalized ads based on your advertising id. You can refer to Google Ads privacy policy (https://policies.google.com/privacy?hl=en-US) to know how they handle your data.
Our app may link to external sites that are not operated by us. Please be aware that we have no control over the content and practices of these sites, and cannot accept responsibility or liability for their respective privacy policies.
You are free to refuse our request for your personal information, with the understanding that we may be unable to provide you with some of your desired services.
Your continued use of our app will be regarded as acceptance of our practices around privacy and personal information. If you have any questions about how we handle user data and personal information, feel free to contact us.
Asp.Net Core adalah framework MVC berbasis cloud untuk membangun aplikasi web di Windows, Mac, dan Linux. Ini merupakan kombinasi dari MVC dan Web API dalam satu framework web programming.
Keunggulan dari Asp.Net Core yaitu lebih ramping dan modular karena banyak arsitektur, open-source dan mudah untuk membangun aplikasi Asp.Net lintas platform pada Windows, Mac, dan Linux. Asp.Net Core dapat dibangun di atas Kestral, IIS, HTTP.sys, Nginx, Apache, ataupun Docker.
Membangun aplikasi dapat menggunakan IDE Visual Studio, yang terbaru saat ini adalah Visual Studio 2019.
Untuk mulai membuat aplikasi web ASP.NET pertama yg diperlukan adalah aplikasi Visual Studio 2019, teman teman bisa mendownloadnya di https://visualstudio.microsoft.com/downloads .
Setelah selesai menginstalnya, kita bias mulai membuat aplikasinya dengan langkah langkah sebagai berikut ini:
Buka aplikasi Visual Studio
Selesai dibuka aplikasinya, kita akan sampai dihalaman start, dihalaman ini kita pilih Create New Project.
Dihalaman Create new project ketikkan asp.net di search box ,kemudian pilih c# di dropdown language dan pilih windows di dropdown platform, setelah itu dimenu tersebut bisa ditemukan template ASP.NET Core Web Application, kita pilih dan kemudian klik tombol next.
Dihalaman Configure your new project ada tiga input yaitu:
Project name
Location
Solution name
Dihalaman ini kita cukup mengisi input Project name dengan mengetikkan HelloWorld dan secara otomatis akan mengisi input lainnya, setelah itu tekan tombol Create
Di halaman Create a new Asp.NET Core Web Application kita pilih Web Application dan pastikan di dropdown di atas terpilih .NET Core dan ASP.NET Core 3.1, setelah itu tekan tombol Create.
Dihalaman utama ,template yg sudah kita pilih tadi, bisa mulai kita gunakan, untuk mengetes halaman tersebjut bisa kita gunakan beberapa shortcut yg biasa di pakai ,yaitu:
CTRL+SHIFT+B
CTRL+F5
F5
Setiap ada perubahan di controller kita harus membuild ulang projectnya dengan menggunakan shortcut ctrl+shift+b
Untuk menjalankan web kita bisa menggunakan tanpa debug menggunakan shortcut ctrl+f5 atau menggunakan f5 untuk debug.
Setelah kita menggunakan shortcut ctrl+f5 secara otomatis browser terbuka dengan alamat localhost:44399 dan menampilkan halmana home, di halaman ini bisa kita lihat ada dua menu ,yaitu:
Home
Privacy
Halaman home posisi filenya ada di folder Pages dan nama filenya Index.cshtml.
Halaman privacy posisi filenya ada di folder Pages dan nama filenya Privacy.cshtml.
Untuk melakukan perubahan kita buka file Index.cshtml ,kemudian lihat dibaris 8 ada tulisan Welcome ,coba kita rubah jadi Hello World kemudian kita save, setelah itu kita buka browser yg tadi sudah terbuka kemudian kita refresh dengan menggunakan shortcut CTR+SHIFT+R untuk mereffresh halaman home ,disini bisa kita lihat perubahanyg sudah kita save tadi.
Setelah pertemuan 2 hari di Snowbird, Uncle bob dan semua rekannya yang terlibat dalam pertemuan itu bekerja keras untuk menuntaskan dokumen dan prinsip-prinsip dari agile, merapihkannya, merumuskannya dan menambahkannya di website. mereka bekerjasama untuk menuntaskan pembukuan dan dokumentasi dari pertemuan itu, mengenai empat nilai itu, mereka semua setuju tanpa ada satupun yang mau untuk merubahnya. mereka bekerja dengan baik dan semakin dekat layaknya sebuah keluarga.
Mereka melakukan komunikasi menggunakan email untuk saling menambahkan, atau berdiskusi untuk menyempurnakan prinsip empat value tersebut, sampai akhirnya selesai dan mereka kembali ke pekerjaan mereka masing-masing.
Uncle bob sempat terpikir mengenai Idea dari Alistair yang ingin membuat pertemuan serupa, dan masi banyak orang-orang lain di sana yang mempunyai idea yang sama, yaitu membuat pertemuan untuk membahas masa depan pembangunan software, dan mereka pun akan menemukan akhir yang sama dengan pertemuan snowbird .
Dapat disimpulkan bahwa banyak programer yang mempunyai keresahan yang sama dengan masa depan software development, mereka pun merasakan hal yang dirasakan oleh uncle bob, merasakan bagaimana waterfall saja tidak cukup dalam pembangunan software kedepannya, sehingga dibutuhkan alternatif yang bisa memudahkan seorang programer, perusahaan, customer dan yang berkaitan, untuk membuat metode pembangunan software. Dan inilah Agile, hasil dari diskusi yang panjang dan kesepakatan dari 17 senior programer dengan keunikan dan sudutpandang yang berbeda namun mempunyai tujuan yang sama. Bravooo
Part 4 sudah selesai , kita lanjut ke part 5 ” Agile Overview “
Ketika kamu mempunyai masalah yang tidak bisa kamu atasi, pasti kamu akan mencari bantuan seseorang.
Misalnya kamu memerlukan desain logo untuk perusahaan kamu. Siapa yang akan kamu cari? Desainer yang memiliki banyak kemampuan, seperti membuat web, mengambar illustrasi, fotografi, dan membuat logo atau kamu akan mencari Desainer yang memang keahlian-nya membuat logo.
Secara umum orang akan memilih yang kedua. Mengapa? Karena orang kedua akan memberikan hasil yang lebih dapat diandalkan karena dia adalah seseorang ahli yang tau lebih dalam tentang seluk-beluk merancang sebuah logo, dibandingkan desainer yang pertama.
Dari sudut pandang diatas nampaknya semua akan setuju, bahwa Desainer harus memiliki spesialisasi jika ingin memperoleh kesempatan lebih besar agar menjadi pilihan utama.
Namun ada sudut pandang lain, ketika sebuah perusahaan mencari kandidat seorang Desainer, secara umum perusahaan-perusahaan akan memilih kandidat Desainer yang menguasai kemampuan lebih banyak dibandingkan dengan Desainer yang spesifik menguasai satu kemampuan tertentu. Hal ini dilakukan agar perusahaan tidak perlu merekrut banyak desainer, tujuanya untuk efisiensi karyawan.
Jika dari sudut pandang diatas, Desainer yang memiliki kemampuan Generalis menjadi pilihan utama.
Lalu kita harus menjadi desainer generalis atau desainer spesialis? Sebelum memilih mari kita lihat dulu kelebihan masing – masing.
DesainerGeneralis
Ketika Paula Schre (Pentagram) ditanya pedapat-nya tentang spesialisasi vs generalisasi, Paula menjawab “spesialisasi itu sempit, generalisasi itu luas. seorang generalis dapat mencoba lebih banyak hal.”
Selain yang dikatakan Paula, seorang generalis juga akan membuat alur kerja sebuah tim menjadi lebih efisien, karena dia akan bisa mengerjakan hal yang lain secara bersaamaan. dengan demikian dia dapat melihat alur kerja sebuah proyek secara keseluruhan.
Christ Thenwell dari envato mengatakan “Kami membutuhkan orang-orang yang memiliki berbagai keterampilan. Hari ini mereka (desainer) dapat melakukan riset pengguna, mewawancarai pelanggan, menulis survei, menganalisis hasil, dll. Di hari berikutnya mereka akan mendesain sebuah visual. Ada saatnya juga mereka bekerja sama dengan Front-end Developer, bahkan hingga menulis kode. “
Christ menambahkan “Sebuah tim yang dibangun dari para desainer generalis adalah sebuah tim yang dapat menghandel banyak pekerjaan desain.”.
Seorang desainer generalis akan mudah beradaptasi, dan dapat menyelesaikan masalah secara efektif. Seorang generalis, bisa memperluas keahlian desainnya, membuatnya lebih flexible dan mudah masuk kelingkungan kerja baru.
DesainerSpesialis
Seorang desainer yang memiliki kemampuan khusus dan menguasai sesuatu hal dengan sangat baik, orang-orang akan mencarinya karena kemampuanya.
Desainer spesialis yang sudah berpengalaman akan memiliki kompetitor yang sedikit, semakin langka dan semakin dicari. Dengan kompetitor yang sedikit dan kemampuan yang khusus seorang desainer spesialis memiliki harga tawar yang tinggi.
“Ada peran tertentu yang membutuhkan kemampuan teknis atau kemampuan desain tingkat tinggi, di mana sangat penting untuk tetap dipercayakan kepada spesialis,” kata Maggie McKosky, (Shutterstock, New York).
Spesialis mampu melihat masalah dengan sangat spesifik dan menciptakan solusi yang sangat spesifik. karena dia memang benar-benar fokus mendalami kemampunyanya tersebut.
“Seorang spesialis mampu menemukan hal-hal yang mendalam dan menemukan ide-ide baru dan menyebarkan pengetahuan itu kepada para generalis, tanpa seorang spesialis para generalis tidak akan menemukan pengetahuan atau ide-ide tersebut” Jamal Nicholas (Truth About Design).
Masih banyak kelebihan dari Desainer Generalis maupun Desainer Spesialis, namun dengan sedikit pemaparan diatas apakah kamu sudah condong untuk memilih salah satunya?
Sabar jangan dulu memilih karena di artikel berikutnya insyaallah saya akan membahas tentang kekurangan masing-masing.
Dengan mengetahui kelebihan sekaligus kekurangan masing-masing, kamu bisa memilih secara objektif diantara keduanya atau bahkan mungkin ada pilihan yang tidak terduga.
akan berlajut ke bagian 2…
catatan kaki :tulisan pertama saya ini disadur dari beberapa sumber.
Bagian ini adalah tentang pertemuan snowbird di Utah, pertemuan dari 17 orang senior programer yang sudah berumur yang berkumpul untuk membahasa sebuah topik , yaitu “The Light Weight Process Summit“, para senior yang mencoba untuk memecahkan permasalahan di dunia programing dan software untuk kedepannya. Kita akan bahas berdasarkan kisah dari Uncle bob, sehingga bisa mengetahui kondisi yang digambarkan oleh uncle Bob.
Uncle bob menceritakan tentang pertemua snowbird, Semua undangan hadir dalam forum itu, terdapat 17 orang yang berkumpul mepresentasikan pandangan yang berbeda, termasuk 5 pandangan yang berbeda tentang “Light Weight Process“. kelompok paling besar dihadiri oleh XP Team (Extream Programing) yang terdiri dari: Kent Beck, Uncle Bob, James Grenning, Ward Cunningham, Dan Ron Jeffries. dari The Scrum Team diwakilkan oleh: Ken Schwaber, Mike Beedle, dan Jeff Sutherland. Jon Kern mempresentasikan Feature-Driven Development, Arie van Bennekum mempresentasikan The Dynamic Systems Development Method (DSDM), Alistair Cockburn mempresentasikan Crystal family of processes.
Sebagian dari peserta tidak berafiliasi. Andy Hunt dan Dave Thomas merupakan programer yang pragmatis, Brian Marick sebagai Test Consultant. Jim Highsmith adalah seorang software management consultant, Steve Mellor yang mempresentasikan the Model-Driven philosophy, dan Martin Fowler seseorang yang dekat dengan kita semua.
Saya tidak begitu ingat tentang pertemuan 2 hari itu, namun beberapa dari teman saya membantu saya mengingat diskusi pada hari itu, karna cukup sulit untuk menggambarkan semua dari seorang yang berumur 65 tahun, tapi saya jamin jika yang saya ingat adalah hal-hal yang penting.
Saya memulai pertemuan itu, menjelaskan kepada peserta undangan untuk membuat suatu tujuan dan manifestasi dari Light WeightProcess beserta pengembangan software dimasa yang akan datang, kami melakukan hal pada umumnya, yaitu menulis semua masalah-masalah yang kami temui dan memulai mengurutkannya sesuai dengan kelompok persamaannya. Saya tidak sadar saat hal yang menakjubkan terjadi, saat seseorang menuliskan di sebuah papan mengenai empat hal:Individuals and Interactions, Working Software, Customer Collaboration, and Responding to Change. dan hal itu dapat mewakilkan the complementary values of processes, tools, documentation, contracts, and plans, tanpa mengurangi maknanya sedikitpun.
Ini adalah Pusat/inti dari Agile, semua orang tidak mengingat siapa yang pertama kali menuliskannya di papan, ada yang berkata itu adalah ward Cunningham, namun Ward sendiri yakin jika yang menulis di papan adalah martin fowler.
Dalam agilemanifesto.org Ward menunjukkan jika seseorang yang lebih banyak menulis di papan adalah martin fowler, Ward menujukkan kepercayaannya bahwa martinlah yang memberikan Idea cemerlang tersebut.
Kami semua bersatu, dan ini merupakan keajaiban. dalm tim kecil itu ada yang menuliskan beberapa kata, ada yang mengoreksinya dan memperbaikinya, memberikan saran dan masukan, ward menulis dalam sebuah pembukaan ” We are uncovering better ways of developing software by doing it and helping others do it”, dan dari sini yang kami sadari bahwa kami sudah menyelesaikannya, ada perasaan yang melegakan di ruangan itu, tidak ada perbedaan pendapat lagi, tidak ada perbedaan argumen lagi, dan tidak ada yang memberikan alternatif lainnya, yang tersisa hanya 4 baris ini:
– Individuals and interactions over processes and tools. – Working software over comprehensive documentation. – Customer collaboration over contract negotiation. – Responding to change over following a plan.
Apakah ini sudah selesai ? hmm, saya rasa begitu, meskipun akan banyak detail yang belum terungkap yang harus kita selesaikan. Namun, apa yang akan kita sematkan untuk hal yang belum terindetifikasi ini ? dari sinilah kita mulai memberi nama yang pantas untuk 4 nilai tersebut, saya lebih suka menyebutnya Light WeightProcess, ada yang memberi sematan inconsequential, Adaptive dan ada yang menyebutkan Agile, namun kata yang paling baik di antara yg baik adalah ” Agile”. dan ward mengajukan untuk di muat dalam website agilemanifesto.org, sebagai bentuk persetujuan dari semua peserta perkumpulan ini.
Inilah hasil dari pertemuan 17 orang senior programing, yang menciptakan metode untuk membuat dan mengembangkan software dimasa yang akan datang. dari sinilah pijakan yang dibuat oleh ke 17 orang tersebut, dan pertemuan itu di abadikan di agilemanifesto.org. sebagai bentuk kesatuan mereka.
Seru kan, kita akan terus lanjutkan yang ke part ke 4 “After Snowbird”
Pada kesempatan ini, saya ingin mengajak anda untuk sama-sama belajar membuat aplikasi Android dengan menggunakan Flutter dan mengimplementasikan BLOCpattern pada aplikasi tersebut.
Artikel ini akan saya perbarui setiap minggunya. sampai proses pembuatan aplikasi yang dimaksud selesai.
Apa itu Flutter?
Flutter adalah sebuah framework open-source yang dikembangkan oleh Google untuk membangun antarmuka (User Interface/UI) aplikasi Android dan iOS.
Apa itu BLOC Pattern?
BLOCpattern adalah state management system untuk Flutter yang direkomendasikan oleh Googledevelopers. BLOCpattern membantu pengelolaan state dan membuat akses ke data tersentralisasi.
Mengapa BLOC?
Ketika membangun atau membuat aplikasi yang production-ready, manajemen pengelolaan state menjadi sangat penting. Oleh karena itu, architectural pattern atau structured project / codebase diperlukan. BLOC berusaha membuat perubahan state dapat diprediksi dengan mengatur kapan perubahan state dapat terjadi, dan “memaksakan” satu cara (khusus) untuk mengubah state pada (keseluruhan) aplikasi.
Bagaimana BLOC mengelola state?
Dengan menggunakan pendekatan STREAMS atau REACTIVE. Secara umum, data akan bergerak dari BLOC ke UI, atau dari UI ke BLOC, dalam bentuk streams. Penjelasan dan pembahasan lebih lanjut mengenai streams dapat dibaca dijawaban StackOverflow berikut: What is a stream.
Jika kita bertanya, sejak kapan dimulainya agile ? bisa jadi saat zaman dahulu disaat sekelompok orang saling berkolaborasi/bekerjasama untuk tujuan bersama, untuk kepentingan bersama. Begitu juga agile di era industri, terciptanya mesin uap, pesawat dan penemuan lainnya, yang terukur, dan berjalan secara natural. itulah agile.
Jadi kapan agile dimulai dalam software? Uncle Bob menggambarkan sesosok Alan Turing, bagaimana Alan sudah banyak membuat program mulai dari tahapan awal yang sederhana dengan telaten, begitu juga saat Alan membuat Automatic Computing Engine dengan hati-hati, Alan membuat langkah kecil, dengan banyak trial, Cek dan real testing. begitu juga dengan Mercury Space capsul yang dalam sela-sela pembuatan control Software nya selalu melakukan testing.
Kisah-kisah hebat sudah banyak tertulis dimana-mana, Ward Cunningham menuliskan dalam wikinya sejarah tentang Larman’s book, Agile & Iterative Development: A Manager’s Guide, dan banyak persaingan metodologi yang bisa membuat sukses industri manufaktur dan industri sekala besar lainnya dengan menggunakan: Scientific Management. Scientific Management merupakan metodologi top-down dari atasan ke karyawan dengan pendekatan perintah dan kontrol, manajer dan team bisa memastikan tercapainya semua tujuan yang sudah di sepakati, hanya saja kebutuhan dan rencana dibahas di awal dan harus berhati2 dengan detail-detail yang belum ada sebelumnya. pastinya butuh gabaran yang utuh dengan detail yg spesifik, dan mungkin bisa jadi masalah besar jika saat proses berjalan, ada ide-ide atau perubahan pada software tersebut.
Scientific Management merupakan metode yang cukup kuno, mungkin sama kunonya dengan pembuatan piramida, stonehenge, bahkan candi borobudur. Namun metode ini sukses membuat banyak karya yang menakjubkan dimasa lalu. dan ide dari metode itu akan terus diulangi sehingga manusia bisa mencapai hal semacam revolusi.
Scientific Management menjadi semakin viral ditangan Frederick Winslow Taylor pada tahun 1880. Dengan pemahaman tersebut mengantarkan Taylor menjadi seorang konsultan menejemen, dan metode itu secara bertahap menjadi sukses dan membuat perusahaan menjadi lebih produktif pada masanya dan setelahnya.
Pada tahun 1970 an, dunia software di hadapkan dengan 2 teknik/metode yang saling bersebrangan, Pre-agile dan Scientific Management. Pre-agile memerlukan langkah yang tepat yang terukur dan dapat di perbaiki secara perlahan, langkanya acak namun bisa menghasilkan hasil yang bagus. Scientific Management lebih mengutamakan spesifikasi software yang detail diawal, sehingga pengerjaan belom bisa dilakukan selama detail belom lengkap. Pre-agile sangat cocok/pas untuk projek dengan cost perubahan yang kecil, karna dapat menyelesaikan masalah secara parsial, dengan perubahan Kesepakatan secara informal. Scientific Management lebih cocok untuk projek dengan cost perubahan yang mahal/tinggi, dengan pemecahan masalah yang baik dengan tujuan yang spesifik.
Jadi, dalam software development manakah yang lebih cocok ? Scientific Management atau Pre-Agile. Uncle bob pun hanya menjelaskan jika pada tahun 1970, software dikerjakan karna sebuah ketidak sengajaan bukan karna persiapan yang jelas.
Pada tahun 1970 Wiston Royce menulis makalah yang mendeskripsikan idenya untuk memenej projek software sekala besar, makalah tersebut terdapat diagram yang menggambarkan rencananya. Royce bukan pencetus diagram tersebut dan hanya menggunakan diagram tersebut sebagai gambaran yang nantinya akan Royce gunakan untuk meruntuhkan diagram tersebut pada halaman selanjutnya dalam makalahnya.
Namun, penempatan Diagram yang mencolok ini membuat pembaca dapat menyimpulkan sendiri isi dari halaman pertama dan kedua dari makalah ini, sehingga menyebabkan perubahan yang dramastis dalam industri perangkat Lunak.
Royce mulai mencermati diagram tersebut, dan melihatnya seperti air yang jatuh dari dinding batu, dari sinilah Royce menyebutnya ” Water Fall ” . hmm begini toh ceritanya .
Waterfall sendiri bisa dikatakan adalah turunan dari Scientific Management. Waterfal melakukan analisa menyeluruh diawal berdasarkan gambaran dan asumsi kita sesuai dengan pengalaman kita di dunia software, membuat rencana dengan detail dan melakukan eksekusi rencana tersebut hingga selesai. meskipun pada dasarnya hal ini bukan yang royce rekomendasikan, itu hanyalah konsep yang orang-orang dapatkan dari membaca makalahnya dan hal ini bertahan hampir selama 30 tahun berikutnya.
Pada tahun 1970, usia Ucle Bob masih 18 tahun, ia bekerja sebagai programer di sebuah perusahaan A. S. C. Tabulating di Lake Bluff, illinois. Perusahaa tersebut mempunyai IBM 360/30 dengan 16K core, IBM 360/40 dengan 64K core, dan variasi 620/f komputer mini dengan 64K core. Uncle bob memprogram 360s dengan mengguakan COBOL,PL/1, Fortran, dan assembler. dan hanya menulis meggunaka Assembler pada 620/f.
Uncle Bob menceritakan kondisi saat itu, “sangat penting untuk mengingat atau merasakan menjadi programer di masa itu, kami menulis pada sebuah kartu khusus untuk code dengan menggunakan pensil, kami menggunakan tombol operator supaya komputer membuka alatnya untuk kami. kami memasukkan kartu yang sudah kami buat dengan sangat berhati-hati ke operator komputer untuk melakukan compile dan testing pada shift ke tiga, karna selama siang hari komputer terlalu sibuk. terkadang memerlukan berhari-hari dari awal code sampai selesai di-compile, dan saat melakukan compile berikutnya biasanya memerlukan satu hari lagi.
Bagiku 620/f sedikit berbeda, mesin itu sudah di dedikasikan untuk Tim kami, kami bisa megaksesnya 24 jam selama 7 hari, kita dapat melakukan 4 kali testing setiap hari, tim kami terdiri dari bermacam-macam orang dan tidak seperti programer saat ini, hanya mengetik, kami dapat menekan tombol kartu kami masing-masing, dari pada memberikan ke mesi operator yang aneh.
Jadi, proses apa yang kami lakukan waktu itu ? pastiya bukan waterfall. kami tidak puya konsep dan detail dari gambaran software sebelumnya. kami hanya berusaha hari demi hari, melakukan compile, testing kode, dan fixing bugs terus menerus, karna kami tidak mempunya acuan metode yang baku, ini juga bukan agile, atau pre-agile. Tidak ada acuan saat kami bekerja, tidak ada rangkaian test dan waktu yang membatasi. kami hanya melakukan koding dan fixing, koding da fixing hingga berhari-hari dan berbulan-bulan”.
Uncel Bob melanjutkan dalam kisahnya, “pertama kali aku membaca tetang waterfall di sebuah jurnal di sekitara tahun 1972, itu seperti berkah, apakah benar kita bisa menganalisa sebuah masalah di awal, dan mendesain penyelesaiannya, dan implementasi semua desain yang sudah di selesaikan? bisakah merancang kegiatan berdasarkan tiga fase itu? ketika kami selesai dengan analisa, apakah benar kita sudah mencapai sepertiga dari projek itu ? aku dapat merasakan kekuatan dari konsep ini dan harus meyakininya , ini seperti sebuah mimpi yang jadi nyata.
Tampaknya, aku tidak sendiri, banyak programer dan perusahaan programing menangkap kesempatan ini. dan seperti yang sudah saya sampaikan, jika waterfall benar-benar mendominasi pemikiran di masa itu. waterfall sangat mendominasi, tapi tidak berhasil, selama tigapuluh tahun kedepan , asosiasi dan semua programer di seluruh dunia mencoba dan selalu mencoba untuk membuat analisa dan desain yang benar, namun saat kita merasa semua berjalan sesuai rencana, masalah selalu ada saat fase implementasi, semua yang sudah kami rencanakan dan persiapkan selama berbulan-bulan menjadi tidak relevan karna kesalahan yang tidak terencana/terduga, hal itu di saksikan didepan para menejer dan pelanggan, dan lebih buruk lagi, waktu Pekerjaan tidak sesuai dengan deadline.
Meskipun kegagalan ini selalu berulang-ulang. kami tetap menggunakan waterfall sebagai pedoman. lagipula kenapa bisa gagal ? bagaimana menganalisa masalah, merancang solusi dan mengimplementasikan solusi dari desain yang gagal terus menerus ? tidak bisa di bayangkan jika permasalahan terletak pada strategi kami, Permasalahan itu terletak pada kami. tanpa kami tau kenapa kami bisa salah. Dominasi metode waterfall sangat tampak pada bahasa pemrograman hari ini, Dijkstra hadir dengan struktur pemrograman pada tahun 1968, struktur analis dan design juga tidak lama dari itu muncul, ketika OOP (Object-Oriented Programing) menjadi populer di tahun 1988, Object oriented analis dan desain (OOA dan OOD) juga Muncul tak lama dari itu, ketiga serangkai itu membuat kondisi semakin rumit, dan kami tidak mudah untuk merubah cara kerja kami yang sebelumnya, namun kemudian kami bisa.
Awal mula reformasi agile mulai tampak pada akhir 1980 dan awal 1990, hal itu tampak pada beberapa komunitas dan beberapa makalah yang di tulis pada tahun 1980, semisal The Smalltalk Community, buku Boock tahun 1991 tentang OOD. cockburn Crystal methode 1991, The Design patterns community 1994, dan makalah spurred dari james Coplien. Pada tahun 1995 Beedle, Devos, Sharon, Schwaber, dan sutherland telah menulis makalah yang sangat terkenal yaitu Scrum, Konsep ini bisa menjadi alternatif dari WaterFall. Begitulah uncle bob mencoba menggambarkan tetang kondisi saat scrum muncul.
Uncle bob beberapa kali bertemu dengan Kent beck pada 1994 saat seminar PLOP, Illinois, dan pada tahun 1999 seminar OOP di munich. dan itu sangat luar biasa bagi uncle bob. Pada masa itu, Uncle bob sebagai konsultan C++ dan OOD, ia terbang kesana kemari untuk membantu banyak orang dalam desain dan implementasi aplikasi menggunakan C++ dan teknik OOD. pada saat itu konsumennya bertanya mengenai proses dan pernah mendengar jika waterfall tidak mix dengan OO (Object Oriented), dan meminta pendapat uncle bob, pertanyaan itu membuat uncle bob sempat terpikir untuk menulis proses OO nya sendiri, namun ia urungkan niat itu setelah membaca tulisan Kent Beck tentang Extreme Programing (XP). Saat uncle Bob membaca Extreme Programing (XP), ia merasa terpesona, ide XP sangat revolusioner, sehingga membuat ia ingin terus belajar.
Pada sebuah seminar di Munich, Uncle Bob menjadi salah satu pematerinya, Dia cukup kaget karna bisa bertemu dengan kent back yang juga berada di forum itu, dia bertemu dengan kent beck saat perjamuan makan siang dan dari pertemuan itu tercapailah kerjasama antar keduanya, dari situlah bermula kunjungan pertama uncle bob kerumah kent beck, selama kunjungan itu uncle bob mengenal Test-Drivent Development (TTD) yang membuat dia semakin tertarik.
Uncle bob mempunyai perusahaan bernama Object Mentor, dan telah melakukan kerjasama dengan kent yang diberinama XP Immersion,kerjasama tersebut adalah membuat sebuah boot camp selama 5 hari untuk pelatihan XP, dan menuai kesuksesan yang cukup besar di akhir tahun 1999 hingga 11 september 2001. mereka berhasil melatih ratusan orang.
Pada musim panas tahun 2000 kent mengundang beberapa orang dari komunitas XP and pattrents Community untuk melakukan pertemuan kecil di dekat rumahnya, mereka sedang membicarakan dan memutuskan bagaimana kelanjutan XP kedepan. Ada sebuah idea yang mengusulkan untuk membuat lembaga non-profit yang berkaitan dengan XP, uncle bob setuju, namun banyak orang tidak setuju, karna sebagian besar dari mereka pernah mempunyai pengalaman yang kurang baik dengan idea tersebut, sengitnya diskusi tersebut uncle bob meninggalkan forum itu, dan di ikuti oleh Martin fowler dan Martin mengajak uncle bob untuk berdiskusi hal ini di chicago.
Pada musim gugur tahun 2000, uncle bob bertemu dengan martin di kantor ThoughtWorks tempat martin bekerja, uncle bob menjelaskan kepada martin tentang keinginannya untuk mengumpulkan orang-orang yang tertarik dengan Lightweight Process, untuk berkumpul dan membuat manifestasinya, Martin yang setuju dengan idea uncle bob langsung membuat undangan untuk orang-orang yang akan mereka undang dalam The lightweight Process Summit.
Alistair Cockburn adalah salah satu undangan dalam acara itu, yang bermaksud untuk membuat acara yang serupa, namun setelah berdiskusi dengan Uncle bob, Alistair cockburn pun merekomendasikan untuk menggabukan acaranya, dan dari sinilah mulai terbentuk pertemuan di Snowbird tersebut.
Gimana, Seru nggk ceritanya ? kita sudah tau kan asal muasal metode Waterfall , TDD, dll. keseruan ini masih berlanjut di part 3 , di tunggu ya