I would like to, again, thank James Robertson for coming down to Richmond to talk about Smalltalk. I was very happy with the talk - everyone seemed really interested - questions were even asked!

James covered some basic Smalltalk stuff: syntax, reserved words, operators, image-based environment, browsers. He then pulled out a Seaside demo, complete with some in-web-browser debugging. [I'm thinking I should have taken some notes during the talk so that I can write a better review.]

It was nice seeing Smalltalk in action, one of the Grand daddies of dynamic languages. Remember, though Smalltalk is roughly 30 years old, from it came: Refactoring support, SUnit - which spawned JUnit, Edit & Continue - the ability to work with live code in a debugger, and, of course, MVC. I'm sure there are more items.

James brought and left a few CDs with VisualWorks 7.5, non-commercial version, preloaded. Contact either Mel Riffe or Matt Overstreet for information on obtaining a copy; he also sent a few with the visiting Charlottesville crew (thanks for coming out guys - excellent questions)

Feel free to add your review in the comments. Cheers!

Our January 8th Meeting will be Smalltalk Night.

James Robertson has been involved with Smalltalk, in one role or another, for quite some time. He's coming down to show off Cincom's VisualWorks Smalltalk offering, including a little bit of Seaside.

On the Cincom Smalltalk site you will also find links to Podcasts and daily Smalltalk screencasts; there's a wealth of information ready for consumption. Helpful Links:

• One Page Syntax Primer
• Cincom Smalltalk
• Cincom Smalltalk Downloads
• Getting started in Seaside and Visual Works
• Squeak
• Avi Bryant on TWiT; creator of Seaside
• Google Search on Smalltalk

Smalltalk has influenced many programming languages, Ruby in particular. In my opinion it is the premier language for Dynamic languages. Many of the ideas and concepts in Ruby were first implemented in Smalltalk. Come join us for what hopes to be a fantastic trip down memory lane and a glimpse into the future.

Head on over to the Upcoming.org Event and let us know you'll be joining us: http://upcoming.yahoo.com/event/379603.

February 12th Meeting Preview...

To be announced.

An ex-coworker of mine recently left the software industry to teach high school, and he asked me to come into his web design class and answer students' questions about the industry. It was an interesting, sobering experience. Most of the questions centered around how much money they would make and how to get hired by a big firm, which was a little disappointing. I tried to emphasize my experience with respect to the money issue:

1. Everything in the industry is constantly changing, so don't base your plans on the industry. I went through college during the dot com boom where kids younger than me were getting BMWs and fat bonuses from employers. Then I graduated after 9/11 where I was lucky to get a crap job in the defense industry. Five years later I ended up right where I'd always intended, and kids graduating now have myriad opportunities. Who knows what the industry will be like when these kids graduate college? Better to hone your skills in many disciplines of computer science (programming in multiple languages, testing, design, debugging, etc.) than to focus on Java because it's big money at this particular moment in history.
2. If you don't love what you do, you'll suck. This is just obvious from what I've seen in the industry. There are plenty of programmers out there, but a large percentage of them are mediocre or worse. Why? This is a day job to them, not something they're genuinely interested in getting better at, but that they can comfortably make money at. Since they aren't applying themselves fully, they're not developing, and they're not going to catch those awesome opportunities on the bleeding edges of the industry where the unrealized profits lay dormant.
3. Getting hired by a big firm is not your only option, contrary to what some of the students think. Because there's such competition among employers for technical talent, organizations are finding that they can distinguish themselves by arriving at different kinds of working arrangements with employees. Newer companies, especially start-ups, are likely to be more flexible in how they negotiate working conditions with employees, such as telecommuting, more vacation time, support for community involvement, etc. There's also consulting and launching your own company - I just hate to hear kids, who should be at their most ambitious and optimistic point in their lives, looking forward to working in a dull corporate environment.
4. Get used to learning constantly. Things move way too fast in this industry for you to learn one language and have that make your career. It's better to challenge yourself by engaging in a wide variety of technologies to hone your general programming, debugging, testing, and other skills. Try out new languages, read blogs, go to conferences, and do your own experimental projects to challenge yourself. Be the guy that can solve any problem with the right tool, rather than "the Java guy" or even "the Ruby guy".

I can't tell for sure, but I think a lot of what I said put their long term career plans in some sort of perspective. The truth is that they can probably be comfortable as a mediocre coder at some mega-corporate conglomerate making a decent living. But they won't be happy, and I kind of feel like it's my role to guide them towards something that will enrich their lives, not put them on hold for fourty hours a week for the rest of their lives.

My teacher friend actually asked me to demo some Rails magic to the class, as he's interested in using Rails with his students. So I gave them a little taste of a Rails project, and since so much of the class were interested in design I focused on giving them a crash course in MVC and how front-ends and back-ends can work together better. It seems like Rails is the perfect technology for kids interested in web development since there's no need for compiling after changes and it's so "english-like". I also made CVREG's presence in the community clear, and I offered any help to the class that may be needed.

My presentation garnered some interest, but it was disappointing to see so little emphasis on the art of programming and so much preoccupation with the scrilla. Oh well, I guess we all think about the bottom line sooner or later, eh?

With Rails 1.2 RC2 released over a week ago and a final release imminent, it might be time to finally check out this RESTFul architecture thing.

With the simply_restful plugin being merged into Rails 1.2, using restful routes is a snap. It takes a bit to get your mind around it, but once you do, you’ll never look back. Restful routes really exposes your application and domain model. All those debates about what goes into what controller are gone. Its entirely worth your time to check it out.

If you have no clue what I’m talking about, fork out the $9 to Grosenbach for his REST screencast.

If you’ve played around with this already and get that it’s the future, check out Andre Lewis’s post on nested resources. Its a fantastic little into into nesting your routes. Its more of a follow along than a post, so get out that text editor!

This plugin tells you what techniques you are using that are out of fashion with the current Rails API. It is not an endorsement by the Rails core team or a guarantee that your code will work correctly. It just tries to identify common problems.

Nubyonrails.com has the details…