Django does not deletes old file when new one is uploading. Instead of it adds '_' to the a new file name and keep old file in the storage. How it can be solved?
It appears that your question is not your real question.
First, your title is just a complaint. You might want to fix that.
Second, "How it can be solved?" is a terrible question, since it isn't a "problem" that needs a "solution". It's a feature of the field.
Third, in a comment (not the question) you ask this ("So there is no way to delete the file? "), which is perhaps worse than both other questions.
The answer is "no". It's not true that there's no way to delete the file.
(Hint, avoid negative questions.)
My preference is to leave it at that. The answer is "No". Please ask better questions.
But, I'll provide a hint as to what I'm guessing your real question is.
http://docs.djangoproject.com/en/1.2/ref/models/fields/#django.db.models.FieldFile.delete
I will agree with the comments that this is a feature and not a bug but I will point out that there was a ticket opened (and later closed as wontfix) against Django that might be helpful if you would like to try to "fix" this. See http://code.djangoproject.com/ticket/11663 for a patch and additional comments/guidance.
Related
I am looking for some online tools to help me preventing my digital products from cloning/copying under DMCA legally.
I am a PHP/WordPress developer, selling some premium plugins on my site, I found a man who is selling the items matching with a couple of items I coded originally but I am confused how I will verify my ownership if I proceed legally?
I apologize if I posted this question on wrong place, but any help regarding my question/request will be highly appreciated.
Thanks.
Watermarking is what you need. This introduces small 'features' into the source code which you can later prove that it's yours. For example you can obviously choose distinctive variable names but these can be renamed. You can use distinctive layout i.e. whitespace characters. You can add redundant code that doesn't do anything but looks as though it does. If the copier retains this then it's pretty clear where it came from.
Additionally, you could obfuscate your code so the copier has a hard time understanding and therefore changing it. If your obfuscation is good enough then you could add code to nodelock it i.e. tie it to your domain and so then copying it to another domain will break it.
People have been saying that JForum is easily customizable, and lots of other things in favor of JForum. Through this question, I want to know from those who have used both Jforum and phpbb, that how easy or difficult is customization of the forum in both of these.
For example, say you want to change the theme/template. In my experience I found it much easier to change theme in phpbb ( but still haven't found a way to change the theme in JForum).
Please also suggest some resources where I can find some support for JForum, I couldn't find any support/documentation and so I'm still confused whether to switch to phpbb even if the client prefers Java?
To put this question another way, is there any reason why someone should use JForum when phpBB is available? (I hope it's not the same thing as Java vs Php)
Ok, 1 month and no answer! Looks like this question is not much important, perhaps because there aren't many who have used JForum and phpbb both.
After going through both of them, I eventually decided to go with phpbb given the customization possible, so my vote is towards phpbb. Opinions on this question are still welcome.
A similar question has already been asked, so I'm not going to waste time re-explaining it, an existing discussion can be found here:
ToAscii/ToUnicode in a keyboard hook destroys dead keys
The reason I'm posting a new question however is that I seem to have come across a 'solution', but I'm not quite sure how to implement it.
This blog post seems to propose a solution to the problem of ToUnicode killing dead-key support:
http://www.siao2.com/2005/01/19/355870.aspx
However I'm not sure how to implement the suggested solution. A push in the right direction would be greatly appreciated.
To be clear, the part I'm referring to is this:
There are two ways to work around this:
1) You can keep calling ToUnicode with the same info until it is cleared out and then call it one more time to put the state back where it was if you had never typed anything, or
2) You can load all of the keyboard info ahead of time and then when they type information you can look up in your own info cache what the keystrokes mean, without having to call APIs later.
I'm not quite sure how to do either of those things (keyboards and internationalization are far from my strong point), so any help would be greatly appreciated.
Thanks
The first part of the answer is entirely information-free. However, the second part does make sense. ToUnicode() should have been a pure function, which merely acts as a lookup. However, it isn't. But you can call it repeatedly for all expected inputs, store those in your own lookup table and access that.
I'd recommend that Microsoft adds a lookDontTouch flag to the wFlags parameter; that would be a trivial non-breaking API fix.
If you broaden your search to include key logging, you might get some answers. The method presented in the link is extremely cumbersome compared to ToUnicode, but it works. It evolves around finding the current active keyboard layout from the registry and then manually load and parse the proper DLL.
As a note of warning, I've seen the loading part fail miserably on 64-bit Windows.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I am writing a C++ static library and I have been commenting with doxygen comments in the implementation files. I have never really had to care very much about documentation but I am working on something now that needs to be documented well for the users and also I am trying to replace my previous bad habit of just wanting to code and not document with better software engineering practices.
Anyway, I realized the other day that I need a couple different types of documentation, one type for users of the library(doxygen manual) and then comments for myself or a future maintainer that deal more with implementation details.
One of my solutions is to put the doxygen comments for file, class, and methods at the bottom of the implementation file. There they would be out of the way and I could include normal comments in/around the method definitions to benefit a programmer. I know it's more work but it seems like the best way for me to achieve the two separate types of commenting/documentation. Do you agree or have any solutions/principles that might be helpful. I looked around the site but couldn't really find any threads that dealt with this.
Also, I don't really want to litter the interface file with comments because I feel like it's better to let the interface speak for itself. I would rather the manual be the place a user can look if they need a deeper understanding of the library interface. Am I on the right track here?
Any thoughts or comments are much appreciated.
edit:
Thanks everyone for your comments. I have learned alot from hearing them. I think I have a better uderstanding of how to go about separating my user manual from the code comments that will be useful to a maintainer. I like the idea that #jalf has about having a "prose" style manual that helps explain how to use the library. I really think this is better than just a reference manual. That being said...I also feel like the reference manual might really come in handy. I think I will combine his advice with the thoughts of others and try to create a hybrid.(A prose manual(using the doxygen tags like page, section, subsection) that links to the reference manual.) Another suggestion I liked from #jalf was the idea of the code not having a whole manual interleaved into it. I can avoid this by placing all of my doxygen comments at the bottom of the implementation file. That leaves the headers clean and the implementation clean to place comments useful for someone maintaining the implementation. We will see if this works out in reality. These are just my thoughts on what I have learned so far. I am not positive my approach is going to work well or even be practical. Only time will tell.
I generally believe that comments for users should not be inline in the code, as doxygen comments or anything like that. It should be a separate document, in prose form. As a user of the library, I don't need to, or want to, know what each parameter for a function means. Hopefully, that's obvious. I need to know what the function does. And I need to know why it does it and when to call it. And I need to know what pre- and postconditions apply. What assumptions does the function make when I call it, and what guarantees does it provide when it returns?
Library users don't need comments, they need documentation. Describe how the library is structured and how it works and how to use it, and do so outside the code, in an actual text document.
Of course, the code may still contain comments directed at maintainers, explaining why the implementation looks the way it does, or how it works if it's not obvious. But the documentation that the library user needs should not be in the code.
I think the best approach is to use Doxygen for header files to describe (to the users) how to use each class/method and to use comments within the .cpp files to describe the implementation details.
Well done, Doxygen commenting can be very useful both when reading code and when reading generated HTML. All the difficulty lies in Well done.
My approach is as following:
For users of library, I put Doxygen comments in header files for explaining what is the purpose of that function and how to use it by detailing all arguments, return values and possible side effects. I try to format it such that generated documentation is a reference manual.
For maintainers, I put basic (not Doxygen) comments in implementation files whenever self-commenting code is not enough.
Moreover, I write a special introductory file (apart from the code) in Doxygen format for explaining to new users of libray how to use the various features of the library, in the form of a user's guide which points to details of reference manual. This intro appears as the front page of the Doxygen generated documentation.
Doxygen allows the creation of two versions of the documentation (one for users and one for "internal use") through the \internal command and the INTERNAL_DOCS option. It is also possible to have a finer grained control with conditional sections (see the \if command and the ENABLED_SECTIONS option.)
As others have already noted, it is also useful to provide users (and also maintainers sometimes) something at a higher level than strictly code comments. Doxygen can also be used for that, with the \mainpage, \page, [sub[sub]]section and \par commands
I recommend you to take a look at this paper: http://www.literateprogramming.com/knuthweb.pdf
I normally applied those ideas to my projects (using Doxygen). It also helps in keeping the doc up to date because it is not necessary to leave the IDE, so one can make annotations while coding and, later on, revise the final pdf document to see what needs to be updated or more detailed.
In my experience, Doxygen requires some work so that the pdf look nice, the graphs and pics in place, etc. but once you find your ways and learn the limitations of the tool, it gets the job done quite well.
My suggestion, besides what Kyle Lutz and Eric Malefant have already said, is to put long explanations about related classes in its own file (I use a header file for that) and add references to other parts using Doxygen tags. You only need to include those headers in the Doxygen configuration file (using pattern matching). This avoids cluttering your headers too much.
There is no quick easy answer, good documentation is hard.
I personally feel a layered model is best.
high level docs in prose. Pictures and videos are very appropriate.
reference level docs should Doxygen (well done doxygen, not just off hand comments).
maintainer docs should not show up in the reference docs, but they could still be doxygen as pointed out by by Éric.
I really like the documentation style used in RakNet. The author uses extensive Doxygen comments and provides a generated reference manual. He also provides some plain html tutorials. Best of all he supplies video walk-throughs of some of the more complicated features.
Another good example is SFML. The quality isn't as good as RakNet but it's still very good. He provides a good overview page in the doxygen generated documentation. There are a few plain html tutorials and a plain html Features/Overview page.
I prefer these styles as Doxygen generated documentation is generally too low level when I'm just starting out, but perfectly concise once I'm in the groove.
I would like to know your opinion on whether it is a good idea to have developers put their name or signature on top of every test they write and why (not)?
I would say no. If you really need to know who wrote the test, you should be able to look back in your version control to see who's to blame. When people start putting their name on things, you lose the sense of collective ownership/blame, and people start to get more concerned with "their" code rather than the system as a whole.
I upvoted Andy's but I'd also add that putting the name in the code also is then something else that must be maintained. eg. Joe creates the test, but Jane changes it, is it Joe's test or Jane's test? And if Jane doesn't change the comment, you'll now go and talk to Joe about the code that Jane wrote... All too confusing. Use Blame and be done with it.
What would you do with the information?
There's no use case for having the author's name.
Generally, the information has one of two meanings.
The person's gone (gone from the company, gone from the project, or a contractor and someone who'll never be found again.)
The person's still around.
In the second case, you already knew that. Having their name in a source code file doesn't clarify the fact that they worked on this code, are still with the company and still on the project.
So, author's name has no use cases.
I favour self-explanatory test cases rather than signed tests.
Even if you know who wrote the test, and he's still working here, and he's available, you cannot be certain he remembers the reasons why he wrote this test.
Make sure the names of the test case are explicit enough. Add comments if necessary, reference bug ID, User Story, Customer ...
I think it depends on the attitude that already exists. If there are many conflicts, then removing all the names is useful, because the code stands for itself. However, if the names are put on the tests (as with code) then the developer is taking ownership.
Taking ownership is always a good thing because it encourages the developer to make it as perfect as possible. It also helps when you need to ask a question about the test, or if the test is failing, and you can't figure out why, you'll be able to ask the expert on the subject.
However, if there is a darker atmosphere, more about developers who are defensive, and are trying to undermine each other, then the names will cause them to focus on 'who made this code wrong' or 'this test failed because X coded it badly' rather than focusing on the error that the test might be detecting.
So there's always a balance when explicitly attaching names to tests like that.
And as Andy mentioned, there's always source control if you REALLY need to know who wrote something.
I think it really depends on what the rest of your culture is around code ownership. If your teams culture is that all code is owned by someone, and only that person can touch that code, then labeling whose code is whose might make sense.
However, I prefer to work on teams where there's collective ownership of code. Sometimes it's nice to have an original author on a file, just to see whose original design it was, but beyond that, I don't think tagging specific tests is useful.
As other people mentioned, if you really need to figure out who made a particular change, you can figure that out from version control. In general though, I think tests should be owned and maintained by the whole team.