> Am 12.12.2014 um 12:14 schrieb Tudor Girba <tu...@tudorgirba.com>:
>
> Hi,
>
> As input for designing new features that better support scripting in Pharo,
> we would benefit from a bit more input around the role scripts play in your
> development life.
>
> To this end, I would like to invite you to share your scripting experience.
> Here are some questions to start from, but feel free to diverge:
>
For me there are two kind of environments that are imported. On the one hand
there is the desktop with a GUI, something that I start manually and that is
being saved regularly for me to stop and continue working. On the other hand it
is a server environment where everything needs to be started automatically
without any GUI. This environment is never saved and always started from the
same saved state.
> - What kind of actions do you put in scripts?
>
Setup, configuration and orchestration of components. Short snippets for code I
don't want to put in methods, snippets for resetting things etc. Examples are:
starting zinc server, adding and configure persistence layer to a stack,
resetting model state etc.
> - Do you rely on script files stored on the disk at all?
>
On the desktop I store workspaces to files as backup and to be able to move
them to a freshly build image. On the server the whole setup is done with
scripts
> - Where do you store your scripts (in one folder, in many folders)?
>
On the desktop I store them in the working directory of the image. I have
separate directories for all of my projects. So the project dependent workspace
files are just in that project folder. I'd like the idea of organizing scripts
but then accessing/navigating to them is more effort then to type it again. I
also store scripts in text documents for e.g. having quick access to Gofer
snippets in order to load common modules I use. This is mainly to set up the
project before writing a metacello config. And not all of those components can
be accessed via configuration browser.
On the server I've built a utility that accesses a directory full of snippets
in a Unix SysV style manner. As an example for our mobility server:
root@2d-apis:/opt# ls -1 mobility-server/launch.d/
10_restore-ui-manager
20_rfb-vnc-server
30_logging
40_mongodb
50_start-mobility
60_scheduler
95_server-setup
The prefix number organizes the order of execution of the snippets. The
snippets are a mixture of shared and individual scripts. Meaning scripts like
restore ui manager and rfb-vnc-server are shared among all installations
because they are always the same. I just symlink them into my projects
launch.d. A script like rfb-vnc-server looks like this
root@2d-apis:/opt# cat mobility-server/launch.d/20_rfb-vnc-server
self optionAt: 'vncport' ifPresent: [:portString|
RFBServer reset.
rfb := RFBServer current.
self optionAt: 'vncpassword' ifPresent: [:password|
rfb setFullPassword: password
].
rfb start: portString asNumber.
self log: 'RFB vnc server started on port ', portString
].
This way I can switch rfb on and off using a commandline switch that is added
to a project configuration. This all is part of image-launcher I want to
release for several years now :) If anyone is interested please ask.
> - Do you version your scripts?
Workspace scripts are versioned via timemachine backup only. Server side
scripts are put into git.
>
> - Do you store them in separate files with dedicated names, or tend to put
> multiple snippets in one larger file?
>
On the desktop it is more the latter because everything a project depends is in
one or two workspaces. On the server as you could see above everything is
separated into indvidual scripts
> - Do you rely on the names of the scripts?
>
On the server for tweaking the order of execution.
> - Why do you use a script file and not a class?
Some of the scripts I put into classes when they grow up to be an utility
function. Parts that contain contextual information I don't put into classes
because I don't want to have filesystem paths, ip addresses and such inside my
code and they are too static if something changes.
I think putting stuff in classes is not always an option. To me scripts act as
glue between the image and outer world where to image have to live in. Scripts
are flexible and adhoc. In my case there is a workflow where a jenkins server
builds the deployable image. If the script code (e.g. for startup) in the image
needs to be tweaked you need to change the image in order to fix it and there
are workflows where this would be pain (rebuilding the image and deploy it to
have the change in effect). So scripts in text files have superpowers here.
Norbert
