Rants Tagged with “Programming”
<< < 1 2 3 4 5 6 (Total Pages: 6/Total Results: 59)
via The Serverside .NET!
Enjoy
I've spent the last few days extending Reporting Services for a client. I am very impressed by their open model, I just wish that there was more 3rd Party support for designers. The
Visual Studio .NET designer is just ok, not great. And a conversion from Crystal to RDL would really rock.
Richard Blewett (of DevelopMentor fame) has a great piece on the insidious nature of this combo. Take a look, its worth it to understand what's going on.
While trolling the DevelopMentor .NET Lists, William D. Bartholomew mentioned a new UML tool that does round-tripping to and from code. I've used Rational's (IBM's) XDE before to do this, but it is buggy and hates source code control.
Sparx Systems' Enterprise Architect is a great tool. It doesn't work in the VS.NET IDE, but works with it very well. I like several important things about it:
- It does roundtripping of the code with no discernable breadcrumbs.
- It is fast and interfaces with VS.NET pretty clearly.
- It costs next to nothing ($189 for the Professional Edition, and $95 for the VS.NET connector).
- Handles the full spectrum of UML Models (Use, Case, Component, etc.)
- Handles Database Modeling fairly well.
- Auto-Layout actually makes decent looking diagrams.
- Knows to connect objects that have references to each other.
One of the features that really stands out is being able to see the model and code at the same time. Changes to the model affect the code and vice-versa:
I was really surprised by the price, since Rational's XDE is $2,500...nearly 10% of the cost for more of a product.
Go get a copy before they figure out they've under-priced it!
Part 1: Coupling Objects
I have been having a conversation about coupling of objects at the interface level. While I am not a fan of coupling objects together, I would like to be able to shortcut some factory code to make the interface be more intuitive. For example, here is code that decouples the interface:
class Foo
{
// ...
Guid _barID;
public Guid BarID
{
get { return _barID; }
}
}
Foo foo = new Foo();
Bar bar = Bar.GetBar(foo.BarID);
Whereas I don't want to tie the objects together, but simply call the factory (the GetBar method) within the Foo class to make getting objects easier and more intuitive. For example:
class Foo
{
// ...
Guid _barID;
public Guid BarID
{
get { return _barID; }
}
public Bar GetBar()
{
return Bar.GetBar(_barID);
}
}
Foo foo = new Foo();
Bar bar = foo.GetBar();
Not much different, but it makes the interface a bit clearer about how to get a Bar from Foo. This assumes some information about how assemblies are built. This does not work well if you have circular references in different assemblies. But in most of the project I have worked on, we use larger assemblies so this happens much more infrequently.
Part 2: Assembly Loading
As I was discussing it, the topic came up of which is better, more small assemblies, or fewer large assemblies. The argument comes down to this:
More small assemblies: Loading less code into memory at a time
Fewer large assemblies: Fewer Assemblies means a better working set.
It is my memory (though possibly flawed) that larger assembies really don't worry about loading lots of code because the real code loaded in the JIT'd code. JIT'd code is certainly created as necessary on a method by method basis. The part my memory is more unsure about is whether all the IL or just the Metadata is read into memory. If all the IL is read in, then the smaller assemblies position has a point.
Any feedback (whether as comments or e-mailed to me directly) is welcomed.
I lost all my NewsGator feeds so I was tracking down my favorite people...and of course Tim's one of them. It was fun...Here's the trail I followed:
Luckily I love clicking links...
I just joined Magenic Technology as a Consultant and they put me at a client right away. Its been so long since I commuted to a job that it was kinda wierd getting up at 6am and driving for an hour. After a couple of years of getting up at the crack of noon and working till late into the night, this is a great change...of course after a couple weeks of this, I may not like it but we'll see.
Right out of the box I am getting to work with Rocky Lhotka's CSLA.NET business object framework. If you know me, you know I have been living and breathing DataSets for several years now. Rocky and I have always been at the opposite ends of the business object discussion. I know there are pros and cons to both of our points of view. I suspect as I use his framework over the next few weeks that my opinions will either strengthen or weaken. Keep tuned in...
How I wish I were there. Evidently the Yukon Public Beta and the VS.NET 2005 Beta will be available. Get them while they're hot!
For all attendees, skip the Heiniken Museum...you're gonna want to remember this convention! TechEd will be very “lekker” this year.
I hate to blog about a blog, but everyone in software development should read this post from Don Box's blog. Thanks to him I now have a name for this. Too many times over the past five years have I been stuck in the middle of the “Academic” vs. “Pragmatic” discussion of some technology.
While branching out and doing something new and risky is occasionally groundbreaking, most of the time it just makes it harder on people who make thier living slinging code. I like to think of it like building a car. Sleek lines, computer controlled ignition, GPS are all neat features, but if it isn't reliable transportation 99.999% of the time, it will be a lemon.
To me it is pertinent to coders that work in the trenches to understand that magical middleground between over and under engineering. When I started development eighteen years ago, the push was small, fast code to deal with the limitations of the hardware of the time. Maintainable code was a laudable goal, but small and fast always won in the end.
Soon after, it was software that could be designed to be tweaked to handle every situation that you could imagine. Ideas like pluggable architectures and components were the buzzwords of the day. In fact, many of these solutions were over engineered to handle solutions that would never come to pass.
In the last five years, things have changed a bit. I now appreciate agility over flexibility. With the daily use of managed languages (Java, .NET, etc.) we can work with code and change underlying fundaments much quicker than before. Engineering enough of a solution to work well; designing interfaces that are flexible; and writing code that makes refactoring easier are the goals of most of my work these days. Its not to say that performance and scalability are not important; they are. Its just that it no longer makes sense to be penny wise and pound foolish.
