I need to simulate a fully functional AS/RS in warehousing. Moreover, I am a complete beginner in this field. Can some please let me know if I could get readymade simulation file? Or if not, please let me know how to learn to do it.
I have checked out the Anylogic website and it's tutorials (They are too lengthy).
fortunately for you, i have developed an AS/RS example that is a ready-made downloadable model for you, available at https://cloud.anylogic.com/model/1f5c7d1f-8782-40ac-957d-d3ba97bf6bf0?mode=SETTINGS
In general, when you want a model example, the first thing you should do is check the anylogic cloud, and if you are lucky the model is downloadable. Unfortunately, most people don't share
It really depends on what type of ASRS you are modeling (shuttle versus unit load) and level of detail you need. Do you need specific slotting and inventory tracking, or simplier black box delays with the assumption inventory is always available? The level of detail you need depends on questions you are asking, and should be addressed prior to starting development. If results from the model are critical and urgent, and you need anything more than simple black box delays, you should consider outsourcing to an experienced professional until you can get your AnyLogic skills up to speed.
For a project we have to write a Matlab simulation and would like to split the work over several persons. As there are some non-professional programmers involved and we are dealing with a short project we want to keep it simple and use Dropbox, so no version management system involved.
What are possibilities to do this? How do we best split the functions? How do you split the program into several files?
Use version control so that you can keep track of who broke what, and commit at regular intervals so that there is a point to version control.
Design the program such that different people can work on it at the same time. Split it into several files which you can independently test for correctness. Have a professional programmer be responsible for the backbone (main function, class definition). Require consistent interfaces and documentation, so it's easy to stick it all together.
Talk to one another frequently. It doesn't have to be large formal meetings in many cases, just turning around and saying "hey, can you look at this?" is often enough. You all need to know who works on what, and where they stand, so that you know who to talk to in case there are questions. It's just so much faster to solve an issue by talking to the person involved rather than by trying to understand their code.
I would use version control - it saves lots of problems in the long run.
Git is good in that there is no central repository - and so everyone owns their own version.
This, in my experience is liked by 'non-programmers' as they like to fiddle (and break) their version.
And git clone http://whatever, as a method of obtaining a distribution is probably as easy as it gets.
And you will need to know when changes were made. For example: you find a bug and are not sure if you need to rerun the previous simulations or not (when was the bug introduced? - does it affect such and such a simulation?). Without version control finding bugs is a major stress because you cannot be sure of the answers to these questions.
There's so many cool ideas out there (ninject, automapper, specflow, etc) that look like they would help but I don't want to add something, tell others about it, and try using it just for it to be added to the growing heap of ideas that didn't quite work out. How can I determine if the promised benefits will happen and that it won't end up as something to be ignored or worked around?
Have a problem
Identify the cost of having the problem, or the value to solving it
Prioritize it against other problems
When it's the top priority, look for a solution that solves the problem with a proportional cost
Do you have the problem that ninject solves? Is it an important problem to solve? Is it the most important? What value will you get from solving it?
I don't think that you can tell whether any framework will deliver your expectations until you try it, and try it in anger and in context. This is usually time consuming and inevitably you'll have a few misses before you get any hits. Don't commit yourself by working through a simple sample from the authors website or howto files; these will always work and may impress but until you try to use the framework in the context of your billion user, multi-lingual, real-time on- and off- line application you're not going to find it's shortcomings.
I recently became part of a complex embedded project team for which I will be developing a part. For the part which is my responsibility there is only old code and not much documentation.
I am keen to make a good start but shyness and fear of appearing stupid makes it difficult to ask questions. How to ask questions ?
I wanted to ask what techniques do you guys use to understand a project ? I mean there are of lots of technical details which one must remember and keep in context in order to make a design. Your read the code and get some facts but how to move ahead ?
For instance you read the code and the document(s) and get some facts A and fact B . How to reach suitable conclusion X for which you may or may not have needed to take into account facts C and D also ?
Code-reading can be particularly difficult if there is not enough documentation and the code is poorly documented and badly written. I guess the best way now is to find the entry point of the code, and slowly understand its flows and what data it uses. I would keep a look out for
Structure - are there any partitioning of entities/system? Where in the code (and how) do they communicate with each other?
Data - what sort of structures are used to hold the global data? How are the data accessed and saved?
If you are doing C or C++, it is also important to find out how memory is handled and for C++ (and other related non-managed memory OOP languages, I guess), how are object ownership contained.
Since it is an embedded project, are there any non-standard code or coding constructs used?
Reading the code is balanced by writing the documentation.
Write the documentation that your replacement will need. Imagine someone who knows less than you. Explain it for that person.
When you cannot explain something to your replacement, ask questions.
When you have a complete description, you will "know" the system.
And you will have produced complete documentation.
You don't mention what kind of tests exist. If there are test cases, modify them and trace how this would affect the end result.
You might want to look at diagrams which give the entire picture of the logical structure of the system, like, for example, looking at class diagrams in an OOP system would be of great help. Looking at the design diagrams of large and complex apps gives you a clear understanding of how the internal modules of the system are organized and this way its makes the task of figuring out what functionality does a particular piece of code does much much easier. In the absence of diagrams, you're best bet would be to start from the entry point of the app, like main() and proceed from there while you draw(literally draw or write down on paper) your own conclusions about the system(this way you can have your own documentation) and ask your peers if they're correct.
My experience is that it's best to start with some kind of task -- a bug fix or other small change. That will provide focus to your learning. I find it hard to read through a binder or sift through pages of source code or documentation without having a way to apply it.
If you have a sandbox where you can play with changes that you've made without messing up the code base, that can be even more helpful.
Does anyone know of a good code obsfucator for Perl? I'm being ask to look into the option of obsfucating code before releasing it to a client. I know obsfucated code can still be reverse engineered, but that's not our main concern.
Some clients are making small changes to the source code that we give them and it's giving us nightmares when something goes wrong and we have to fix it, or when we release a patch that doesn't work with what they've changed. So the intention is just to make it so that it's difficult for them to make their own changes to the code(they're not supposed to be doing that anyway).
I've been down this road before and it's an absolute nightmare when you have to work on "obfuscated" code because it drives up costs tremendously trying to debug a problem on the client's server when you, the developer, can't read the code. You wind up with "deobfuscators", copying the "real code" to the client's server or any of a number of other issues which just become a real hassle to maintain.
I understand where you're coming from, but it sounds like management has a problem and they're looking to you to implement a chosen solution rather than figuring out what the correct solution is.
In this case, it sounds like it's really a licensing or contractual issue. Let 'em have the code open source, but make it a part of the license that any changes they submit have to come back to you and be approved. When you push out patches, check the md5 sums of all code and if it doesn't match what's expected, they're in license violation and will be charged accordingly (and it should be a far, far higher rate). (I remember one company which let us have the code open source, but made it clear that if we changed anything, we've "bought" the code for $25,000 and they were no longer responsible for any bug fixes or upgrades unless we bought a new license).
Don't. Just don't.
Write it into the contract (or revise the contract if you have to), that you are not responsible for changes they make to the software. If they're f-ing up your code and then expecting you to fix it, you have client problems that aren't going to be solved by obfuscating the code. And if you obfuscate it and they encounter an actual problem, good luck in getting them to accurately report line number, etc., in the bug report.
Please don't do that. If you don't want people to alter your Perl code then put it under an appropriate licence and enforce that licence. If people change your code when you licence says that they shouldn't do that, then it's not your problem when your updates not longer work with their installation.
See perlfaq3's answer to "How Can I hide the source for my Perl programs? for more details.
It would seem your main issue is clients modifying code which then makes it difficult for you to support it. I would suggest you ask for checksums (md5,sha, etc) of their files when they come to you for support, and similarly check files' checksums when patching. For example, you can ask the client to provide the output of a provided program which goes through their install and checksums all the files.
Ultimately they have the code, so they can do whatever they want to it. The best you can do is enforce your licenses and to make sure you only support unmodified code.
In this case obfuscating is the wrong approach.
When you release the code to the client you should keep a copy of the code you send them (either on disk or preferably in your version control as a tag/branch).
Then if your client makes changes you can compare the code they have to the code you sent them and easily spot the changes. After all if they feel the need to make changes there is a problem somewhere and you should fix it in the master codebase.
Another alternative for converting your program into a binary is the free PAR-Packer tool on CPAN. There are even filters for code obfuscation, though as others have said, that's possibly more trouble than it's worth.
I agree with the previous suggestions.
However if you really want to, you can look into PAR and/or Filter::Crypto CPAN modules. You can also use them together.
I used the latter (Filter::Crypto) as a really lightweight form of "protection" when we were shipping our product on optical media. It doesn't "protect" you, but it will stop 90% of the people that want to modify your source files.
This isn't a serious suggestion, however take a look at Acme::Buffy.
It will at least brighten your day!
An alternative to obfuscation is converting your script to a binary using something like ActiveState's Perl Dev Kit.
I am running a Windows O/S and use perl2exe from IndigoSTAR. The resulting .EXE file will be unlikely to be changed on-site.
As others have said, "how do I obfuscate it" is the wrong question. "How do I stop the customer from changing the code" is the right one.
The checksum and contract ideas are good for preventing the "problems" you describe, but if the cost to you is the difficulty of rolling-out upgrades and bug-fixes, how are your clients making changes that don't pass the comprehensive test suite? If they are capable of making these changes (or at least, making a change which expresses what they want the code to do), why not simply make it easy/automated for them to open a support ticket and upload the patch? The customer is always right about what the customer wants (they might not have a clue how to do it "the right way", but that's why they are paying you.)
A better reason to want an obfuscator would be for mass-market desktop deployment where you don't have every customer on a standing contract. In that case, something like PAR -- anything which packs the encryption/obfuscation logic into a compiled binary is the way to go.
As several folks have already said: don't.
It's pretty much implicit, given the nature of the Perl interpreter, that anything you do to obfuscate the Perl must be undoable before Perl gets its hands on it, which means you need to leave the de-obfuscation script/binary lying around where the interpreter (and thus your customer) can find it :)
Fix the real problem: checksums and/or a suitably worded license. And support staff trained to say 'you changed it? we're invoking clause 34b of our license, and that'll be $X,000 before we touch it'....
Also, read why-should-i-use-obfuscation for a more general answer.
I would just invite them into my SVN tree on their own branch so they can provide changes and I can see them and integrate their changes into my development tree.
Don't fight it, embrace it.
As Ovid says, it's a contractual, social problem. If they change the code, they invalidate the warranty. Charge them a lot to fix that, but at the same time, give them a channel where they can suggest changes. Also, look at what they want to change and make that part of the configuration if you can. They have something they want to do, and until you satisfy that, they are going to keep trying to get around you.
In Mastering Perl, I talk a bit about defeating obfucators. Even if you do things like making nonsense variables names and the like, modules such as B::Deparse and B::Deobfuscate, along with Perl tools such as Perl::Tidy, make it pretty easy for the knowledgable and motivated person to get your source. You don't have to worry about the unknowledgable and unmotivated so much because they don't know what to do with the code anyway.
When I talk to managers about this, we go through the normal cost benefit analysis. There is all sorts of stuff you could do, but not much of it costs less than the benefit you get.
Good luck,
Another not serious suggestion is to use Acme::Bleach, it will make your code very clean ;-)