The Artima Developer Community
Sponsored Link

Agile Buzz Forum
Smalltalk Presentation Report

0 replies on 1 page.

Welcome Guest
  Sign In

Go back to the topic listing  Back to Topic List Click to reply to this topic  Reply to this Topic Click to search messages in this forum  Search Forum Click for a threaded view of the topic  Threaded View   
Previous Topic   Next Topic
Flat View: This topic has 0 replies on 1 page
James Robertson

Posts: 29924
Nickname: jarober61
Registered: Jun, 2003

David Buck, Smalltalker at large
Smalltalk Presentation Report Posted: Nov 27, 2007 2:15 AM
Reply to this message Reply

This post originated from an RSS feed registered with Agile Buzz by James Robertson.
Original Post: Smalltalk Presentation Report
Feed Title: Travis Griggs - Blog
Feed URL: http://www.cincomsmalltalk.com/rssBlog/travis-rss.xml
Feed Description: This TAG Line is Extra
Latest Agile Buzz Posts
Latest Agile Buzz Posts by James Robertson
Latest Posts From Travis Griggs - Blog

Advertisement

A couple weeks ago, I gave a presentation to the TriCities Linux Users Group about Smalltalk. I solicited advice on how to do this from the community, and received some good advice, especially from Dave Buck and Bob Westergaard. I thought I'd take a moment to at least give an overview of what I did and how it all worked out.

I did the classical "presentation" for the first 15 minutes or so. 12 slides. Agenda, about me, Smalltalk's still alive, etc.

Next part was a 15-20 minute overview of the Smalltalk language, using workspaces. Workspaces were variables, unary messages, keyword messages, binary messages, assignment. In that order. I had a number of examples using literal objects through this. Always ended with an example that combined them and showed the precedence. I stuck to always "printing" the result right in the workspace. This went pretty well. The hardest part for them to grok was the keyword:syntax:. We discussed afterward, that having a cheatsheet handout, basically the contents of the workspace would have been handy to help people follow along and refer back to.

At this point what I wanted to do, but was not able because the build I was using was having socket issues, was to load the public package "NetworkInterface" and show that you didn't have to use the IDE workspaces to do all of this. You could do it right in command line shell interpretor style.

We then moved into the IDE and interactive demos. So the first thing I introduced was to go back to some of those slides and use the same expressions to show them the inspector. People thought these were pretty cool. I pointed out that we could modify the objects live in the inspector, that we used the same style of expressions we had in the workspace.

This was followed by "Inspector Part 2." I loaded the Steroids package that Bob Westergaard kindly ported from Java. I fired it up and played it for a second. Everyone loves a retro game. Then we ripped it open with an inspector and began to change the game itself. We made asteroids come and go, both by flipping their flag, as well as just removing them from the collection. We changed their delta translation/rotation values and watched them take off spinning madly across the screen. This got a lot of appreciative laughs and fun. This was an important part because I wanted to show the effects you can effect with the inspector in a real application. Not just playing with examples.

The idea was to move up the chain in "complexity" of the IDE. So next was the browser. Breezed through simple navigation and stuff. Showed some of the lesser refactorings, such as the fact that rename method rewrites all your code for you. That it's more than just a jumped-up sed/awk script operating on source. Then we showed extract-to-method. And then extract-to-comoponent. I used a simplified example of implementing a midpoint: method, and then extracting out the "half" method. This was well received, not as impressive as the inspectors though. There were lots of questions about source code control, because it was sensed with all of this power, you'd have issues coordinating changes. We restarted the asteroids game and made some changes in it's behavior; I rendered some of the asteroids as gradients using Cairo. And watched the system change live.

Then we went to the debugger. Started by evaluating some of the precedence expressions we had done in the workspace. I had walked them through what was happening earlier, but this would have been really nice to possibly move right up front, especially when I was having so much trouble communicating with words how keyword messages work. Kind of torn on this.

The final part was to put a breakpoint in and play with the asteroids game some more. Bob had pointed out a great sequence where you do an extract-to-component on the fly from the debugger in the game, but I just didn't make it that far. By this time, the discussion (which I had encouraged to be open) had built enough of it's own momentum that we spent the rest of the time answering various questions.

All and all, it went pretty well, it was well received. There's some things I'll do different if I ever do it again, but it was a good first run.

Read: Smalltalk Presentation Report

Topic: Seaside featured on FLOSS Weekly Previous Topic   Next Topic Topic: Smalltalk Daily 11/23/07: Shore Components

Sponsored Links



Google
  Web Artima.com   

Copyright © 1996-2019 Artima, Inc. All Rights Reserved. - Privacy Policy - Terms of Use