From bret at pettichord.com Tue Nov 6 14:34:39 2007 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 6 Nov 2007 13:34:39 -0600 Subject: [Wtr-development] Thoughts on FireWatir Message-ID: Over the past week, I've taken a close look at FireWatir, with two questions in mind. First, can we make use of it at Dovetail to execute our tests? We have a Watir-based test suite that has over 50 tests and runs in nearly 5 minutes. We've developed it over the past couple of months for a new product. Many of our developers are developing on Macs, so they have a particular interest in using Firefox for testing. Our app needs to support both IE and Firefox. Secondly, what is the best way to get FireWatir in sync with Watir 1.5 and how should we maintain it going forward? This is a harder question, for a number of reasons that I will try to explain. FireWatir is based on Watir 1.4. Angrez Singh and the Firewatir team took a copy of the Watir 1.4 code base and then changed it so that it would work with Firefox instead. A lot of the Watir code was reused. It essential amounts to a fork of Watir 1.4. In the past two years since, the Watir code base has evolved significantly. We've cleaned up a lot of the code (both library and test code), refactored much of the code to remove duplication and added support for new attributes and methods (including multiple-attribute support). Few of these changes have been backported to the Firewatir code base. For me, reading through the Firewatir code during the past week has often felt like a trip back in time. The more that I've reviewed it, the more that I've realized that maintaining FireWatir as a separate code base is a dead end. Some of the classes are direct copies of the original Watir classes (some of which have since changed), some have minor modifications, others are completely changed. Clearly the right way to support this going forward would be to share the classes that can be the same, and refactor the code to maximize the use of shared classes. Indeed, Watir needs a pluggable architecture that will allow adapters for particular browsers, thus supporting SafariWatir and Selenium-RC integration as well. Figuring out how to do this is not trivial. At the same time, it is consistent with the kind of technical refactoring we've been doing for some time in the Watir 1.5 code base. Incremental refactoring of both the code bases is possible because they both have comprehensive test suites that we can use to ensure that the necessary architectural changes don't break the software. The place to start integrating the two code bases is probably with with tests themselves. Very few changes should be needed to allow the tests to run against either Watir::IE or FireWatir. After reviewing the code, it is pretty clear that running the Watir tests against Firewatir would result in dozens of failures, mostly indications of gaps between where Watir and FireWatir stand today. But synchronizing the test suite and providing a means to mark individual tests as specific to IE or Firefox is really the only way to ensure that the two versions stay in sync. Some have asked about the core mechanism used in FireWatir. FireWatir requires a Firefox plugin called the Javascript Shell or JSSH. This plugin provides a console interface to the Javascript running in the browser. Once installed, you can actually telnet into Firefox and execute javascript commands. FireWatir connects to this interface using a socket. The basic mechanism is powerful, because it means that anything that can be done in Javascript can be done with FireWatir. However it does require that the plug in be installed first. JSSH is currently provided for Windows (32 bit), Linux and Mac. It is not currently available for FireFox 3.0 (Gran Paradiso) currently under development. Althought it was apparently development independently, it seems that FireWatir users are currently the only users of JSSH. The JSSH code base is open-source, and indeed part of the Firefox code base, but it is unclear to me whether anyone is committed to maintaining this code going forward. This seems to me to be the greatest long-term risk as regards FireWatir. Also the various builds of JSSH that are available appear to have been compiled by different people and different times and they do not seem to have a common or consistent convention regarding versioning. I would feel a lot better if this had some more organizition behind it. Perhaps this could be sponsored by the Mozilla Foundation. Going forward with developing a single code base supporting two browsers will require us to have a stricter testing policy that we've had so far. Installing CruiseControl.rb (link) on a Windows virtual server will allow us to automatically run our tests on both IE and Firefox whenever code changes are made. The results would be public, so any one could see them. Having this in place makes it easier for us to coordinate the work of multiple contributors who may be using different development platforms. A hosted Windows virtual server, which is what we would need to run our tests, costs about $50 a month. This makes me think that it may now be time to pass the hat and ask users to help fund Watir development going forward. I'm not sure if I should simply ask people to send me money (say, using a paypal button), or whether we should go through the formality of setting up a non-profit or selling memberships in a society. I'd appreciate your thoughts on this. Jason Darling suggests T-shirts sales. In working with FireWatir this week, I spent a lot of time struggling with a speed issue. My tests would run very slowly, especially when typing. They seemed slower than what a manual tester would do. Tests would run fine for a bit, and then would suddenly slow down, making me think that some kind of resource had been exhausted. Although it showed up slightly differently in different circumstances, I reproduced the problem on three different machines, with both XP and Vista, and both with the Dovetail test suite and the FireWatir unit tests. I have also spoken with both Paul Rogers and Jim Matthews, both of who have made significant use of FireWatir and have not seen this problem. Indeed, Jim says that FireWatir is faster than Watir for him. I eventually found a workaround for my speed problem, but it remains an issue of concern for me. I don't know whether the problem lies in FireWatir itself or in the JSSH plugin. The next step would be to add a debugging/logging layer to FireWatir to help debug these and other issues. In running the Dovetail tests, I ran into five specific errors, blocking about 90% of the tests. Three were obviously caused by missing features new to Watir 1.5. I suspect the other two were also in this category, but did not have time to track them down far enough. In investigating these issues, I noticed that the attach command was missing. I use this all the time to debug tests. Without it, my ability to investigate the source of errors was limited. This feature was included in Watir 1.4; I'm not sure why it isn't in FireWatir. The missing features I looked into could be added to FireWatir trivially. Merging the code bases would accomplish this as a side effect. Looking forward, I think it will be a long term project to integrate Watir and FireWatir. We don't have many contributors, all of us mostly work on Watir on our own time. It took us two years to go from 1.4 to 1.5 and I think it will be a similar timeframe to see the complete integration of Watir and FireWatir. -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-development/attachments/20071106/6fb4cf2a/attachment.html From nathamberlane at gmail.com Wed Nov 7 08:26:22 2007 From: nathamberlane at gmail.com (Nathan Lane) Date: Wed, 7 Nov 2007 06:26:22 -0700 Subject: [Wtr-development] Thoughts on FireWatir In-Reply-To: References: Message-ID: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> So this seems like an awesome idea to me. I'm not any kind of official developer for WATIR, but i'd be willing to become one. I wouldn't mind volunteering my time regularly also in order to keep the project away from needing much, if any, money. I developed the library that helps access spreadsheets through UNO and OpenOffice.org in Ruby (that a couple of people have picked up using). I'd like to see FireWatir and Watir unified in some pluggable way also, so that all I need to do is specify what browser I want to use, and with that also do SafariWatir at some point. My skills in these areas include understanding OLE/COM/UNO, JavaScript, XML, ReXML, XPath, and Ruby (though I haven't pinned down all of the Ruby coding conventions just yet - I still use a variety of syntaxes I think.) Please let me know how I can help in these matters. Again I require no funding, and can work on this regularly. I'd like to do that to make Watir even more usable as a test tool and to get my name out there. Thanks Nathan Lane On 11/6/07, Bret Pettichord wrote: > > Over the past week, I've taken a close look at FireWatir, with two > questions in mind. First, can we make use of it at Dovetail to execute our > tests? We have a Watir-based test suite that has over 50 tests and runs in > nearly 5 minutes. We've developed it over the past couple of months for a > new product. Many of our developers are developing on Macs, so they have a > particular interest in using Firefox for testing. Our app needs to support > both IE and Firefox. > > Secondly, what is the best way to get FireWatir in sync with Watir 1.5 and > how should we maintain it going forward? This is a harder question, for a > number of reasons that I will try to explain. > > FireWatir is based on Watir 1.4. Angrez Singh and the Firewatir team took > a copy of the Watir 1.4 code base and then changed it so that it would > work with Firefox instead. A lot of the Watir code was reused. It essential > amounts to a fork of Watir 1.4 . In the past two years since, the Watir > code base has evolved significantly. We've cleaned up a lot of the code > (both library and test code), refactored much of the code to remove > duplication and added support for new attributes and methods (including > multiple-attribute support). Few of these changes have been backported to > the Firewatir code base. For me, reading through the Firewatir code during > the past week has often felt like a trip back in time. > > The more that I've reviewed it, the more that I've realized that > maintaining FireWatir as a separate code base is a dead end. Some of the > classes are direct copies of the original Watir classes (some of which have > since changed), some have minor modifications, others are completely > changed. Clearly the right way to support this going forward would be to > share the classes that can be the same, and refactor the code to maximize > the use of shared classes. Indeed, Watir needs a pluggable architecture that > will allow adapters for particular browsers, thus supporting SafariWatir and > Selenium-RC integration as well. Figuring out how to do this is not trivial. > At the same time, it is consistent with the kind of technical refactoring > we've been doing for some time in the Watir 1.5 code base. Incremental > refactoring of both the code bases is possible because they both have > comprehensive test suites that we can use to ensure that the necessary > architectural changes don't break the software. > > The place to start integrating the two code bases is probably with with > tests themselves. Very few changes should be needed to allow the tests to > run against either Watir::IE or FireWatir. After reviewing the code, it is > pretty clear that running the Watir tests against Firewatir would result in > dozens of failures, mostly indications of gaps between where Watir and > FireWatir stand today. But synchronizing the test suite and providing a > means to mark individual tests as specific to IE or Firefox is really the > only way to ensure that the two versions stay in sync. > > Some have asked about the core mechanism used in FireWatir. FireWatir > requires a Firefox plugin called the Javascript Shell or JSSH. This plugin > provides a console interface to the Javascript running in the browser. Once > installed, you can actually telnet into Firefox and execute javascript > commands. FireWatir connects to this interface using a socket. The basic > mechanism is powerful, because it means that anything that can be done in > Javascript can be done with FireWatir. However it does require that the plug > in be installed first. JSSH is currently provided for Windows (32 bit), > Linux and Mac. It is not currently available for FireFox 3.0 (Gran > Paradiso) currently under development. Althought it was apparently > development independently, it seems that FireWatir users are currently the > only users of JSSH. The JSSH code base is open-source, and indeed part of > the Firefox code base, but it is unclear to me whether anyone is committed > to maintaining this code going forward. This seems to me to be the greatest > long-term risk as regards FireWatir. Also the various builds of JSSH that > are available appear to have been compiled by different people and different > times and they do not seem to have a common or consistent convention > regarding versioning. I would feel a lot better if this had some more > organizition behind it. Perhaps this could be sponsored by the Mozilla > Foundation. > > Going forward with developing a single code base supporting two browsers > will require us to have a stricter testing policy that we've had so far. > Installing CruiseControl.rb (link) on a Windows virtual server will allow > us to automatically run our tests on both IE and Firefox whenever code > changes are made. The results would be public, so any one could see them. > Having this in place makes it easier for us to coordinate the work of > multiple contributors who may be using different development platforms. A > hosted Windows virtual server, which is what we would need to run our tests, > costs about $50 a month. This makes me think that it may now be time to pass > the hat and ask users to help fund Watir development going forward. I'm not > sure if I should simply ask people to send me money (say, using a paypal > button), or whether we should go through the formality of setting up a > non-profit or selling memberships in a society. I'd appreciate your thoughts > on this. Jason Darling suggests T-shirts sales. > > In working with FireWatir this week, I spent a lot of time struggling with > a speed issue. My tests would run very slowly, especially when typing. They > seemed slower than what a manual tester would do. Tests would run fine for a > bit, and then would suddenly slow down, making me think that some kind of > resource had been exhausted. Although it showed up slightly differently in > different circumstances, I reproduced the problem on three different > machines, with both XP and Vista, and both with the Dovetail test suite and > the FireWatir unit tests. I have also spoken with both Paul Rogers and Jim > Matthews, both of who have made significant use of FireWatir and have not > seen this problem. Indeed, Jim says that FireWatir is faster than Watir for > him. I eventually found a workaround for my speed problem, but it remains an > issue of concern for me. I don't know whether the problem lies in FireWatir > itself or in the JSSH plugin. The next step would be to add a > debugging/logging layer to FireWatir to help debug these and other issues. > > In running the Dovetail tests, I ran into five specific errors, blocking > about 90% of the tests. Three were obviously caused by missing features new > to Watir 1.5. I suspect the other two were also in this category, but did > not have time to track them down far enough. In investigating these issues, > I noticed that the attach command was missing. I use this all the time to > debug tests. Without it, my ability to investigate the source of errors was > limited. This feature was included in Watir 1.4; I'm not sure why it isn't > in FireWatir. The missing features I looked into could be added to FireWatir > trivially. Merging the code bases would accomplish this as a side effect. > > Looking forward, I think it will be a long term project to integrate Watir > and FireWatir. We don't have many contributors, all of us mostly work on > Watir on our own time. It took us two years to go from 1.4 to 1.5 and I > think it will be a similar timeframe to see the complete integration of > Watir and FireWatir. > > -- > Bret Pettichord > Lead Developer, Watir, http://wtr.rubyforge.org > Blog, http://www.io.com/~wazmo/blog > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Nathan Lane -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-development/attachments/20071107/76deb145/attachment-0001.html From bret at pettichord.com Wed Nov 7 15:36:00 2007 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 7 Nov 2007 14:36:00 -0600 Subject: [Wtr-development] Website update Message-ID: Zeljko, I updated the wtr.rubyforge.org website with the changes that you made a couple of weeks ago. Also granted you access to Rubyforge so you can make these updates yourself in the future. Thanks for your help. The Documentation page should probably be updated further to keep up with other changes you've made since. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-development/attachments/20071107/5bdeb663/attachment.html From zeljko.filipin at gmail.com Thu Nov 8 11:02:17 2007 From: zeljko.filipin at gmail.com (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 8 Nov 2007 17:02:17 +0100 Subject: [Wtr-development] Website update In-Reply-To: References: Message-ID: On Nov 7, 2007 9:36 PM, Bret Pettichord wrote: > I updated the wtr.rubyforge.org website with the changes that you made a > couple of weeks ago. Thanks Also granted you access to Rubyforge so you can make these updates yourself > in the future. I browsed admin pages, but could not find where web site should be updated. Can you help me? > Thanks for your help. Glad I could help. > The Documentation page should probably be updated further to keep up with > other changes you've made since. Sure. I am done with work for today, but I hope I will have some time tomorrow. ?eljko -- ZeljkoFilipin.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-development/attachments/20071108/c44b8127/attachment.html From bret at pettichord.com Thu Nov 8 11:20:53 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 8 Nov 2007 10:20:53 -0600 Subject: [Wtr-development] Website update In-Reply-To: References: Message-ID: On Nov 8, 2007 10:02 AM, ?eljko Filipin wrote: > > I browsed admin pages, but could not find where web site should be > updated. Can you help me? > You use ftp. I'm sending details privately. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-development/attachments/20071108/e79f991b/attachment.html From bret at pettichord.com Thu Nov 8 11:42:05 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 8 Nov 2007 10:42:05 -0600 Subject: [Wtr-development] Thoughts on FireWatir In-Reply-To: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> References: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> Message-ID: On Nov 7, 2007 7:26 AM, Nathan Lane wrote: > So this seems like an awesome idea to me. I'm not any kind of official > developer for WATIR, but i'd be willing to become one. I wouldn't mind > volunteering my time regularly also in order to keep the project away from > needing much, if any, money. I developed the library that helps access > spreadsheets through UNO and OpenOffice.org in Ruby (that a couple of > people have picked up using). I'd like to see FireWatir and Watir unified > in some pluggable way also, so that all I need to do is specify what browser > I want to use, and with that also do SafariWatir at some point. My skills > in these areas include understanding OLE/COM/UNO, JavaScript, XML, ReXML, > XPath, and Ruby (though I haven't pinned down all of the Ruby coding > conventions just yet - I still use a variety of syntaxes I think.) Please > let me know how I can help in these matters. Again I require no funding, and > can work on this regularly. I'd like to do that to make Watir even more > usable as a test tool and to get my name out there. > You've been a great help to the community in the past and we'd love to have more of your help. If you would like commit rights, the next step would be for you to submit a patch to the Watir/FireWatir code base. Or you can continue to support related projects, such as the oohelper, for which we are very greatful. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wtr-development/attachments/20071108/7b7a22d2/attachment.html From bret at pettichord.com Tue Nov 6 14:34:39 2007 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 6 Nov 2007 13:34:39 -0600 Subject: [Wtr-development] Thoughts on FireWatir Message-ID: Over the past week, I've taken a close look at FireWatir, with two questions in mind. First, can we make use of it at Dovetail to execute our tests? We have a Watir-based test suite that has over 50 tests and runs in nearly 5 minutes. We've developed it over the past couple of months for a new product. Many of our developers are developing on Macs, so they have a particular interest in using Firefox for testing. Our app needs to support both IE and Firefox. Secondly, what is the best way to get FireWatir in sync with Watir 1.5 and how should we maintain it going forward? This is a harder question, for a number of reasons that I will try to explain. FireWatir is based on Watir 1.4. Angrez Singh and the Firewatir team took a copy of the Watir 1.4 code base and then changed it so that it would work with Firefox instead. A lot of the Watir code was reused. It essential amounts to a fork of Watir 1.4. In the past two years since, the Watir code base has evolved significantly. We've cleaned up a lot of the code (both library and test code), refactored much of the code to remove duplication and added support for new attributes and methods (including multiple-attribute support). Few of these changes have been backported to the Firewatir code base. For me, reading through the Firewatir code during the past week has often felt like a trip back in time. The more that I've reviewed it, the more that I've realized that maintaining FireWatir as a separate code base is a dead end. Some of the classes are direct copies of the original Watir classes (some of which have since changed), some have minor modifications, others are completely changed. Clearly the right way to support this going forward would be to share the classes that can be the same, and refactor the code to maximize the use of shared classes. Indeed, Watir needs a pluggable architecture that will allow adapters for particular browsers, thus supporting SafariWatir and Selenium-RC integration as well. Figuring out how to do this is not trivial. At the same time, it is consistent with the kind of technical refactoring we've been doing for some time in the Watir 1.5 code base. Incremental refactoring of both the code bases is possible because they both have comprehensive test suites that we can use to ensure that the necessary architectural changes don't break the software. The place to start integrating the two code bases is probably with with tests themselves. Very few changes should be needed to allow the tests to run against either Watir::IE or FireWatir. After reviewing the code, it is pretty clear that running the Watir tests against Firewatir would result in dozens of failures, mostly indications of gaps between where Watir and FireWatir stand today. But synchronizing the test suite and providing a means to mark individual tests as specific to IE or Firefox is really the only way to ensure that the two versions stay in sync. Some have asked about the core mechanism used in FireWatir. FireWatir requires a Firefox plugin called the Javascript Shell or JSSH. This plugin provides a console interface to the Javascript running in the browser. Once installed, you can actually telnet into Firefox and execute javascript commands. FireWatir connects to this interface using a socket. The basic mechanism is powerful, because it means that anything that can be done in Javascript can be done with FireWatir. However it does require that the plug in be installed first. JSSH is currently provided for Windows (32 bit), Linux and Mac. It is not currently available for FireFox 3.0 (Gran Paradiso) currently under development. Althought it was apparently development independently, it seems that FireWatir users are currently the only users of JSSH. The JSSH code base is open-source, and indeed part of the Firefox code base, but it is unclear to me whether anyone is committed to maintaining this code going forward. This seems to me to be the greatest long-term risk as regards FireWatir. Also the various builds of JSSH that are available appear to have been compiled by different people and different times and they do not seem to have a common or consistent convention regarding versioning. I would feel a lot better if this had some more organizition behind it. Perhaps this could be sponsored by the Mozilla Foundation. Going forward with developing a single code base supporting two browsers will require us to have a stricter testing policy that we've had so far. Installing CruiseControl.rb (link) on a Windows virtual server will allow us to automatically run our tests on both IE and Firefox whenever code changes are made. The results would be public, so any one could see them. Having this in place makes it easier for us to coordinate the work of multiple contributors who may be using different development platforms. A hosted Windows virtual server, which is what we would need to run our tests, costs about $50 a month. This makes me think that it may now be time to pass the hat and ask users to help fund Watir development going forward. I'm not sure if I should simply ask people to send me money (say, using a paypal button), or whether we should go through the formality of setting up a non-profit or selling memberships in a society. I'd appreciate your thoughts on this. Jason Darling suggests T-shirts sales. In working with FireWatir this week, I spent a lot of time struggling with a speed issue. My tests would run very slowly, especially when typing. They seemed slower than what a manual tester would do. Tests would run fine for a bit, and then would suddenly slow down, making me think that some kind of resource had been exhausted. Although it showed up slightly differently in different circumstances, I reproduced the problem on three different machines, with both XP and Vista, and both with the Dovetail test suite and the FireWatir unit tests. I have also spoken with both Paul Rogers and Jim Matthews, both of who have made significant use of FireWatir and have not seen this problem. Indeed, Jim says that FireWatir is faster than Watir for him. I eventually found a workaround for my speed problem, but it remains an issue of concern for me. I don't know whether the problem lies in FireWatir itself or in the JSSH plugin. The next step would be to add a debugging/logging layer to FireWatir to help debug these and other issues. In running the Dovetail tests, I ran into five specific errors, blocking about 90% of the tests. Three were obviously caused by missing features new to Watir 1.5. I suspect the other two were also in this category, but did not have time to track them down far enough. In investigating these issues, I noticed that the attach command was missing. I use this all the time to debug tests. Without it, my ability to investigate the source of errors was limited. This feature was included in Watir 1.4; I'm not sure why it isn't in FireWatir. The missing features I looked into could be added to FireWatir trivially. Merging the code bases would accomplish this as a side effect. Looking forward, I think it will be a long term project to integrate Watir and FireWatir. We don't have many contributors, all of us mostly work on Watir on our own time. It took us two years to go from 1.4 to 1.5 and I think it will be a similar timeframe to see the complete integration of Watir and FireWatir. -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathamberlane at gmail.com Wed Nov 7 08:26:22 2007 From: nathamberlane at gmail.com (Nathan Lane) Date: Wed, 7 Nov 2007 06:26:22 -0700 Subject: [Wtr-development] Thoughts on FireWatir In-Reply-To: References: Message-ID: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> So this seems like an awesome idea to me. I'm not any kind of official developer for WATIR, but i'd be willing to become one. I wouldn't mind volunteering my time regularly also in order to keep the project away from needing much, if any, money. I developed the library that helps access spreadsheets through UNO and OpenOffice.org in Ruby (that a couple of people have picked up using). I'd like to see FireWatir and Watir unified in some pluggable way also, so that all I need to do is specify what browser I want to use, and with that also do SafariWatir at some point. My skills in these areas include understanding OLE/COM/UNO, JavaScript, XML, ReXML, XPath, and Ruby (though I haven't pinned down all of the Ruby coding conventions just yet - I still use a variety of syntaxes I think.) Please let me know how I can help in these matters. Again I require no funding, and can work on this regularly. I'd like to do that to make Watir even more usable as a test tool and to get my name out there. Thanks Nathan Lane On 11/6/07, Bret Pettichord wrote: > > Over the past week, I've taken a close look at FireWatir, with two > questions in mind. First, can we make use of it at Dovetail to execute our > tests? We have a Watir-based test suite that has over 50 tests and runs in > nearly 5 minutes. We've developed it over the past couple of months for a > new product. Many of our developers are developing on Macs, so they have a > particular interest in using Firefox for testing. Our app needs to support > both IE and Firefox. > > Secondly, what is the best way to get FireWatir in sync with Watir 1.5 and > how should we maintain it going forward? This is a harder question, for a > number of reasons that I will try to explain. > > FireWatir is based on Watir 1.4. Angrez Singh and the Firewatir team took > a copy of the Watir 1.4 code base and then changed it so that it would > work with Firefox instead. A lot of the Watir code was reused. It essential > amounts to a fork of Watir 1.4 . In the past two years since, the Watir > code base has evolved significantly. We've cleaned up a lot of the code > (both library and test code), refactored much of the code to remove > duplication and added support for new attributes and methods (including > multiple-attribute support). Few of these changes have been backported to > the Firewatir code base. For me, reading through the Firewatir code during > the past week has often felt like a trip back in time. > > The more that I've reviewed it, the more that I've realized that > maintaining FireWatir as a separate code base is a dead end. Some of the > classes are direct copies of the original Watir classes (some of which have > since changed), some have minor modifications, others are completely > changed. Clearly the right way to support this going forward would be to > share the classes that can be the same, and refactor the code to maximize > the use of shared classes. Indeed, Watir needs a pluggable architecture that > will allow adapters for particular browsers, thus supporting SafariWatir and > Selenium-RC integration as well. Figuring out how to do this is not trivial. > At the same time, it is consistent with the kind of technical refactoring > we've been doing for some time in the Watir 1.5 code base. Incremental > refactoring of both the code bases is possible because they both have > comprehensive test suites that we can use to ensure that the necessary > architectural changes don't break the software. > > The place to start integrating the two code bases is probably with with > tests themselves. Very few changes should be needed to allow the tests to > run against either Watir::IE or FireWatir. After reviewing the code, it is > pretty clear that running the Watir tests against Firewatir would result in > dozens of failures, mostly indications of gaps between where Watir and > FireWatir stand today. But synchronizing the test suite and providing a > means to mark individual tests as specific to IE or Firefox is really the > only way to ensure that the two versions stay in sync. > > Some have asked about the core mechanism used in FireWatir. FireWatir > requires a Firefox plugin called the Javascript Shell or JSSH. This plugin > provides a console interface to the Javascript running in the browser. Once > installed, you can actually telnet into Firefox and execute javascript > commands. FireWatir connects to this interface using a socket. The basic > mechanism is powerful, because it means that anything that can be done in > Javascript can be done with FireWatir. However it does require that the plug > in be installed first. JSSH is currently provided for Windows (32 bit), > Linux and Mac. It is not currently available for FireFox 3.0 (Gran > Paradiso) currently under development. Althought it was apparently > development independently, it seems that FireWatir users are currently the > only users of JSSH. The JSSH code base is open-source, and indeed part of > the Firefox code base, but it is unclear to me whether anyone is committed > to maintaining this code going forward. This seems to me to be the greatest > long-term risk as regards FireWatir. Also the various builds of JSSH that > are available appear to have been compiled by different people and different > times and they do not seem to have a common or consistent convention > regarding versioning. I would feel a lot better if this had some more > organizition behind it. Perhaps this could be sponsored by the Mozilla > Foundation. > > Going forward with developing a single code base supporting two browsers > will require us to have a stricter testing policy that we've had so far. > Installing CruiseControl.rb (link) on a Windows virtual server will allow > us to automatically run our tests on both IE and Firefox whenever code > changes are made. The results would be public, so any one could see them. > Having this in place makes it easier for us to coordinate the work of > multiple contributors who may be using different development platforms. A > hosted Windows virtual server, which is what we would need to run our tests, > costs about $50 a month. This makes me think that it may now be time to pass > the hat and ask users to help fund Watir development going forward. I'm not > sure if I should simply ask people to send me money (say, using a paypal > button), or whether we should go through the formality of setting up a > non-profit or selling memberships in a society. I'd appreciate your thoughts > on this. Jason Darling suggests T-shirts sales. > > In working with FireWatir this week, I spent a lot of time struggling with > a speed issue. My tests would run very slowly, especially when typing. They > seemed slower than what a manual tester would do. Tests would run fine for a > bit, and then would suddenly slow down, making me think that some kind of > resource had been exhausted. Although it showed up slightly differently in > different circumstances, I reproduced the problem on three different > machines, with both XP and Vista, and both with the Dovetail test suite and > the FireWatir unit tests. I have also spoken with both Paul Rogers and Jim > Matthews, both of who have made significant use of FireWatir and have not > seen this problem. Indeed, Jim says that FireWatir is faster than Watir for > him. I eventually found a workaround for my speed problem, but it remains an > issue of concern for me. I don't know whether the problem lies in FireWatir > itself or in the JSSH plugin. The next step would be to add a > debugging/logging layer to FireWatir to help debug these and other issues. > > In running the Dovetail tests, I ran into five specific errors, blocking > about 90% of the tests. Three were obviously caused by missing features new > to Watir 1.5. I suspect the other two were also in this category, but did > not have time to track them down far enough. In investigating these issues, > I noticed that the attach command was missing. I use this all the time to > debug tests. Without it, my ability to investigate the source of errors was > limited. This feature was included in Watir 1.4; I'm not sure why it isn't > in FireWatir. The missing features I looked into could be added to FireWatir > trivially. Merging the code bases would accomplish this as a side effect. > > Looking forward, I think it will be a long term project to integrate Watir > and FireWatir. We don't have many contributors, all of us mostly work on > Watir on our own time. It took us two years to go from 1.4 to 1.5 and I > think it will be a similar timeframe to see the complete integration of > Watir and FireWatir. > > -- > Bret Pettichord > Lead Developer, Watir, http://wtr.rubyforge.org > Blog, http://www.io.com/~wazmo/blog > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Nathan Lane -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Nov 7 15:36:00 2007 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 7 Nov 2007 14:36:00 -0600 Subject: [Wtr-development] Website update Message-ID: Zeljko, I updated the wtr.rubyforge.org website with the changes that you made a couple of weeks ago. Also granted you access to Rubyforge so you can make these updates yourself in the future. Thanks for your help. The Documentation page should probably be updated further to keep up with other changes you've made since. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at gmail.com Thu Nov 8 11:02:17 2007 From: zeljko.filipin at gmail.com (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 8 Nov 2007 17:02:17 +0100 Subject: [Wtr-development] Website update In-Reply-To: References: Message-ID: On Nov 7, 2007 9:36 PM, Bret Pettichord wrote: > I updated the wtr.rubyforge.org website with the changes that you made a > couple of weeks ago. Thanks Also granted you access to Rubyforge so you can make these updates yourself > in the future. I browsed admin pages, but could not find where web site should be updated. Can you help me? > Thanks for your help. Glad I could help. > The Documentation page should probably be updated further to keep up with > other changes you've made since. Sure. I am done with work for today, but I hope I will have some time tomorrow. ?eljko -- ZeljkoFilipin.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Nov 8 11:20:53 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 8 Nov 2007 10:20:53 -0600 Subject: [Wtr-development] Website update In-Reply-To: References: Message-ID: On Nov 8, 2007 10:02 AM, ?eljko Filipin wrote: > > I browsed admin pages, but could not find where web site should be > updated. Can you help me? > You use ftp. I'm sending details privately. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Nov 8 11:42:05 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 8 Nov 2007 10:42:05 -0600 Subject: [Wtr-development] Thoughts on FireWatir In-Reply-To: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> References: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> Message-ID: On Nov 7, 2007 7:26 AM, Nathan Lane wrote: > So this seems like an awesome idea to me. I'm not any kind of official > developer for WATIR, but i'd be willing to become one. I wouldn't mind > volunteering my time regularly also in order to keep the project away from > needing much, if any, money. I developed the library that helps access > spreadsheets through UNO and OpenOffice.org in Ruby (that a couple of > people have picked up using). I'd like to see FireWatir and Watir unified > in some pluggable way also, so that all I need to do is specify what browser > I want to use, and with that also do SafariWatir at some point. My skills > in these areas include understanding OLE/COM/UNO, JavaScript, XML, ReXML, > XPath, and Ruby (though I haven't pinned down all of the Ruby coding > conventions just yet - I still use a variety of syntaxes I think.) Please > let me know how I can help in these matters. Again I require no funding, and > can work on this regularly. I'd like to do that to make Watir even more > usable as a test tool and to get my name out there. > You've been a great help to the community in the past and we'd love to have more of your help. If you would like commit rights, the next step would be for you to submit a patch to the Watir/FireWatir code base. Or you can continue to support related projects, such as the oohelper, for which we are very greatful. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Tue Nov 6 14:34:39 2007 From: bret at pettichord.com (Bret Pettichord) Date: Tue, 6 Nov 2007 13:34:39 -0600 Subject: [Wtr-development] Thoughts on FireWatir Message-ID: Over the past week, I've taken a close look at FireWatir, with two questions in mind. First, can we make use of it at Dovetail to execute our tests? We have a Watir-based test suite that has over 50 tests and runs in nearly 5 minutes. We've developed it over the past couple of months for a new product. Many of our developers are developing on Macs, so they have a particular interest in using Firefox for testing. Our app needs to support both IE and Firefox. Secondly, what is the best way to get FireWatir in sync with Watir 1.5 and how should we maintain it going forward? This is a harder question, for a number of reasons that I will try to explain. FireWatir is based on Watir 1.4. Angrez Singh and the Firewatir team took a copy of the Watir 1.4 code base and then changed it so that it would work with Firefox instead. A lot of the Watir code was reused. It essential amounts to a fork of Watir 1.4. In the past two years since, the Watir code base has evolved significantly. We've cleaned up a lot of the code (both library and test code), refactored much of the code to remove duplication and added support for new attributes and methods (including multiple-attribute support). Few of these changes have been backported to the Firewatir code base. For me, reading through the Firewatir code during the past week has often felt like a trip back in time. The more that I've reviewed it, the more that I've realized that maintaining FireWatir as a separate code base is a dead end. Some of the classes are direct copies of the original Watir classes (some of which have since changed), some have minor modifications, others are completely changed. Clearly the right way to support this going forward would be to share the classes that can be the same, and refactor the code to maximize the use of shared classes. Indeed, Watir needs a pluggable architecture that will allow adapters for particular browsers, thus supporting SafariWatir and Selenium-RC integration as well. Figuring out how to do this is not trivial. At the same time, it is consistent with the kind of technical refactoring we've been doing for some time in the Watir 1.5 code base. Incremental refactoring of both the code bases is possible because they both have comprehensive test suites that we can use to ensure that the necessary architectural changes don't break the software. The place to start integrating the two code bases is probably with with tests themselves. Very few changes should be needed to allow the tests to run against either Watir::IE or FireWatir. After reviewing the code, it is pretty clear that running the Watir tests against Firewatir would result in dozens of failures, mostly indications of gaps between where Watir and FireWatir stand today. But synchronizing the test suite and providing a means to mark individual tests as specific to IE or Firefox is really the only way to ensure that the two versions stay in sync. Some have asked about the core mechanism used in FireWatir. FireWatir requires a Firefox plugin called the Javascript Shell or JSSH. This plugin provides a console interface to the Javascript running in the browser. Once installed, you can actually telnet into Firefox and execute javascript commands. FireWatir connects to this interface using a socket. The basic mechanism is powerful, because it means that anything that can be done in Javascript can be done with FireWatir. However it does require that the plug in be installed first. JSSH is currently provided for Windows (32 bit), Linux and Mac. It is not currently available for FireFox 3.0 (Gran Paradiso) currently under development. Althought it was apparently development independently, it seems that FireWatir users are currently the only users of JSSH. The JSSH code base is open-source, and indeed part of the Firefox code base, but it is unclear to me whether anyone is committed to maintaining this code going forward. This seems to me to be the greatest long-term risk as regards FireWatir. Also the various builds of JSSH that are available appear to have been compiled by different people and different times and they do not seem to have a common or consistent convention regarding versioning. I would feel a lot better if this had some more organizition behind it. Perhaps this could be sponsored by the Mozilla Foundation. Going forward with developing a single code base supporting two browsers will require us to have a stricter testing policy that we've had so far. Installing CruiseControl.rb (link) on a Windows virtual server will allow us to automatically run our tests on both IE and Firefox whenever code changes are made. The results would be public, so any one could see them. Having this in place makes it easier for us to coordinate the work of multiple contributors who may be using different development platforms. A hosted Windows virtual server, which is what we would need to run our tests, costs about $50 a month. This makes me think that it may now be time to pass the hat and ask users to help fund Watir development going forward. I'm not sure if I should simply ask people to send me money (say, using a paypal button), or whether we should go through the formality of setting up a non-profit or selling memberships in a society. I'd appreciate your thoughts on this. Jason Darling suggests T-shirts sales. In working with FireWatir this week, I spent a lot of time struggling with a speed issue. My tests would run very slowly, especially when typing. They seemed slower than what a manual tester would do. Tests would run fine for a bit, and then would suddenly slow down, making me think that some kind of resource had been exhausted. Although it showed up slightly differently in different circumstances, I reproduced the problem on three different machines, with both XP and Vista, and both with the Dovetail test suite and the FireWatir unit tests. I have also spoken with both Paul Rogers and Jim Matthews, both of who have made significant use of FireWatir and have not seen this problem. Indeed, Jim says that FireWatir is faster than Watir for him. I eventually found a workaround for my speed problem, but it remains an issue of concern for me. I don't know whether the problem lies in FireWatir itself or in the JSSH plugin. The next step would be to add a debugging/logging layer to FireWatir to help debug these and other issues. In running the Dovetail tests, I ran into five specific errors, blocking about 90% of the tests. Three were obviously caused by missing features new to Watir 1.5. I suspect the other two were also in this category, but did not have time to track them down far enough. In investigating these issues, I noticed that the attach command was missing. I use this all the time to debug tests. Without it, my ability to investigate the source of errors was limited. This feature was included in Watir 1.4; I'm not sure why it isn't in FireWatir. The missing features I looked into could be added to FireWatir trivially. Merging the code bases would accomplish this as a side effect. Looking forward, I think it will be a long term project to integrate Watir and FireWatir. We don't have many contributors, all of us mostly work on Watir on our own time. It took us two years to go from 1.4 to 1.5 and I think it will be a similar timeframe to see the complete integration of Watir and FireWatir. -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From nathamberlane at gmail.com Wed Nov 7 08:26:22 2007 From: nathamberlane at gmail.com (Nathan Lane) Date: Wed, 7 Nov 2007 06:26:22 -0700 Subject: [Wtr-development] Thoughts on FireWatir In-Reply-To: References: Message-ID: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> So this seems like an awesome idea to me. I'm not any kind of official developer for WATIR, but i'd be willing to become one. I wouldn't mind volunteering my time regularly also in order to keep the project away from needing much, if any, money. I developed the library that helps access spreadsheets through UNO and OpenOffice.org in Ruby (that a couple of people have picked up using). I'd like to see FireWatir and Watir unified in some pluggable way also, so that all I need to do is specify what browser I want to use, and with that also do SafariWatir at some point. My skills in these areas include understanding OLE/COM/UNO, JavaScript, XML, ReXML, XPath, and Ruby (though I haven't pinned down all of the Ruby coding conventions just yet - I still use a variety of syntaxes I think.) Please let me know how I can help in these matters. Again I require no funding, and can work on this regularly. I'd like to do that to make Watir even more usable as a test tool and to get my name out there. Thanks Nathan Lane On 11/6/07, Bret Pettichord wrote: > > Over the past week, I've taken a close look at FireWatir, with two > questions in mind. First, can we make use of it at Dovetail to execute our > tests? We have a Watir-based test suite that has over 50 tests and runs in > nearly 5 minutes. We've developed it over the past couple of months for a > new product. Many of our developers are developing on Macs, so they have a > particular interest in using Firefox for testing. Our app needs to support > both IE and Firefox. > > Secondly, what is the best way to get FireWatir in sync with Watir 1.5 and > how should we maintain it going forward? This is a harder question, for a > number of reasons that I will try to explain. > > FireWatir is based on Watir 1.4. Angrez Singh and the Firewatir team took > a copy of the Watir 1.4 code base and then changed it so that it would > work with Firefox instead. A lot of the Watir code was reused. It essential > amounts to a fork of Watir 1.4 . In the past two years since, the Watir > code base has evolved significantly. We've cleaned up a lot of the code > (both library and test code), refactored much of the code to remove > duplication and added support for new attributes and methods (including > multiple-attribute support). Few of these changes have been backported to > the Firewatir code base. For me, reading through the Firewatir code during > the past week has often felt like a trip back in time. > > The more that I've reviewed it, the more that I've realized that > maintaining FireWatir as a separate code base is a dead end. Some of the > classes are direct copies of the original Watir classes (some of which have > since changed), some have minor modifications, others are completely > changed. Clearly the right way to support this going forward would be to > share the classes that can be the same, and refactor the code to maximize > the use of shared classes. Indeed, Watir needs a pluggable architecture that > will allow adapters for particular browsers, thus supporting SafariWatir and > Selenium-RC integration as well. Figuring out how to do this is not trivial. > At the same time, it is consistent with the kind of technical refactoring > we've been doing for some time in the Watir 1.5 code base. Incremental > refactoring of both the code bases is possible because they both have > comprehensive test suites that we can use to ensure that the necessary > architectural changes don't break the software. > > The place to start integrating the two code bases is probably with with > tests themselves. Very few changes should be needed to allow the tests to > run against either Watir::IE or FireWatir. After reviewing the code, it is > pretty clear that running the Watir tests against Firewatir would result in > dozens of failures, mostly indications of gaps between where Watir and > FireWatir stand today. But synchronizing the test suite and providing a > means to mark individual tests as specific to IE or Firefox is really the > only way to ensure that the two versions stay in sync. > > Some have asked about the core mechanism used in FireWatir. FireWatir > requires a Firefox plugin called the Javascript Shell or JSSH. This plugin > provides a console interface to the Javascript running in the browser. Once > installed, you can actually telnet into Firefox and execute javascript > commands. FireWatir connects to this interface using a socket. The basic > mechanism is powerful, because it means that anything that can be done in > Javascript can be done with FireWatir. However it does require that the plug > in be installed first. JSSH is currently provided for Windows (32 bit), > Linux and Mac. It is not currently available for FireFox 3.0 (Gran > Paradiso) currently under development. Althought it was apparently > development independently, it seems that FireWatir users are currently the > only users of JSSH. The JSSH code base is open-source, and indeed part of > the Firefox code base, but it is unclear to me whether anyone is committed > to maintaining this code going forward. This seems to me to be the greatest > long-term risk as regards FireWatir. Also the various builds of JSSH that > are available appear to have been compiled by different people and different > times and they do not seem to have a common or consistent convention > regarding versioning. I would feel a lot better if this had some more > organizition behind it. Perhaps this could be sponsored by the Mozilla > Foundation. > > Going forward with developing a single code base supporting two browsers > will require us to have a stricter testing policy that we've had so far. > Installing CruiseControl.rb (link) on a Windows virtual server will allow > us to automatically run our tests on both IE and Firefox whenever code > changes are made. The results would be public, so any one could see them. > Having this in place makes it easier for us to coordinate the work of > multiple contributors who may be using different development platforms. A > hosted Windows virtual server, which is what we would need to run our tests, > costs about $50 a month. This makes me think that it may now be time to pass > the hat and ask users to help fund Watir development going forward. I'm not > sure if I should simply ask people to send me money (say, using a paypal > button), or whether we should go through the formality of setting up a > non-profit or selling memberships in a society. I'd appreciate your thoughts > on this. Jason Darling suggests T-shirts sales. > > In working with FireWatir this week, I spent a lot of time struggling with > a speed issue. My tests would run very slowly, especially when typing. They > seemed slower than what a manual tester would do. Tests would run fine for a > bit, and then would suddenly slow down, making me think that some kind of > resource had been exhausted. Although it showed up slightly differently in > different circumstances, I reproduced the problem on three different > machines, with both XP and Vista, and both with the Dovetail test suite and > the FireWatir unit tests. I have also spoken with both Paul Rogers and Jim > Matthews, both of who have made significant use of FireWatir and have not > seen this problem. Indeed, Jim says that FireWatir is faster than Watir for > him. I eventually found a workaround for my speed problem, but it remains an > issue of concern for me. I don't know whether the problem lies in FireWatir > itself or in the JSSH plugin. The next step would be to add a > debugging/logging layer to FireWatir to help debug these and other issues. > > In running the Dovetail tests, I ran into five specific errors, blocking > about 90% of the tests. Three were obviously caused by missing features new > to Watir 1.5. I suspect the other two were also in this category, but did > not have time to track them down far enough. In investigating these issues, > I noticed that the attach command was missing. I use this all the time to > debug tests. Without it, my ability to investigate the source of errors was > limited. This feature was included in Watir 1.4; I'm not sure why it isn't > in FireWatir. The missing features I looked into could be added to FireWatir > trivially. Merging the code bases would accomplish this as a side effect. > > Looking forward, I think it will be a long term project to integrate Watir > and FireWatir. We don't have many contributors, all of us mostly work on > Watir on our own time. It took us two years to go from 1.4 to 1.5 and I > think it will be a similar timeframe to see the complete integration of > Watir and FireWatir. > > -- > Bret Pettichord > Lead Developer, Watir, http://wtr.rubyforge.org > Blog, http://www.io.com/~wazmo/blog > _______________________________________________ > Wtr-development mailing list > Wtr-development at rubyforge.org > http://rubyforge.org/mailman/listinfo/wtr-development > -- Nathan Lane -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Wed Nov 7 15:36:00 2007 From: bret at pettichord.com (Bret Pettichord) Date: Wed, 7 Nov 2007 14:36:00 -0600 Subject: [Wtr-development] Website update Message-ID: Zeljko, I updated the wtr.rubyforge.org website with the changes that you made a couple of weeks ago. Also granted you access to Rubyforge so you can make these updates yourself in the future. Thanks for your help. The Documentation page should probably be updated further to keep up with other changes you've made since. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From zeljko.filipin at gmail.com Thu Nov 8 11:02:17 2007 From: zeljko.filipin at gmail.com (=?UTF-8?Q?=C5=BDeljko_Filipin?=) Date: Thu, 8 Nov 2007 17:02:17 +0100 Subject: [Wtr-development] Website update In-Reply-To: References: Message-ID: On Nov 7, 2007 9:36 PM, Bret Pettichord wrote: > I updated the wtr.rubyforge.org website with the changes that you made a > couple of weeks ago. Thanks Also granted you access to Rubyforge so you can make these updates yourself > in the future. I browsed admin pages, but could not find where web site should be updated. Can you help me? > Thanks for your help. Glad I could help. > The Documentation page should probably be updated further to keep up with > other changes you've made since. Sure. I am done with work for today, but I hope I will have some time tomorrow. ?eljko -- ZeljkoFilipin.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Nov 8 11:20:53 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 8 Nov 2007 10:20:53 -0600 Subject: [Wtr-development] Website update In-Reply-To: References: Message-ID: On Nov 8, 2007 10:02 AM, ?eljko Filipin wrote: > > I browsed admin pages, but could not find where web site should be > updated. Can you help me? > You use ftp. I'm sending details privately. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: From bret at pettichord.com Thu Nov 8 11:42:05 2007 From: bret at pettichord.com (Bret Pettichord) Date: Thu, 8 Nov 2007 10:42:05 -0600 Subject: [Wtr-development] Thoughts on FireWatir In-Reply-To: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> References: <9afbd5b90711070526g3547a7a2hd20d8f7cf515353f@mail.gmail.com> Message-ID: On Nov 7, 2007 7:26 AM, Nathan Lane wrote: > So this seems like an awesome idea to me. I'm not any kind of official > developer for WATIR, but i'd be willing to become one. I wouldn't mind > volunteering my time regularly also in order to keep the project away from > needing much, if any, money. I developed the library that helps access > spreadsheets through UNO and OpenOffice.org in Ruby (that a couple of > people have picked up using). I'd like to see FireWatir and Watir unified > in some pluggable way also, so that all I need to do is specify what browser > I want to use, and with that also do SafariWatir at some point. My skills > in these areas include understanding OLE/COM/UNO, JavaScript, XML, ReXML, > XPath, and Ruby (though I haven't pinned down all of the Ruby coding > conventions just yet - I still use a variety of syntaxes I think.) Please > let me know how I can help in these matters. Again I require no funding, and > can work on this regularly. I'd like to do that to make Watir even more > usable as a test tool and to get my name out there. > You've been a great help to the community in the past and we'd love to have more of your help. If you would like commit rights, the next step would be for you to submit a patch to the Watir/FireWatir code base. Or you can continue to support related projects, such as the oohelper, for which we are very greatful. Bret -- Bret Pettichord Lead Developer, Watir, http://wtr.rubyforge.org Blog, http://www.io.com/~wazmo/blog -------------- next part -------------- An HTML attachment was scrubbed... URL: