I've been playing around with IL lately and I think I've figured out a way to inject any IOC container (i.e. LinFu, Ninject, StructureMap, Autofac, etc) into any legacy application without changing the original source code. Would any have a use for this, or is this just a weird idea? (EDIT: I know this is bordering on a programming/article question, but this isn't exactly your typical "SEND CODEZ PLZZ" question, so I figured the lounge would be the best place to get some opinions on this... :))

Do you know...LinFu?

ied wrote:

I'd suggest considering Plasma also.

I'd love to get a Plasma TV, but alas I'm still in a 3rd world country, and in practical terms, they don't broadcast anything here that would even require the picture quality of a Plasma TV, so for now, it's either I stick with an LCD TV, or just get myself the LCD projector.

Do you know...LinFu?

Christopher Duncan wrote:

I've had a projector system for years, and here's something to consider. In addition to the fact that the bulbs are pretty expensive to replace (~$300), when they go it sounds like a small explosion and the last one that went showered the couch and floor with a fine mist of powdered glass. Never again.

How long did your projector last before the bulb blew itself out?

Do you know...LinFu?

PIEBALDconsult wrote:

Ummm... both?

I can only buy one of them--buying both of them would be a waste of money.

Do you know...LinFu?

I was thinking of buying an LCD projector (720p) with an HDMI input and then turn one of the walls in my room into a projection wall so I could make my room seem like a movie theater when I turn all the lights out. The problem is that the LCD projectors here in Manila cost about the same as buying a small 32-inch LCD TV with a 1080p resolution. So anyway, here's the question--in your opinion, which would give a better picture quality--the LCD TV, or the LCD projector? I already have my 5.1 speaker system set up in the room, but I can't decide which option is better. The thought of having a wall-sized display is geekgasmic, but then again, going for the 1080p might give me the same picture quality with a tighter screen. What do you think? :)

Do you know...LinFu?

Maruf Maniruzzaman wrote:

We already have some good one- Spring.NET, Unity, Castle and more- How much does this worth? Waste of time?

As someone who has written no less than three of them (Click here[^], here[^], and here[^]), I'll have to say that writing your own IOC container can be a very enlightening experience, but be prepared to sacrifice hundreds of hours of your time to put one together. If you're going to build an DI/IOC framework just for the sake of learning how DI/IOC containers work, then go for it--but I don't recommend writing one unless you need to do something that the seven (?) other DI/IOC containers don't already do.

Do you know...LinFu?

public void InSpace()
{
try
{
// Scream...
you.Scream();
}
catch(Exception ex)
{
// No one can hear you...
}
}

Do you know...LinFu?

Is a post that lets you put in code snippets or something? Man, I think I've been gone from CP way too long... :)

Do you know...LinFu?

peterchen wrote:

How do you apply programming skill to lose weight? Lock the fridge with an encryption algorithm you can't crack?

Not quite. A simple example would be to write something that would keep track of your workouts and your caloric intake, and it would still be up to you to do the rest of the work so that you can lose the weight.

Do you know...LinFu?

Clickety[^] :)

Do you know...LinFu?

In the debate of nature vs nurture, I believe that it's all a matter of configuration, with knowledge and skill as the software, and neurological brainpower as the hardware. Some people really have to work hard to get the knowledge and skill working on their biological 'hardware'. Others can easily attain the same knowledge and skill because their brains just might work faster than others.

peterchen wrote:

Is this distinctness unique for programming?

So to answer your question, distinctness isn't unique for programming. Not every brain out there can comprehend the 'software' (or attain the skill or knowledge) per se, and since no two brains are alike (even among twins), it's not a stretch to say that no two brains will perform at the same rate, much less be able to comprehend the same information at the same rate. I read somewhere that it takes about ten years to master a skill, and in those ten years, the human brain goes through profound changes that make it easier for a person to perform that skill effortlessly. So when you look at a person and see that they "just don't get it", it could just be that way because they currently lack the knowledge or the brain capacity to understand that particular skill. That assumes, of course, that they're not literally diagnosed as mentally retarded (i.e. IQ >=100)

Do you know...LinFu?

Pete O'Hanlon wrote:

Have you looked into Pex[^]? It's an interesting concept, to say the least.

From what I can tell, Pex looks like a brute-force solution to unit testing--it solves some of the coverage problems in TDD by attempting to quantify every possible input and output that might come out of a single method. There's two problems to this approach: 1) Observability, and 2) Isolating the component to be tested. The first problem of observability has a lot to do with the software engineering equivalent of the Uncertainty Principle--how do you observe the behavior of an app without having to modify it? For example, if I wanted to test the DAL of a legacy app and that application has a tightly-coupled architecture, how do you verify the behavior of the DAL without modifying its architecture to support unit testing? With Pex, you can only test the components of an architecture if their behavior can be "observed" by the unit tests generated by Pex; however, in a legacy app, you might not have the luxury of modifying the architecture to support those unit tests. The isolation problem rears its ugly head when you have legacy code that is ridden with "copy & paste" code. In order to use automated unit testing (much less Pex), you would have to refactor out the duplication and then mock out the components around the component to be tested, and then test the component itself. Once you have the component isolated, it is then (and only then) that you can throw Pex at it and have it do its brute-force approach to finding holes in your code. The problem with using Pex with legacy apps is that the approach might be too invasive. In the current state of automated unit testing and TDD, this is akin to giving bypass surgery to a patient who just wants a medical checkup. What I want to do is diagnose the patient (per se) without killing them in the process. IMHO, we're practically in the Dark Ages when it comes to diagnosing legacy apps, and that has to change.

Do you know...LinFu?

RChin wrote:

I also hook it up with my laptop and use it as a huge screen Smile The HD resolution is crystal clear and sharp as hell !

What type of connection do you use to connect the HDTV to your laptop? And more importantly, how does the VGA output look on your TV? does it still look clear even though it's not DVI?

Do you know...LinFu?

I went out and bought myself a small 32" LCD TV, and needless to say, the thing is practically huge in comparison to my old 20-inch monitor. I've never really had an LCD TV before, and I just noticed that my new TV has an DVI/VGA plug in the back of it--and considering that the 32" TV has a resolution of 1900x1024 (or something like that), it might just be a kick-ass monitor--but my question is this: If I use it as a 32-inch monitor, is this thing going to kill my eyesight? :P

Do you know...LinFu?

Does anyone happen to know which classes in the LINQ to SQL provider are sealed so I can go about unsealing it and plugging in my own providers? Thanks. :) *evil grin*

Do you know...LinFu?

Mark Churchill wrote:

Hrmmm I'd be assuming you are kinda boned in that case without some real trickery. Most legacy code of this kind I've seen tends to be fairly rigid - definitely no dependancy injection or even factory patterns. It sounds hard.

Without a doubt, it is incredibly difficult--you'd have to find a way to isolate the target component and then "extrude" it so that you can test its behavior without pulling it completely out of a compiled assembly--in essence, it's like refactoring in reverse--albeit in a binary form. It's definitely a black art, to say the least.

Mark Churchill wrote:

Possibly you could do something like post-process the compiled DAL, and replace instantiations of certain classes with your mocked instances, and then run the tests. :S

Actually I'm not too worried about how to replace the classes or methods with mocks--what I'm really looking for is a a common set of testing practices that I can programmatically apply to the portion of legacy code that I want to test. Based on the lack of responses to this thread, however, I can only surmise that there aren't that many people out there that specialize in applying automatic regression tests to legacy code without changing the design--so for now it's more of a pipe dream, but I'll have a lot of fun making it a reality. Thanks for the input, Mark!

Do you know...LinFu?

For many years, I've had a problem controlling my weight, and given the sedentary nature of working as a developer in an office setting, it's really easy to get out of shape and turn into a "blob", of sorts. I was thinking about applying some of my programming skills to losing weight and posting the results here on CP as an article--but I'm not sure if that would qualify as a "programming" article. So anyway, here's my question--do you think something like that would be applicable on CP, or should I just leave something like this to my own blog?

Do you know...LinFu?

There seems to be more than quite a few docs out there that teach you how to do TDD from scratch, but I haven't seen much theoretical work done on "mocking out" and testing existing components from legacy apps--for example, if I have a DAL that's already plugged into my four-year old .NET 1.1 app, is there anyway I can apply post-hoc unit tests to the DAL without changing its design? What I'm really looking for is a catalog of "mocking patterns" that give me solutions to various problems so that I can isolate my legacy components and test them without modifying the design--so my question is, has anyone managed to do this yet?

Do you know...LinFu?

I've been thinking about writing a few more articles for CP, but the problem is that I can't seem to find enough time to write full-length articles. Given my time constraints, I only have enough time to write articles that are two to three pages long. The articles aren't short enough to be just code snippets, and they might not be long enough to get past a "2" or "3" rating. So anyway, my question is this: should I just wait and clump everything together into one big article, or would writing these "micro" articles be a sound strategy? p.s. I could just post these articles on my blog, but I doubt it will get nearly the same amount of exposure as a CP publication. Anyway, what do you guys think?

Do you know...LinFu?

Oakman wrote:

Anyone played it yet? #2 had crashed so many times I finally gave up.

I'm still playing Fallout 3 on my PS3, and man, it's gorgeous. The character generation process alone is worth the price of admission--you basically start from your character's birth (literally) and the process works its way through "flashbacks" in your character's lifetime to determine your stats. At first, I thought it was going to be lame because the action in Fallout 3 is done in real time, but it turns out that they have a combat system called VATS which slows the action down and lets you queue up actions so that you target individual body parts, and if you're a big fan of gore, then you'll delight in watching body parts explode as the game shows you how your bullets rip through corpses in slow motion. :) So back to your original question--is it stable? On a PS3, I'd say yes. Is it worth it? Oh yeah. :)

Do you know...LinFu?