Via 37 Signals,
The small team size comes with a bunch of advantages: They’re self-contained, can work swiftly and quietly, don’t have the presence of conventional military troops, and are able to operate without a big infrastructure.
Big can be powerful. But even the Army realizes small can be a great way to get things done too.
Yup, sounds about right.
I’m pleased to announce that we are looking for another full-time developer to join our agile team of long time Smalltalk fans. Here at DeepCove Labs our primary focus is evolving and maintaining a mature industry leading international payment processing platform that we have built from the ground up over the past 6 years.
Ideal candidate is someone who has experience with Smalltalk, SQL and last, but definitely not least, Seaside. They must be enthusiastic, motivated and as excited about using cutting edge technology to solve business problems as we are. I should point out that good self task management and time management skills are a big plus as we work as equal peers and share roles every day of the week. We are not XP fanatics, but some things are second nature to us,
Our primary requirements are as follows:
Experience with any of the following would be a major plus:
Our office is located in the heart of Downtown Vancouver, steps away from Pacific ocean, beautiful parks, shopping and entertainment district and all major transit connections. All employees receive excellent health/dental benefits package and few other perks. We like to think we are an open, flexible and friendly place to work, so please drop me an email with your resume if you are interested.
Update (Nov 26): Few folks had pinged me to ask if telecommuting is an option and the simple answer is that for this particular position we would like someone who would be willing to relocate to Vancouver and work from our office together with the rest of the team.
Finally, a decent implementation of panels using MooTools, which means I can finish my migration from YUI+Scriptaculous to MooTools some time this year if time allows.
I’m personally not against a principle of constant critical evaluation of one’s work, but its also very important to sit back once in a while and look at the bigger picture. Is what you do important? Does it help people get stuff done? Do they enjoy getting stuff done with your application? If all the answers are ‘Yes’, then you must be doing something right, so give yourself a pat on the back, go home, forget about work for the weekend and chill out. Which is what I’m going to do now, but not before leaving you with this graph of all our visitors since the official release about 4 months ago. Perhaps not as impressive as Dabble DB’s graph would be, but since they aren’t bragging about theirs I might as well throw mine out to set a precedent… ;)
I did a quick run-through today to see what it would take to move our application from the most recent version of Seaside 2.7 to the brand-spanking-new 2.8 snapshot Michel published this morning. Here are some notes about the changes I had to make and a few rewrite snippets to give you a starting point if you run into the same issues (you may not though).
1. WACanvasTableReport has been renamed to WATableReport, you will need to fix any subclasses you may have added
2. There’s currently no way to subclass WAApplication in 2.8 in a configurable way, it was previously possible via #applicationClass and was used to implement custom #expiryPathFor: behavior; I’ll see about integrating my changes with the main branch for good as I think generalized behavior in that area would benefit many
3. Preference called #useSessionCookie is no longer there, so the following will fail miserably,
(self registerAsApplication: ‘cooler’)
preferenceAt: #useSessionCookie put: false;
yourself
instead, WACookieSession has been added as a subclass of WASession, so you’ll need to do,
(self registerAsApplication: ‘cooler’)
preferenceAt: #sessionClass put: WACookieSession;
yourself
or, if you already have your custom subclass of WASession and would like to have it use cookies for tracking, just move it and subclass off of WACookieSession instead.
4. #linkToScript: has been replaced with a much cleaner canvas-like API, previously it was used inside #updateRoot: to link to external JavaScript files (please note my use of #resourceUrl: instead of standard #url:, that is because I have a custom resource URL installed in #resourceBaseUrl preference and would like attached scripts to respect the prefix),
updateRoot: root
super updateRoot: root.
root linkToScript: ‘/other/charts/charts.js’.
instead you will need to use,
updateRoot: root
super updateRoot: root.
root javascript resourceUrl: ‘/other/charts/charts.js’.
and here’s a rewrite pattern to help you change your code in one go,
Search for:
“@root linkToScript: “@url
Replace with:
“@root javascript resourceUrl: “@url
5. Same goes for #linkToStyle: although I’ve been using a more complicated variant #linkToStyle:titled:media:, but rewrites come to the rescue once again,
Search for:
“@root linkToStyle: “@url titled: “@title media: ’screen’.
Replace with:
“@root stylesheet url: “@url; addScreen
Search for:
“@root linkToStyle: “@url titled: “@title media: ‘print’.
Replace with:
“@root stylesheet url: “@url; addPrint
6. You can’t use awkward #heading:level: utility method to do,
html heading: ‘Need some help?’ level: 2.
instead use the full expanded API,
(html heading)
level: 2;
with: ‘Need some help?’.
or this simple rewrite (you can tell I’m fan, eh?),
Search for:
“@html heading: “@text level: “@level
Replace with:
“@html heading level: “@level; with: “@text
That’s about it for now, but I’m not all the way there yet as I now need to track down a nasty memory emergency that comes up when I try to submit a form, but I suspect it may be partly something in my code since I can’t reproduce it in the stock image, although it worked just fine for the longest time in 2.6 and 2.7, so I’m not fully convinced its my fault yet… More to follow.
Update 1: Okay, I found infinite recursion in Seaside’s codebase, seems to be the difference between Squeak and VisualWorks, but pretty easy to fix
Update 2: With a couple more fixes in place, we have liftoff. Exciting times and less painful than I was preparing for.
Michel Bany has just published another port of Seaside for VisualWorks in the Public Repository, go check it out, but read his disclaimer first.
As requested on this list I published Seaside 2.8 on the public Store repository.
SeasideForWebToolkit(2.8a1.390.0,mbany)
SeasideForSwazoo(2.8a1.390.0,mbany)both are based on Squeak version Seaside2.8a1-lr.390, July 4, 2007.
I also published Scriptaculous based on its most current Squeak version.
SeasideScriptaculous(2.8a1.205.0,mbany)
based on Squeak version Scriptaculous-mb.205, July 6, 2007.
The version number for Scriptaculous in the public Store repository (2.8a1.xxx) is meant to indicate that it will not work with Seaside 2.6 and Seaside 2.7.
Although I did not check, I expect most of the Seaside add-ons to fail with Seaside 2.8 (SeasideAsync, SeasideTesting, WebDesignerTool, SeaChart, ShoreComponents,etc.).
I’ll be trying it out first thing (once all the important work stuff is done, of course, wink).
Unfortunately, I don’t have much time to get into my own take on Smalltalk Solutions 2007 right now, other than to say I’m very impressed with the turnout and appreciate everyone’s feedback, hopefully this will do some good for someone out there.
As promised, here are the slides from the presentation in a variety of formats for you (incidentally hosted on S3, which is something I’d talked about briefly as well),
Enjoy, and comment if you have any questions!
What are you waiting for? Go ahead and register, unless you enjoy missing early bird rates and lining someone else’s pockets with cash. You have until April 11, so don’t say you haven’t been warned.
Looks like the answer may very well be “<3″ as Travis is still hard at work getting Cairo/VisualWorks integration up to speed. Let’s just say I’m glad my Smalltalk Solutions session does not conflict with his, cause I’m afraid I’d have to cancel mine if it did. Here’s a preliminary schedule if anyone’s interested (and you should be!).
Google released their Code Search product today, which seems like a step in the right direction if only they keep adding more language-specific features to it. Want to give it a whirl? Try seaside lang:smalltalk!
