SoC March 2007

soc@lists.squeakfoundation.org

28 participants
67 discussions

topics
by Ralph Johnson 02 Apr '07

02 Apr '07

The proposals tend to fall into several categories, and there are some proposals that are very similar. There are in fact five proposals (from four people) that propose adding a module to Seaside to make it like Ruby on Rails. I think that this topic has the biggest potential to make an impact. Seaside is powerful, but it is not easy to learn for people who do not already know Smalltalk well. If there was a "Seaside on Sails" that was as easy to learn as Ruby on Rails, Seaside (and Squeak) could really take off. It looks to me like these proposals are being overlooked by the mentors, perhaps because none of us are web developers or have used Ruby on Rails. I haven't use it either, but I have read the documentation and I can see why it has made such a big impact. I'd love to see Squeak capture some of that market. So, I urge mentors to read these proposals and to vote on them. There are a lot of tool-oriented proposals. I tend to like them, but other mentors do, too, so I won't say much about them. There are a couple of proposals to make something like "rake" for Squeak. I don't understand these. I've built several large systems in Smalltalk and never felt the need for make. I don't know rake, and when I read the proposals I feel like I am missing something. Could someone explain why we need something like this? -Ralph

6 12

various questions
by Ralph Johnson 30 Mar '07

30 Mar '07

Is this list reserved for mentors, or are students on it, too? In other words, is this an appropriate place to discuss various cases? I wonder if our scoring will have any impact on how many students will be supported to work on Squeak projects? If it looks like we have a lot of good candidates, is is possible that we might get one more line of support than if we give most of them average scores? -Ralph Johnson

4 7

Review guidelines
by Giovanni Corriga 30 Mar '07

30 Mar '07

Hi all, I'm sorry for having been silent for two days, but I had a backlist of stuff to complete before working on the Soc proposals. Here's a set of proposed guidelines for reviewing the applications. First of all, refer to the guide to the mentors app at http://tinyurl.com/29awt6 . The mentors app itself is at http://code.google.com/soc/mentor_home.html . Applications: I think that every mentor should review all the applications. A mentor should also click on the "willing to mentor" button for every application they think they can act as mentor. Don't worry about the number of students you'd end up mentoring - we can sort that out later, when we know exactly how many students Squeak will have to mentor. Scores: the available ones are +4, +2, +1, -1, -2, and N/A which really is 0. I propose the following guidelines for the assigning scores: +4 - We MUST have this proposal accepted. +2 - This proposal is cool. +1 - If Google gives us many students, we should do this. N/A - Meh. -1 - Something about this proposal is perplexing -2 - There are serious problems with this proposal. Again, all mentors should review every application and at least _consider_ scoring it. Known students vs. newcomers: Many proposals are by students who already know Squeak and are silent members of our community (or would like to get involved in the community), but on the other hand many proposal are by student who don't know Squeak and/or the tools. The fact that a student doesn't know Squeak shouldn't be used to downgrade his proposal(s), as long as the student has good OO skills and is willing to learn the language and the environment before June. The rationale for this is that the SoC is a good way to increase awareness for Squeak, so we shouldn't be so quick to dismiss newcomers. We should instead try to strike a balance between "squeaker students" and newcomers (but please not that this doesn't mean we have to reserve half of our student slots to newcomers, though). SoC mailing list: this mailing list can be used for general discussions about the SoC and the proposals. Details about the single proposal should be discussed in the comments of the mentor application. Any questions/comments/etc. ? Giovanni

2 1

Squeak's Summer of Code applications: 25 students, 34 submissions
by Giovanni Corriga 29 Mar '07

29 Mar '07

Hi all, Applications for the Google Summer of Code 2007 are now closed. Squeak received a total of 34 valid submissions from 25 students, much more than what I expected, this being our first Summer of Code and all. All the applications seem interesting, and in the coming days we mentors will review and evaluate them. On April 11th Google will then publish the name of the accepted students. Unfortunately, the number of accepted students will be less than 25. While we wait for April 11th to know the names of the lucky winners, I'd like to thank all the students who decided to apply for a Squeak project and all the mentors who volunteered for this task and who helped many students with their applications. Thanks, all! Ciao, Giovanni

6 9

Proposal Ranking
by Steven Dee 27 Mar '07

27 Mar '07

Hello, I've submitted three proposals to Squeak for Google's Summer of Code. For reference, the proposals are available at <http://mrd-srv.ath.cx/soc/proposals/squeak/>. Currently, I'd most like to work on Sake, followed by the Plan 9 port, and finally collaborative development. Collaborative development is placed last not because I don't find the idea interesting--quite the opposite, I'd love to see it realized--but because I'm not entirely confident that it is within my capabilities as a relative newcomer to Squeak. Thanks, Steven Dee

1 0

Application preferences
by Matthew Fulmer 27 Mar '07

27 Mar '07

I submitted 3 applications. I ranked them by preference, most desired first: 1. Peek viewer/debugger: http://wiki.squeak.org/squeak/5965 2. Unified Code Browser based on Omni and StarBrowser http://wiki.squeak.org/squeak/5761 3. Reimplement IDE Tools in a Structured Way http://wiki.squeak.org/squeak/5759 -- Matthew Fulmer -- http://mtfulmer.wordpress.com/ Help improve Squeak Documentation: http://wiki.squeak.org/squeak/808

1 0

Proposal to port development tools to the OmniBrowser framework
by andrew morton 27 Mar '07

27 Mar '07

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(a)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.

2 1

Summer of Code: still a little time left for the student applications
by Giovanni Corriga 27 Mar '07

27 Mar '07

Hi all, this is a friendly reminder to all the students interested in applying for the Google Summer of Code program. The deadline has been extended (yes, yet again), and is now Tuesday 27th, 16:00 UTC. So if you still have an application to submit you have a little time left. Giovanni

1 0

Application: collaborative development
by Benjamin Schroeder 27 Mar '07

27 Mar '07

Hi everyone, Coming in just under the wire, I have submitted an application to do the "collaborative development" project proposed by Ralph Johnson. I've copied the text at the end of this mail, although I think it is now unfortunately too late to revise it. :) Benjamin Schroeder ABSTRACT The Croquet environment, built on top of Squeak, provides a rich 3D space for collaboration. Squeak has good tools for browsing and editing source code, but none of these are available inside Croquet. We propose to develop Croquet versions of the Squeak programming tools, which could then be shared for collaborative development. Development sessions, including sound and video, could be recorded for later viewing. This would be especially useful for creating demonstrations for use in teaching. PROPOSAL It is becoming more and more popular for people to collaborate on the development of computer programs. An open source project might involve contributors from around the globe; two people in the same room might choose to work in a "pair programming" style. Furthermore, it is often useful to understand how a program was developed. A demonstration can give insight into a technique's particulars, and into the "whys" of the technique, in ways that a static presentation of the end result cannot. One of Squeak's traditional strengths has been its flexible and powerful programming tools: browsers, inspectors, and workspaces. However, these are meant for use by a single person, or by a small number of people at one workstation. Croquet is built on top of Squeak and provides a rich environment, with 3D graphics and audio, for multiple people. We propose to develop versions of the standard Squeak programming tools for use inside Croquet. Because of the nature of Croquet, this would enable basic collaboration between even geographically distributed groups. However, it should also be possible to record collaborative sessions, both video and audio, for later playback. This would be especially useful for creating demonstrations for use in teaching. It is possible that, depending on the implementation, these demonstrations could also be paused at any point, allowing a student to explore directions not present in the original playback. In the future, this idea could be extended to support other forms of playback for collaborative development. For example, a developer could record code comments that showed different alternatives that were tried, or why different changes were made over time. A reviewer could browse through code, making audio comments and marking things up as she went. IMPLEMENTATION NOTES AND ROUGH SCHEDULE There are several implementation issues to consider. First, the look of the shared tools: how will they be presented in the Croquet environment? Perhaps more importantly, where will the code that is being edited reside? Traditionally, Squeak code is edited inside a local, running image, and modifying system classes modifies the behavior of that image. Will editing the shared code result in changes to the system of each participant? Alternately, will the shared code act as a shared, but separate model within the Croquet environment? The latter option seems simpler. There are also issues to consider regarding recording. I intend to explore TeaTime, Croquet's distributed object model, to see if there is a way to record a session at a low level; this could enable playback with the possibility of interactivity. However, if this proved impractical, fixed-viewpoint video and audio could be recorded. The Summer of Code lasts approximately 12 weeks. I intend to approach the implementation in an iterative fashion, with an end-to-end system (shared tool, recording, playback) released every three weeks. This approach, similar to the release strategy of Extreme Programming, will both provide early feedback on implementation strategies and make it likely that, even in the case of delays, some useful system will be completed. Weeks 1-3 Learn about Croquet distributed object model. Review implementation of standard Squeak tools. Create shared Squeak object system server. Present Workspace for that server in a Croquet portal. Recording and playback for Workspace. Weeks 4-6 Inspectors, with recording and playback. At midterm, the system should be able to work with individual objects, allowing exploration using standard system classes. However, editing of classes and addition of new classes will not be possible until the Browser is completed in the remaining weeks. Weeks 7-9 Browsers, with recording and playback. Weeks 10-12 Cleanup and documentation. Additional recording scenarios, if time permits. RELATED WORK The Self programming language included a multi-user environment called Kansas. Kansas was, in the words of its creators, "a large flat space with multiple people in it", that is, a large shared desktop; it supported collaboration in 2D. [http://web.media.mit.edu/ ~lieber/Lieberary/Softviz/CACM-Debugging/Kansas/Kansas.html] A similar environment, Nebraska, was created for Squeak. [http:// wiki.squeak.org/squeak/1356] BIOGRAPHICAL INFORMATION I am a Ph.D. student in the Computer Science and Engineering department of The Ohio State University. I am interested in software techniques and new media to support creativity and learning, and in the power that ideas from computing bring to creative work and thinking in general. I have extensive experience working with Squeak, both professionally and in open source projects. I wrote the Squeak/.NET bridge, which allows .NET objects to be used from Squeak; this is useful both for exploration and for integration with Windows libraries. More recently, I worked on a Self-style prototype system, Marmalade, and a hypertext workspace, Zest; I presented these at the LL4 workshop (http://ll4.csail.mit.edu). However, I have little experience with Croquet, and hope that this project will give me a chance to learn about it. I am also hoping to learn more about what works well, and what doesn't, when people work together in a shared virtual space. (This proposal is based on a project idea proposed by the Squeak mentoring organization: http://wiki.squeak.org/squeak/5941)

1 0

Summer of Code: only 1 day left for the student applications
by Giovanni Corriga 26 Mar '07

26 Mar '07

Hi all, this is a friendly reminder to all the students interested in applying for the Google Summer of Code program. Remember that the deadline is Monday 26th (actually, Tuesday 27th at 00:00 UTC). This gives you a little more than 1 day for submitting your application. So what are you waiting for? Submit NOW! Giovanni

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

SoC March 2007