I'm working on a website with Visual Studio Code.
Is there a way to save only the files being used by a project into a separate folder?
Basically what I'm looking for is a tool which would scan all the local resources linked by all html files (meaning linked images, videos, files), and then it would save them all in a separate folder.
The reason why I'm asking this is because at the moment I'm testing things out, meaning I'm using image A, then image B, C and so on so forth. These images live in subfolders, so now I ended up with some images which I'm actually using in the html pages and some which I'm not. The thing is, is not simple to check which images I'm using.
You'll find the same principle in 3d applications, such as 3ds Max for instance, where, once you're done with the project, you can use a Resource Collector tool to strip out all the unused assets and save only the ones used by the project.
I've looked for an extension or a solution to this without any luck, so I guess an extension does not exist yet, but I think it would be a nice tool.
I don't understand why someone downvoted my post.
Either what I'm asking is already possible, although like I said I searched and I didn't find anything, or who downvoted consider my request stupid.
Whatever the reason, I believe it would be more mature to give a proper answer, even if whoever downvoted did it for either one of the two possible reason above.
In fact:
The solution already exists: like I said, I didn't find it, so if someone knows the solution why not simply posting it here?
The solution doesn't not exist but someone thinks it's a stupid idea. Well, it is not and it would be polite and civilized to discuss it.
In the current era it became so easy to express opinions without actually doing anything, by simply pressing a button to say nothing valuable, as a "I like".
I never stop feeling amazed where the social media behavior it's taking us.
I have an old system that was written in PHP a long time ago that I would like to update to node.js to allow me to share code with a more modern system. Unfortunately, one of the main features of the PHP system is a tool that allows it to load an existing PDF file (which happens to be a government form), fill out the user's information, and provide a PDF to the browser that has all of that information present.
I have considered making a PHP script that will just do the PDF customization and using node for everything else, but it seems like something like this should be able to be done without requiring PHP to be installed.
Any idea how I might solve my problem just using node?
After a lot of searching and nearly giving up, I did eventually find that the HummusJS library will do what I want to do!
Update April 2020: In the intervening years since I posted this other options have cropped up which look like they should work. Since this question still gets a lot of attention I thought I'd come back and update with some other options:
pdf-lib - This one is my current favorite; it works great. It may have limitations for extremely large PDFs, but it is constantly improving and you can do nearly anything with it -- if not through the helper API then through the abstraction they provide which allows you to use nearly any raw PDF feature, though that requires more knowledge of the PDF file format than most possess.
It's worth noting that pdf-lib doesn't support loading encrypted pdfs, but you can use something like qpdf to strip the encryption before loading it.
https://www.npmjs.com/package/nopodofo - This one should be one of the best options out there, but I couldn't get it working myself on a mac
https://www.npmjs.com/package/node-pdfsign - Not exactly the same thing but can be used with other tools to do digital signatures on a PDF. Haven't used it yet, but I expect do
Update Dec 2021: I'm still using pdf-lib and I think it's still the best available library, but there are a lot of new libraries that have come out in the last couple of years for handling PDFs, so it's worth looking around a bit.
No tool is perfect, and I'm about to start several long-term projects using Trac, and wanted a heads up of the kinds of problems I may or may not experience with it. In other words, Trac meets my needs in the short term, and I've already made the decision to use it, but I want to know what to expect down the road.
I am not looking for:
"Use product X instead of Trac because..." answers.
"Trac is great because..." answers.
A comparison to any other specific system.
"Trac doesn't support Feature X" answers. I can read the feature list too, thank you very much.
I am looking for:
"Feature X does not behave as expected..."
"Trac behaves oddly when..."
"Trac doesn't fully support..."
"Trac itself has a known bug that will likely never be fixed..."
And especially "Trac can't handle..."
etc
So, what Trac-induced headaches do I have to look forward to?
For future reference, this question was asked while Trac v0.11 was the latest stable release.
There is still no common view on how to handle multi projects. If this is not your case - the rest should work for you.
One issue that I have run into with a long-term Trac instance is the 'version' field. There is no distinction between the list of versions that can be assigned to a ticket, and the list of versions that can be queried for in the custom query interface. So if the version list for that field starts getting cumbersomely long, you can't really trim it without limiting what you can search for.
One of these days I'll get around to fixing that...
Trac 0.11 is rather more of a resource hog than 0.10 was; in large part due to the switch to Genshi for the templating engine. You may want to keep an eye on resources on the server, memory in particular. I expect to see some increased attention paid to performance in 0.13 or so.
Oh, and if you run into problems, #trac on freenode can be a nice resource.
Disclosure: I'm one of the Trac developers
We've used Trac for several years with multiple projects. After thinking for a minute I still can't come up with any significant problem to list.
http://trac-hacks.org/ticket/131 - Persistent Logins (i.e. persistent login session cookies across browser restarts) is still not committed.
It means when you get your svn post-commit mail with the trac link then
if your browser isn't already loaded (remembering your login) you have to enter your credentials to see content (depending on how you have security set). This is only an issue if you only trust a certain class of users on your network. Browsers remembering credentials mitigate this, and for high-security situations you may not want the option at all, but for us it is slightly annoying.
0.12 is quite close to release, i would go straight for r9125 trunk or thereabouts:
multiple source repository support (branch landed in trunk with r9125)
live text editing previews
ticket comment editing with diffs are
those are three primaries why i went ahead and moved all my envs into 0.12dev. there are many more minor nice things that make a difference over 0.11, though.
i think running trac out of SVN working copy provides very nice upgrade and general manageability, so that is what i would recommend.
multiple project support is the biggest culprit so far and i'm looking to put in some work myself to improve that situation.
When someone else reassigns your ticket, you don't get notified.
I have a complex sharepoint deploy with multiple EventReceivers and Workflows.
I also have schema changes to existing lists, adding new columns of metadata and changing existing columns.
Should I package a single feature, eventreceiver or workflow, to a single solution, or should I put multiple features inside the single solution since they all work together?
One major reason I am asking is for future code upgrades. If the features are seperated, then an upgrade in one portion of code would not require a re-deploy of all the features in the solution. Is this something I should worry about or does the "stsadmin -o upgradesolution" take care of any issues with the upgrade of a solution with many features?
Let me know if this makes sense to any SharePoint gurus out there.
Thank you,
Keith
Update:
Looking at the website drax referenced, I found this reference site: http://msdn.microsoft.com/en-us/library/aa543659.aspx
This statement seems to put a large handicap on upgrading features in solutions:
Solution upgrade can only be used to
replace files. You can add new files
in a solution upgrade and remove old
versions of the files, but you cannot
install Features or use Feature event
handlers to run code for Feature
installation and activation. The
following operations are not supported
in solution upgrade.
Removing old Features in a new
version of a solution.
Adding new Features in a solution
upgrade.
Updating or changing the receiver
assembly for existing Features in a
new version of a solution.
Adding or changing Feature elements
(Element.xml files) in a new version
of a solution.
Adding or changing Feature
properties in a new version of a
solution.
Changing the ID or scope of old
Features in a new version of a
solution.
Removing Feature elements
(Element.xml files) in a new version
of a solution.
Removing Feature properties in a new
version of a solution.
So... What can you do with a solution upgrade?
I would advise against splitting everything into multiple solutions. Maintaing that can quickly become nightmare. Try to structure your project, which should is used to create WSP, in same manner as 12 folder of sharepoint. Then you can use WSP builder, last stable version brings a lot of useful stuff.
Also i've not noticed any problems with redeploying solutions. According to this article and to my experience deployment of WSP takes care of synchronization between versions. So if you will add some new features they will appear and if you remove/change features they will be modified accordingly.
EDITED:
So I did some quick research on MOSS Updating topic. According to MS there are two ways of updating solutions:
In-place update
Incremental update
Basically, in-place update is standard way of updating. Meaning you are relying on build-in functionality as described in this (same document as posted before) document. Problem with this solution is that it lacks quite a lot of functionality (versioning, changing of ID's of features,...).
Incremental update (this is how MS calls it probably) don't rely on build-in solutions. That means it is up to everybody to implement it by themselves :(. What is even better I was not really able to find any guidelines for this approach. I suppose that approach you would like to take is example of incremental update (splitting project into many independent solutions).
Also note that Incremental update is not officially supported by MS.
So I don't really know what advice should I give to you. Single WSP is more maintanable than buch of them, also if you are doing just some minor changes updates work perfectly. But if you need to make some bigger structural changes problems start to show.
I'll probably wait and see if people with more MOSS expertise can say something about this topic.
Basically (for the reasons you've mentioned), you should think of solutions as you would .Net assemblies - atomic units of code that can be deployed separately from others. Using upgradesolution will cause a redeploy of all the contained features - if nothing's changed, then nothing should change for the sites that use that feature. But, if that makes you nervous, consider splitting it up.
UpgradeSolution is really handy if you are just updating the assembly and leaving the provisioned files intact.
Unless you specify -local then upgradesolution will perform a full iisreset across your infrastructure. This is really worth noting for when you are planning the right time to perform upgrades.
Recently I've been doing lots of weekend coding, and have began to really need a bugtracker as things are gaining speed. This is probably the worst case scenario because I basically have to let things cool down over the week,so I simply can't remember the bugs in my head. So far I've been using a text file to jot down bugs,but I'd rather use something a bit better.
The biggest points here are ease of use and very little setup time.Don't want to spend more than an hour learning the basics and trying to install something. Also in my case I'm on a Mac so that would help, but solutions for other platforms are welcomed as they will likely help others.
FogBugz has a student/startup edition that's free indefinitely, for 2 or less users.
Personally, I use Excel. (Wait, come back, I'm not crazy!) For a bigger / team project, I've gotten a ton of mileage out of Bugzilla, but that tends to be kind of overkill for a one-person project.
But, a well-organized spreadsheet, with columns for things like "status", "description", "code module", "resolved date," etc, gets you pretty close to what you'd need for a small project. Sorting a spreadsheet by column isn't anywhere near a search, but its a whole lot better than "find in text file."
Heck, if you use Google docs rather than excel, you can even publish the thing as an RSS feed and get it anywhere.
And, the major advantage is that the setup time and learning curve are both effectively nil.
Addendum: And of course, the instant your "One-Person Bug Tracker" becomes a "Two-Person Bug Tracker" you must switch to something better. Bugzilla, FogBugz, anything. Trust me, I've been there.
Trac or Redmine are both pretty good. I don't know how easy they are to set up on a Mac.
It's worth mentioning that FogBugz also has a free version for up to 2 users, which would suit you. It is hosted so there is no installation and you can use something like Fluid to access it in its own window.
I don't think you need a full blown bugtracker for your scenario.
Try tiddly wiki, store each bug in a tiddler and give them tags like 'open' or 'closed'.
There is no installation required (only one html file), and it's very easy to use.
And platform neutral.
If you're working on a LAMPP stack, then for ease of setup and use I would probably recommend Mantis. It's written in PHP / MySQL and the only installation involved was specifying where the database should be created and what credentials should be used.
Oh, and its FOSS.
I would suggest Omnigroup's Omnifocus - it's an excellent task tracker, and if you just make the mental leap from bug to task, I think it works famously for one man projects as well as being an excellent way to organize your no doubt burgeoning task queue.
Eclipse has a really interesting system--I don't know why so few people seem to know about it.
It's tied in with their to-do list. It gives you the ability to enter bugs with as much or as little info as you like. You can tie it to versioning or an external bug tracker if you like. It's a decent bug tracker in itself.
The real trick is how it works with your source code.
Before you begin work you select a bug from the list. All the time you're coding, it tracks what files you are editing. It can close old tabs for you, and will also highlight areas of the source tree that you have modified a lot.
The nice thing is, you can go back to any bug you've edited an you will get your "Environment" back. Not only all your notes and stuff, but the same tabs will open up and the same sections of code in the navigator will be highlighted.
Also eclipse works with virtually any language, it's not just restricted to Java...
let me put in a good word for ditz - it's a bit bare-bones, but it has the invaluable feature that bugs are checked into your repository. it's also very easy to use once you get used to its way of doing things
You can use fogbugz for free if you're a one man team.
It's super easy to use and quick to learn.
They made it so that bugs are really easy to enter, no mandatory fields.
I'm the author of BugTracker.NET mentioned in another post. If I were looking for a tracker for JUST ONE PERSON with MINIMUM hassle, I'd use FogBugz, because it's hosted. No installation, no need to worry about backups.
But, what are you doing about version control? Don't you have to worry about that too, and backing that up? If so, consider something like Unfuddle or CVSDude where you can get BOTH Subversion and Trac, or Subversion and Fogbugz.
I use Mantis at home and I'm happy with it. It can be a pain in the arse to get it working so you can choose to download a free and ready-made VM installation. Cannot be easier than that,
Maybe a spreadsheet would be the next logical step? I know it sounds really un-sexy, but if you're the only user, you don't have to worry much about others mucking it up, and it adds a few basic features over a text file like sorting. Then if you later need to graduate to something RDBMS-backed, you would likely have a feasible import path. I just know that for me, when working by myself, I don't tend to get around to putting bugs in anything that requires more care and feeding than that (of course when working with others the collaborative needs make a more defined repository a requirement, but that's a different story).
EDIT: After noting the availability of free, hosted access to FogBugz, I'm re-thinking the bar for care and feeding...
RT from BestPractical is great.
I also get a lot of mileage out of just keeping a list of items in a text file with vi, if I can express them all in one line. This is usually for many small todo items on a single component or task.
I've tried bugtracker.net and even though it's a little bit rough on the edges, it's free and was built with ASP.NET:
http://sourceforge.net/project/showfiles.php?group_id=66812
Are you using a source control repository as well? If not, you really should, even though you're only a one-man team.
My personal preference is to use a VMWare Virutal Application (free) that offers no-hassle setup gives you access to both Trac and Subversion. You can find many different virual appliances through searching. Here is one example of getting a Trac/SVN virtual appliance up and running:
http://www.rungeek.com/blog/archives/how-to-setup-svn-and-trac-with-a-virtual-appliance/
Trac is an excellent project management tool that sports a bug tracker, wiki, and integrated source control management. It's adaptable to your needs, and fits me very well personally.
I use bugzilla for this purpose. Plus for me was that it has integration with Eclipse (precisely with Mylyn). FogBuzz has it to but AFAIK it is nonfree.
Plus it sits on my laptop so I can code and add/remove bugs when offline (it was biggest disadvantage of hosted solutions for me)
Installation was not a problem in Ubuntu (and any debian-based distro I suppose).
I dig ELOG in those cases, it's more of a personal blog, but it's easy to handle and install, the data is local on your computer and you can search all entries via fulltext. Always sufficed for me.
If you have a Windows box with IIS and MSSQL (including SQL Server Express), you should look at Bugtracker.net. It is free and open source (you get the source code), and it is extensible.
Even if you are a one man shop, having a free bug tracking system with this much power will allow you to grow over time, because it is fairly easy to add future users into the system.
You can also customize it for the look of your organization, business or product.
Ontime 2008 by Axosoft is free for a single user licence. It's industrial strength and will give you alot more that just bug tracking!
http://www.axosoft.com
Jira which now has free personal licenses.
I am using leo for this purpose. To be more specific, its cleo plugin.
Of course you might need to spend some time to get used to leo, but it will pay off.
A flat text file is just a list, an Excel spreadsheet is a two-dimensional list.
leo lets you keep the data in a tree! And it also has clones.