My job is to upgrade all of our applications that use OpenSceneGraph (an openGl toolkit) version 0.9.9 to the latest and greatest 2.8. Well quite a few caveats come with this task:
1.) After version .9.9 there was a major overhaul the the core OpenSceneGraph (OSG). Commonly used functions and classes were added and removed. Simply put, I can't just replace the old with the new and modify a few deprecated or removed functions - there is a lot that needs to be changed.
2.) Our applications were built using MFC in Visual Studio 2003. They want me to stick with using that for the upgrade.
3.) Good organized documentation for my particular scenerio for OSG seems impossible to find and unorganized and scattered at best.
My question is: What would be a somewhat detailed methodical approach for tackling this problem. I've got about two weeks to upgrade one of the applications. The plan is then to follow and apply this approach for the rest of the applications. For me, the biggest hurdle is finding a starting point. On most projects I work on, I can easily just dig right in and figure it out with a little organization and plan at hand. This seems like a bit more convoluted problem, with a more accurate and precise plan of action needed. Your ideas and suggestions are much appreciated.
In my opinion, you should upgrade your osg to new version and try to build it again until you get no exception.
for every exception which is not solved easily, you can ask to osg-mailing list.
you can also ask what are the major changes with your current version and latest version.
Related
I have the source code from a plugin for second life to play in a browser but the problem is it's been created for Firefox 3.5, so what I'm trying to do is to bring it up to speed and upgrade it to the current Firefox.
Unfortunately I'm not sure how to go about this as I am literally just looking into this now, any help is greatly appreciated
What's your main aim here? Are you interested in simply making the extension work somehow in the latest firefox or are you more interested in optimizing performance?
Optimization of an application is a very general topic. You can look into the upgrades Gecko has gone through in the recent versions. If there seems to be any specific module for which Gecko is now offering a better interface/compatibility, you might try adapting the same. Again, this is really the programmer's judgment and skill which lets him draw the boundary between feasible and non-feasible development. For a module which is extensively linked with many other modules, it might be a good idea to leave it as it is to avoid sleepless nights (of course that's just my opinion. For some, that is the real kick :D).
If you are interested in creating high-performance plugins, you might like to give Google Web Toolkit a try. It is a Java library which compiles java into optimized javascript introducing various performance oriented quirks. I understand that it is not possible to switch an entire application to GWT easily and wouldn't help you just now, but I think it is worth mentioning for future use.
On the other hand, if you are just interested in making the extension work, you may look into Nightly Tester Tools, which is an extension used to override add on compatibility.
Our dev team uses VS.NET for app development and TortoiseSVN/VisualSVN for version control. It seems that almost every day issues arise with the working copy or the repository getting screwed up, and folks just throw up their hands and call me when it happens. There are definitely human factors at work (SVN works as it should) but I'm tired of playing SVN helpdesk to the dev team. Can anyone recommend a better/more intuitive setup for version control?
Agent SVN works well for me. It integrates nicely with Visual Studio.
SVN is about as simple as version control systems get. Problems should only arise when dealing with merging operations...those can be tricky.
If you don't address the "human factors" it won't matter which version control system you use, you will always be the helpdesk. To address these kinds of problems, you typically need to:
Set up a wiki with common "recipes" for version control tasks.
Include a workflow diagram for how changes are made to your code (for those who don't like to read).
Host a training session that is specifically
designed for your users (use the wiki
material).
When helping someone with a problem, be sure to make them perform the actual fix. Don't just do it for them, talk them through it instead.
Make a point of directing users to product documentation when helping them.
Introducing a new version control system into any organization should include the items I listed. I realize it is extra work for those who get it done, but it does save you from long "support" hours down the road.
Can anyone recommend a better/more intuitive setup for version control?
Better? Yes. More intuitive? That's debatable. Look into distributed version control software, namely Mercurial or Git. Both have freely available plugins to integrate with Visual Studio. And if you can manage spending a little money, I've heard very good things about Fog Creek's Kiln.
As for your issues with SVN, I have a couple tips. The first is to make sure you keep everyone synced on the same version of the product. It tends to update frequently, and so this can be tricky, as you also don't want to fall too far behind the current version. The second is that we used to have big problems with Tortoise trying to cache icon overlays on mapped network drives. There is an option you can turn off somewhere that suddenly made things way more stable. But that was at my last job, and I don't remember the exact setting any more.
I think you already gave the answer in your question - sort out the "human factors" by providing appropriate training. Version control for software development doesn't get much simpler than SVN, so from the way your question is phrased, my guess would be that said human factors are just going to find other ways of making your life interesting.
if you have issues with your repository getting screwed (like committing on tags, wrong commit messages...), one of the easiest way is to play it the hard way : put hooks on the server to enforce policies. You can have a look in official documentation.
Basically, this is an easy way to enforce naming / formatting and avoid a lot of human issues (committing on tags, messing with externals...)
Last year, in 2009 GSoC, I participated with an organization called Winlibre. The basic idea is having a project similar to Aptitude (or Apt-get) and a GUI like Synaptic but for Windows and just to hold (initially), only open source software. The project was just ok, we finished what we considered was a good starting point but unfortunately, due to different occupations of the developers, the project has been idle almost since GSoC finished. Now, I have some energy, time and interest to try to continue this development. The project was divided in 3 parts: A repository server (which i worked on, and which was going to store and serve packages and files), a package creator for developers, and the main app, which is apt-get and its GUI.
I have been thinking about the project, and the first question that came to my mind is.. actually is this project useful for developers and Windows users? Keep in mind that the idea is to solve dependencies problems, and install packages "cleanly". I'm not a Windows developer and just a casual user, so i really don't have a lot of experience on how things are handled there, but as far as I have seen, all installers handle those dependencies. Will windows developers be willing to switch from installers to a packages way of handling installations of Open source Software? Or it's just ok to create packages for already existing installers?
The packages concept is basically the same as .deb or .rpm files.
I still have some other questions, but basically i would like to make sure that it's useful in someway to users and Windows developers, and if developers would find this project interesting. If you have any questions, feedback, suggestions or criticisms, please don't hesitate posting them.
Thanks!!
be sure to research previous efforts on this. Google turns up several similar/relevant efforts.
http://en.wikipedia.org/wiki/Package_management_system#Microsoft_Windows
http://windows-get.sourceforge.net
http://pina.plasmite.com
IIRC there was an rpm for windows at some point
Also I think there was some guy (who used to work at MS) in the news recently that basically is starting up a very similar project. I can't find a link to this now.
But anyway, yeah, it would be awesome if there was such a standard tool and repository.
I can only speak for myself, but obviously I could definitely make use of such a tool as I found your post through googling! ;)
My two use cases for this tool would the following ones:
1. I generally avoid to re-install my system as long as possible (in fact I manage to do so only for switching to a reasonable (not each an every) new version of Windows every few years or to setup new computers). But still I'd like my software to be up-to-date. Neither do I want to have to go to all the web pages and check manually if there are compatibility issues with the new version of Doxygen, Graphviz and the latest version of MikTeX for example, nor do I want to have to navigate to the download pages and run the setups all by myself. I just want to schedule ONE SINGLE (!) tool, which checks whether there are new updates or not and updates those applications which are not in conflict with any other application version.
If it unavoidably happens to me that I have to re-install my system, I don't want to get the new setups neither (and check compatibility). I even don't want to wait for one setup to finish in order to start the next one, I just want to check the tools I need, or even better, I want to simply load my "WinApt XML" batch installation file, which gets the installers and handles the setups sequentially all by itself.
I don't know enough about the architecture of .deb or .rpm but IMHO the most reasonable would be to maintain a DB with only the names, versions, dependencies and the location of the different versions' download locations. I mean, most of the tools available for Windows provide .msi packages anyways, which (I guess) is the application itself and some custom installation properties (really not sure how scripting is handled, but I know that creating a MSI in Visual Studio has very limited abilities to create custom installation steps and I can only imagine this is due to limitations of MSI protocol).
I guess a GUI will be mandatory for Windows users ;) but I personally would prefer the additional ability to handle the setups with the console.
Well, I like the idea and would love to hear from that (or such a) tool in the future.
Cheers
Check out NSIS. It's an open source MSI creator. You might be able to use it as part of your package creation software.
http://nsis.sourceforge.net/Main_Page
For the ALT-.Net tool/lib stack there have been some affords in this direction: Horn Get
However, the usability in a real world project has been subject in this SO question.
Microsoft has recently put a release of their Code Contracts framework on DevLabs with a commercial license. We're interested on using them in our project (mostly C#, some C++/CLI) to gradually replace all the custom validation code, but I'm keen to know about the experience other people have had with it before we commit to it, specifically:
Do you think the framework is sufficiently mature for large and complex commercial projects?
What problems have you run into while using it?
What benefits have you got from it?
Is it currently more pain than it's worth?
I realise that this is a somewhat subjective question as it requires opinion, but given that this framework is a very significant part of .NET 4.0 and will (potentially) change the way we all write validation code, I hope that this question will be left open to gather experience on the subject to help me make a decision to a specific, answerable question:
Should we be starting to use it next month?
Note that we do not ship a code API, only a web service one, so for the majority of code breaking compatibility in terms of the exception type thrown is not a concern. However, as I'm hoping more people than just me will benefit from this post and its answers, any detail around this area is more than welcome.
The last mature response to this was in 2009, and .NET 4 is out. I figure we're due for an update:
Code Contracts might well be mature enough for your Debug releases.
I realise this is somewhat of an upgrade from “Harmless” to “Mostly Harmless”.
The Code Contracts home page links to quite thorough documentation in PDF format. The documentation outlines usage guidelines in section 5. To summarize, you can pick how brave you feel about the Contract Tools re-writing your IL in your Release builds.
We're using the “don't rewrite my Release IL” mode.
So far, I'm most enjoying this unexpected benefit: there's less code, thus less code to test. All your guard clauses melt away.
if(arg != null) {
throw new ArgumentNullException("arg");
}
// Blank line here insisted upon by StyleCop
becomes:
Contract.Requires(arg != null);
Your functions are shorter. Your intent is clearer. And, you no longer have to write a test named ArgumentShouldNotBeNull just to reach 100% coverage.
So far, I've run into two problems:
I had a unit test which relied on a contract failure to succeed. You might argue the existence of the test was a blunder, but I wanted to document this particular prohibition in the form of a test. The test failed on my build server because I didn't have the tools installed. Solution: install the tools.
We're using two tools that rewrite IL: Code Contracts and PostSharp. They didn't get along too well. PostSharp's 2.0.8.1283 fixed the problem. I'd cautiously evaluate how any two IL-rewriting tools get along, though.
So far, the benefits are outweighing the hazards.
Addressing out-of-date concerns raised in other answers:
Code Contracts's documentation is quite thorough, though regrettably in PDF.
There's at least one Code Contract forum hosted by Microsoft.
Code Contracts Standard Edition is free if you have any VS2010 license.
.NET 4 is out. I've run into Microsoft's contracts when implementing generic collection interfaces.
I've been playing around with the code contracts some more myself on a small but moderately complex standalone project, which needs to inherit from some BCL classes and use other ones.
The contracts thing seems great when you're working in a completely isolated environment with just your own code and primitive types, but as soon as you start using BCL classes (which until .NET 4.0 do not have their own contracts) the verifier cannot check whether they will violate any of the requires/ensures/invariants and so you get a lot of warnings about potentially unsatisfied constraints.
On the other hand, it does find some invalid or potentially unsatisfied constraints which could be real bugs. But it's very hard to find these because there is so much noise that it's hard to find out which ones you can fix. It's possible to suppress the warnings from the BCL classes by using the assume mechanism, but this is somewhat self-defeating as these classes will have contracts in the future and assumptions will lessen their worth.
So my feeling is that for now, because in 3.5 we're trying to build on a framework that the verifier does not sufficiently understand, that it's probably worth waiting for 4.0.
Judging by this thread I would say it is not quite mature enough to use for an enterprise level project. I haven't used it myself, but people are still running into bugs that would bring your contract-critical project to a halt. It seems like a really great framework and the example videos they've provided have been exciting, but I'd wait for:
Existence of a community forum. You're going to want to be able to discuss inevitable problems you run into with other developers, and you want to know there is a decently strong base of developers out there to discuss solutions with.
A successful pilot project release. Generally, when Microsoft Research releases something that they think is mature enough to be used in a commercial project, they will work with an organization to pilot it, and then release that project open source to as a proof of concept and trial-by-fire of all of the major features. This would give a lot of confidence that most of the common contract scenarios are covered and working.
More complete documentation. Plain and simple, at some point you're going to want to do something with contracts that you can't do yet using Microsoft Code Contracts. You want to be able to quickly and clearly reason that your scenario is not yet supported. The current documentation is going to keep you guessing and trying different things, though, in my opinion, which will result in a lot of wasted time.
It's not mature enough.
It will be as soon as Microsoft releases it with the affordable editions of VS, but without the static code analysis it's not usable at all.
The editions of VS, that have it, are so insanely expensive that only a handful of people will ever be able to afford it.
It's a shame Microsoft killed this amazing idea with their pricing policy. I wish Code Contracts would become mainstream, but they won't.
Epic fail.
We have a collection of commercial MFC/C++ applications which we sell using Stingray Objective Toolkit, we have source code license and have ported it in the past to Solaris/IRIX/HP-UX/AIX using Bristol Technologies WindU (Windows API on UNIX, including MFC).
Any long story short recently about 18 months ago we ported Stingray to Win64, but a long a tedious task, during this time I did some research on commercial and open source alternative MFC extension libraries things like Ultimate Toolbox and Prof-UIS.
Has anyone else used Stingray and moved to an alternative?
If so which one would you suggest?
What were the main perils of the move?
Yes, we haved moved away from Stingray. It depends on what Stingray components you are using. For the grid control, you can use the free MFC gridcontrol from www.codeproject.com or the commercial one from http://www.bcgsoft.com/. The free one is OK but development has stalled, so no modern UI rendering etc.
The 'layout editor' Stingray component can be replaced by the one from bcgsoft.com, but I don't have experience with that - we rewrote the functionality we needed from that on our own (it was only a subset of what Stingray provided).
As for alternative MFC toolboxes, I suggest bcgsoft because part of their toolbox is in the Visual Studio Feature Pack so it's free and fits very well with VS. I have looked at Ultimate Toolbox (stay away from it, stale code that isn't updated anymore) and Prof-UIs (OK but I found it not so easy to integrate).
Now that BCG is part of the 'official' MFC I don't see a reason to choose something else than BCG (except for maybe the cost, if you need a free alternative you can look at codeproject).
I have limited experience with Stingray.
However, I want to suggest trying CodeJock's Xtreme Toolkit Pro (http://www.codejock.com). Its GUI is very good and its supported very well.
I have been using Stingray for last eight years or so, and have looked at moving off it a couple of times. So far, I've decided against, principally because I have ported a version to Windows CE & Mobile and don't see much else giving the same solution on this platform. While Stingray isn't perfect, they have now got a 64bit version, and it's a pretty stable product.
What I am doing, is replacing the very weak areas of Stingray, such as the XML support, with alternatives. In this case I went with Expat for performance reasons.
The perils of moving? You could go from something stable but old fashioned to pretty but flakey ;) In my case, I would also kill a fair number of my automated test scripts that work at GUI level.
Edit: Just to add a bit to the above, I moved from VS2003 to VS2008 this week and at the same time Objective Studio 2006 v2 to Objective Studio 10.1. The transition was pretty seamless, with one minor glitch that was promptly handled by RogueWave tech support. Even this would have gone unnoticed if we didn't have a very extensive GUI regression test suite. IMO, Stingray is a very mature, well supported, feature rich and most importantly stable product. I for won't be moving of it any time soon without very good reason.