Action changes marked by colors

[PvD_SE]

Hi folks!

When adjusting existing processes and objects to new specifications, or just to fix errors, we tend to mark the changed actions in dark blue. Old actions we mark in light grey. This to make it easily visible what has been changed on each page.

On the next errant of the same process or object, we start with changing the blue actions back to black, and remove the now obsolete grey actions. Following that, we'll commence with the fix, again marking changes in blue and old stuff in grey. 

This is how we work, but perhaps there are better ways to mark changes for the next developer. Or perhaps it is deemed best to not mark changes at all?

How do you mark (or not mark) your changes to processes and objects?

------------------------------
Happy coding!
Paul
Sweden
------------------------------

[michaeloneil]

Hi Paul

You can compare changes in blue prism but comparing the old and new version of the process/object and it should clearly show where changes have been made.




------------------------------
Michael ONeil
Technical Lead developer
NTTData
Europe/London
------------------------------

[PvD_SE]

Hi Michael,

Thanks for your swift reply! I am aware of the compare window but prefer not to use it.

This is of course easiest as you don't have to do a thing in the process to see the changes. But it requires you to bringing up that window time and time again where I would like to see changes 'live' in the process while I'm working in it. Also, while having a data item or action properties window open in your process, you cannot open the compare window any more - something that I consider a major bug in BP. 

With my decades long career in coding, removing or changing lines in program code is usually a big no-no. Instead you mark the erroneous line as a comment and create a new line with the correct code, leaving the commented line in place. True to habit, I attempt to do similarly in BP, hence the color thing and my question. Again, as I noted, perhaps it is only my place of work that finds this useful.

------------------------------
Happy coding!
Paul
Sweden
------------------------------

[michaeloneil]

Hi

I think the colour coding of the changes is a good approach, its not something I've done before but certainly seems reasonable. I tend to duplicate the action in blue prism that Im changing so the old code is sitting there unattached to anything and i can create the changes I require. I can then easily revert back if required and once I am sure the change is stable I delete the old action/code. I might look at using something like colour coding though as it could be useful.

------------------------------
Michael ONeil
Technical Lead developer
NTTData
Europe/London
------------------------------

[PabloSarabia]

Hi!

In my case, we use colors only for separte and organize stages and data items. (For example if the process need to work with different applications, one color per application)

Usually, when we are developing the process we use the black and normal style to put the stages, and when we revise it, we change it to dark blue and bold.

If we need to add any comment or indicate that something change we use the Notes Stage in green color always. Useful if the logic is strange or similar.

And always, we put in the comments when you save what we change.

If we need to check any different between process version we use the compare function as Michael said.


And I would like to say goodbye with a sentence (Just for joking)

"Code never lies, comments (and in this case, color too) sometimes do."
-Ron Jeffries-



See you in the Community, bye 🙂

------------------------------
Pablo Sarabia
Solution Manager & Architect
Altamira Assets Management
Madrid
------------------------------

[PvD_SE]

Hi Pablo,

I like the idea of dedicating a color to an application used in the process. Kudos for that idea! And thanks for sharing!

I can close with an old quote from my programming professor 30+ years ago:
"Problems are created at the terminal, and solved on paper."
My interpretation:
"Code can lie, depending on the medium is is viewed on."

Note to anyone born after 1980:
This was in the time were we accessed a server via a dedicated workstation that might show you 15 lines of code on the tiny mono-chrome screen. So, we'd print everything in order to browse and understand the program code. Hmmm, I wonder if I am what they nowadays leisurely refer to as a dinosaur...

------------------------------
Happy coding!
Paul
Sweden
------------------------------