> On Dec 12, 2014, at 9:14 AM, Tudor Girba <tu...@tudorgirba.com> wrote: > > 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: > > - What kind of actions do you put in scripts?
Automation. Mostly devops and orchestration (so they make Jenkins life easier (not true but it keeps the CI jobs more maintainable)) Truth is that developers save time too > > - Do you rely on script files stored on the disk at all? every day > > - Where do you store your scripts (in one folder, in many folders)? depends on the project In flow there are some scripts in some folders that creates a convenient syntax and we keep some of them in a hidden folder .hood > > - Do you version your scripts? git does it for me > > - Do you store them in separate files with dedicated names, or tend to put > multiple snippets in one larger file? I’m not considering snippets and scripts in the same category. For snippets I use workspaces. Typically I use a class with the name of the app and in its class side I put convenient methods. Some examples: Airflowing start. “starts all the services used inside the image" Airflowing start. “stops them" Airflowing restart. “stops them, do 5 garbagecollects and starts" Airflowing maintainer update executeOn: ‘databaseName’. “executes the current update (a custom class with custom actions) on 1 particular database" Airflowing maintainer update execute. "executes the current update in all databases” There are others for many day-to-day things, including capturing monthly payments PetShop <https://github.com/flow-stack/petshop/tree/develop>’s backend uses that idea too PetShop stop; reset; start. PetShop <https://github.com/flow-stack/petshop/tree/develop>’s frontend is (is flow <https://github.com/flow-stack/flow>-based so we’re talking about Amber <http://amber-lang.net/>) using that idea too PetShop start “registers the app, publishes shared remote objects and instantiates the main controller) Same for many other private projects > > - Do you rely on the names of the scripts? > Not only script names but also folder names. This is what makes the terminal to be more productive. More airflowing examples: $ <— you’re in the root of the project in dev $ ./actions <— type ‘a' and pres tab once and you get the actions folder, press tab again and it lists all of the things you can do, some of them are: getDataToSpace getRelease pullDev freshDev getFlowingWorker getStagingImage pullMaster when you do that, as you probably guessed, the script naming criteria becomes pretty close to method naming criteria Another relaying of the names of the scripts is for keeping configuration out of the image as used by ConfigurationFiles <http://smalltalkhub.com/#!/~sebastianconcept/ConfigurationFiles>: It’s a very simple class that make a bunch of assumptions to allow you to have all the configuration files you want under conf/ directory so you can inside the image do things like: ConfigurationFiles at: #Zinc at: #port ConfigurationFiles at: #MongoDB at: #databaseName ConfigurationFiles at: #VNC at: #port etc etc And here is an example of how the VNC file looks like $ cat {imageDir}/conf/VNC.conf "############ VNC accessor. Settings for the VNC server so headless images can provide an UI through VNC clients" Dictionary new at: #use put: true; at: #localOnly put: true; at: #port put: 5908; at: #interactivePassword put: ’secret'; yourself > - Why do you use a script file and not a class? > As mentioned, I do use classes too. Mostly to do actions inside the worker images. Also to build images. The next examples use the ./load or ./build or ./cleanBuild script to create the development setup of the respective projects https://github.com/sebastianconcept/Mapless/blob/master/cleanBuild <https://github.com/sebastianconcept/Mapless/blob/master/cleanBuild> and to implement the image customization there is the {ProjectName}Builder class that those scripts file in to get that done. Here is Mapless example: https://github.com/sebastianconcept/Mapless/blob/master/MaplessBuilder.st <https://github.com/sebastianconcept/Mapless/blob/master/MaplessBuilder.st> Here is same idea used for the flow’s backend: https://github.com/flow-stack/flow/blob/master/backend/FlowBuilder.st <https://github.com/flow-stack/flow/blob/master/backend/FlowBuilder.st> BTW in flow’s root folder there is ./cleanBuild to trigger building both, back and frontend: https://github.com/flow-stack/flow/blob/master/cleanBuild <https://github.com/flow-stack/flow/blob/master/cleanBuild> here is how it cleans and triggers the build https://github.com/flow-stack/flow/blob/master/cleanBuildFrontend <https://github.com/flow-stack/flow/blob/master/cleanBuildFrontend> the frontend’s concrete implementation: https://github.com/flow-stack/flow/blob/master/frontend/build <https://github.com/flow-stack/flow/blob/master/frontend/build> Here is how it ./startAll hides a multiplatform start https://github.com/flow-stack/flow/blob/master/startAll <https://github.com/flow-stack/flow/blob/master/startAll> and here is the OS X implementation that opens one terminal per service started: https://github.com/flow-stack/flow/blob/master/.hood/platform/osx/basicStart.sh <https://github.com/flow-stack/flow/blob/master/.hood/platform/osx/basicStart.sh> > > > Cheers, > Doru > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com/> > > "Every thing has its own flow"
