[Seaside] Remote Development with Squeak/Seaside

[C. David Shaffer]

Adrian Lienhard wrote:

>
> actually, about a year or two ago we used a web interface to 
> Monticello or DVS, the ancestor of Monticello, to load the new code. 
> We also had (and still have one) images running headless. But 
> sometimes it's really useful to have the ui remotely, e.g., to 
> evaluate some initialization scripts or to flush the seaside cache. 
> You could also do this over the web of course, its just more 
> convenient. Especially when there were problems it was very useful to 
> have VNC, to look at the process browser, or even to do a alt-. 
> Though, this should, hopefully, not be very often needed ;-)


Most of the time on a real "deployed" app you will not need VNC.  
However, depending on your customer's needs you might deploy earlier 
than you like, especially if they don't mind a few hiccups.  In these 
cases having VNC (and the bandwidth to support it) are really a must.  
I'm mostly using Seaside in this situation right now.  My biggest 
customer is experimenting with several small apps.  I develop locally 
but don't have the time to develop "upgrade scripts" so when I need to 
make a change I suffer through VNC.

The roll over method that Andrew and Avi discussed would be the way to 
go for a production app.  I'm just not there yet and I am probably not 
the only one working Seaside into the nooks and crannies where we don't 
have a solid $$ investment in the work so time has to be kept to a 
minimum.  I suspect that I'm not in the minority here.  I don't collect 
a dime for any work in Seaside.  That day will come and at that time 
I'll invest in better infrastructure.

>
>>
>> So basically,
>> Develop locally.
>> Publish to MC repository.
>> Update server from the MC repository.
>

...then debug.  Especially if you're running against GOODS.  Honestly, 
in my type of Seaside work (again, "proof of concept" apps) you don't 
have time to work methodically along writing migration scripts for your 
DB as you refactor your classes.  I deploy early and often and have a 
customer that is willing to endure a 1 or 2 hour hiccup while I fix 
things after the "update server from the MC repository".  Plus, I can 
always "roll back" the previous version if the migration didn't go 
well...BACK UP YOUR IMAGE AND DB BEFORE YOU UPDATE!!!!! :-) :-) :-)

> Jimmie Houchin wrote...
>
>> I have not developed a website, so have no experience. I wasn't sure 
>> how it was normally done in Squeak/Seaside. I couldn't imagine 
>> actively developing with the deployed image machine. But I wasn't 
>> quite sure how one went about adding new features and items to a 
>> deployed website that you don't have physical access to.
>
Yes, you don't want your customers to suffer through "active 
development" on a live app.  Still, though, there is a difference 
between developing and debugging a deployed app.  I release almost once 
a week which means every week I spend some time on VNC dealing with 
problems on the server.  It drives me nuts but I'll live with it rather 
than go back to JSP's.

>>
>> My server currently is at my home on my LAN. I wanted to learn 
>> somewhat how these issues were handled,while I can explore and 
>> experiment with the different processes while I currently do have 
>> physical access. Once I deploy access is about 80 miles, 128 km, or 
>> about 2 hours away. Not horrible, but also not horribly convenient. :)
>
In my opinion, unless you have a serious app you won't have the time to 
invest in the procedures needed to make deployment seamless.  If you're 
just muddling your way along, like me, you'll want to have VNC access 
that you can live with.  When I finally collect a check from something 
in Seaside I'll change my tune.  Again, I don't think that I'm alone.

David

-- 
C. David Shaffer
http://www.cs.westminster.edu/~shaffer
http://www.shaffer-consulting.com