> > Also I would like to throw my 2 cents in as someone that develops not as > one that writes scripts and tools on a per-show basis to get shots finaled, > but as one that works on longer term projects to serve the ongoing > pipeline. The advise from that conference might be more applicable to > situations like that, where a shot-delivery time frame is not the case. It > really just depends on whether your deliverable is a shot, or software.
I agree, I am also employed as a Pipeline Engineer and do not have the pressing need to script for a single shot but rather develop Pipeline Tools and APIs that are consumed by various departments. I can totally understand where you are coming from and it makes complete sense. I started out as an artist (animator, rigger, and generalist) and then a TD and gradually segway into Pipeline. During this journey, I clearly saw my development focus shift from 'just make it work' to 'make it beautiful and readable'. On Sat, Sep 17, 2016 at 1:47 PM, Justin Israel <justinisr...@gmail.com> wrote: > > > On Sat, Sep 17, 2016 at 5:34 PM Alok Gandhi <alok.gandhi2...@gmail.com> > wrote: > >> @Justin: I agree with readability trumping performance, and almost at all >> times, I follow almost the same tenets. However, in our trade, performance >> is ever more critical and is becoming important every single day. The >> entertainment industry is one of the major stakeholders when it comes to >> demand for processing power. We need that water to look real, 10 million >> polygon processing, we need that. And on top of that, we work on deadlines, >> sometimes unreal. When there is a pressing need to process huge amounts of >> data so that the shot can be approved, we have to do that. And it is at >> such moments, readability might take a back seat. This by no means is a >> justification for ignoring readability but rather the state of affairs. >> There is sometimes a tradeoff involved, sometimes not. You can get the best >> of both the worlds if you have enough time on your hand. >> > > I appreciate this need. Ultimately we have to deliver shots and meet > deadlines. Ultimately we are in the business of making > Movies/Television/Games/<entertainment>, and not necessarily software. > > But really, it doesn't change the point of the advise from that conference > speaker. Even if performance ends up becoming the primary focus, then > naturally the other points become secondary. And you have to weigh those > decisions, right? Do we need this solution beyond this shot? This show? Who > gets to maintain it? How easy it is to continue to be adapted to the next > challenge. > > Also I would like to throw my 2 cents in as someone that develops not as > one that writes scripts and tools on a per-show basis to get shots finaled, > but as one that works on longer term projects to serve the ongoing > pipeline. The advise from that conference might be more applicable to > situations like that, where a shot-delivery time frame is not the case. It > really just depends on whether your deliverable is a shot, or software. > > >> >> It is good that we have a growing and healthy open source community, with >> studios investing in making amazing open source projects - OpenVDB exr, >> Alembic, USD etc. to name a few. With neatly written API to handle >> low-level high-processing procedures, all abstracted for the benefit of >> writing clean yet power packed code. >> >> That's my two cents. >> >> On Sat, Sep 17, 2016 at 9:15 AM, Justin Israel <justinisr...@gmail.com> >> wrote: >> >>> >>> >>> On Sat, 17 Sep 2016, 1:09 PM yury nedelin <ynede...@gmail.com> wrote: >>> >>>> Is performance something you are concerned with for this process? >>>> Yury >>>> >>> Marcus had said it was not a concern. I was just sharing some >>> interesting info on the topic of readability and maintainability >>> >>>> On Sep 16, 2016 6:16 PM, "Justin Israel" <justinisr...@gmail.com> >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sat, Sep 17, 2016 at 5:27 AM Alok Gandhi <alok.gandhi2...@gmail.com> >>>>> wrote: >>>>> >>>>>> >>>>>> Coming back to some of the points that Ian raised: >>>>>> > Readability is a perfectly valid goal to seek but I >>>>>> find maintainability is often overlooked. >>>>>> >>>>>> IMHO more readable code is more maintainable. Readability goes hand >>>>>> in hand with maintainability. In fact, I very much agree that code lasts >>>>>> longer than an author and if you write readable code it will be easier to >>>>>> read and understand for the people after you are gone and are not >>>>>> available >>>>>> to explain why you did what. If by maintainability you meant actually >>>>>> extensibility, then it is a completely different aspect. >>>>>> >>>>> >>>>> As an aside, I just recently went to a convention, and in one of the >>>>> talks the speaker opened with his list of priorities for designing >>>>> software: >>>>> >>>>> 1. Integrity - The software should operate in a predictable manner, >>>>> respond appropriately to exceptional conditions, and clean up nicely >>>>> during >>>>> a termination >>>>> >>>>> 2. Readability - The intent of the code should be clear >>>>> >>>>> 3. Simplicity (has to be justified to be more important than #2) >>>>> 4. Performance >>>>> >>>>> He basically yelled at us for 10 minutes about the importance of the >>>>> first two, and said only when you can prove to me that everything else is >>>>> addressed, that you should then look at performance. It was a pretty good >>>>> talk. >>>>> >>>>> >>>>>> > In driving to a solution avoiding the additional markup (as in my >>>>>> solution or in json/XML) you've likely put yourself (and too often your >>>>>> team after you've left) in a place where you'll need to rewrite the >>>>>> function for future feature requests. >>>>>> >>>>>> If you read my previous posts in this threads, you will see that I >>>>>> clearly mentioned that getting input is an administrative logic. In >>>>>> fact, I >>>>>> provisioned for it and alluded to Marcus about it. Here's what I wrote: >>>>>> >>>>>> - Right in the beginning, we parse the string in a single line, >>>>>> keeping the administrative logic out from the rest of our business >>>>>> code. >>>>>> You can easily replace this single line with whatever parser you want. >>>>>> >>>>>> This means that the code that is responsible for creating nodes >>>>>> should not worry itself with how it is getting the data in, JSON or YAML. >>>>>> And the parser, whichever it is, should not worry about what is going to >>>>>> happen to data it outputs. any good architecture should take care of this >>>>>> point. Making components decoupled and flexible. Good architecture does >>>>>> not >>>>>> only apply to huge libraries or big project, it should be given thought >>>>>> to >>>>>> every single small quantum of code, a function and even inside parts of a >>>>>> function. I did not avoid the input data structure, I simply did not work >>>>>> on that part as was not required my Marcus originally. Even then, I >>>>>> separated the code so that in my implementation, nowhere it does rely on >>>>>> whether I choose JSON or YAML or some other markup. If ten years later, >>>>>> somebody wants to use my implementation, with JSON the only change it >>>>>> would >>>>>> require is to change the first line of my code. >>>>>> >>>>>> >>>>>> >>>>>> On Sat, Sep 17, 2016 at 12:56 AM, Marcus Ottosson < >>>>>> konstrukt...@gmail.com> wrote: >>>>>> >>>>>>> Thanks Ian! >>>>>>> >>>>>>> Some notes. >>>>>>> >>>>>>> - The implementation is up for grabs, but I'd like to keep the >>>>>>> interface of the function; that is, passing a single string with >>>>>>> indentation for hierarchy. >>>>>>> - Performance is not important here, because (1) the function is >>>>>>> only being used in example code, where the call itself should fall into >>>>>>> the >>>>>>> background and (2) creating a hierarchy can safely take a few hundred >>>>>>> milliseconds if it means more readable code. >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Python Programming for Autodesk Maya" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to python_inside_maya+unsubscr...@googlegroups.com. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/python_inside_maya/ >>>>>>> CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw% >>>>>>> 40mail.gmail.com >>>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAFRtmODtC8L1BiXxbTOHRH_KwK32ZxRZeo%3DatdrKgdkeThNzRw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Python Programming for Autodesk Maya" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to python_inside_maya+unsubscr...@googlegroups.com. >>>>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>>> msgid/python_inside_maya/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q >>>>>> 9Z0pGYBBBjYZhYbLDHKMQ%40mail.gmail.com >>>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMT8pNLXc4XM7jT4AVQETE37Q9Z0pGYBBBjYZhYbLDHKMQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>> . >>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>> >>>>> -- >>>>> You received this message because you are subscribed to the Google >>>>> Groups "Python Programming for Autodesk Maya" group. >>>>> To unsubscribe from this group and stop receiving emails from it, send >>>>> an email to python_inside_maya+unsubscr...@googlegroups.com. >>>>> >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>>> msgid/python_inside_maya/CAPGFgA0Sxx%2B2319C1Mv4omtaiEvjppJPrFjVYtg >>>>> mYxSJvs74AQ%40mail.gmail.com >>>>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0Sxx%2B2319C1Mv4omtaiEvjppJPrFjVYtgmYxSJvs74AQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>> >>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Python Programming for Autodesk Maya" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to python_inside_maya+unsubscr...@googlegroups.com. >>>> To view this discussion on the web visit https://groups.google.com/d/ >>>> msgid/python_inside_maya/CACqGSch6_LnZ%3DXajnQ%3DAZX% >>>> 2Br2Fwy99rW8WjM4kdUCmKMUpb7jA%40mail.gmail.com >>>> <https://groups.google.com/d/msgid/python_inside_maya/CACqGSch6_LnZ%3DXajnQ%3DAZX%2Br2Fwy99rW8WjM4kdUCmKMUpb7jA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Python Programming for Autodesk Maya" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to python_inside_maya+unsubscr...@googlegroups.com. >>> >> To view this discussion on the web visit https://groups.google.com/d/ >>> msgid/python_inside_maya/CAPGFgA0oCXTvXzUC%2BBdkfotstBL%2BJ% >>> 3D32tmhXS3rETQxKQ7Q2HQ%40mail.gmail.com >>> <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0oCXTvXzUC%2BBdkfotstBL%2BJ%3D32tmhXS3rETQxKQ7Q2HQ%40mail.gmail.com?utm_medium=email&utm_source=footer> >>> . >> >> >>> For more options, visit https://groups.google.com/d/optout. >>> >> >> >> >> -- >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Python Programming for Autodesk Maya" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to python_inside_maya+unsubscr...@googlegroups.com. >> To view this discussion on the web visit https://groups.google.com/d/ >> msgid/python_inside_maya/CAPaTLMSybL5Gp6zch%3DzxgqxMuxGkRHDBVMDWjG0kRg% >> 2BfTJM7DA%40mail.gmail.com >> <https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMSybL5Gp6zch%3DzxgqxMuxGkRHDBVMDWjG0kRg%2BfTJM7DA%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- > You received this message because you are subscribed to the Google Groups > "Python Programming for Autodesk Maya" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to python_inside_maya+unsubscr...@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/ > msgid/python_inside_maya/CAPGFgA1WcHaU9YQdsan5rJA30tnVx > EjMo6BKKb4sc9Rbm_ACBA%40mail.gmail.com > <https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA1WcHaU9YQdsan5rJA30tnVxEjMo6BKKb4sc9Rbm_ACBA%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > > For more options, visit https://groups.google.com/d/optout. > -- -- You received this message because you are subscribed to the Google Groups "Python Programming for Autodesk Maya" group. To unsubscribe from this group and stop receiving emails from it, send an email to python_inside_maya+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAPaTLMSF%3Defsqh2CFxPztR_Drb4jwASeJHgwAa1hDk2sRjEwdg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
