I have almost 100 website that will update in a condition, I have a winzip archive that contains the files that replaces those websites. I want to know that
I can extract that files in a folder and then copy them to all 100 websites folders
I can extract the archive directly to 100 websites folders
which one is better in performance and less prone to errors.
Possibly better solution (seeing as your source code is the same in each case):
Have your source code in one place on the system and point all the different web sites to the same physical folder.
Related
We outsourced the development of Blackberry 5, 6, and 7 apps. Please bare in mind that I have absolutely no knowledge of Blackberry development at all.
Development is complete, and they have sent us the source code - a collection of .cod, .csl, .cso, .debug, .jad and .rapc files.
I would at least like to review the code in terms of it's consistency and standards - somewhat a measure of the quality. Clean code is not something specific to any one platform.
I have tried to open each of these files in notepad, but with no source code found.
Please advise me on what I need before I go pay them a visit.
The files you have been given are the files that are created as part of the build of your project and the resultant executable files. There is no source included here.
In a BB OS Build, regardless of the development environment used, the Java source files will all have the suffix .java, and the assets (images etc.) will have a suffix appropriate to the asset (like .png). If you don't see these file suffixes, then you have not been given the actual source. You should be able to view the java files using Notepad, the other files will open in an appropriate application (like paint).
To get the complete source, you should just ask the full 'project' files for your development. This will be a directory with a number of sub directories. The actual names used and the structure will depend on the development tool. If your developer is using Eclipse, then the two important directories are called src for source and res (resources) for the assets. If they are using another development environment, then the directories might have different names. So you should ask them what development environment they are using too.
Two other points:
1) If you are paying for this development and wish to review the code, but are not familiar with Java, then I would recommend that you pay someone to review the code who has knowledge of BB Java. There are two reasons for this:
(a) you will not be able to form a judgement on the appropriateness of the code without some understanding of Java, and
(b) you will not understand if the correct BB Java approaches have been used.
You need to be cautious about this, because programmers will always find fault in other developer's code. The question is how significant the faults are.
2) Some developers might be wary of giving source to their client while some payment is outstanding.
We are just migrating from D7 to D2010 and are having a debate about cleaning up the project paths. We have a number of directories with a large number of Pas files that are included on some project paths, but only a few of the files are actually used by any single project.
One option is to eliminate the project paths completely and only have all used files in the dpr.
The second option is to keep only the needed files in the dpr and have project paths to the directories for the rest of the files.
Is there any argument for one option over the other?
Having all your units explicitly in the dpr immensely improves compilation time, code completion, error insight and general navigation.
It does not prevent you from keeping your files organized in folders and sub-folders, but just don't rely on the different paths to find them.
On a big project with millions LOC, it makes a huge difference.
I'm in favor of separating "library units" from "project units" and keeping all "library units" in the search path, with all the "project units" in the project file. Here's why:
Our line-of-business projects are large, almost million-LOC type of projects, but besides those there are literally hundreds of smaller projects for all sorts of tiny little things. Having the "library units" available on the search path makes it really easy to just use those units without adding them to the project: One less step that adds up!
Using the search path makes moving PAS files around easier. This matters allot to me since I'm in the process of re-organizing our whole "build environment" to make better use of version control systems.
When you change one of the shared units and it becomes dependent on yet an other shared unit, you don't need to updates lots of projects, they just work.
I'd never consider adding third-party components (or VCL components) to my project, so why add my "library units" to the project? We need to draw the line somewhere, because if we'd add absolutely all files to the project hoping for faster compile times we'd end up with unmanageably large projects!
Delphi automatically changes the name of the files in it's DPR file to be relative file names. Because of this you can't really move your project from it's current position. Now try "branching" and keeping two copies of the project alive at the same time, on the same machine (a "release" and a "work-in-progress"). (this is me tring preparing my build enviroment for GIT, with the sole purpose of being able to BRANCH).
For reference, my "library units" are those units that are used in unrelated projects (think: components and utilities).
I would argue in favor of including all files that the project uses in the project itself. This will improve performance of the "Insights" by ensuring that used units are part of the project. In addition, this will enable you to more easily manage your code inside the Project Manager. Having large complicated paths is fragile and can be hard to manage.
The comments about speeding up Insights got me intrigued and I will give that a try but so far I never included shared units in the projects that used them. Instead I created packages for each library and added them to the project group (mostly for organizational purposes only, i.e. I never actually compile them as runtime packages). I found this easier to manage (especially with all the recent improvements in the project manager) than having all files in one project as the folder hierarchies inside the individual (package-)projects won't be as deep and especially there's no ".."-level that way.
Reasons to not include all files in the project:
less time to open/close a project (forms and datamodules need extra time)
faster file refactorings (renaming/moving of files and directories does not require to edit all projects)
easier to find the units which are the core requirements and the entry point location for the application logic (uses MyInterfaces, MyTypes, MymMainUnit;)
And this QC entry:
Report No: 77687 (RAID: 273031)
Status: Open Editing in the .dpr
source gets slower with more units in
the project
http://qc.embarcadero.com/wc/qcmain.aspx?d=77687
Update: Now I know that there are many ways to open the project file :) - But my point is that in a dpr with 500 unit references, it is hard to find the 'important' (or 'main') units, which are the starting point to drill down into the source - and it is easier to investigate code if it is a 'lightweight' project file which contains only the necessary unit references.
right now i am simply ftping everything (all of my source code included) but i figured there was a best practices way to get the right dlls and the right aspx files to deploy.
Despite some other tools I feel the best approach is to develop an understanding of the files needed to run the app and upload them appropriately. Depending on how you organize your application you'll be surprised at how simple it is to upload an MVC app. Here's what I do and I hope it helps:
I create a folder in the root of my web app called "assets." In the folder you'll find sub-folders for "css", "js", "images", and "type". I do this for organization as well as when I upload I don't have to find several folders (Content, Scripts, Css, etc) I just upload "assets".
I make sure my supporting class libraries, when built, copy their .dll to my web app's bin folder. That way all necessary .dll's are in the web app's bin folder.
I then upload the following files and folders:
assets
bin
Views
Default.aspx
Global.asax
web.config (production version)
Very simple and not very scary. This is a little simplified as I almost always have other folders and files I use (sitemap.xml, robot.txt, favicon.ico, App_Data (sometimes), etc, etc) but the above is the bare minimum needed. Works great for small to medium sites.
You can build into a different build folder, using msbuild /p:OutputDir=Build\, which will eliminate extraneous files, then FTP that build folder.
I'm eager to see if anyone has better answers though. Good question.
Is there a way to group a bunch of DLL's and still use them at run time (not zipped up). Sorry this question sounds terse and stupid, but I'm not sure what more to ask.
I'll explain the situation though:
We've had two standalone Windows Applications and now one of our Applications has swelled to such ungainly proportions that the other application cannot run outside of the scope of the first app. We want to maintain some of the encapsulation we had while letting the smaller program in on some of the bigger program's features.
There is no problem in running the application, other than we don't want to send out all the 20-30 DLL's that the smaller project has.
It is possible to do this by adding startup code which checks if the DLLs are present on the target system and if not then extracts them from the resources section (or simply tagged onto the end of the exe). A good example of this being done is Process Explorer - it's distributed as a single binary, but when run it extracts and installs a driver.
If you have a situation where most, or all, of those assemblies have to be kept together, then I would highly recommend just merging the code files into the same project and recompiling. This would leave you with one assembly.
Of course there are other considerations like compile time, overall size of the final dll, how often various pieces change, and whether each component is deployed without the others.
One example of a company that did this is Telerik. Their dev components are all compiled into the same assembly. This makes deployment an absolute breeze. Contrasting that is Dev Express which put just about each control into it's own assembly. Because of this just maintaining, much less deploying, a Dev Express project is not something for the faint of heart.
(I don't work for either of those companies. However, I have a lot of experience with both toolkits.)
You could store the DLLs as Resources, and use BTMemoryModule, which essentially allows you to LoadLibrary on a Stream.
That way you could compile-in the multiple DLLs straight into the EXE or into a single resource DLL.
see http://www.jasontpenny.com/blog/2009/05/01/using-dlls-stored-as-resources-in-delphi-programs/
Maybe this applied to other Delphi's (I've only used 7). We've got our code broken up so that nearly every DLL in our fairly massive app is in a different folder.
99% of the open source stuff I've downloaded to plug into Delphi have had all their source munged into one folder.
It seems like this was an assumption that the developers of Delphi made about the coding practices of it's users that may be non-obvious.
I don't think so. In fact, In more recent versions they've added features to the project manager to make it easier to deal with the fact that code is spread around different directories (such as the flatten directories option), so I think it is accepted that this is how many people organize their code.
I suspect it's more to do with projects growing organically over time, and whether anyone takes the time to tidy up.
I for one definitely do not put all the sources into one directory but rather keep them in groups that have something in common. e.g. I use subversion externals quite extensively
(see http://www.dummzeuch.de/delphi/subversion/english.html , the section about externals).
I prefer different modules to be hosted on different folders, then have a common folder for units that is shared among different modules, makes management easy. e.g
myClientServerApp:(parent)
Client folder :(child)
server filder (child)
lib - (child)
Back in DELPHI 7 I also had all files in one folder. It has easy for small projects, but very hard for med to big one.
So I began to create a folder structure for all DELPHI projects small or big.
Over the year I am trying to improve, this folder structure, and every new project I make a small improvement so that it is simpler, logical, and more organized.
This day I am trying to make some parts of it sharable to several project. Its work in progress.
It would seem that having all the units in one folder would save you headaches in doubly named units. On the other hand, it might be handier to keep your projects in different folders when checking in and out of your version control. On the other hand it really doesn't promote code reuse to have them separated out like that.