[SoC] Proposal to port development tools to the OmniBrowser framework

Tue Mar 27 06:56:34 UTC 2007

Hi Andrew,

I have some comments:

- I think the OmniBrowser is currently too limited to support every
kind of tool: the meta-graph is too static. How do you plan to deal
with that?

- You plan to reimplement TestRunner. However, TestRunner has been
changed a few month ago and build on top of ToolBuilder. What will be
the benefit of your work? How does it compare to
http://smallwiki.unibe.ch/stefanreichhart/omnitesting/ and
http://www.squeaksource.com/Testing?

- Refactorings already exist in the OmniBrowser framework
(http://mc.lukas-renggli.ch/omnibrowser/). Moreover, they are included
into the squeak-dev image, version 95. What do you plan to do exactly?

- I'm pretty sure actions and actors are deprecated in the OmniBrowser
framework. Commands replaced them. Why do you plan to base your work
on that?

I think your work can be very interesting for the Squeak community.
You should improve this application to reflect that fact.

Bye

2007/3/27, andrew morton <drewish at katherinehouse.com>:
> Any final comments on this proposal would be much appreciated.
>
> Thanks,
> andrew
>
>
> Port development tools to the OmniBrowser framework
> Application for Summer of Code 2007
> Andrew Morton
> drewish at katherinehouse.com
> http://drewish.com/
>
>
> Synopsis
> I'm interesting in working on Andrew Black's proposal to re-implement
> IDE tools within the OmniBrowser framework
> (http://wiki.squeak.org/squeak/5945). Being a fan of agile development
> techniques like test driven development and refactoring tools, I would
> like to focus on adding support for running unit tests and the
> refactoring engine to the OmniBrowser.
>
> Project
> Squeak is blessed with a large number of interesting development
> tools, however, that mean it is also cursed by a proliferation of
> incompatible, single-feature browsers. One possible way to rectify
> this situation is by moving the tools to a common framework where all
> the browsers can benefit from shared tools. The OmniBrowser provides
> such a platform and by porting existing tools to it, it could be made
> into a more usable development environment and hasten the demise of
> the single-feature browser.
>
> The project will be developed in three phases. The first phase will be
> porting the SUnit test runner to the OmniBrowser framework. I will
> maintain the features of the original and copy the majority of its
> current interface. The only changes I envision are dropping the "Run
> Profiled" feature and displaying the tests in a single column grouped
> by success or failure.
>
> In the second phase, I will add support for the Refactoring Engine to
> the OmniBrowser. The OmniBrower has extensive support for Actions that
> can be shared between different part of its interface. My goal will be
> to create Actions for the various class, class variable and method
> refactorings.
>
> The third phase is a more open-ended and designed to make use of any
> remaining time. The OmniBrowser collects a great deal of information
> on classes and methods to provide the senders and implementors
> browsers. I believe this information, in conjunction with the change
> notifications provided by the Announcements framework would make it
> possible to determine dependency and selectively run tests referencing
> changed classes and methods.
>
> Schedule
> May 28
>     * Begin coding by migrating the SUnit test runner
>     * Create OBTestCaseNode class to represent test cases
>     * Create a OBTestNode class to represent individual tests
>     * Add a #testBrowser method to OBMetagraph to provide a test metagraph
> June 11th
>     * Add a OBTestCaseFilter to find test cases (isKindOf: TestCase
> for SUnit or using the spec category for SSpec)
>     * Create an OBTestCategoryActor to provide actions for running a
> category of test case
>     * Create an OBTestCase Actor to provide actions for a single test case
>     * Create an OBTestCollectionDefinition to render a graphical view
> of running tests
> June 25th
>     * Begin adding support for the refactoring engine
>     * Determine the best way to introduce the refactoring actions
> July 9th
>     * Upload code for mid-term evaluation
>     * Add method refactoring actions
> July 23rd
>     * Add class refactoring actions
> Aug 6th
>     * Any remaining time spent working on improving the test browser
> Aug 20th
>     * Upload code for final evaluation
>
>
> Benefit for Squeak
> The Squeak community could benefit greatly from an end to the
> proliferation of single-feature browsers. Migrating tools into the
> framework will help locate limitations in the current structure and
> provide momentum to centralize on a single browser.
>
>
> Biography
> I am in my senior year studying Computer Science at Portland State
> University in Portland, Oregon. I have been working with open source
> PHP projects for over four years and have recently begun to explore
> Squeak and Smalltalk. I was introduced to Squeak in Andrew Black's
> Advanced object oriented programming class. Although I had never used
> a pure-OO language before then, the simplicity of the syntax and the
> idea that everything is a just a message sent to an object made it
> very easy to pick up. I am looking forward to gaining additional
> experience coding in Smalltalk and building more advanced programs.
>
> My first open source effort was born out of a desire to learn about
> PHP 5's object oriented features; it resulted in a project called
> Phlickr which is a Flickr API kit for PHP 5. With Rob Kunkle, I
> co-authored Building Flickr Applications with PHP
> (http://apress.com/book/bookDisplay.html?bID=10079) published by
> Apress. This book covers using Phlickr as a tool for building websites
> and scripts to manage photos on Flickr.
>
> A year and a half ago I became actively involved with Drupal, a
> content management system written in PHP,  while working as the web
> administrator at KPSU (Portland State University's college radio
> station). (http://drupal.org/user/34869) I wrote the Station module
> (http://drupal.org/project/station) which is used by many college,
> community and commercial radio stations to display their programs,
> play lists and weekly schedule. I re-wrote and now maintain the Audio
> module (http://drupal.org/project/audio), which is used at KPSU to
> provide an archive of all shows broadcast over our web stream. I also
> wrote the Flickr module (http://drupal.org/project/flickr) and
> recently have become a maintainer of the Image module
> (http://drupal.org/project/image).
>
> Working with the Drupal developer community has been an excellent
> introduction to the dynamics of an open source project. It taught me
> the need to communicate with others to convince them that a solution
> is the best one and should be adopted by the community.
> _______________________________________________
> Soc mailing list
> Soc at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/soc
>

-- 
Damien Cassou