rudimusmaximus / devflow Goto Github PK
View Code? Open in Web Editor NEWA Dev Flow for Google Appscript
A Dev Flow for Google Appscript
objective / purpose
Demo to walk through examples of the .
see also https://mashe.hawksey.info/tag/google-apps-script-patterns/
objective / purpose
A few files to establish .gs namespace for our work with enums to handle semantic versioning
completion checklist
This is pre v1.0.0 release work.
Gist for example nested namespace in an addon
more changes
do this both in cli git and gitkraken
Add any history or detail in this subsection. Add others if needed
update
because this repo is the public repo of a private user (not org), we need better access to the issues to collaborate on them.
SO, we are using glo boards. With some risks. See #32
And also review how histories are updated with changes to issue summary line/title.
Globoard users with edit access CAN EDIT EACHOTHERS comments.
objective / purpose
Create some ZenHub releases and initial epics to collect issues for planning some work.
completion checklist
This is a planning item for discussion.
v0.1.0 "empty shell" - the basic repository with .github folder of templates for contributing, issues, and pull requests and without code
v0.2.0 "namespace w semantic versioning" - a few files to establish .gs namespace for our work
v0.3.0 "make test ready" - automation of applying naming standards during script development and sheets testing
v1.0.0 "minimal addon for sheets" - Demonstrable, can clone and publish test as addon; a basic sidebar and at least one function to demonstrate changes, workflow start and restart
v1.1.0 "what's new" - the what's new approach from earlier TU Episode
all future releases - star this repo and follow via zen board, fork and suggest, or create issues for requests
objective / purpose
CONFIRM and REVIEW for accuracy against git flow practice and git kraken implementation by running demonstrations on a test repository while monitoring the git directly.
completion checklist
POST LIVE:
objective / purpose
See #7, implement what we demonstrated into this repository....OR demo what we implemented if demo is created afterward.
completion checklist
POST LIVE:
objective / purpose
We have sheets analytics in our make test ready / goListing process. expand it's use so we can capture start, restart, and demo starts, ask demos to include with same pattern or as improvement in phase II.
Criteria | Meets Specifications |
---|---|
1. this | a. subtopic b. another sub topic |
2. that | a. subtopic b. another sub topic |
3. this | a. subtopic b. another sub topic |
4. that | a. subtopic b. another sub topic |
5. this | a. subtopic b. another sub topic |
cover
how to remove this
objective / purpose
establish analytics that account for TC, RC, and our listing if placed into marketplace
may need to cover the different kinds of logging in this or separate
discuss
completion checklist
POST LIVE:
objective / purpose
How to document best practices with the tools we are using. For example, git hooks or commit templates in GitKraken, packages and themes in atom, etc.
completion checklist
POST LIVE:
objective / purpose
Formalize git commit style for DevFlow.
completion checklist
POST LIVE:
Referencing style guides for Udacity nanodegree front end web developers, modify contributing.md with an adapted template for DevFlow. These are not automated, so add a check for consistency in the default issue lifecycle.
See these from Udacity course notes:
Adapted from Udacity Git Style Guide for this DevFlow.
We need this new checklist item in the issue lifecycle.
Add a section in contributing based on Git commit style guide above.
type: subject
body
footer
WHERE subject is mandatory and the rest optional based on content.
where repo uses git flow and semantic versioning inside codebase namespace.
EXAMPLE modified from Udacity
feat: Summarize changes in around 50 characters or less
More detailed explanatory text, if necessary. Wrap it to about 72
characters or so. In some contexts, the first line is treated as the
subject of the commit and the rest of the text as the body. The
blank line separating the summary from the body is critical (unless
you omit the body entirely); various tools like `log`, `shortlog`
and `rebase` can get confused if you run the two together.
Explain the problem that this commit is solving. Focus on why you
are making this change as opposed to how (the code explains that).
Are there side effects or other unintuitive consequences of this
change? Here's the place to explain them.
Further paragraphs come after blank lines.
- Bullet points are okay, too
- Typically a hyphen or asterisk is used for the bullet, preceded
by a single space, with blank lines in between, but conventions
vary here
If you use an issue tracker, put references to them at the bottom,
like this:
Resolves: #123 [DO NOT use GitHub issue close language if running sprints using ZenHub Here]
See also: #456, #789
n/a
Note when using GitFlow and our DevFlow label scheme with this new commit style guide, we have three different schemes of classifying changes each with its own purpose and we can make the case for each being equally valid. We will do all three. Listed here for clarity.
GitFlow Branch types | Git Commit subject line types |
Issue Label Scheme |
---|---|---|
feature, release, hotfix |
feat, fix, docs, style, refactor, test, chore |
The relevant portion of our label scheme would be: DOCUMENTATION, admin-bug, admin-duplicate, admin-enhancement, admin-invalid, admin-optimization, admin-question/assignment Plus the other DevFlow labels as dictated in CONTRIBUTING.MD guidelines |
Open for suggestions. Can this be done in the repo so copies get the enforcement? or is this a per machine basis?
This is one answer but githooks are unique to local user repo and do not persist or propogate; still could offer as template to help submitters?
Review what happens to life of commit messages as the change moves through the fork and pull contribution lifecycle.
https://support.gitkraken.com/working-with-repositories/githooks
TODO
objective / purpose
Good addition to label scheme whether public or private repo. If private, maybe good suggestion for new team member.
completion checklist
POST LIVE:
In DevFlow, we have github accounts, gitkraken accounts and others. How can I best manage my profile image?
Will use a few of theirs and sometimes your github avatar. BUT it will use a gravator if you have one with wordpress by checking for one with the email you use for GitKraken and GitFlow (the same).
GitHub uses identicons and allows you to set a profile image. Intructions here
See this wiki how and gravatar site to setup a gravatar for all your needs :)
Create a gravatar associated with the same email you are using for GitKraken and then it will just work.
objective / purpose
Demonstrate use of epic to group 2 issues, ideally this grouping would be around the user story.
Starting in the Contributor, Participant, or Spectator column:
1 Please ask your questions in a New Issue and paste the Outline from the next comment block below. Add detail as necessary and include issue numbers by # notation if there are any.
2 Assign the following labels to your new issue:
3 Assign a best guess at the Complexity of your question from the following options:
4 As the question is worked, add any tasks if we need to track completion or divide and conquer
5 When the group is satisfied with an answer, update the Final Answer section making sure tasks if any are completed.
6 Add the Label "Fixed"
7 DO NOT CLOSE the issue as we want to see them in glo boards
See GitHub's Guide for advice on using markdown styling.
objective / purpose
restart not creating new menus like start workflow is
completion checklist
POST LIVE:
Current work around:
objective / purpose
Add more from presentation into the readme and contributing files
completion checklist
See changes in readme and contributing.md files and original presentation is design.
objective / purpose
fix bad link. (see images)
completion checklist
POST LIVE:
objective / purpose
Demonstrate DevFlow being used on a Chromebook.
From readme.md's special note on chromebooks:
"It is possible to install and run some releases of Linux on a Chromebook that's been put into Developer mode.
Please see "crouton" - Chromium OS Universal Chroot Environment
The cool part here is that you are not dual booting and the Chromebook appears to receive updates and continues to support multiple users. I'm told this voids the warranty on the Chromebook? Worth exploring."
Please provide an example of this working and describe how you did it.
completion checklist
POST LIVE:
wip
No change this repo, this issue is documenting an answer to a question.
wip
n/a
n/a
n/a
objective / purpose
"what's new" - the what's new approach from earlier TU Episode
completion checklist
POST LIVE:
objective / purpose
Establish repo, shake out process with 1 test account and volunteer, get addon to point of being able to clone and run test as addon.
Criteria | Meets Specifications |
---|---|
1. Comply with rubric | a. no rubric |
2. Promo Tiles | a. TODO: update notes see also #49 |
3. Comply with authorization lifecycle | a. Install and onOpen trigger functions that create menu scheme for all demos and allows for start/restart |
4. DevFlow Guidelines | a. Follow addon conventions b. Use semVersioning w 'make test ready' automation and nested namespacing see #8, #5, #11, #13, #14 c. Templates and guidelines for git commits, glo board usage. see epic #34 , |
5. Demo participants | a. Enable demo so phase II participants can add their demos following our guidelines. |
objective / purpose
Host images for the README.md file starting with the original presentation for this repository.
POST LIVE:
objective / purpose
we need to check our overall process as we designed for one registered script to publish to a domain; let's expand to allow for publishing to groups, unlisted links, domains, and market.
Establish guidelines, see discussions. Dedicated scripts for each, but review and document.
completion checklist
POST LIVE:
see working notes Registered scripts (IDs by type), make test ready (current stated domain)
Create new enums:
Modify logic here to account for new enums for registered scripts (additional or logic)
see Add-on/Con-stants-structs-tainers.gs
/**
* Returns the requested hardcoded literal as a string when logic is required
* to determine. otherwise, use appropriate Enums.
*
* @param {string} requestedField - field name of hard coded value for curent version of CF Maker
* @return {string} responseString - the value associated with the requested field name.
*/
function getLiteral(requestedField) {
var response = "";
switch (requestedField) {
case "currentStatedDomainCode":
//STATED DOMAINS are unique to the domain the script is deployed from (assumed same id when published via developer dashboard)
// if not set at deployment, undregistered scripts will be treated as a disposable alhpa, meaning the script is a test copy and not a script file that gets pushed to a production domain (ie published to the store)
var scriptId = ScriptApp.getScriptId();
if (scriptId === RCM$.ThisAddon.Enums.RCC_REGISTERED_SCRIPT_ID) {
response = RCM$.ThisAddon.Enums.REDCROWCONSULTING_STATED_DOMAIN_CODE;
break;
} else if (scriptId === RCM$.ThisAddon.Enums.RCM_REGISTERED_SCRIPT_ID) {
response = RCM$.ThisAddon.Enums.REDCROWMETHODS_STATED_DOMAIN_CODE;
break;
};
response = RCM$.ThisAddon.Enums.DISPOSABLE_ALPHA_STATED_DOMAIN_CODE; //is unrecognized and likely a "disposable alpha script which could be in any domain and if so the user email will be a developer and give it away; note: this value is checked in go listing so change with care
break;
default:
response = "Requested field not defined among literals.";
break;
} //end switch
return response;
} //end getLiteral
Completed for two domains as follows and will test to LNK from RCM domain in phase II project.
For existing registered scripts,
From @rcm
Scenario | Results | Comments |
---|---|---|
1. unregistered newly created, standalone script | created script and sheets target named DevFlow TC - 0.5.4-registeredScripts.3 - Wed Sep 05 2018 12:36:11 GMT-0500 (CDT) |
able to test, no issues, found edge case 1 |
2. registered MKT | a. with long semVer renamed script and created identical target sheet DevFlow RC - 0.5.4-registeredScripts.3 - Wed Sep 05 2018 12:43:36 GMT-0500 (CDT) b. with short semVer, reanamed script with no target sheet as expected (see notes) |
a. able to test, no issues b. no target to test and not yet published, no issues 2 |
3. registered LNK | a. with long semVer b. with short semVer |
a. able to test, no issues b. able to test, no issues |
[18-09-05 13:06:19:561 CDT] Sheet is at https://docs.google.com/a/redcrowconsulting.com/spreadsheets/d/1hKLgQHLoSvKcUGYBbcVJEcigwIuI_MbdAFUniEjVRYM/edit
[18-09-05 13:06:19:562 CDT] Completing successfully.
[18-09-05 13:06:19:562 CDT] Tracking analytics...
[18-09-05 13:06:20:187 CDT] STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1pvIALzhxpkzV1MlgNX4Q1qtIBDD9LD4fh0HfXWnYwNcsjFLlYIIFH3WP/edit?usp=drivesdk
SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible
Naming your script 'Unexpected goListStatus in renaming. Investigate.'
Scenario | Results | Comments |
---|---|---|
1. unregistered newly created, standalone script | pass | pass |
2. registered MKT | pass | pass |
3. registered LNK | n/a | n/a |
Potential issue or training note. When pulling into new script and semVer is short, the make test ready will stop as follows:
[18-09-05 13:06:16:664 CDT] Starting analytics...
[18-09-05 13:06:16:665 CDT] Setting 'GoNoGo Status' to 'N'...
[18-09-05 13:06:16:724 CDT] Checking if already goListed...
[18-09-05 13:06:17:395 CDT] Not listed. Creating new goListRcd...
[18-09-05 13:06:17:401 CDT] Creating standard name...
[18-09-05 13:06:17:402 CDT] Renaming script to:
'Unexpected goListStatus in renaming. Investigate.'...
[18-09-05 13:06:18:504 CDT] Writing goListRcd...
[18-09-05 13:06:18:745 CDT] Priming script properties...
[18-09-05 13:06:18:822 CDT] Creating matching target Sheet for testing... ↩
log was as follows
[18-09-05 12:47:27:808 CDT] Starting analytics...
[18-09-05 12:47:27:809 CDT] Setting 'GoNoGo Status' to 'N'...
[18-09-05 12:47:27:861 CDT] Checking if already goListed...
[18-09-05 12:47:28:425 CDT] Not listed. Creating new goListRcd...
[18-09-05 12:47:28:430 CDT] Creating standard name...
[18-09-05 12:47:28:431 CDT] Renaming script to:
'DevFlow'...
[18-09-05 12:47:29:178 CDT] Writing goListRcd...
[18-09-05 12:47:29:364 CDT] Priming script properties...
[18-09-05 12:47:29:461 CDT] This is a production deployment. No matching test sheet required.
[18-09-05 12:47:29:461 CDT] Completing successfully.
[18-09-05 12:47:29:462 CDT] Tracking analytics...
[18-09-05 12:47:30:681 CDT] STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowmethods.com/d/11Gzf_FjgohKQddB4Fk3cSTAfhUGfjdWof2WoolG-pS8-1uvRhIFiR9_K/edit?usp=drivesdk
SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible ↩
@rudimusmaximus commented on Wed Jun 28 2017
Hola! @rudimusmaximus has created a ZenHub account for the rudimusmaximus organization. ZenHub is the only project management tool integrated natively in GitHub – created specifically for fast-moving, software-driven teams.
To get set up with ZenHub, all you have to do is download the browser extension and log in with your GitHub account. Once you do, you’ll get access to ZenHub’s complete feature-set immediately.
ZenHub adds a series of enhancements directly inside the GitHub UI:
Still curious? See more ZenHub features or read user reviews. This issue was written by your friendly ZenHub bot, posted by request from @rudimusmaximus.
objective / purpose
Shake out how we work special projects with volunteers and on team. This epic will collect meta type work so we can establish best practices we will later bake into what we call DevFlow.
Criteria | Meets Specifications |
---|---|
1. this | a. subtopic b. another sub topic |
2. that | a. subtopic b. another sub topic |
3. this | a. subtopic b. another sub topic |
4. that | a. subtopic b. another sub topic |
5. this | a. subtopic b. another sub topic |
objective / purpose
Demonstrable, can clone and publish test as addon; a basic sidebar and at least one function to demonstrate changes, workflow start and restart, placeholder menu items for intended demo list
completion checklist
POST LIVE:
Nice article. I use DevFlow to resolve his item 1 but a nice article. I will point out his comment on material design is about android add-ons and NOT standard GSuite add-ons which have their own style guide -- see apps script add-ons style guide
See article on auth flow and file naming conventions for script separation "6 deadly sins"
Also, see comments in clasp issue on gs to js describing files approach for add-ons. In these notes, the contributor describes their file naming approach: "
Also about the client javascript, we currently have this sort of typical structure (locally):
─ main.gs
─ someLib.gs
─ sidebar/
└─ index.html
└─ clientCode.js.html
─ dialog/
└─ index.html
└─ clientCode.js.html
"
Review that against the 6 sin article and also see #5 #29 #28 but periods in file name is ok TODO:test
TODO:
These are the files that Gas GitHub Assistant will pull or push to hosted repo (currently GitHub)
See also #49. Here, are the promo/marketing tiles and icon options for our top level addon.
https://drive.google.com/a/redcrowmethods.com/file/d/17TqcXiqBniFhy4Tk3tb4Gcq3iHY-GPCy/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1J8CL--1UWWcp5_MoYuafrDhbQaoiv-wQ/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1fNTRacjyoAnuawbRyHRs-iZwMO2Lz_-u/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1nh72Vvd2wt0hLuf9ls873PHwgqzDdaVr/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1rP_t4Ehg7OMSWMeX2dH5Z_lg_8xP6Vw0/view?usp=sharing
https://drive.google.com/a/redcrowmethods.com/file/d/1tKXOw9q6lGitMrTQNZH4BH3q39XM7b4F/view?usp=sharing
n/a yet
objective / purpose
completion checklist
POST LIVE:
objective / purpose
"make test ready" - automation of applying naming standards during sheets addon script development and sheets testing 'test as addon'
completion checklist
POST LIVE:
full pipeline documentation
Since DevFlow recommends creating some of your own automation to improve standards where possible, we felt the need to design something around semantic versioning. When 'testing as addon' from a standalone script, a target sheet has to be selected when defining the test. Over time, you generate lots of sheets. Additionally, many scripts can be created since we have the ability to pull from our origin repositories.
Criteria | Meets Specifications |
---|---|
1. Register and track any number of scripts | a. Ability to register a script ID as the official script from which an addon would be published, b. Document short 'stated domain codes' such as @rcc, @rcm for the registered scripts; all other scripts should have a stated domain code of "DA!" for 'disposable alpha'; |
2. Script and Target Sheet Naming | a. ability to programmatically rename script, b. Create new target sheet using same naming scheme as script, c. The name follows a standard of derived from rules base on addon name, semantic version, long name designating branch and iteration with timestamp and designates release candidate, test copy, or ready as addon name only' (this is because when script is published the name becomes the name of the addon in the menu) |
3. Go No Go | a. provide a function to test file was 'go listed' by make ready in documented sheet (to be used on start workflow in future) b. must persist data not otherwise available at runtime so can run goNoGo for a user if so desired (see properties services) |
5. Special cases | a. does not allow for duplicate make ready on scriptID&semVer combination |
These are in the go list table and are used for the naming logic. Registered domains get the "@" symbol followed by a short code -- so ["@"]+["unique short 3 or 4 digit code"]
The only exception is "DA!" which is reserved for all unregistered scripts.
Start with these three:
Registered means we enum the script id, assign it a domain code, and check for it in the logic.
Make test ready runs functions in a namespaced goListSvc. 'GoListing' is achieved via mini-service here in a namespace and run prior to testing or deployment post changes;
External google sheet with access for contributors wishing to employ the "make test ready" process.
Special note: the GMT Stamp is in GMT, but the created file name is in offset GMT based on the local server time zone. This is so the developer can recognize the time on their new script names and target sheets.
Y | M | W | GMT Stamp (-5CDT,-6CST) | Active User | Stated Domain |
AddOnVer | Script ID | Go List Status | Script Name | Script URL |
---|---|---|---|---|---|---|---|---|---|---|
2018 | 5 | 21 | 2018.05.26 04:19:09.000 AM | [email protected] | @rcc | 0.3.0 | 1EdAROkZV8jZmDrzAtfbjDWFinWPOlMT3JPVgcn-_RxXXcg87wJVIoBoi | READY | DevFlow | https://script.google.com/a/redcrowconsulting... |
2018 | 5 | 21 | 2018.05.24 07:08:11.000 PM | [email protected] | DA! | 0.3.0-makeTestReady.14 | 1j11oy1rKWZrJttYBpCFjrIHk4Xd_LVO1t7PO4LL11WSv0Qa8i9YcvrZf | TEST COPY | DevFlow TC - 0.3.0-makeTestReady.14 - Thu May 24 2018 14:08:11 GMT-0500 (CDT) | https://script.google.com/a/redcrowconsulting... |
2018 | 5 | 21 | 2018.05.24 05:35:52.000 AM | [email protected] | @rcc | 0.3.0-makeTestReady.14 | 1EdAROkZV8jZmDrzAtfbjDWFinWPOlMT3JPVgcn-_RxXXcg87wJVIoBoi | R CANDIDATE | DevFlow RC - 0.3.0-makeTestReady.14 - Thu May 24 2018 00:35:52 GMT-0500 (CDT) | https://script.google.com/a/redcrowconsulting... |
2018 | 5 | 21 | 2018.05.24 05:32:46.000 AM | [email protected] | DA! | 0.3.0-makeTestReady.14 | 1dL0u0lOuCdakopBqUQSbaAr1ot0lBcAtBO8Y4djtA-xktgDaxL1JsAs4 | TEST COPY | DevFlow TC - 0.3.0-makeTestReady.14 - Thu May 24 2018 00:32:46 GMT-0500 (CDT) | https://script.google.com/a/redcrowconsulting... |
2018 | 5 | 21 | 2018.05.24 05:25:18.000 AM | [email protected] | @rcm | 0.3.0-makeTestReady.14 | 11Gzf_FjgohKQddB4Fk3cSTAfhUGfjdWof2WoolG-pS8-1uvRhIFiR9_K | R CANDIDATE | DevFlow RC - 0.3.0-makeTestReady.14 - Thu May 24 2018 00:25:18 GMT-0500 (CDT) | https://script.google.com/a/redcrowmethods... |
Get the following standard name
Format:
[USER_FACING_NAME_OF_ADDON]+' TC - '+[CURRENT_ADDON_VERSION]+' - '+[newDate in GMT offset into local server time zone]
Example:
DevFlow TC - 0.3.0-makeTestReady.14 - Thu May 24 2018 14:08:11 GMT-0500 (CDT)
Get the following standard name for registered scripts with novel semantic versions (previously unlisted per req 5.a.)
Format:
[USER_FACING_NAME_OF_ADDON]+' RC - '+[CURRENT_ADDON_VERSION]+' - '+[newDate in GMT offset into local server time zone]
Example:
DevFlow RC - 0.3.0-makeTestReady.14 - Thu May 24 2018 00:35:52 GMT-0500 (CDT)
Get the following standard name
Format:
[USER_FACING_NAME_OF_ADDON]
Example:
DevFlow
The reason here is that the published addon will list the script name in the store and in the addons menu.
github.com/rudimusmaximus/DevFlow
Develop: feature/newBranchName
G/gs/namespace_DEV$_top_level.gs
. Set the DEV$.Developer.Enums.CURRENT_ADDON_VERSION
value to something like "0.3.0-newBranchName.1"
Hint: you can just make this change and iterate on the web copy if you like which may happen as you debug.DevFlow should now have same name scripts and target sheets iterating on Semantic Versions.
n/a
"make test ready" will be a recommended, DevFlow best practice process. We will not enforce in the addon's start workflow mechanism BECUASE we want casual enthusiasts to be able to fork and pull, clone and run a test as addon locally without membership to globoard or edit access to the two external files required for that process.
We will leverage the built-in StackDriver analytics to capture within a 7 day? window all execution times and exceptions.
That said, consider a review in phase III or sooner if time permitting, to review the analytics used in the goList 'make test ready' process.
We may be able to leverage approach to generate objects we pass to stackdriver logging and not to any table.
Review what we use and if we should move to Universal Time or other OR if we can/should match stackdriver's approach. Must allow for people around the world contributing.
External google sheet with access for contributors wishing to employ the "make test ready" process.
Special note: the GMT Stamp is in GMT.
Y | M | W | GMT Stamp (-5CDT,-6CST) | Active User | Stated Domain |
Add On Ver |
Current LoB | Step | Sub Step - by click, action, scenario scheme |
D secs |
Exit Memo | S | E | External Output | Ux count |
Ux secs |
Net secs |
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
2018 | 5 | 21 | 2018.05.26 04:19:10.000 AM | [email protected] | @rcc | 0.3.0 | Repurposed for DevFlow | Go list a script | developerAction: G Web Editor > 'goListTheCurrentScript' | 1.927 | STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1EdAROkZV8jZmDrzAtfbjDWFinWPOlMT3JPVgcn-_RxXXcg87wJVIoBoi/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible |
1 | 0 | Event log entry | 0 | 0.000 | 1.927 |
2018 | 5 | 21 | 2018.05.24 07:08:12.000 PM | [email protected] | DA! | 0.3.0-makeTestReady.14 | Repurposed for DevFlow | Go list a script | developerAction: G Web Editor > 'goListTheCurrentScript' | 2.404 | STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1j11oy1rKWZrJttYBpCFjrIHk4Xd_LVO1t7PO4LL11WSv0Qa8i9YcvrZf/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible |
1 | 0 | Event log entry | 0 | 0.000 | 2.404 |
2018 | 5 | 21 | 2018.05.24 05:35:55.000 AM | [email protected] | @rcc | 0.3.0-makeTestReady.14 | Repurposed for DevFlow | Go list a script | developerAction: G Web Editor > 'goListTheCurrentScript' | 2.55 | STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1EdAROkZV8jZmDrzAtfbjDWFinWPOlMT3JPVgcn-_RxXXcg87wJVIoBoi/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible |
1 | 0 | Event log entry | 0 | 0.000 | 2.550 |
2018 | 5 | 21 | 2018.05.24 05:32:47.000 AM | [email protected] | DA! | 0.3.0-makeTestReady.14 | Repurposed for DevFlow | Go list a script | developerAction: G Web Editor > 'goListTheCurrentScript' | 2.206 | STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowconsulting.com/d/1dL0u0lOuCdakopBqUQSbaAr1ot0lBcAtBO8Y4djtA-xktgDaxL1JsAs4/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible |
1 | 0 | Event log entry | 0 | 0.000 | 2.206 |
2018 | 5 | 21 | 2018.05.24 05:25:20.000 AM | [email protected] | @rcm | 0.3.0-makeTestReady.14 | Repurposed for DevFlow | Go list a script | developerAction: G Web Editor > 'goListTheCurrentScript' | 2.4 | STATUS: Renamed script, created goListRcd, file link https://script.google.com/a/redcrowmethods.com/d/11Gzf_FjgohKQddB4Fk3cSTAfhUGfjdWof2WoolG-pS8-1uvRhIFiR9_K/edit?usp=drivesdk SHEETS: 0 hidden, 0 deleted, 0 created, 0 made visible |
1 | 0 | Event log entry | 0 | 0.000 | 2.400 |
n/a
objective / purpose
completion checklist
POST LIVE:
objective / purpose
completion checklist
POST LIVE:
objective / purpose
Improve edge scenario experience where user attempts to 'make test ready' a freshly updated script (whether new TC or updated RC) that has a short semVer in it and HAS not updated for long semVer.
Test each.
There may be an issue when doing this for a registered release candidate script. confirm
completion checklist
POST LIVE:
"make test ready" is a recommended, DevFlow best practice process.
See #8 ...DevFlow/issues/8 for complete details. Otherwise, follow the steps in this issue and ask for a walkthrough.
Using your GitHub account to signup,
With the same Google email from which you will be editing your scripts, get permissions to the two external google sheets required to employ the "make test ready" process. As follows:
This issue is your work aid. Follow the steps in this issue and ask for a walkthrough.
Remember, it's voluntary to follow this process; however, it will improve your workflow if you are iterating changes on your forked version of DevFlow.
It's really there to make things easier for the developer. Processes take time to get used to, but once you debug live and generate a number of files...you should see the benefits.
Practitioners, you can further customize the target sheet creation to help in your project. Say, include a baseline data set of sheet or sheets in your target google spreadsheet.
After all, it's called Make Test Ready.
objective / purpose
Demo to walk through examples of the CSS pakage for add-ons. consider including link to style guide.
Create an issue for each part.
see also https://developers.google.com/apps-script/add-ons/css
and https://developers.google.com/apps-script/add-ons/style
globard edit users can delete labels (not sure if this synchs to github...not yet anyway). Labels may just be 'seeded' form the repo. explore more, create a way to backup to dummy repo using label copy tool.
add a working list in table view using md
We are using ZenHub for code sprints and Glo for this project work to 'Shake Out' the dev flow process. This means using the label scheme and documenting along the way - especially as glo is a young product.
Phase II will use a Glo board to facilitate discussion around templates and deliverables for the repo and to get ready to use ZenHub in live sprints in phase III and trial sprints in late phase II. The Glo boards will facilliate our Weekly wednesdays.
5/11/18 pm - Had a long chat with support, they are contacting developement and documenting some qeustions:
1 board out of sync with github issue
2 assignments to issues
3 making more issue fields available
More updates to come, link to chat part 1 here
Link to chat part 2.
Looks like some changes like labels are posted in github history as the admin owner of the globoard.
Participant and other history changes are noted by github username. Explore other differences. Basically, there are card activities and card actions that stay on the globoard in terms of viewing the log of activity. Many of these don't exist in GH.
As long as we are logged into our glo-boards, we are in sync with latest (noted)
Labels are seeded from repo when synced board is created but nature of sync with deletes and edits is unclear.
Move assignments to GH manually by someone with write access to master repo (possibly our two leads). IF we can confirm that contributors can be assigned issues after their changes make it to the default (in our case master) branch. Appears the case with @DevFlow-Developer1 testing with @RobGoelz. if so, we just need to have globoard users make modest readme.md contributions and get those into master. maybe by sprint time the glo sync will work for assignments. see last block of notes and update, more testing to come.
TODO: update. Current approach is branch protection settings see #31 and to keep assignments inside of glo board UNTIL we are ready for sprint work.
See the gist for getting started with GAS in issue #45 about it's support of javascript and while Google has accepted ES6 compliance as a TODO, there is no timeline.
On google plus
Paul Miller has a nice Es6-shim ready for browser use
Which was modified to work with serverside HERE
Use patterns proven effective and DO NOT TRANSPILE. WHEN we can get a reliable date of support OR a proven and popular solution. Refactor the code!
This will be difficult but will be a good learning point as we learn ES6 and use some older JS in the form of GAS.
objective / purpose
the basic repository with .github folder of templates for contributing, issues, and pull requests and without code
completion checklist
see presentation notes in readme.me and contributing.md
objective / purpose
completion checklist
POST LIVE:
objective / purpose
see #56
completion checklist
POST LIVE:
Need a place to catch up.
We are driving to put 'everything' into the repo and keep up to date via Glo Board.
Here is a direct link to the web app for this board
Notes from meetings will be logged Markdown style in updates to this issue here in chronological order.
Meetings will be on Wednesdays and either be a working session, a general session or combination of the two:
Key Completed:
Key Upcoming:
Leads with access to maintain a high-level plan. The main dates are above.
Our website hosts the latest and most detailed publically available plan is on our site.
See our project site
Abbreviations:
Agenda: special guest from at&t scheduled to join us!
1 State of the repo and release updates
2 Phase II our "deliverables" updates - repo documents to model the DevFlow approach
3 State of the Demos updates - when started
4 Session Highlight - Make Test Ready process, Glo Boards show and tell demo with lessons learned
5 Q&A - Open questions and hands-on
Notes:
Here's the presentation PDF with live links AND the recorded session of 1hr30m.
Hear from our at&t guest at the end after the demo.
GAS Basics working sessions to try out GAS on sheets data; some of these could be turned into demos of successful "GAS patterns"
Topics covered include
This week's Cool links:
Unassigned Action Items: research items, problems to solve, notes, special items
Next Week: part 2
Canceled due to holiday; merging with General Session II.
GAS Basics working sessions to try out GAS on sheets data; some of these could be turned into demos of successful "GAS patterns"
Topics covered include
This week's Cool links with a few more added for time off:
Next Week: IMPORTANT TIME OFF MESSAGE
our add-on working sessions to prep our addon so volunteers can add demos
Topics covered include
This week's Cool links:
Upcomming:
our add-on working sessions to prep our addon so volunteers can add demos.
Topics covered include
This week's Cool links with a few more added for time off:
Upcomming:
No recording. Working session.
Hot links include incorporating Clasp see #62.
If you want to do a demo, let us know by saying so on issue 46 by Wed the 19th. State which one and whether you'd like to get it done before next General Session on second Wednesday in Oct or during phase III and we will reserve it for you. Two easy and a third possible, others will be in Phase III. Watch the vid, pick one if you want. Contributors get their pic and LinkedIn included as part of the demo AND can say they contributed to an open source project.
Agenda:
Notes:
1 Here's the presentation PDF with live links AND the recorded session of 41m 30s.
2 Be sure and also check the pdf slides as we added a little content after the meeting.
3 Phase III is OPEN TO THE PUBLIC (more to come)
4 Feedback themes
5 Rudy's notes on organizing principles of getting good at something B/H, C, M
B/H - behavior the critical success factors
figure out what they are, make them your habits, observe the best you can find, follow critical content creators on twitter, pay attention
C - competence
many kinds/domains (this is the stuff of methodologies) examples of competence/acumen include - technical, professional, business, others…
in your career you will generally be working on maybe 4-8 that you should master (check that number, i’m just throwing that out there)
rating competence - if on a scale of 1-5; 1 would be newly trained and 5 might be gets paid to present or published content for sale
M-mastery
10,000hrs + continual learning
a good motto borrowed from martial arts “we need more practice”
6 Closing notes
Rob and I will be working on DevFlow as an ongoing open source with attribution project. So keep watching the space. Also, you can now watch for release updates.
Startup activities:
Additionally, I applied for the ND to learn how to make my own prototypes and help me in bootstrapping a startup.
If you want to learn about that, get to know us through the DevFlow project first.
If your company is looking to establish a GAS team using DevFlow, please reach out as I might be doing some of that in the new year as well.
7 Next items
Add it to this issue history in a new comment block and mention TODO or TODO. Thanks.
A brief strategic overview with links galore.
Try this gist which is now part of a repo "BurningGAS". See below.
This is the ISSUE.MD file in the .github directory.
Link to file on Master
Link to file on Develop
Contribution Guidelines on Master
Contribution Guidelines on Develop
The markdown file's links are above. To save time when working in GloBoard for a code related issue, the first comment section block below contains the markdown text in Develop as of 2018.05.14. Just:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.