fluid-work IRC Logs-2008-06-09

Owned by Fluid IRC Log Bot
Last updated: Jun 09, 2008Version comment
7 min read

[09:38:03 EDT(-0400)] * anastasiac (n=team@142.150.154.105) has joined #fluid-work
[09:52:53 EDT(-0400)] * theclown (n=theclown@142.150.154.101) has joined #fluid-work
[10:07:02 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work
[10:08:36 EDT(-0400)] * smkeesle (n=smkeesle@h66.146.40.69.ip.alltel.net) has joined #fluid-work
[10:08:46 EDT(-0400)] * smkeesle (n=smkeesle@h66.146.40.69.ip.alltel.net) has left #fluid-work
[10:09:27 EDT(-0400)] * Kris_ (n=Kris@in-143-200.dhcp-149-166.iupui.edu) has joined #fluid-work
[10:24:28 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined #fluid-work
[10:44:39 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[11:06:21 EDT(-0400)] * Kris_ (n=Kris@in-99-248.dhcp-149-166.iupui.edu) has joined #fluid-work
[11:08:26 EDT(-0400)] * Kris__ (n=Kris@iupui-vpn-33-153.noc.iupui.edu) has joined #fluid-work
[11:32:36 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-38.LIPS.Berkeley.EDU) has joined #fluid-work
[12:02:43 EDT(-0400)] <ecochran> Michelle, Colin, Anastasia: anyone game for switching to jQuery 1.2.6 today?
[12:03:03 EDT(-0400)] * Kris_ (n=Kris@in-143-200.dhcp-149-166.iupui.edu) has joined #fluid-work
[12:03:17 EDT(-0400)] <ecochran> sorry I forgot, I have to do it this way
[12:03:51 EDT(-0400)] <ecochran> michelled, colinclark, anastasiac: anyone game for switching to jQuery 1.2.6 today?
[12:19:12 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has joined #fluid-work
[12:19:35 EDT(-0400)] <davidb> ecochran, colinclark, everyone... you probably saw jquery ui 1.5 was released?
[12:19:40 EDT(-0400)] <davidb> http://jquery.com/blog/2008/06/09/jquery-ui-v15-released-focus-on-consistent-api-and-effects/
[12:20:45 EDT(-0400)] <ecochran> davidb: no, I hadn't seen that
[12:20:48 EDT(-0400)] <ecochran> thks
[12:21:01 EDT(-0400)] <davidb> np
[12:21:07 EDT(-0400)] * davidb trundles away
[12:37:02 EDT(-0400)] <anastasiac> ecochran, hi - just saw your post (I was switched over to another account)
[12:37:19 EDT(-0400)] <anastasiac> regarding upgrading: it's definitely on the list - not sure about today
[12:40:07 EDT(-0400)] <anastasiac> our next dev iteration starts tomorrow - maybe slot it in for then? We're going to want some significant QA on it, so we should check with Jonathan's availability maybe
[12:40:07 EDT(-0400)] <anastasiac> do you know if there's a JIRA for the upgrade?
[12:40:25 EDT(-0400)] <anastasiac> doesn't seem to be one... I'll file it
[12:40:35 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[12:41:07 EDT(-0400)] <anastasiac> done: FLUID-714
[12:42:06 EDT(-0400)] <anastasiac> davidb, thanks for the heads-up re jquery UI release!
[12:48:04 EDT(-0400)] <colinclark> ecochran: The 1.2.6 update is going to be awesome.
[12:48:18 EDT(-0400)] <colinclark> Slightly sticky for us, though, because of our use of pre-release version of jQuery UI.
[12:48:32 EDT(-0400)] <colinclark> ecochran: So we'd want to go to jQuery UI 1.5 at the same time.
[12:48:46 EDT(-0400)] <colinclark> I'm thinking an experimental branch in the next day or so is in order.
[12:49:06 EDT(-0400)] <colinclark> Though I'm hesitant to make a full switch without doing a full round of QA to watch for regressions.
[12:49:07 EDT(-0400)] <ecochran> I would be a little wary of the jQuery UI 1.5 release
[12:49:18 EDT(-0400)] <ecochran> I would like to see it bake for at least a week
[12:49:41 EDT(-0400)] <colinclark> ecochran: That's the thing; it's risky to upgrade jQuery without also bring UI up to date.
[12:50:01 EDT(-0400)] <colinclark> That's why I'm suggesting a slightly conservative approach: branch, experiment, test.
[12:50:01 EDT(-0400)] <ecochran> colinclark: so we should wait a week on all of it
[12:50:09 EDT(-0400)] <colinclark> When we're sure, we can move trunk over.
[12:50:26 EDT(-0400)] <ecochran> I will start working with 1.2.6 in my own work today
[12:50:28 EDT(-0400)] * jessm (n=Jess@cpe-069-134-127-060.nc.res.rr.com) has joined #fluid-work
[12:50:33 EDT(-0400)] <colinclark> Would be nice to have Justin around to help out with this one. He doesn't start until the end of the month, however.
[12:50:53 EDT(-0400)] <michelled> ecochran, colinclark: I'm looking forward to the switch over. I was not too happy about shipping using a particular trunk checkout of jQuery UI
[12:51:07 EDT(-0400)] <ecochran> jQuery bugs show up very quickly because so many people are using it
[12:51:26 EDT(-0400)] <ecochran> the forums are seeing a few plugins breaking, esp. on IE
[12:51:51 EDT(-0400)] <ecochran> my worries about the jQuery UI code is just that there are so many fewer bodies playing with it
[12:52:15 EDT(-0400)] <ecochran> but you guys are right, ultimately what we care about is how it stacks up with our code
[12:55:09 EDT(-0400)] <colinclark> ecochran: Yep, exactly. And since our code also depends on aspects of jQuery UI, we need to test the full stack.
[12:55:53 EDT(-0400)] <colinclark> The nice thing is that the jQuery UI team did a great job of keeping the APIs and codebase quite stable throughout, so I expect it will be a pretty strong release.
[12:56:18 EDT(-0400)] <ecochran> I just realized, I can't start coding against the new jQuery stack until we all do, since my checkins might not run on the old base
[12:56:29 EDT(-0400)] <ecochran> so I'll wait until we can go through a test cycle
[12:56:34 EDT(-0400)] <ecochran> I'm just very eager
[12:58:28 EDT(-0400)] <michelled> Cool! They've actually looked at automated testing for drag an drop! One thing that can be crossed off my to-do list. (smile) Now I just need to find some time to write the tests!
[12:58:29 EDT(-0400)] <michelled> http://ui.jquery.com/bugs/browser/trunk/tests/simulate/jquery.simulate.js
[13:00:54 EDT(-0400)] <ecochran> michelled: what do you think about tests that are semi-automated? eg. there needs to be some minimum of user input...
[13:01:03 EDT(-0400)] <ecochran> I'm thinking of the uploader
[13:01:28 EDT(-0400)] <ecochran> since we can't select files any other way since the file selection happens in the swf
[13:01:57 EDT(-0400)] <michelled> ecochran: I think this sort of test needs to be covered in the QA plan for a component.
[13:02:13 EDT(-0400)] <ecochran> OK
[13:02:19 EDT(-0400)] <michelled> The only problem is that the QA plans don't get run nearly as often as the unit tests.
[13:02:29 EDT(-0400)] <ecochran> there still feels like part of it could be automated
[13:02:37 EDT(-0400)] <ecochran> but I'll leave that to Justin
[13:02:51 EDT(-0400)] <michelled> Can we set up a swf object and inject it into the uploader for unit tests?
[13:03:06 EDT(-0400)] <ecochran> I'm been thinking about that
[13:03:23 EDT(-0400)] <ecochran> we just don't know exactly what the swfObj does
[13:03:40 EDT(-0400)] <ecochran> we've been treating it as a blackbox
[13:03:47 EDT(-0400)] <ecochran> which feels right to me
[13:04:06 EDT(-0400)] <michelled> that makes sense. So now I feel like I should be able to duck type a swf object and inject that.
[13:04:19 EDT(-0400)] <michelled> We do know how we expect to interface with it after all.
[13:04:26 EDT(-0400)] <ecochran> yes
[13:05:06 EDT(-0400)] <ecochran> I had very good luck doing something like that for the demo code
[13:05:46 EDT(-0400)] <ecochran> I am sending the real events as much as possible
[13:06:00 EDT(-0400)] <colinclark> I'm in a call so half-distracted...
[13:06:05 EDT(-0400)] <ecochran> and just removed another 10 lines of demo cod last week
[13:06:14 EDT(-0400)] <michelled> right. I think that makes sense in the case of demo
[13:06:16 EDT(-0400)] <colinclark> Is there a way to specify a known filename to the component?
[13:06:35 EDT(-0400)] <colinclark> So that it is fully automated?
[13:07:46 EDT(-0400)] <michelled> I guess I need to look at what specifically we want to unit test but I'm wondering if we can create some super simple obj that responds to what ever we ask it with known answers. So for example, we set the file queue up and the files sizes etc.
[13:08:52 EDT(-0400)] <michelled> colinclark, do you mean the Uploader component or the swf object?
[13:09:11 EDT(-0400)] <colinclark> michelled: Well, I guess it's ultimately the swf uplader.
[13:09:14 EDT(-0400)] <colinclark> uploader
[13:12:00 EDT(-0400)] <ecochran> we can't do true uploads with out a true swfObj
[13:12:00 EDT(-0400)] <colinclark> michelled: Your strategy makes a lot of sense. Mocking things in a dynamic language is really easy. (smile)
[13:12:21 EDT(-0400)] <ecochran> the swfObj doesn't actually know the files paths, only the swf itself knows that for security reasons
[13:13:31 EDT(-0400)] <colinclark> At worst, this is something a Selenium test could cover. To test the whole workflow of uploading, we move from the realm of unit tests-testing each piece of behaviour individually-and into acceptance testing which encompasses larger sequences.
[13:13:59 EDT(-0400)] <michelled> again, I'm not close enough to the code to know but there may be things that we want to/can test in a unit test without doing a full upload.
[13:14:02 EDT(-0400)] <colinclark> So the idea of creating mock objects is to test our individual pieces of code.
[13:14:37 EDT(-0400)] <colinclark> michelled, ecochran: I think there likely is a lot we want to test without doing a full upload.
[13:15:42 EDT(-0400)] <ecochran> michelled, colinclark: agreed
[13:16:32 EDT(-0400)] <colinclark> When it comes to testing with real files, it sounds like a job for an automated Selenium acceptance test.
[13:24:15 EDT(-0400)] <ecochran> colinclark: still would need a fair amount of user input
[13:24:51 EDT(-0400)] <colinclark> ecochran: You can automate user input with Selenium. Have you ever taken a look at it? Quite cool.
[13:25:11 EDT(-0400)] <colinclark> ecochran: Megan May has been using it a lot for Sakai recently.
[13:29:43 EDT(-0400)] <ecochran> colinclark: I've used Selenium... very tricky stuff
[13:29:56 EDT(-0400)] <ecochran> but as far as I know it doesn't work outside the browser
[13:30:10 EDT(-0400)] <colinclark> ecochran: Cool. Yes, it's got its quirks. This seems like something it would handle well.
[13:30:13 EDT(-0400)] <ecochran> so the same issues we have with the swf, Selenium would have too
[13:30:42 EDT(-0400)] <colinclark> ecochran: Does not working outside of the browser matter? I can't imagine many useful tests that would work out of the browser.
[13:31:12 EDT(-0400)] <colinclark> You're right, though, that there would be up-front setup requirements to run the tests.
[13:31:21 EDT(-0400)] <ecochran> yes
[13:31:29 EDT(-0400)] <michelled> colinclark: the uploader brings up a dialog to the file system. I doubt selenium could talk to the dialog
[13:31:32 EDT(-0400)] <colinclark> ecochran: Not something you'd have running hourly on the daily build server, for example.
[13:31:37 EDT(-0400)] <michelled> sounds like a security issue
[13:31:47 EDT(-0400)] <colinclark> michelled: Really? Wow.
[13:31:48 EDT(-0400)] <ecochran> it's that damnable File OS dialog
[13:31:57 EDT(-0400)] <colinclark> We should try it.
[13:33:18 EDT(-0400)] <colinclark> michelled, ecochran: Yes, it looks like it can't work with the file chooser dialog.
[13:33:22 EDT(-0400)] <colinclark> (sad)
[13:33:55 EDT(-0400)] <colinclark> "Other special dialogs can't be dismissed by javascript, and thus currently cannot be interacted with. These include the "Save File", "Remember this Password" (Firefox), and modal (IE) dialogs. When they appear, Selenium can only wring its hands in despair."
[13:34:11 EDT(-0400)] <ecochran> in other news, I'm having a doozy of bug where I can't resume once I've paused... what is strange is that the problem doesn't appear to be on my end... all the right events are firing, the swf reports that the upload is starting and then... nothing... no progress events are coming back
[13:34:53 EDT(-0400)] <ecochran> and Ray is on vacation
[13:34:59 EDT(-0400)] <michelled> weird.
[13:35:16 EDT(-0400)] <michelled> are there forums for swf? Maybe someone else has bumped into this
[13:35:24 EDT(-0400)] <ecochran> yes, Ray on vacation is odd
[13:35:33 EDT(-0400)] <michelled> (smile)
[13:35:38 EDT(-0400)] <ecochran> I'll look
[13:35:55 EDT(-0400)] <ecochran> it was working fine forever... so I'm thinking that my Jetty is unhappy
[13:36:15 EDT(-0400)] <ecochran> But I'm continuing to look at the changes that I made
[13:37:51 EDT(-0400)] * davidb (n=davidb@142.150.154.101) has left #fluid-work
[13:46:06 EDT(-0400)] * jessm (n=Jess@cpe-069-134-127-060.nc.res.rr.com) has joined #fluid-work
[14:03:07 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[14:27:39 EDT(-0400)] <michelled> jessm: colin will be there in a moment - we are looking at an issue together right now
[14:27:57 EDT(-0400)] <jessm> k, thanks for letting me know
[14:31:32 EDT(-0400)] * Kris_ (n=Kris@in-143-200.dhcp-149-166.iupui.edu) has left #fluid-work
[16:18:17 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[16:23:37 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[17:07:34 EDT(-0400)] * JASIGLogBot (i=jasigch@jasigch.Princeton.EDU) has joined #fluid-work
[17:07:36 EDT(-0400)] * apetro-_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[17:25:48 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[18:06:52 EDT(-0400)] * michelled (n=team@142.150.154.197) has left #fluid-work
[18:09:15 EDT(-0400)] * theclown_afk (n=theclown@142.150.154.101) has left #fluid-work
[18:33:47 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[19:56:02 EDT(-0400)] * smkeesl1 (n=smkeesle@h66.146.40.69.ip.alltel.net) has joined #fluid-work
[20:05:46 EDT(-0400)] * apetro-- (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined #fluid-work
[20:24:15 EDT(-0400)] * jessm (n=Jess@cpe-069-134-127-060.nc.res.rr.com) has joined #fluid-work
[23:08:23 EDT(-0400)] * apetro-_ (n=apetro@ip68-98-37-188.ph.ph.cox.net) has joined #fluid-work