how do you use scripts?
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? - Do you rely on script files stored on the disk at all? - Where do you store your scripts (in one folder, in many folders)? - Do you version your scripts? - Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file? - Do you rely on the names of the scripts? - Why do you use a script file and not a class? Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"
Hi! I am not sure what you mean by âscriptâ.
- What kind of actions do you put in scripts?
I usually write two kind of scripts: - Roassal visualizations - Short script, usually a gofer action to load a particular application
- Do you rely on script files stored on the disk at all?
Not at all. No idea how this work. Even if I would, I am not sure I would use it
- Where do you store your scripts (in one folder, in many folders)?
instance method.
- Do you version your scripts?
Using Monticello
- Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file?
No
- Do you rely on the names of the scripts?
I rely on the method name
- Why do you use a script file and not a class?
I solely use classes. Alexandre
I agree, I am not sure what you mean by a script here - can you elaborate? Personally, I think the environment erases a lot of the conceptual difference between a "script" vs. a "program". On Fri, Dec 12, 2014 at 7:56 AM, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi!
I am not sure what you mean by âscriptâ.
- What kind of actions do you put in scripts?
I usually write two kind of scripts: - Roassal visualizations - Short script, usually a gofer action to load a particular application
- Do you rely on script files stored on the disk at all?
Not at all. No idea how this work. Even if I would, I am not sure I would use it
- Where do you store your scripts (in one folder, in many folders)?
instance method.
- Do you version your scripts?
Using Monticello
- Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file?
No
- Do you rely on the names of the scripts?
I rely on the method name
- Why do you use a script file and not a class?
I solely use classes.
Alexandre
I agree, I am not sure what you mean by a script here - can you elaborate?
As I know Doru, he probably deliberately left out the meaning of script in his email. So, this is up to us to tell what we mean by scripting. We all have a vague notion of what a âscriptâ is. I guess Doru want to capture this. Cheers, Alexandre
Personally, I think the environment erases a lot of the conceptual difference between a "script" vs. a "program".
On Fri, Dec 12, 2014 at 7:56 AM, Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>> wrote: Hi!
I am not sure what you mean by âscriptâ.
- What kind of actions do you put in scripts?
I usually write two kind of scripts: - Roassal visualizations - Short script, usually a gofer action to load a particular application
- Do you rely on script files stored on the disk at all?
Not at all. No idea how this work. Even if I would, I am not sure I would use it
- Where do you store your scripts (in one folder, in many folders)?
instance method.
- Do you version your scripts?
Using Monticello
- Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file?
No
- Do you rely on the names of the scripts?
I rely on the method name
- Why do you use a script file and not a class?
I solely use classes.
Alexandre
For me, a script is an example for MathsOntologie, which is what I want to run when copied in the Workspace then Alt-D-ed. I distribute them with MathsOntologie and they are not versioned. I have ont script per file, all the scripts are grouped in an "exeamples" folder on disk, but I can not always open them because of utf-8 characters which are not correctly imported. Every file has a name recalling the script. I don't use "example" objects because I never thought about it (so, thanks for the idea). But if I knew how to incorporate MathsOntologie inside DrGeo I would use Hilaire's way of storing the examples of course... Alain On Fri, Dec 12, 2014 at 3:14 PM, Tudor Girba <tudor@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?
- Do you rely on script files stored on the disk at all?
- Where do you store your scripts (in one folder, in many folders)?
- Do you version your scripts?
- Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file?
- Do you rely on the names of the scripts?
- Why do you use a script file and not a class?
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
Is there any reason why this project is not public on SS3 ?  ----------------- Benoit St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein) From: Alain Busser <alain.busser@gmail.com> To: Any question about pharo is welcome <pharo-users@lists.pharo.org> Sent: Friday, December 12, 2014 10:56 AM Subject: Re: [Pharo-users] how do you use scripts? For me, a script is an example for MathsOntologie, which is what I want to run when copied in the Workspace then Alt-D-ed. I distribute them with MathsOntologie and they are not versioned. I have ont script per file, all the scripts are grouped in an "exeamples" folder on disk, but I can not always open them because of utf-8 characters which are not correctly imported. Every file has a name recalling the script. I don't use "example" objects because I never thought about it (so, thanks for the idea). But if I knew how to incorporate MathsOntologie inside DrGeo I would use Hilaire's way of storing the examples of course... Alain On Fri, Dec 12, 2014 at 3:14 PM, Tudor Girba <tudor@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? - Do you rely on script files stored on the disk at all? - Where do you store your scripts (in one folder, in many folders)? - Do you version your scripts? - Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file? - Do you rely on the names of the scripts? - Why do you use a script file and not a class? Cheers,Doru -- www.tudorgirba.com "Every thing has its own flow"
Le 12/12/2014 12:14, Tudor Girba a écrit :
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.
Really not much.
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?
Short, tentative, draft experiments (i.e. tentative unit tests).
- Do you rely on script files stored on the disk at all?
No.
- Where do you store your scripts (in one folder, in many folders)?
NA
- Do you version your scripts?
No.
- Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file?
NA.
- Do you rely on the names of the scripts?
No.
- Why do you use a script file and not a class?
As soon as the code is more than a tentative draft, I move it to a class. If I ask scripting like tasks to students, I ask them to do it in a class, not as a set of scripts ;) Unless you count Makefiles as scripting... In which case they happen outside the Pharo world. All in all, I would hate having to explain (to students or co-workers?) intricaties of scripts files saved to disk, versionned in a different way than the rest of the code, with different menus and code search uses. I also very regularly erase and rebuilt my pharo repositories, so anything not saved in a Monticello repository is lost. Thierry
Hi Tudor, On Fri, Dec 12, 2014 at 3:14 AM, Tudor Girba <tudor@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?
Actions that build and/o bootstrap systems. These are typically of two different kinds: - shell scripts to launch images invoked with Smalltalk scripts - Smalltalk scripts - Do you rely on script files stored on the disk at all?
Yes. - Where do you store your scripts (in one folder, in many folders)?
Typically each project that uses one or more scripts has those scripts in the main directory or a scripts subdirectory of that project's main directory. - Do you version your scripts?
The version control system for the project does that. - Do you store them in separate files with dedicated names, or tend to put
multiple snippets in one larger file?
Definitely lots of small scripts with separate names. Some times they call each other. - Do you rely on the names of the scripts?
Yes. They typically indicate what the script does, e.g. buildspurtrunkimage.sh which in turn uses UpdateSqueakTrunkImage.st BuildSpurTrunkImage.st & LoadSpurPackages.st
- Why do you use a script file and not a class?
Ah, sometimes the script file contains a class. For example, the Newspeak bootstrap. But that class is eliminated before the image is finally saved. The choice as to whether to use a class or not depends on the complexity of the task, the usefulness of breaking things into methods etc. Sometimes the script contains many lines, sometimes it's jut way too simple for a class, e.g. BuildSqueakTrunkVMMakerImage.st: "Change the update stream to trunk, update, then build as per 4.5" [MCMcmUpdater defaultUpdateURL: 'http://source.squeak.org/trunk'; updateFromServer] valueSupplyingAnswer: true. "don't use fileIn; it causes an error when the saved image is started" Compiler evaluate: (FileStream oldFileNamed: 'BuildSqueak45VMMakerImage.st') contentsOfEntireFile The advantage that a non-class single doit script has over a class is that the former is much easier to edit with any text editor. For a class one really needs the IDE, and for some tasks one wants to edit outside of the IDE. If you want to look at some examples of scripts I use see - the shell scripts named foo.sh and the Smalltalk scripts named Foo.st, which together build Spur, in http://www.squeakvm.org/svn/squeak/branches/Cog/image - the shell scripts named foo.sh and the Smalltalk scripts named Foo.st, which together build Newspeak, in https://bitbucket.org/newspeaklanguage/nsboot_bleeding_edge/src Cheers,
Doru
-- www.tudorgirba.com
"Every thing has its own flow"
-- HTH, Eliot
On 12 Dec 2014, at 12:14, Tudor Girba <tudor@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:
Every image that I am working in for some time contains multiple open workspaces that I need and depend on, that I dare not close because they might contain important stuff.
- What kind of actions do you put in scripts?
Starting points for coding, exploring, starting/stopping services, loading code, generally useful expressions, snippets of code that will evolve in something else later on.
- Do you rely on script files stored on the disk at all?
Not really, but I tried (both using save/load and ScriptManager) - I think the extra step is too much, a permanent workspace in an image is so much easier.
- Where do you store your scripts (in one folder, in many folders)?
Just next to the image, mostly. But I tried structured saving with ScriptManager.
- Do you version your scripts?
No
- Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file?
Both
- Do you rely on the names of the scripts?
If there are names, yes.
- Why do you use a script file and not a class?
Some tools end up as class methods, if not real code. But changing a class (code) is more serious than playing/experimenting/exploring code in a workspace. === One of the things that I do is mail snippets around internally, so that I and others have them in their mailbox for later reference. === We need something very low friction, like automatic saving/remembering.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 12 Dec 2014, at 12:14, Tudor Girba <tudor@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:
Every image that I am working in for some time contains multiple open workspaces that I need and depend on, that I dare not close because they might contain important stuff.
- What kind of actions do you put in scripts?
Starting points for coding, exploring, starting/stopping services, loading code, generally useful expressions, snippets of code that will evolve in something else later on.
- Do you rely on script files stored on the disk at all?
Not really, but I tried (both using save/load and ScriptManager) - I think the extra step is too much, a permanent workspace in an image is so much easier.
- Where do you store your scripts (in one folder, in many folders)?
Just next to the image, mostly. But I tried structured saving with ScriptManager.
- Do you version your scripts?
No
- Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file?
Both
- Do you rely on the names of the scripts?
If there are names, yes.
- Why do you use a script file and not a class?
Some tools end up as class methods, if not real code.
But changing a class (code) is more serious than playing/experimenting/exploring code in a workspace.
===
One of the things that I do is mail snippets around internally, so that I and others have them in their mailbox for later reference.
===
We need something very low friction, like automatic saving/remembering.
Cheers, Doru
-- www.tudorgirba.com
"Every thing has its own flow"
On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
===
We need something very low friction, like automatic saving/remembering.
Why not searching among the doit(s) stored in the changes?
Thierry
Yes, that combined with Workspace's 'Previous contents' and the new automatic saving of Playground after Go. It just needs to become a really safe and dependable - so that you just know you can safely close a workspace/playground with an important script and always can get it back.
2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
===
We need something very low friction, like automatic saving/remembering.
Why not searching among the doit(s) stored in the changes?
Thierry
Yes, that combined with Workspace's 'Previous contents' and the new automatic saving of Playground after Go.
Isn't the Playground saving after go a duplication of the Changes recording of the associated doit?
It just needs to become a really safe and dependable - so that you just know you can safely close a workspace/playground with an important script and always can get it back.
I rebuilt my images regularly, so it could be nice to have that linked to a repository. And yes, simple and dependable. Like in: there is no need to explain how it works... Or that the how is obvious. Saving states of the workspaces / playground in a kind of log and doits as actions on those? Visible in searches? Stored in the package cache? Robust to multiple images use on it? Thierry
Just a clarification: Playground is saving after each change, not only after a Go. To some extent, it is some sort of duplication with the DoIt actions, but the Playground saves the entire code, not just the executed one. It saves the contents in a play-cache folder by default, but you can configure it to be in a central folder shared by multiple images. The idea is exactly to try to find a mechanism that is transparent and let's you play without worrying about save/load. We still have to refine the mechanism a bit though. Please also note that GTSpotter searches through past Playground pages which means that discovery is now easier than before. Cheers, Doru On Tue, Dec 16, 2014 at 1:17 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
===
We need something very low friction, like automatic saving/remembering.
Why not searching among the doit(s) stored in the changes?
Thierry
Yes, that combined with Workspace's 'Previous contents' and the new automatic saving of Playground after Go.
Isn't the Playground saving after go a duplication of the Changes recording of the associated doit?
It just needs to become a really safe and dependable - so that you just know you can safely close a workspace/playground with an important script and always can get it back.
I rebuilt my images regularly, so it could be nice to have that linked to a repository. And yes, simple and dependable. Like in: there is no need to explain how it works... Or that the how is obvious.
Saving states of the workspaces / playground in a kind of log and doits as actions on those? Visible in searches? Stored in the package cache? Robust to multiple images use on it?
Thierry
-- www.tudorgirba.com "Every thing has its own flow"
2014-12-16 13:23 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Just a clarification: Playground is saving after each change, not only after a Go. To some extent, it is some sort of duplication with the DoIt actions, but the Playground saves the entire code, not just the executed one.
It doesn't make the distinction between a go on a selection or on the full code? I'd wonder about the correctness of the save, then.
It saves the contents in a play-cache folder by default, but you can configure it to be in a central folder shared by multiple images.
Ok. If we have a better log format than the changes, could all this (changes and those scripts) be unified/integrated?
The idea is exactly to try to find a mechanism that is transparent and let's you play without worrying about save/load. We still have to refine the mechanism a bit though.
Please also note that GTSpotter searches through past Playground pages which means that discovery is now easier than before.
I expected that feature :) Thanks, Thierry
Cheers, Doru
On Tue, Dec 16, 2014 at 1:17 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
===
We need something very low friction, like automatic saving/remembering.
Why not searching among the doit(s) stored in the changes?
Thierry
Yes, that combined with Workspace's 'Previous contents' and the new automatic saving of Playground after Go.
Isn't the Playground saving after go a duplication of the Changes recording of the associated doit?
It just needs to become a really safe and dependable - so that you just know you can safely close a workspace/playground with an important script and always can get it back.
I rebuilt my images regularly, so it could be nice to have that linked to a repository. And yes, simple and dependable. Like in: there is no need to explain how it works... Or that the how is obvious.
Saving states of the workspaces / playground in a kind of log and doits as actions on those? Visible in searches? Stored in the package cache? Robust to multiple images use on it?
Thierry
-- www.tudorgirba.com
"Every thing has its own flow"
Hi, On Tue, Dec 16, 2014 at 1:41 PM, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-16 13:23 GMT+01:00 Tudor Girba <tudor@tudorgirba.com>:
Just a clarification: Playground is saving after each change, not only after a Go. To some extent, it is some sort of duplication with the DoIt actions, but the Playground saves the entire code, not just the executed one.
It doesn't make the distinction between a go on a selection or on the full code? I'd wonder about the correctness of the save, then.
I do not understand what you mean. Playground saves all contents after each edit operation. So, you can open a Playground, type 42, close it without executing anything, and you will have a page with '42' contents. We used to have the saving triggered only on Go, but that was too brittle as sometimes you might close a Playground by mistake before executing anything. Does that make sense now? It saves the contents in a play-cache folder by default, but you can
configure it to be in a central folder shared by multiple images.
Ok.
If we have a better log format than the changes, could all this (changes and those scripts) be unified/integrated?
Indeed, that would be interesting. Cheers, Doru
The idea is exactly to try to find a mechanism that is transparent and let's you play without worrying about save/load. We still have to refine the mechanism a bit though.
Please also note that GTSpotter searches through past Playground pages which means that discovery is now easier than before.
I expected that feature :)
Thanks,
Thierry
Cheers, Doru
On Tue, Dec 16, 2014 at 1:17 PM, Thierry Goubier < thierry.goubier@gmail.com> wrote:
2014-12-16 13:00 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
On 16 Dec 2014, at 12:54, Thierry Goubier <thierry.goubier@gmail.com> wrote:
2014-12-16 12:44 GMT+01:00 Sven Van Caekenberghe <sven@stfx.eu>:
===
We need something very low friction, like automatic saving/remembering.
Why not searching among the doit(s) stored in the changes?
Thierry
Yes, that combined with Workspace's 'Previous contents' and the new automatic saving of Playground after Go.
Isn't the Playground saving after go a duplication of the Changes recording of the associated doit?
It just needs to become a really safe and dependable - so that you just know you can safely close a workspace/playground with an important script and always can get it back.
I rebuilt my images regularly, so it could be nice to have that linked to a repository. And yes, simple and dependable. Like in: there is no need to explain how it works... Or that the how is obvious.
Saving states of the workspaces / playground in a kind of log and doits as actions on those? Visible in searches? Stored in the package cache? Robust to multiple images use on it?
Thierry
-- www.tudorgirba.com
"Every thing has its own flow"
-- www.tudorgirba.com "Every thing has its own flow"
Hi, Here are my answers: El 12/12/14 a las 06:14, Tudor Girba escribió:
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?
Being a non programmer newbie with some experience python and some other scripting languages, scripts bridge the gap between pharo and my previous experiences in programming. I use scripts to: - Put everything that is not in a method or some concept test of something that would end in a method. - Run some code snippets when I'm catching up with the list and try to understand what the talk is about. - Ask questions more precisely trying to run minimal examples of my issues to focus the question. - Interchange text notes with code for making memories of my own understanding.
- Do you rely on script files stored on the disk at all?
Yes.
- Where do you store your scripts (in one folder, in many folders)?
In a ston file which contains my notes on different projects which doesn't conform to the class hierarchy/logic. I have attached my "Aprentice Notes" as an example.
- Do you version your scripts?
Yes on fossil dvcs.
- Do you store them in separate files with dedicated names, or tend to put multiple snippets in one larger file?
One larger file in ston format.
- Do you rely on the names of the scripts?
Yes and the hierarchy where they are located. See the attached screenshot.
- Why do you use a script file and not a class?
See first answer. Cheers, Offray
Am 12.12.2014 um 12:14 schrieb Tudor Girba <tudor@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
participants (10)
-
Alain Busser -
Alexandre Bergel -
Benoit St-Jean -
David Boeren -
Eliot Miranda -
Norbert Hartl -
Offray Vladimir Luna Cárdenas -
Sven Van Caekenberghe -
Thierry Goubier -
Tudor Girba