Arie Kusuma Atmaja wrote: > On 5/28/07, Andry S Huzain <[EMAIL PROTECTED]> wrote: >> > >> > On 5/28/07, Aditya Agustyana <[EMAIL PROTECTED]> wrote: >> > seperti yg kita ketahui RoR punya banyak tool untuk melakukan >> > debugging, dari mulai irb, ruby/script console, ruby >> > script/breakpointer sampe method <%= debug %> yg ada di view/helper >> > >> > nah yg ingin sy tanyakan, pada saat kapan dan bagaimana anda >> > menggunakan keempat hal tsb ? >> > >> > btw, selain keempat hal di atas... ada lagi ndak cara lain ntuk >> > melakukan debugging di RoR ? >> >> >> Mungkin ini bukan "debug" dalam arti sebetulnya, tapi saya sudah jarang >> banget melakukan "debugging" dengan prinsip-prinsip sederhana: >> >> * Setiap kali bikin controller + action, langsung tulis unit test-nya. >> Baik untuk model testing (untuk class-class Model) ataupun functional >> testing (untuk class-class Controller). Kan sudah disediain >> skeletonnya? Di >> RoR, rake:test itu adalah sahabat paling baik buat programmer :) > > Adit pakai autotest dit.. > > http://zentest.rubyforge.org/ZenTest/ > >> >> * Kedua, saya pakai logger. Meskipun develop di komputer sendiri, tapi >> selalu berpikiran bahwa aplikasi ini nanti akan ada di production server, >> dimana kita nggak bisa menjalankan script/console. Logger itu >> satu-satunya >> cara. >> >> * Ketiga, untuk test di tahap tatap muka web (a.k.a), saya pakai plugin >> Selenium IDE untuk Firefox. Kalau dibutuhkan ngetest di IE, baru pakai >> Watir. >> >> Paling banyak sih, yang bisa benar-benar dikatakan debugging sekarang >> cuma >> ada disisi javascript + AJAX + DOM menggunakan Firebug + Firefox. >> >> >> >> -- >> http://andryshuzain.com >
ada tulisan bagus :-D tau gini biasa, dari si pat maddox. sumber: http://weblogs.sqlteam.com/jeffs/archive/2007/05/23/60215.aspx Real Programmers don't need to write test applications! You are a very important, talented, enterprise-level programmer! You write and maintain millions of lines of code, compiling your applications takes several hours, and your databases contain hundreds of tables with millions of rows. Even the best and brightest and most experienced programmers, now and then, come upon a class or library or technique that is new to them. That's right, even you! You can admit it, no one's looking. But it really has no effect on your productivity, because you can quickly refer to the documentation or books or Google or many other resources to obtain the knowledge you need without missing a beat. Heck, you don't even need to post a question in a programming forum -- who could help you, after all? It's usually the other way around, right? So, you've done your research and gained the knowledge to use this feature and it's time to put it to use. Implementation -- that's what separates the men from the boys! You have a hectic schedule and you are very, very important with no time to waste, but you're armed with knowledge, you're feeling good, you just drank 4 diet Pepsis for the caffeine and you have an unlimited supply of Cheetos ready to go. No pressure, but the fate of the entire organization is counting on you. You open up your enterprise application in the development environment, wait 10 minutes for the massive project to load, and then you spend 20 more minutes carefully going through code and checking to see where the new feature needs to be implemented. It might be a new T-SQL feature in SQL 2005 that you are using, a library in .NET that you haven't worked yet, a general programming technique that you are about to employ for the first time, or maybe an external library that you will incorporate into your project. It's really irrelevant -- the key is, it's time to make some changes and you, and you alone, have the expertise to get it done on such a large scale application. After all, who else can go through millions of lines of code to figure it out? Not those junior programmers, that's for sure. They sure have a quirky way of doing things, mostly because they are not on the same time constraints and at the same level as you. You see, those junior programmers are just not capable of implementing and testing this new technique on your enterprise applications. They don't have the patience, the skill, or the know-how to do it. When you see them "working" on applications, you notice that a lot of time they seem to instead be working on "Hello World" projects! Simple 10 line projects! Single SELECT SQL statements! Talk about programmers who have much to learn! You haven't touched a simple project or SQL statement in years and you wouldn't be caught dead doing so! The horror! Could you imagine such a scenario? Hypothetical CIO: "Hey, have you finished the deployment of Complicated Enterprise Application 2007 yet?" Hypothetical You: "Uh no, sorry ... I am trying to get this console application to print my name." I mean, come on! So, the development environment is ready to go. You've read the documentation, you know exactly how to implement the new technique into your code, and after 10 or 15 minutes -- it's done! Not too shabby, eh? Time for a compile, another Pepsi, and a test run. Now, even the big-time programmers get bugs. You may be the best, but even the best experiences these, right? Sure enough, you get a run-time error. Back to the documentation. Ah ha! This class library requires a few more properties to be set up or there's some other tweak to make that wasn't specified in the documentation. Clickety-clickity-click -- done! Recompile ... wait ... execute the application ... wait ... drink a Pepsi .... wait ... bathroom break ...wait ... run the test ... wait .. Damn! Another run-time error. You notice some other quirk that wasn't clear in the documentation. Hmm, you may have to try this a few ways to get it to work right. Fair enough, that's how it goes for enterprise level important programmers, right? This stuff almost literally is rocket science, after all! Well, after several more changes and compiles, now it runs, but something doesn't quite look right. The new technique isn't doing just what you thought; time to make some changes. Back to the source code, check it out line by line, and run it again. You'll get it figured out before too long, right? Unfortunately, this is what happens when you work with complicated systems,and it's what you get paid for. One day, while waiting for the latest compile and then for the testing process to run, you look over and see "junior programmer #5" working again on yet another silly little program. "Hey junior!" you shout (they hate when you call them that), "what you got there? Tic Tac Toe??" "Um, no," he replies meekly, "I am testing a new component. I created a small, simple program that I can tweak and run quickly and easily so that I can be sure I understand how it works." "Whoah! Sounds complicated, junior!" You belch back sarcastically. "I guess that's why you make the big bucks like me, right! Look at this puppy," you say, pointing an orange cheese-covered finger towards your monitor, "over 10,000,000 lines of code! 10-tier architecture! I don't need no silly 'test application' to tell me how to program!" "Yeah, I guess I am pretty lame," junior responds, ashamed. "Remember last week when you recommended that I exclusively use FULL OUTER JOINS in my SQL code? I didn't understand how they work, so I did something similar to this ... I created two small tables, put in a few rows of sample data, ran some simple scripts in Query Analyzer and looked at the results, testing different joins and verifying the effect on the results. Because I am so new and inexperienced, it was the easiest way for me to learn how it works. Kind of embarrassing, huh?" You laugh. "Yikes! A newbie!" you exclaim, crumbs of Cheetos spitting from your mouth. "When I first used the new T-SQL features in 2005, I went straight to the General Ledger and started changing the reports! I don't have time to mess around! The data looked good to me after a few runs, the totals seem to match, it all compiled and worked after only a few tries. There were a few bugs here and there we are still looking in to, but I think it's unrelated. The real problem is waiting for those damn QA guys to finish testing and tying out the ledger reports to let me know if things are working right. How the hell can I be sure that these T-SQL enhancements work correctly until they get back to me with the results??!! It takes them forever! Idiots!" Junior nods and goes back to "work" on his "important project." Ah, kids these days .... Anyway, the compile is done, the program is executing -- and it looks OK! It took several weeks of work and lots of tweaking, but it looks right as best you can tell, the new technique you've used seems to work fine. There was some trial and error (the damn documentation wasn't clear!) but you've got it now. You send off the latest build to the QA guys, and add another bullet point to your resume! A job well done, you sit back, put your stocking-and-sandaled feet up on your desk and look over at Junior while you absent-mindedly play with your pony tail.... Poor Junior, he has a lot to learn from you about programming! Print | posted on Wednesday, May 23, 2007 12:27 PM | Filed Under [ Humor Miscellaneous Techniques ] Feedback # re: Real Programmers don't need to write test applications! Lol, Call me a Junior or a Newbie all ya want Mr. "Enterprise Developer". I'll write my test apps (Or rather Unit and Integration tests) regardless ;) It is interesting speaking with guys who approach development this way and how they don't seem to recognize that half their job as a good engineer/developer is ensuring quality, not just quantity in what they produce. That's where the real ROI for a company is in custom software. Your time is cheap compared to the 10s, 100s, or even 1000s using your software and how much they cost the company with every bug they encounter. 5/23/2007 1:06 PM | Lucas Goodwin # re: Real Programmers don't need to write test applications! What senior level dev is this targeted at?? I think it's the junior guys who do what you describe. Everyone longtime dev I work with is perfectly comfortable writing small test programs, and does so quite often. It would be impossible to work with huge APIs like the .NET Framework without testing in at least some kind of isolation... BTW, was "I mean, come on!" a reference to the South Park "Cripple Fight" episode? 5/23/2007 1:21 PM | Adam Machanic # re: Real Programmers don't need to write test applications! Well, I call myself a Senior Developer, having 20 years of experience, and I am doing Unit-Tests for the last 7 years or so. I am also trying to convince all of the colleages I get to work with, if they don't already unit-test their stuff. But I was simply baffled at the answer I got from someone "more senior" than me: "If you program correctly from the start and do a little thinking beforehand, then you don't need no stinking test cases, then they're all superfluous" Oh well. Can I go and shoot the guy? 5/23/2007 1:42 PM | Daniel # re: Real Programmers don't need to write test applications! ok... how much did you get from Pepsi for that story? :))) 5/23/2007 3:10 PM | Mladen # re: Real Programmers don't need to write test applications! Hi Adam -- weird, for some reason your feedback gets flagged as spam ... stop pimping viagra so much!! Anyway, my joke is that the programmer isn't as senior or as important as he thinks he is ... we see these people all the time, especially in the sqlteam forums. Someone will dump a huge SQL statement and ask for help on a LEFT OUTER JOIN and how it works, and I always tell them: If you don't know how a left outer join works, don't just try it in your production code! Use northwind or a table of fruits or numbers or letters and LEARN how it works! don't just run it on your actual data and hope that it "looks ok"! Of course, they always refuse, because they just don't have time and they don't see the value in doing that. Same with reports, even Excel formulas .... I see it over and over ... I just find it funny. You're right, Adam, a true senior developer will ALWAYS break things down into small, simple apps to test and learn new techniques. You're lucky to have worked with good developers over the years, because I sure haven't! 5/23/2007 3:20 PM | Jeff # re: Real Programmers don't need to write test applications! mladen -- I negotiated with Mountain Dew but they wouldn't meet my price .... :) 5/23/2007 3:28 PM | Jeff # re: Real Programmers don't need to write test applications! Yet another great article. Thanks Jeff, I see this all the time, was once a victim myself..bit me in the arse too many times. 5/23/2007 5:43 PM | Jon # re: Real Programmers don't need to write test applications! You had me convinced you were a "real" programmer until you reached "class library". Unless by "class library" you mean a library of assembler defines that somehow emulate a class. 5/24/2007 1:37 AM | Andrew # re: Real Programmers don't need to write test applications! http://en.wikipedia.org/wiki/Class_library 5/24/2007 7:29 AM | Adam Machanic # re: Real Programmers don't need to write test applications! I have on more than one occasion had to bring a 'senior developer' down to earth by teaching them of Failures Rich Rewards. One of the most effective ways of doing this is locking them out of source control until they can demonstrate that their solution works in isolation and in a controlled (sandboxed) environment. They kick and scream for the first couple of times but when they miss their first deadline and the managers descend they're usually more than happy to do all the testing they can. This topic could also be extended to many other engineering related topics. Like Real Programmers don't use branches, or Real Programmers don't use source control. Great article! 5/24/2007 8:55 AM | R Keith -- Arie || ariekeren, YM!=riyari3, http://ariekusumaatmaja.wordpress.com http://groups.yahoo.com/groups/id-ruby "Never say RTFM. Turn the trolls into committers", Audrey Tang - conisli-ofun.pdf
