Seaside Experience Report

1. 1 developer, 1 framework, 12 months Seaside Experience Report Boris Popov Smalltalk Solutions 2007 Toronto, ON

2. This is not a Seaside tutorial • This is an experience report • Yours might differ, but hopefully be as pleasant • Tons of credit goes to Michel Bany • He maintains all Seaside VisualWorks ports • Works for Cincom • Questions are most welcome as we go along Heads up

3. Located in Vancouver, BC • 4 developers, all Smalltalkers • XP attitude, not worship • Tests, tests and some more tests • Lack of code ownership • Frequent, small releases • On-site customer • 40 hour weeks DeepCove Labs

4. Payment Processing Platform • Multiple currencies (>150) • Multiple countries (>65) • Multiple types • Debits • EFT, BACS, ACH, ESP, Cards, Checks, RCK • Credits • EFT, BACS, ACH, ESP, Cards, Checks, CHAPS • Reported • Millions of transactions a month Raven

5. Smalltalk throughout • Except a handful of C libraries, external utilities • VisualWorks 7.4.1 (7.5 already tested) • Microsoft SQL Server 2005 SP2 • Homegrown, minimalistic OR mapping • Client APIs • Batch (WebDAV) • Real time (REST) Technology

6. Web portal for clients • Payment Initiation • Terminals (Card, Check Issue, EFT) • Batch upload (All available payment types) • Reporting • Payment tracking (including possible returns) • Daily account statements • Statistics • Charts • Raw data exports Raven online

7. Smalltalk Solutions 2006 • Ajax with Seaside / Intro to Seaside • Avi Bryant & Andrew Catton • Smallthought Systems Inc • Critically acclaimed DabbleDB • Hands-on coding session using Squeak • First real exposure to Seaside • Simple prototype built while flying back Humble beginning

8. Prototype (~3 hours)

9. WebDAV only option to send/receive files • Somewhat awkward, especially in 2006 + • Windows built-in support very flaky • Vista even worse, must have Office installed (d’oh!) • Push model is maintenance magnet • Needed web front end sooner than later • Fear factor • Servlets & SSP seem harder than they should be • Limited in-house resources A little context

10. Showed prototype to the group on arrival • Obviously cheesy, but it’s vision that counts • Management expressed support • Planning • No extended meetings • No design sessions • No CRC cards • “Just make it go” First steps

11. mockup (~8 days)

12. Go for slick as early as possible • Professional look stimulates and motivates • Layout affects functionality • Functionality affects layout • It’s a never-ending pursuit of balance • Don’t let developers do designers’ job! • Find the right person • Must read ALA and know what CSS Zen Garden is Visual Design matters

13. Initial understanding of the domain • Express what you want to get done, not how • Existing brand materials and ideas (if any) • Elements and variations of the template • Future directions to include extra flexibility • Agree on a working model • Ask for initial set of HTML templates to work off • Future updates are mostly limited to CSS files Interacting with designer

14. Today (~12 months) + style A

15. Today (~12 months) + style b

16. Two-factor authentication was strongly desired • Why RSA? • Strong presence in financial services, familiarity factor • Customized pricing per token and licensing cost • Easy to integrate (handful of DLLCC calls) • Why not VeriSign? • Wouldn’t even talk to us… Security

17. What does it look like? • How does it work? • Generates one time use token every 60 seconds • Seeded in-sync with the server • Passed along with username and PIN for auth RSA SecureID

18. Components, components, components • All applications start with a root component • Root component has children • Child components have children • It really is as simple as it sounds • Session is always there • Callbacks glue it all together Application skeleton

19. It’s not magic, you must get down and dirty • But it’s messages, not templates! • Reuse/Refactor, not Copy/Replace • New render canvas API is all about brushes Html generation Header>>renderContentOn: html html div id: ‘header’; with: [(html span) class: 'descriptive-label‘; with: 'Logged in as:'. (html span) class: 'user'; with: self session user label]

20. Simplicity at it’s best, you can thank the blocks callbacks • (html form) • defaultAction: [self process]; • with: [(html label) • tooltip: ‘Minor units, with decimals, e.g. 150.00 or 19.95’; • with: ‘Amount’. • (html textInput) • class: ‘required’; • value: self amount; • callback: [:value | self amount: value]. • (html submitButton) • yui; • callback: [self process]; • text: ‘Process’]

21. Ajax & Effects courtesy of script.aculo.us • Used by Ruby on Rails, Apple, Digg and Gucci • Heavily objectified by Lukas Renggli ajax, web 2.0 and friends (html div) id: ‘time’; with: [self renderTimeOn: html]. (html anchor) onClick: ((html updater) id: ‘time’; callback: [:render | self renderTimeOn: render]); with: ‘Update Time’ renderTimeOn: html html text: (Timestamp now printUsing: ‘hh:mm:ss.fff’)

22. Don’t worry, you won’t get it right the first time • Seaside encourages constant improvement • Smaller components = Less coupling • Example • Search (defines criteria, fetches results) • Report (defines presentation, pagination, etc) • Column (defines value, formatting, rendering, etc) • Reuse searches, reports, columns all you want Late binding

23. Initial deployment

24. Minimize seaside requests

25. Add fault tolerance

26. Simplify everything

27. Automated build process once all tests pass • Upload all resources to S3 • Trim all sample and config applications • Configure application for deployment • Set session timeout value • Set deployment mode • Set protocol to HTTPS • Install secure, user-friendly error handler • Save headless image Building the server

28. How about a quick demo then we’ll go to questions Raven online demo

29. Thanks for coming