I can't seem to find much documentation for the code that Power Tools Beta 4 generates. I'm particularly interested in how to modify the code when new table fields are added, and how to add relationships. Where can I find a description of all the code pieces that are generated?
Also, I thought there was a way to regenerate and overwrite the Power Tools code after it has been generated but I just get errors when I try to do that. Do I need to delete all the generated entities in order to re-generate?
Related
I have a large application to manage consisting of of three or four executables and as many as fifty .dlls. Many of the source code files are shared across many of the projects.
The problem is a familiar one to many of us - if I change some source code I want to be able to identify which of the binaries will change and, therefore, what it is appropriate to retest.
A simple approach would be simply to compare file sizes. That is an 80% acceptable solution, but there is at least a theoretical possibility of missing something. Secondly, it gives me very little indication as to WHAT has changed; It would be ideal to get some form of report on this so I can then filter out irrelevant (e.g. dates/versions copyrights etc..)
On the plus side :
all my .dcus are in a row - I mean they are all built into a single folder
the build is controlled by a script (.bat)(easy, for example, to emit .obj files if that helps)
svn makes it easy to collect together any (two) revisions for comparison
On the minus side
There is no policy to include all used units in all projects; some units get included because they are on a search path.
Just knowing that a changed unit is used/compiled by a project is not sufficient proof that the binary is affected.
Before I begin writing some code to solve the problem I would like to ask the panel what suggestions they might have as to how to approach this.
The rules of StackOverflow forbid me to ask for recommended software, but if anyone has any positive experiences of continuous integration tools that would help - great
I am open to any suggestion or observation that is relevant in this context.
It seems to me that your question boils down to knowing which units are contained in your various executables. Since you are using search paths, it will be hard for you to work this out ahead of time. The most robust way to find out is to consult the .map file that the compiler emits. This contains a list of all units contained in your executable.
Once you know which units are contained in each executable, you need to know whether or not anything has changed in those units. That information is contained in your revision control system. Put this all together and you have the information that you need.
Of course, just because the source code for a unit has changed, you might argue that re-testing is not needed. Perhaps the only change made was the version, or the date in a copyright label or some such. But it is asking too much to be able to ask a computer to make such a judgement. At some point you need a human to step up and take responsibility.
What is odd about this though is that you are asking the question at all. It seems to me to be enormously risky to attempt partial testing. I cannot understand why you don't simply retest the entire product.
After using it for > 10 years for commercial in-house and freelancer work in large projects, I can recommend to try Apache Ant. It is a build tool which supports dependencies, and has many very helpful features.
Apache Ant also integrates nicely with CI tools such as Hudson/Jenkins, Bamboo etc.
Another suggestion - based on experience with Maven - is to design the general software architecture as modular as possible. If modules (single or multiple source or DCU files in one directory) use a version number in the directory name as a version number, it is possible to control exactly how application are composed from these modules.
If you want to program such a tool yourself the approach would be something like this:
First you need to detect wheter there were any changes made to seperate source files. As you already figured out comparing the file size is bad idea as the file size can stay the same despite lots of changes made to it (as long as there is same amount of text in pas file its size won't change). So instead you could check the last modification time for specific file or create some hash value like MD5 hash for comparison (can be quite slow).
Then you need to generate yourself a dependancy tree which will tell you which files are used for which project/subproject.
Finally based on changes detected in seperate files you check the dependancy tree to see which projects needs to be recompiled.
The problem of such approach is that you would probably have to update the dependancy tree manually each time when new unit is added to the project or an existing one is removed from the project.
But the best way would be to go and use some version controll software istead of reinventing the wheel. I myself like the way how GIT works and I belive that with proper implementation of GIT into the project mannager itself could be quite powerfull do to GIT support of branching/subbranching (each project is its own branch, each version of your software can be its own subbranch).
Now latest version of Delphi does have GIT integration done though SVN but this unfortunately limits some of best GIT functionality. So if you maybe decide to go and integrate GIT support directly into Delphi I'm first in line to use it.
I am working with an undocumented, 100.000 lines Delphi 7 project and one of my goals is to create a software architecture document from the source code.
Can you give me any ideas on how to approach this?
These tools work with Delphi 7 and are of great help:
the UML tool ModelMaker
the refacotoring tool ModelMaker Code Explorer
the documentation tool Documentation Insight (as of august 2012)
UML diagrams are a great way to get an overview of structure. How well that overview is, depends on how well the structure is.
For taking over projects like these, I start with some basic documentation (often in MarkDown format, as that text based format is version control friendly, and generates nice HTML).
To get that going, it helps if the original developers or/and some base documentation are still there.
Then just start to:
fix bugs / apply feature requests
use ModelMaker to get a feel for overall structure
use ModelMaker Code Explorer as a refactoring tool
use Documentation Insight to document inside the source code (you can generate help files and web pages with the pro version, see feature matrix)
update my Markdown documents with any information that does not fit in the source code documentation well
Note you can put some documentation in using Model Maker Code Explorer, but it can not be exported as help files, since it uses a different documentation format than Documentation Insight.
So I agree with the comment by Jan Doggen (thanks Jan!): just start. Make sure you have the right tools to help that going.
Try running the source code through a newer Delphi version that supports UML modeling, then let it show you how different sections of code related to each other.
Understand will do the job. Free download includes 15 days evaluation which will be more then enough for what you need to document.
I find it incredibly tedious every time I edit a core data model in the XCode model builder to select "Editor -> Create NSManagedObjectSubclass", then select the project group and directory in which to place the generated files, and agree that yes, I do want to replace their old versions.
It would be really great to have a one line shell command to generate these with a default group and directory. Does such a tool exist? If not, how would one go about writing such a tool?
I don't think there's any way to automate Xcode like that. The closest you can come is the generic UI automation functionality in AppleScript, but what you're asking for is pretty complex.
Instead, you may want to investigate mogenerator. It doesn't do the exact same thing that Xcode does, but it is basically a tool to regenerate CoreData classes as part of your build system, without interfering with custom code you may want to write for the class.
I hope what does retrofitting of code mean?
Since you checked-out the code from
prod, if any changes have been
deployed in prod, then retrofitting of
a code will add those changes to your
code to make your code deploy-ready.
Hope retrofitting is already known stuff. I know SUPERCE does in identifying the changes happened to code but do we have a tool which incorporated the changes automatically? Lemme know if you have a solution or question needs to be rephrased?
You can use the ISPF Editors "COMPARE" command. It will merge the changes in as info lines and you can use the makedata (MD in the prefix area) command to accept the changes.
Hope that helps.
Another option to consider is "Merge+Reconcile" from SERENA Software. It can compare up to 8 variations (derivatives) and uses an ISPF-editor like interface. If you're working on a huge merge, you may want to use its "Work In suspense" feature, where you save your intermediate results and come back on it at a later time to continue where you left of.
Refer to page 15 of this PDF for way more details.
My this has aged. When in parallel development (say multi year projects with multiple major releases in the pipeline).
The retrofit occurs when an accepted and implemented change needs to be shoehorned into the other arms, where code may not be identical prior to the change. It may not possible to automate.
When building ASP.NET projects there is a certain amount of boilerplate, or plumbing that needs to be done, which is often identical across projects. This is especially the case with MVC and ALT.NET approaches. [I'm thinking of things such as: IoC, ORM, Solution structure (projects), Session Management, User Management, I18n etc.]
I would like to know what approach you find best for 'reusing' this plumbing across projects?
Have a 'master solution' which you duplicate and rename somehow? (I'm using a this to a degree at the moment, but it's fairly messy. Would be interested how people do this 'better')
Mainly rely on Shared Library projects? (I find this appropriate for some things, but too restrictive for things that have to be customised)
Code generation tools, such as T4? (Similar to the approach used by SharpArchitecture - have not tried this myself)
Something else?
Visual Studio supports Custom Templates.
I definitely (mostly!) go for T4 templates in conjunction with a modified version of SubSonic 3. I kind of use the database to model my domain and then use the T4 templates to generate the model and associated controllers and views. It takes about 50-60% of the effort out and keeps a consistency in place.
I then work on overrides (partials) of the classes along with filters and extension methods to 'make the app'. Now that I'm familiar with the environment and what I'm doing, I can have a basic model with good plumbing in place in a very short space of time. More importantly, because I create a set of partial class files, I can regenerate all I want without losing any of my 'custom' coding.
It works for me anyway :)
You could do it the bearded, t-shirted, agile style and create a nice template and put it in sourcecontrol. So when you need a new project, you just checkout the template?
For insanely fast MVC site setup, I use modified T4 templates (created with T4 Editor) and with ALOT of help from Oleg Sych's blogs for page generation (for your typical add/edit/index pages) combined with an awesome implementation of an automated create-update-delete called MVCCrud (if LINQ-to-SQL is your preferred data access method)
Using modified T4 templates and MVCCrud you can create fully functional entities (Create/Edit/List/Delete) with error handling and intuitive error messages in about 4 minutes for each.
I create a new project using the new project wizard so that I get unique project GUIDs assigned. Then I would use "Add Existing Item" to copy items from similar projects if it made sense to do so.
I sometimes use a file diff tool to copy references from one project to another, otherwise I just add the references by hand. A file diff tool can also be used to include similar source files, but the underlying files have to be copied anyway, so I prefer "Add Existing Item".
I've used T4 to generate solution and project files, but that definitely seems like an edge case and not something that would normally be necessary. In that case, I'd probably wrap the T4 in a PowerShell like script to create and populate the rest of the directory structure.
I use "shared libraries" pretty aggressively in general, but not specifically due to this scenario.
In general, I don't find myself reusing plumbing between projects much. It's probably more often that I hack away in one "prototype" project, then abandon it, and rebuild the project from scratch following the above approach and only bring over the "non-hacky" code.
I'm creating a MVC2 application template at http://erictopia.com. It will contain all the basic items I think should be in a MVC project. These include BDD specifications, an ORM (NHibernate and possibly Lightspeed), T4 templates, custom providers, ELMAH support, CSS/Javascript minifier, etc.