Workflow for script coding and testing

[UserQuestion]

This question is about the workflow for crafting Sketchup Ruby scripts.

I have no problem installing others' scripts, or with programming. What has me at a loss is how to craft a script and make iterative changes, with intervening runs/tests.

In basic, VBA, fortran and so on, I could make an immediate run, and modify a program. But with SU2013, and the RBZ that is installed from one location into the SU Program Plugin Folder, I get tangled:
a. having to modify the folder name from Zip to RBZ, just to make edits, and back again
b. making edits of RB scripts in what I call the myProject area, to install afterwards using the SU2013 extension installation schema
c. not seeing a simple way to uninstall an extension, and then install the modified version
d. not recognizing a way to use a RB menu script to create a Toolbar and Icon which would call a script which installs or uninstalls the script being worked on

I thought there might be a way to just create a "run/install script icon", hit that button to run/install, see what happens, edit the script using notepad++, and hit the button again to test...and so on.

I haven't found a workflow URL for this process in the SU documentation at Trimble/Google, and the SU extensions I've opened provide good clues/hints for coding, but don't help with how I can make the workflow for coding/testing/coding/testing...work.

Can anyone provide some pointers to good URLs, or what you consider good sample extensions that show off what I'm trying to do?

Thanks

[Dan Rathbun]

So anyhow, what I do (if I am not using Github or SVN, etc.) is make a local repo folder in the plugins folder, usually named "project"

... beneath that are various project plugins folders as they would be named when they eventually are installed into the "Plugins" folder by the SCF Tools installer, the built-in install from Archive button, or Trimble's ExtensionWarehouse.

IF you write a SkecthupExention registration script for the project, it would go temporarily in the "project" folder, instead of the "Plugins" folder.
(So everything is removed one level down into the "project" hierarchy.. get it?)

Since you are in development, you do not need to have SketchUp do the startup load via extension early on... you will load manually from the Ruby Console command line.

Start SketchUp... open the Console... and assuming your project folder name is "User_Widget" and it's loader file is named "widget_loader.rb".. you would type:
load "project/User_Widget/widget_loader.rb"

If any errors are output.. note the filename and line in the first error message, ALT+TAB back to Notepad++, make changes to the code, resave the file... ALT+TAB back to SketchUp... and reload.

I often use Jim Foltz' Ruby Toolbar that remembers the last file loaded, and assigns it to a button.

There are also a few WebDialog based editor / utilities that can also make it easier to reload files.

[Dan Rathbun]

(1) If you are going to develop, logon as an admmistrator, so you have full access rights to the plugins folder. (Or right-click the SketchUP icon, and choose "Run As Administrator", or "Run with elevated Privileges" etc.)

(2) Forget about zip & rbz during development, that is the avenue of distribution.

(3) Stop thinking of SCRIPT, and start thinking of your code as being defined WITHIN and executing FROM your namespaces. You need to choose a toplevel namespace (module name,) and then write ALL of your plugins within a sub-module of your toplevel module. (Clarify: I mean each plugin has it's OWN sub-module of your toplevel author/company module. That way NONE of your plugins clash with each other, NOR any other author's plugins.)

(4) BE wary of comparing Ruby to Fortran, BASIC, etc. Ruby is MUCH different. It is a dynamic language. This means that modules and classes can be modified at any time. Methods can be redefined, removed, access changed (made private,) etc.
This also means you can reload a file that defines your plugin's module, after making changes, and the changed methods are updated. This is great for development.

(5) Ruby is 100% object-oriented. Ruby has 2 (TWO) things. Objects and references that point at objects. Ruby does not really have variables, but the documentation and some query methods refer to "variables", but I think it is best to have programmers from other languages know from day one, that Ruby only has references, not variables like BASIC.
For example, Ruby references can point at any object, at any time, of any class, and then be changed (re-assigned,) to point at any other object, of any other class (or perhaps the same class.)
So any "typing" of reference names is only in your mind. It it makes you "comfy" to say use bMyRefName to hold a reference only to true or false (or nil,) then thats OK.

Add

(6) Read the "Pick-Axe" Ruby book cover to cover. (see the Ruby Resources sticky topic.)
Doing so will make your journey so much easier, and avoid asking all the questions here that people who do not read the book first have already asked (here and in other forums.)

(7) Do not think or write your code in a linear manner. Think in and write code in an event-driven manner. (Have your code respond to things the user does, or act upon objects the user has selected, or do something with the entity the user has just modified, etc.)
See the API dictionary on all the observer classes.