I'm currently exploring different integrations that can be done between Google App Script and Git. This is part of a bigger attempt to integrate Git data into my project management system. I'll post more on that later. GitHub supports a number of very nice sub-systems. One of them is the GitHub Issues ticket tracking system. It's fairly robust and comes with GitHub - which means it's highly integrated out-of-the-box. Integration with Google's App Script is done via the fetchURL command and JSON object manipulation. After a good bit of experimentation, I've settled on querying GitHub Issues with an "on open spreadsheet event" to avoid issues with Google's quota system. Essentially, Google prevents you from calling the fetchURL command more than X times (see the quota limits ) per day. That's not great if you have people actively working and changing data in a spreadsheet. Some of my other App Script routines are running thousands of times per d
Serge Dosyukov recently posted about the speed of the Delphi installer. While I agree that it's annoying to have to wait for the initial installation, I find that one of the largest failures in most development environments (including Delphi) is uniformity in a group setting.
For some reason, you can use products like subversion to manage your source code, but there is no product to standardize and manage your development environment. In our case, we have a handful of developers who all are working on different aspects of a large application (>1 million lines of code). We need to be able to manage the third-party add-ons and Delphi patches in a uniform way. The only method of doing this (to my knowledge) is to carefully install everything in the same paths and, usually, same order.
At one point I thought we could be clever and tried to install all add-ons to a networked drive for every workstation to minimize the amount of thrash we encounter when installing SP for the add-ons. Needless to say, that was a terrible idea. We encountered problems with locks being placed on the files which caused Delphi to either crash outright or to remove the packages that were causing the problem. It's a little disingenuous to say that it "removed the package". It prompted for the removal of the package. If we didn't, Delphi simply shut down.
I think the development environments should be modeled on a source control system. I don't mind the base install with the licensing restrictions, etc., etc. Once the base install is there though, I would like to be able to connect to a source repository that actually understands Delphi, it's add-on structures, and the registry entries needed to run, and be able to sync the changes up or down. That would let me take an add-on, install it on a test machine to make sure it works, sync it and then clone it down to the workstations. Better still, once the repository is built, let me roll back in time to something that is stable if we discover 3 months after a SP release that project XYZ just doesn't work with that SP.
If CodeGear got clever, they could setup an open API that would let the add-on vendors install to the repositories and deal with the licensing issues that everyone is concerned about. Sort of an Apple Store in an open and transparent fashion (gasp!). Obviously, you could actually set the repository system up to be a true retail presence and let the add-ons register and sell via the repository. I'm sure everyone who is using Share-It is paying a small fee anyway. Wouldn't it be a better idea to capture that fee AND make everyone's life easier at the same time?
How do you handle the group environment? The last time we looked at this problem in depth we were on D7. Is there a better way in D2007?
For some reason, you can use products like subversion to manage your source code, but there is no product to standardize and manage your development environment. In our case, we have a handful of developers who all are working on different aspects of a large application (>1 million lines of code). We need to be able to manage the third-party add-ons and Delphi patches in a uniform way. The only method of doing this (to my knowledge) is to carefully install everything in the same paths and, usually, same order.
At one point I thought we could be clever and tried to install all add-ons to a networked drive for every workstation to minimize the amount of thrash we encounter when installing SP for the add-ons. Needless to say, that was a terrible idea. We encountered problems with locks being placed on the files which caused Delphi to either crash outright or to remove the packages that were causing the problem. It's a little disingenuous to say that it "removed the package". It prompted for the removal of the package. If we didn't, Delphi simply shut down.
I think the development environments should be modeled on a source control system. I don't mind the base install with the licensing restrictions, etc., etc. Once the base install is there though, I would like to be able to connect to a source repository that actually understands Delphi, it's add-on structures, and the registry entries needed to run, and be able to sync the changes up or down. That would let me take an add-on, install it on a test machine to make sure it works, sync it and then clone it down to the workstations. Better still, once the repository is built, let me roll back in time to something that is stable if we discover 3 months after a SP release that project XYZ just doesn't work with that SP.
If CodeGear got clever, they could setup an open API that would let the add-on vendors install to the repositories and deal with the licensing issues that everyone is concerned about. Sort of an Apple Store in an open and transparent fashion (gasp!). Obviously, you could actually set the repository system up to be a true retail presence and let the add-ons register and sell via the repository. I'm sure everyone who is using Share-It is paying a small fee anyway. Wouldn't it be a better idea to capture that fee AND make everyone's life easier at the same time?
How do you handle the group environment? The last time we looked at this problem in depth we were on D7. Is there a better way in D2007?
Comments
I am going to discuss it more here:
http://blog.dragonsoft.us/wp-admin/post-new.php?posted=280
http://blog.dragonsoft.us/2008/08/12/was-delphi-in-workgroup/
We manage our IDE and components through a detailed document written up in our internal wiki. I wrote about it here. Since it's not compiler specific, it works for all of our development tools.
What we did was to take a virtual machine, carefully installing one third party add-on at a time, submitting the delphi folder, the 3. party folder, a dump of the file list from system32 (it's too big to check in to version control) and a dump of the registry to subversion.
Now we can easily see what files were installed by the different 3. party extensions, as well as what they did to the registry.
Here's a post I wrote about it back in february: new use for subversion
Does anyone else has some ideas to share about this?