This is a query from a beginner wondering about best practice suggestions - I have a system for myself but am wondering what other more experienced people do.
My desired end result is a way to access a number of specified files which are in multiple different places within a working directory.
My specific example is with Django, where my HTML, CSS & JS files are spread in different directories (such as Template & Static). What I'm imagining is a way to quickly access/open all three files, even if they're in different locations - possibly creating a "ProjectFoo" folder, then within that folder are links/shortcuts/aliases to the required files.
I'm currently using the Favorites (https://marketplace.visualstudio.com/items?itemName=kdcro101.favorites) which covers the majority of my uses, and there are also these alternatives:
VSCode-Favorites: https://marketplace.visualstudio.com/items?itemName=howardzuo.vscode-favorites
Project Manager: https://marketplace.visualstudio.com/items?itemName=alefragnani.project-manager
...but am wondering aobut recommendations regarding best practice - what is the usual way people go about this, as it seems (to me at least) that it might be a common workflow issue.
Thanks!
Rich
Related
I am working on a Firefox extension it is a context menu for automating bbCode, HTML, MarkDown, etc.
It is functional now, but I have a file which is the size of the rest of the code combined, an Excel spreadsheet. (Yes, I know, lame)
I use it as a database for organizing the menu IDs, arguments, internationalization, etc.
It's useful, for me at least, and I want to make it available, but it is not properly a part of the application, it should be a part of the background documentation.
Is there a way in Github/Git to separate documentary files from those that a part of execution of the code?
I've looked through Github, and I haven't found a spot (with revision control) to put this.
I'm going to deploy a QML based application. Now I'm wondering it's better to use resources system for .qml files and their associated files or using relative addressing or there is a better way?
The first way maybe make the project difficult to manage if the number of qml files and your images become larger and larger. Also I think it would be harder to deploy third party plugins like Qt desktop components.
And the second way is not secure as it should be. Every one can open a text editor and edit your .qml files.
Is there a better way?
Using Resource system :
Binds all the dependencies into one single binary, thus no problem of placing them at exact locations as per the paths given in your code.
Many times you would not want to share your qml code/images etc. [close source projects], helpful in those cases. Also it is more secured as no one can modify your files and cripple your application possibly.
You will not be able to modify these dependent files at run time, which might be required in some cases.
The first way maybe make the project difficult to manage if the number of qml files and your images become larger and larger.
Contrary to what you say, I think its easier to manage them, how so many files there might be. You can see here how easy it is to do using Qt Creator.
Relative addressing:
All the dependencies are scattered at different locations, thus problem of placing them at exact locations as per the paths given in your code.
Since your files are directly available to anyone who would want to access them, unsecure.
If there is a modification required in one the files at run time, you can do it. Eg. having a log file and writing/reading some data into/from it.
Difficult to manage(compared to first approach) when number of files increase as exact paths have to be given.
One personal advantage I have found of second approach is in situations like this :
I need to send my Qt apps for Demos to clients with managers, offshore. These demos go on full day. If some minor UI feature ( eg size of a button seems very small ) is getting too much negative attention, we can direct the manager over call to the respective qml file, and make him do small changes ( eg. scale : 1.5 ) This is helpful as we wont have time to build the whole system, resend the exes to them etc.
Is there a better way? Not that I have seen any. I thinks its a matter of finding which one of the above suits your requirements more.
I've been asked to write scope the effort for rebranding a significant iPhone/iPad application for multiple customers, locale, languages, etc. Each incarnation of the rebrand might include different look and feel, possibly different behavior, or subsets of functionality.
My initial impression is it should be possible to use a single xCode project, and just include multiple .plist files targeted to specific project configurations. I'm unsure exactly how to accomplish this in xCode, thus I'm not sure how to accurately estimate the effort required.
I'm looking for pointers and developer references to find the most reasonable method to rebrand an existing app multiple times without forking new xCode project each time.
The feature I've been looking for is called "Targets" in xCode.
I'm going to use these as described here to deploy my single project into multiple binaries.
I'm not sure that's possible but with MVC, Cocoa makes it easy to localize apps.
I've used a client-server approach, where everything specific to one customer is downloaded or configured from a remote server. You still need customers with overlapping requirements, but you can switch on/off modules based on the needs of a particular customer.
Low-tech approach: grab the data, configuration files, and images from a different location in the file system. Or the same location, but drop the new customer data into the directory and archive the old. A plist, a text file, a series of #defines, etc, can switch a behavior on or off. Write your code so that it doesn't know how many images, which modules, what color the buttons are, etc, until it checks the configuration and gets the data and images it needs from your directory.
I do alot of bugfixing and implementing new features for several different customers. These customers all report their bugs, change requests and new feature request into our Trac system.
Sometimes these requests result in me creating some SQL change scripts, sometimes there are Excel documents or Access databases with testdata, Word documents from the customer and so on. Alot of files that are used to fix one ticket and then can be deletede when the ticket is closed.
I usualy do this by creating folders in the filesystem like this: /customerXX/TicketNNNNN and then just dumping everything in there.
How do you organize your workfiles? Have you found some fantastic tool to do this?
I would say for scripts or files that are related to a particular ticket, the best thing to do would be to attach the file to that ticket in your issue tracking software - almost all issue trackers that I've worked with will allow you to do this. That way, you can look back and a) see exactly what you did in case something goes wrong, or b) do exactly the same thing if the issue comes up again later. That's almost certainly the best place to keep files with extra info from the customer, too (or at least the first place most people will look).
For frequently re-used scripts that aren't specific to a particular ticket, I would create a scripts/ or bin/ directory in the associated project, and keep them in there.
I also have a small handful of useful files that I keep in src/misc/ off my home directory, with things like SQL queries to get readable "explain" output out of Oracle and such, that aren't specific to any particular project. The number of these is small enough that subdirectories aren't necessary, though - I suspect if you ended up with a large number of these files, many of them could/should be moved to specific projects or your issue tracking system.
JIRA has been quite helpful for this at my site. It supports issue tracking, file attachments,and you can easily customize and categorize your projects and issues.
I use Fogbugz and I add all file to the case. I believe that no matter what application you use, The important is to keep this files for future references. If your bug-tracking tool does not let you attach file then add the files to the version control.
We use CaWeb4 and find it very easy to use for our bug tracking.
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 2 years ago.
Improve this question
I am working in a team of five. We are working on a C# application with five csprojects.
The problem is that for each csproject, each of my colleagues has their own ideas on how to reference a DLL; some would like to link in by Project reference, other would like to link in the DLL only. So each and every one of us will have our own csproject.
I want all of them to check in their csproject; but given that every copy of csproject is different, there isn't really a feasible mechanism to do that, is there? But if I don't ask them to check in their csproject, then every time they add a new file, I would have to manually edit my csproject and that's very tedious, not to mention that it beats the purpose of continuous integration.
Is there any strategy to handle this? I know it would be best to enforce a standard, but is there any other option leaving this aside?
There is a reason why the csproject content is different for everyone; not everyone has all of the five csprojects, and not everyone can have all of the 5 csprojects. So invariably some will have to end up having to reference DLLs instead of projects, and some want to reference by projects for the ease of debugging. If I were to enforce a standard, as the answers here suggest, I would have to solve this issue.
As to why we need to split into multiple csprojects, that's because we want to reuse some parts of the code for other applications, and because not everyone can have all access to the source code. It's more political than technological.
Your problem is not how to handle it with Source Control.
Your problem is that you (or management) needs to get your team to adopt a set of standards the entire team follows.
If you let everyone follow their own mish-mash of ideas and do not get team cohesion on the basics it will only end in tears...
You're almost certainly solving the wrong problem. If you fork the .csproj files to cater to invididual preferences, you are incurring additional work and introducing the likelihood of errors, for exactly the reason you describe -- every time Alice adds a file to AlicesX.csproj, Bob has to learn about this and add the same file to BobsX.csproj.
You really need to consider this as a problem of standards and team dynamics: agree on how DLLs will be referenced in the master sources, and require everyone to stick to that. If the "losing" side don't like to work that way, sure, they can use their preferred style in their private working copies. But you really only want one master source, and you want to work towards getting everybody to buy into the way the master source does it.
Per your edit: If you really, really cannot come to an agreement with your colleagues, then I would still suggest a single master, but write a little utility that the dissenters can use that converts project references to DLL references (or vice versa). .csproj files are just XML so this is pretty trivial to do. If you cannot even agree on what is going to be the repository format, then you will need to maintain parallel .csproj files, but I'd still write the utility to ensure that changes made to DllReferencingProj.csproj get copied to ProjectReferencingProj.csproj. But I still say you're just making more work and storing up more pain for yourself than if you had the squabble and got it over with: in order to function as a team, you're going to need to find some way of resolving disputes, and this is as good as test case as any.
Time to make everyone grow up and follow a standard. If you're all working on the same code you should decide together whether referencing the dll or the project is best and then stick to it. Once you guys figure this one out you can decide whether to indent 2 or 4 spaces or a tab. Then decide whether to put your curly braces on the same line as or the next line after your function declarations. I'm not even going to speak to the vagaries of Hungarian notation...
Our configuration is as follows:
Project -> copy dll to common folder
Project -> copy dll to common folder
Main Project -> Copy exe to common folder, run application from common folder
Doesn't much matter how you reference using this configuration, the dlls will be picked up from the application folder and you're golden.
Continuous integration shouldn't care about your .csproj files. I guess they're MSBUILD files? Or something?
Don't use them for CI. They're junk. They accrue garbage because they make too many things invisible. Create a clean build structure that is independent of them, you'll be thankful you did. And then only check in a project file when you're adding something, and everyone else can update/merge. You don't need to have the same or even similar project files most of the time. On my team we don't even run the same version of VS across all workstations.