Difference between revisions of "Communicating Of Patterns"
(Created page with "= Bridging The Gap = Creating scripts to automate graphics-orientated programs like InDesign, Illustrator... is not quite the same as general software development. In general...") |
(→Bridging The Gap) |
||
| Line 2: | Line 2: | ||
Creating scripts to automate graphics-orientated programs like InDesign, Illustrator... is not quite the same as general software development. | Creating scripts to automate graphics-orientated programs like InDesign, Illustrator... is not quite the same as general software development. | ||
| − | In general software development, most times the people | + | In general software development, most times the people viewing software source code are software developers or engineers. |
| − | + | They share a large amount of background knowledge that does not need to be communicated. | |
| − | In that case the different actors do not necessarily share | + | Properly written source code written by one engineer can be read and understood by another engineer. They understand the basic rules of software development, and there is no need to re-iterate what is common knowledge between them. |
| + | |||
| + | It's not a simple situation. There are many often mutually conflicting schools of thought around 'proper' software development, and two software engineers disagree on what is 'best practice'. But they'll understand what the other rules are, even if they don't necessarily agree with them. One engineer might prefer indentation with spaces, the other might prefer tabs (an eternal debate that will never be settled). | ||
| + | |||
| + | When it comes to writing scripts for graphic workflows, the situation is even more complex. Often a software developer is involved, but at the same time, a non-software developer will be involved too. For example, a graphics designer might want to tweak some existing script to better match their workflow. | ||
| + | |||
| + | In that case the different actors do not necessarily share an understanding of what rules there might be. | ||
| + | |||
| + | When a non-developer reads a script written by a software developer, a lot of detail will escape being noticed. | ||
This web site is an attempt to bridge that gap. | This web site is an attempt to bridge that gap. | ||
| − | It allows a software engineer to communicate to a 'consumer' of the software what they need to pay attention to | + | It allows a software engineer to clearly communicate to a 'consumer' of the software what they need to pay attention to, and to highlight important aspects in a standardized way. |
It allows a graphics-orientated person to understand important details about a script without needing to get a degree in computer science. | It allows a graphics-orientated person to understand important details about a script without needing to get a degree in computer science. | ||
Revision as of 00:10, 6 April 2017
Bridging The Gap
Creating scripts to automate graphics-orientated programs like InDesign, Illustrator... is not quite the same as general software development.
In general software development, most times the people viewing software source code are software developers or engineers.
They share a large amount of background knowledge that does not need to be communicated.
Properly written source code written by one engineer can be read and understood by another engineer. They understand the basic rules of software development, and there is no need to re-iterate what is common knowledge between them.
It's not a simple situation. There are many often mutually conflicting schools of thought around 'proper' software development, and two software engineers disagree on what is 'best practice'. But they'll understand what the other rules are, even if they don't necessarily agree with them. One engineer might prefer indentation with spaces, the other might prefer tabs (an eternal debate that will never be settled).
When it comes to writing scripts for graphic workflows, the situation is even more complex. Often a software developer is involved, but at the same time, a non-software developer will be involved too. For example, a graphics designer might want to tweak some existing script to better match their workflow.
In that case the different actors do not necessarily share an understanding of what rules there might be.
When a non-developer reads a script written by a software developer, a lot of detail will escape being noticed.
This web site is an attempt to bridge that gap.
It allows a software engineer to clearly communicate to a 'consumer' of the software what they need to pay attention to, and to highlight important aspects in a standardized way.
It allows a graphics-orientated person to understand important details about a script without needing to get a degree in computer science.
