Oops, just noticed there was a new thread dedicated to stalker
On Sat, May 10, 2014 at 1:01 PM, Nils Lerin <[email protected]> wrote: > That's incredible Erkan! I've been planning on developing something very > similar to stalker for some time now but seeing how stalker seems to do > exactly what I wanted I might continue from there. You don't happen to have > a video or screenshot demonstrating the Anima interfaces? > > /Nils > On May 9, 2014 11:39 PM, "Erkan Özgür Yılmaz" <[email protected]> wrote: > >> Hey Justin, >> >> I should start promoting Stalker more, it was my little baby for the last >> 4-5 years or in a much meaner perspective it was all my brain farts >> structured and ordered in a way that may be helpful to others, and I think >> it is time for letting it to fly and start its own journey. >> >> E.Ozgur Yilmaz >> eoyilmaz.blogspot.com >> >> >> On Sat, May 10, 2014 at 12:21 AM, Justin Israel >> <[email protected]>wrote: >> >>> I'm surprised Stalker didn't come up in the other thread about path >>> structures and parsing (regex/schema/pyparsing/...). Seems pretty relevant! >>> I also just recognized your name as having been associated with Stalker, >>> when I came across it a few years back. >>> >>> >>> On Sat, May 10, 2014 at 7:46 AM, Marcus Ottosson <[email protected] >>> > wrote: >>> >>>> Ah! I knew I recognised your name. Good work with Stalker, got it >>>> recommended to me by a friend of mine a while back. I may just have another >>>> look. :) >>>> >>>> >>>> On 9 May 2014 19:31, Erkan Özgür Yılmaz <[email protected]> wrote: >>>> >>>>> You might be interested in: >>>>> >>>>> https://pythonhosted.org/stalker/tutorial.html >>>>> >>>>> At least it will help you to start from some where. And I should start >>>>> ptomoting it as it is pretty mature right now. >>>>> On May 9, 2014 8:15 PM, "Marcus Ottosson" <[email protected]> >>>>> wrote: >>>>> >>>>>> Software design is a big topic, is it ok if I refer you to some books >>>>>> instead of answering them here? >>>>>> >>>>>> Based on your questions, here is what I'd suggest, in this order: >>>>>> >>>>>> 1. Code >>>>>> Complete<http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?s=books&ie=UTF8&qid=1399654675&sr=1-1&keywords=code+complete> >>>>>> 2. Domain-driven >>>>>> design<http://www.amazon.com/Domain-Driven-Design-Tackling-Complexity-Software/dp/0321125215/ref=sr_1_1?s=books&ie=UTF8&qid=1399654632&sr=1-1&keywords=domain-driven+design+tackling+complexity+in+the+heart+of+software> >>>>>> 3. API Design >>>>>> C++<http://www.amazon.co.uk/API-Design-C-Martin-Reddy/dp/0123850037> >>>>>> 4. Game Engine >>>>>> Architecture<http://www.amazon.co.uk/Game-Engine-Architecture-Jason-Gregory/dp/1568814135/ref=sr_1_1?s=books&ie=UTF8&qid=1389698296&sr=1-1&keywords=game+engine+architecture> >>>>>> 5. Physically Based >>>>>> Rendering<http://www.amazon.co.uk/Physically-Based-Rendering-Theory-Implementation/dp/0123750792> >>>>>> >>>>>> >>>>>> *Code Complete* >>>>>> Give this book a quick glance (its rather large), it should prepare >>>>>> you for what lies ahead. >>>>>> >>>>>> *Domain-driven design* >>>>>> Consider adopting this thinking to your object models. >>>>>> >>>>>> *API Design for C++* >>>>>> Not specifically for Python, but provides some very good >>>>>> methodologies on dividing interface from implementation. >>>>>> >>>>>> *Game Engine Architecture* >>>>>> To wet your appetite, this one might open your eyes as to how *big* a >>>>>> piece of software can get. >>>>>> >>>>>> *Physically Based Rendering* >>>>>> Whereas this one might open your eyes as to how a *complex* piece of >>>>>> software can look. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 9 May 2014 11:36, Justin Israel <[email protected]> wrote: >>>>>> >>>>>>> Hey David.... >>>>>>> >>>>>>> >>>>>>> On Fri, May 9, 2014 at 8:24 PM, David Martinez < >>>>>>> [email protected]> wrote: >>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm working on a new script and I'm looking for some advice in >>>>>>>> relation to *Software Design*. >>>>>>>> >>>>>>>> The tool that I'm working on allows to import files into the >>>>>>>> current scene and make changes to the hierarchy. The tool is going to >>>>>>>> be >>>>>>>> used by a few different departments and the way files are imported >>>>>>>> depends >>>>>>>> both on the department using the tool and the options selected from the >>>>>>>> interface. Here is a list of the things that I want to accomplish: >>>>>>>> >>>>>>>> *Here are some things to keep in mind* >>>>>>>> >>>>>>>> *Creating classes for Project* >>>>>>>> >>>>>>>> Different projects might have different folder structures and the >>>>>>>> data is not necessarily in the same place for each different project. >>>>>>>> Because of that, I thought that the best thing to do would be to >>>>>>>> create a >>>>>>>> base class in which I define the basic functionality and then. for >>>>>>>> those >>>>>>>> projects that have a different structure, I can subclass from the base >>>>>>>> class and overwrite the methods that need to be tweaked. By doing so, I >>>>>>>> won't be duplicating code but just only changing the one that I need to >>>>>>>> change. >>>>>>>> >>>>>>>> Question 1: >>>>>>>> Does that sound like the best way to go? >>>>>>>> >>>>>>> >>>>>>> It may not be the best approach to try and describe each new project >>>>>>> in terms of a subclass. Unless I misunderstood you and your subclasses >>>>>>> are >>>>>>> just "variations" of a "type" of project. What might be more flexbile >>>>>>> is to >>>>>>> create a concrete project class that has a common interface, but can >>>>>>> derive >>>>>>> its locations and properties from a template. Something that allows you >>>>>>> to >>>>>>> whip up a new version of a textual template when there is a new project, >>>>>>> and nothing in your codebase has to be changed. This template might >>>>>>> indicate where logs go, or where image outputs go, or maya scenes, etc. >>>>>>> But it sounds like the right idea in terms of your base class, to >>>>>>> have a consistent interface being provided. That base class might end up >>>>>>> just being the concrete class. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> *Isolate Functionality * >>>>>>>> I understand that the best thing to do is isolate functionality and >>>>>>>> avoid having functions/methods that try and tackle with a bunch of >>>>>>>> unrelated stuff. Having said that, I'm not sure when to stop breaking >>>>>>>> things down and I often end up with functions/methods that have simple >>>>>>>> calls to built-in or third party libraries. When that happens, it is >>>>>>>> crear >>>>>>>> to me that I've gone too far. >>>>>>>> >>>>>>>> Question 2: >>>>>>>> How do you decide what needs to be broken down and what doesn't? >>>>>>>> >>>>>>> >>>>>>> I read a book on refactoring once (I don't remember the name, sorry. >>>>>>> I am also a film major, so I have only ready *one* book on refactoring). >>>>>>> It mentioned something about refactoring after you begin to repeat >>>>>>> yourself 3 or more times. There is generally a basic concept you want to >>>>>>> follow of separating concerns, and having a class serve one and only one >>>>>>> purpose. But that doesn't mean you always have to worry so much about >>>>>>> how >>>>>>> much to separate upfront. That is the point of refactoring. When a >>>>>>> single >>>>>>> class or function starts looking like it is doing more than its targeted >>>>>>> purpose... you can split it up. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> *Allow different UIs* >>>>>>>> >>>>>>>> I want to be able to control the same functionality using different >>>>>>>> UIs (only one would be running at the same time). Because of that, it >>>>>>>> is >>>>>>>> clear to me that none of the core functionality should be part of the >>>>>>>> interface but isolated (see previous point) >>>>>>>> >>>>>>>> This would allow me to have different versions of the UI and or >>>>>>>> different ways to display the data. This could also be used to load >>>>>>>> one or >>>>>>>> the other based on the existence of some libraries on the system. >>>>>>>> Ideally, >>>>>>>> I would like to be able to switch between different UIs at runtime. >>>>>>>> >>>>>>>> Again, it looks to me like OOP might be helpful here. The way I see >>>>>>>> it, I could create a base class that communicates with the main script >>>>>>>> and >>>>>>>> then a series of subclasses that, not only display a different >>>>>>>> interface >>>>>>>> but overwrite the functionality of those methods when necessary. >>>>>>>> >>>>>>>> Question 3: >>>>>>>> Do you think the use of classes is justified here? Would do rather >>>>>>>> use another approach? >>>>>>>> >>>>>>> >>>>>>> OOP does not always == best. It is just a design concept. OOP aside, >>>>>>> you definitely have the right idea that it is beneficial to separate >>>>>>> your >>>>>>> business logic from your display logic. One library should solely focus >>>>>>> on >>>>>>> providing that layer of representing your core concepts like loading, >>>>>>> parsing, opening, saving,... Then you can have any number of views that >>>>>>> wrap around this logic. This means you can also have command line tools >>>>>>> that build on the same core library. When you want to then change the >>>>>>> way >>>>>>> something is loaded, you only have one place to change it. Your display >>>>>>> code shouldn't care at all how the business logic works. It should only >>>>>>> worry about how to communicate between the business logic and the user >>>>>>> inputs, and how to display the available controls and data. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> *Linking different elements together* >>>>>>>> >>>>>>>> I have to admit that I'm having trouble on seeing how to link the >>>>>>>> different elements together. At the moment I have different classes >>>>>>>> for the >>>>>>>> UI, the project and also for the importer itself (given the fact that >>>>>>>> depending on the department, the import process should be different). >>>>>>>> >>>>>>>> At the moment, I have the UI create an instance of the importer >>>>>>>> class, since it the department is defined in the interface and the >>>>>>>> importer >>>>>>>> will relate on some of the instance attributes of the UI. Having said >>>>>>>> that, >>>>>>>> I have the feeling that the instance of the importer should be created >>>>>>>> somewhere else and only change when the department is changed instead >>>>>>>> of >>>>>>>> the UI itself. If that's the case, I'm not sure how I would communicate >>>>>>>> with the instance variables of the UI. >>>>>>>> >>>>>>>> Question 4: >>>>>>>> What do you think it would be the best way to structure the code in >>>>>>>> this case? If I create an instance of the importer outside of the UI, >>>>>>>> should I pass the instance of the UI as an attribute in order to >>>>>>>> access its class attributes? I want to make sure I'm structuring the >>>>>>>> code >>>>>>>> in a way that makes sense. >>>>>>>> >>>>>>> >>>>>>> I would think the importer should have no knowledge of UI concepts. >>>>>>> It might help (and this might sound related to the previous question) if >>>>>>> you think of them in completely different pieces. How can the importer >>>>>>> stand alone? How can it function without your UI, given only parameters. >>>>>>> Also, it may be beneficial to avoid defining department stuff in code >>>>>>> unless it is a modular type system and not something part of the core. >>>>>>> That >>>>>>> way you don't have to update core logic when department details change >>>>>>> or >>>>>>> you need to create the concept of a new department. This may go back to >>>>>>> templates or configuration files that are loaded into an interface. >>>>>>> Forgive >>>>>>> me though if my answer sounds vague. It is possible you could need to >>>>>>> create a few interfaces which you are referring to as departments. >>>>>>> >>>>>>> I'm not sure how to fully answer this one, but ultimately I know it >>>>>>> involves thinking about them as completely separate pieces. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Thanks a lot in advance, >>>>>>>> >>>>>>>> Cheers, >>>>>>>> >>>>>>>> >>>>>>> Hope this helps a little bit. >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> 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 [email protected]. >>>>>>>> To view this discussion on the web visit >>>>>>>> https://groups.google.com/d/msgid/python_inside_maya/CAMLeNpz%2BWStu%2B8yp6s2LWaY1JtJJ4_fjrU1agGruUFY18xv_Zw%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAMLeNpz%2BWStu%2B8yp6s2LWaY1JtJJ4_fjrU1agGruUFY18xv_Zw%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 [email protected]. >>>>>>> To view this discussion on the web visit >>>>>>> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA34h7C7h7ccOTgt0bB04Mad7wTEAPyzGBxp_gNqF0X%2Baw%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA34h7C7h7ccOTgt0bB04Mad7wTEAPyzGBxp_gNqF0X%2Baw%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>>>> . >>>>>>> >>>>>>> For more options, visit https://groups.google.com/d/optout. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Marcus Ottosson* >>>>>> [email protected] >>>>>> >>>>>> -- >>>>>> 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 [email protected]. >>>>>> To view this discussion on the web visit >>>>>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBxKr5Wfiqg8iMWNHESEgg7KVu7e2BWnqz%3DjQbTz%2BcCrQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOBxKr5Wfiqg8iMWNHESEgg7KVu7e2BWnqz%3DjQbTz%2BcCrQ%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 [email protected]. >>>>> To view this discussion on the web visit >>>>> https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx7kLeZr%2B0M%3Dgv%2BoQ6%2BbSb%2BEmfynOQxJPcEvH2Zahe29MA%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx7kLeZr%2B0M%3Dgv%2BoQ6%2BbSb%2BEmfynOQxJPcEvH2Zahe29MA%40mail.gmail.com?utm_medium=email&utm_source=footer> >>>>> . >>>>> >>>>> For more options, visit https://groups.google.com/d/optout. >>>>> >>>> >>>> >>>> >>>> -- >>>> *Marcus Ottosson* >>>> [email protected] >>>> >>>> -- >>>> 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 [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD8AqQjExcJrwdnnysnPh5w6_AXLTyybWztF0Hx%2BRRPQg%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAFRtmOD8AqQjExcJrwdnnysnPh5w6_AXLTyybWztF0Hx%2BRRPQg%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 [email protected]. >>> To view this discussion on the web visit >>> https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0BqEUdhT81%2BRSguRQ6WEnkFmYZdb%2BW%3Dr6%3D8s7sF5vbxQ%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAPGFgA0BqEUdhT81%2BRSguRQ6WEnkFmYZdb%2BW%3Dr6%3D8s7sF5vbxQ%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 [email protected]. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx7twouZ%2BU33NXXnKvoosjrUPrHHfE8X%2BNXDVWSOfo8Nrg%40mail.gmail.com<https://groups.google.com/d/msgid/python_inside_maya/CAGNmyx7twouZ%2BU33NXXnKvoosjrUPrHHfE8X%2BNXDVWSOfo8Nrg%40mail.gmail.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > st -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/python_inside_maya/CAGkBUFfj1sKc%3DEKVYUJeGVwc0m3ex9ATrJRor5mhtg3v3KEezw%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
