Speechless :omg: .

Recently I've been reading alot about how women in IT are still being predjudiced against - lower salaries, experience bias from men, fewer in positions of power, the usual stories about how women can't seem to make it in a male-dominated industry. Given my own experience in IT, I'm inclined to think that most of this is rubbish as I've found gender to be mostly irrelevant. I've found that hard work, being good at your job and having the confidence to stand your ground carries far more weight than "being a skirt". Am I alone in this thinking?

modified on Wednesday, May 5, 2010 2:15 PM

Hate to break it to you, but countries with a strong Brittish infuence are far more likely to use "darta" than those with a strong American influence. It's not about being snobby, it's about how trashy your country's accent is/isn't ;P

I think the point of duct tape coding has been missed - just because you're on a tight deadine doesn't mean you should write dodgey code. I don't see it as being an acceptable excuse. I've recently been involved on a project with an insane deadline where the developers did some of the worst coding I've ever seen. Their excuse - the deadline was too tight & they needed to get it done. The end result of all their duct tape coding, was that after "completing" the code, they then had a ton of bug fixes to do. Of the total number of hours they spent on the ENTIRE project, over 40% of that was bug fixes. My take on duct tape code is just to do your best to do it properly the first time (I do concede there are times when duct tape coding is a necessity. I am guilty of doing it too, but only in dire circumstances after the customer has explicity been made to understand that it's a short term solution and they are willing to take the risk). What's the point of being able to meet a deadline when your customer thinks your software sucks when they use it? You're killing your own business.

Talk about lazy! Is t really that hard type ()? ;P

Hah! Victory :-D It appears that if you add logging, you find out what the problem is...

        // Instantiate a new Engine object
        Engine engine = new Engine();

        // Instantiate a new FileLogger to generate build log
        FileLogger logger = new FileLogger();

        // Set the logfile parameter to indicate the log destination
        logger.Parameters = @"logfile=" + strlogFile;

        // Register the logger with the engine

        engine.RegisterLogger(logger);

        // Build a project file
        bool success = engine.BuildProjectFile(strProjectFile);

        //Unregister all loggers to close the log file
        engine.UnregisterAllLoggers();

        if (success)
            MessageBox.Show("Build succeeded.");
        else
            MessageBox.Show(@"Build failed. View " + strLogFile + " for details");

Using the above code, I was able to view the log of the issue: C:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft.WinFX.targets(64,7): error MSB4127: The "GetWinFXPath" task could not be instantiated from the assembly "PresentationBuildTasks, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35". This issue in turn needs the following config file settings to be added:

<configuration>
<configSections>
<section name="msbuildToolsets" type="Microsoft.Build.BuildEngine.ToolsetConfigurationSection, Microsoft.Build.Engine, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</configSections>
<startup>
<supportedRuntime version="v2.0.50727" safemode="true"/>
<requiredRuntime version="v2.0.50727" safemode="true"/>
</startup>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Build.Framework" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-99.9.9.9" newVersion="3.5.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
<!-- To define one or more new toolsets, add an 'msbuildToolsets' element in this file. -->
</configuration>

My project builds! :cool:

Someone out there must be able to help me... I'm trying to find/design a way of automating my project's builds, publishing, versioning in VSS etc and I'd like to create an app/script that will obey my command and do in one easy button click, what would otherwise take copious amounts of time & attention. The general idea is: Build a project/solution based on the .*proj files, publish the project with different config settings & install location depending on whether the app is going to QA, Pre-Prod or Production. I would also like to be able to have Source Safe's labelling done automatically. So far, I have found that Microsoft's MSBuild Reference on MSDN is virtually useless ( :wtf: ???), but I have been able to compile a project via the command line using it. I found that Microsoft.Build.BuildEngine looked perfect for what I'm trying to acheive, however, using the following code, I can't get it to build the project:

Engine engine = new Engine();
Project project = new Project(engine);
project.Load(strProjFile);
project.Build();

The Build method on the Project keeps returning False - no error, nothing. (Before you ask, yes, the path to the project file is correct - the same file builds fine through VS2008 as well as MSBuild) (Oh, and again, Great Job Microsoft on the crummy documentation) If anyone has an idea of where I am going wrong, please, please, please! Let me know :-)

The scary thing is that I work in the major capital of my country... One of only 2 major IT towns. We're not in some backwater hick town where you would expect low quality developers.

Can't be that serious a problem if you can still post..?

Having recently been plagued with a junior developer whose coding doesn't seem to be improving (even after working for close to 3 years :wtf: ) and interviewing a bunch of people who despite extensive programming experience, still cannot complete a very basic coding test :confused:, I've decided to investigate what skills the coding community reasonable think that Junior, Intermediate and Senior developers should be capable of... Opinions please?

We have development, QA and production environments (at a minimum). Developers are banned from using their own local version of the databases - they either use the central development database, or nothing. Updates are made directly to development database as we work and scripted out with a date and release stamp. That way each developer is working on the most current version. When development gets uploaded to QA, we run the collective database scripts for everything that's changed since we last updated QA. I do find though, that this is tedious and you have to keep a hawk eye on fellow developers. I've been planning to write my own DB comparison tool which will script out the differences between to databases... Recently discovered Red Gate's SQL toolbelt though (awesome product) which does an excellent job of scripting the differences (and a host of other nifty features), but it' price is a bit prohibitive so we won't be using it past the trial... :^) :^)

LOL :-D I'm thinking of changing my job description to Salvage Consultant ;P

WTF!!!???? :omg: I think I might be close to speechless. Has the man never had a blue screen of death and gotten annoyed? Never thought I'd hear of some genius campaigning for application failure...

I think the worst projects to take over are those similar to the one I'm currently stuck with : It's a relatively small & simple... in theory. What complicates it is the fact that it's been through serveral developers already :mad:, is in a mix of C# and VB, uses various versions of the framework, is reliant on heaps of 3rd party DLL's, uses a 3rd party data access and business logic layer classes that are enormous & difficult to understand, there are no business requirements documents for it, it has no technical spec, the database uses a mix of naming conventions... I could go on. Oh, and if that wasn't enough, the developer that was working on it is AWOL :wtf: so no support from there...