Wow - I have been a fan of Redgate for a while. I have used some of their tools in the past (Ants, Sql Compare). In the past I have liked Apex SQL Edit for my SQL Server specific SQL Coding. Well - now Redgate is offering a free SQL Editor here. This comes via my pal John.

Gotta love free stuff;

Chris

I just wanted to make a few quickie comments on mock frameworks. I have been using Rhino Mocks daily. It is great. In the past I had tried NMock and just found it too clunky.

In short - NMock leaves you with a lot more ’stringy’ stuff to deal with. Rhino is MUCH more in the language. You type normal code. Your refactoring tools work. Your IDE helps you, etc.
The purpose of using a mock framework is basically so you can just work on testing the CUT (class under test). The CUT should usually be the ONLY concrete class in the test. This all works when you are practicing IoC. When you are using IoC - you pass in dependencies from the outside. When you do this - and you are seperating your interfaces from implementation - you can pass mock interfaces to your CUT. Once you do that - the mock can act as a spy.

1. The mock lets you wriggle into code branches so that you can test pieces of the code that are otherwise difficult to get to.
2. The mocks make your tests simpler. You do not have to instantiate lots and lots of classes correctly - you just set up interfaces and expectations and you are good.
3. The mocks make your tests more stable. You do not have to worry about changing test data etc.
4. The mock can act as a spy and tell you if it is being treated as you expect while it is ‘on the inside’

This used in conjunction with a code coverage tool (like Clover or NCover) helps you to really work your tests to cover your codebase fully.

Carry this over to the Java world - Rhino is much more like EasyMock which I am now writing some tests with. I had formerly used JMock (sort of like NMock in usage) - but I just replaced my jar reference and updated several tests. The tests are immediately more understandable, cleaner and therefore - better.

More another day - Maybe I will get around to posting comparison examples.
Chris

Well, I have often complained to my teams that “you should never try/ catch everything - and eat it up without letting anyone know”. Now - I have an example from a current project where I found some scary code this week. Thankfully this is not representative of the entire codebase.

Do you see what we have here:

This is a friendly recursing stack exploding problem. If we get ANY exception during the ‘try’ block - then the desired effect is just to set the _issuerID to a default value - 0. However - due to a ‘typo’ the call actually does what??? It calls back to the same property getter, then - the same thing happens again and again and again and again… you get the picture.

To make matters worse - lets look at another bit from this 1 line try block…..

Now - if we were to go through the exercise of delving down into all the calls in the _fullTrade.InstrumentID - we would see the same lovely pattern of - “try/ catch everything eat it”. This means that when we call that property, We get even more eaten exceptions that we are unaware of.

Now - lets take this and look at the real effects of this: Lets say that we load 1000 instances of these objects. Then lets say that we need to put all 1000 of these on the screen somehow and we call this particular property. If were to make 1000 calls like this and all 1000 calls threw and ate 6 errors - then we are ‘eating’ a hidden 6000 thrown exceptions. You witness my dismay herein.

In any case - the argument that I was presented with by the perpetrator was; “it makes the code easier to read to not have all the ‘precondition checks’ etc. before just executing the 1 line of code”. That is an admirable goal - to have code that is easy to read. This must be measured with the desire to not throw and eat 6000 exceptions.

Thankfully - someone was nice enough to put in this recursion error that I happily found and expelled. In addition to the joy of killing a bug - I got to purge a bad practice from the project - NO EATING EXCEPTIONS BLINDLY!

-Chris

While reading Sam Gentile’s blog today I came across an article regarding the SCBAT (Smart Client Baseline Architecture Toolkit) and GAT (Guidance Automation Toolkit). I was also discussing this stuff this morning with my friend and collegue Marc. In any case - this stuff reminds me of something I had advised doing (and have begun doing) for a current project. It also reminds me of something in Rails.

The essence of all of this stuff:

You have some application patterns, structures and practices. You want to create all the ’stuff’ you need to use the architecture pattern effectively and efficently, with as little confusion as possible.

For example:

In the now famed Rails web development framework - when you want to create a new project, new view/ controller etc, you just issue some command line .. commands.

For example - to create a new application you can issue a command like:

rails path/to/your/new/application

This will create the folders, base files, etc for your new web application: folders for views, controllers, models, etc. You can also use the rails generate command to create new controllers etc. like:

rails script/generate controller SomeController

Now you have the basics of your Rails application.

SCBAT with GAT

Now - looking at the SCBAT - these great fellows are trying to do is to allow you to enter some data - and it will spit out all of the folders, code etc to make a compliant CAB application. This automates away all of the grunt work, it makes it clear what is needed and it provides the guidance needed to use the frameworks. This is what Sam is talking about in his post here. Cool stuff - making it easier for the team to work effectively with the frameworks.

Frameworks/ System architectures for non-trivial applications are complex. It is a fact of programming life. That being said - doing as much ‘Guidance Automation’ as possible sets the team up for success and takes away increasing amounts of potential error.

Prototype Spiked for a current project as Guidance Automation

I will be leaving my current project (a credit derivative trading smart client application) in 6 weeks. I will be going to a new project (FX options trading stuff). As I have been trying to set up the team I am leaving behind up for continued success using the application infrastructure we have developed - I considered making a custom sort of code generator that functions as these other GAT type things/ Rails type things do… it would take the basic data and go create all the classes, events, folders, etc needed to use the framework effectively.

A screenshot of the basic code generator.

In a few hours I was able to create an application that would take in the information about what the View was to do - and to automate the creation of many classes needed. Since we are using a Model/ View/ Presenter pattern where the View communicates with the Controller via events, there is a set of pattern classes that we can simply create if we know what the view/ controller are trying to do. Hopefully before I leave here - I will be able to leave the team with their own custom Guidance Automation type applicatio that will help keep them on track. This was in truth inspired by how rails works. I am looking forward to using CAB, SCBAT and enabling more and more code generation and other types of guidance automation.

-Chris

Object oriented software development is something that takes people time to get. Often I find myself pointing people to this this article to sum up why I am doing or something, why something feels right or wrong to me.

This is not a new article - I just find myself pointing people to this better explaination than I could give on more and more occasions.

Summary of principals:

The Open Closed Principle (OCP) ?
A module should be open for extension but closed for modification.

The Liskov Substitution Principle (LSP) ?
Subclasses should be substitutable for their base classes.

The Dependency Inversion Principle (DIP) ?
Depend upon Abstractions. Do not depend upon concretions.

The Interface Segregation Principle (ISP) ?
Many client specific interfaces are better than one general purpose interface

The Release Reuse Equivalency Principle (REP) ?
The granule of reuse is the granule of release.

The Common Closure Principle (CCP) ?
Classes that change together, belong together.

The Common Reuse Principle (CRP) ?
Classes that aren’t reused together should not be grouped together.

The Acyclic Dependencies Principle (ADP) ?
The dependencies betwen packages must not form cycles.

The Stable Dependencies Principle (SDP) ?
Depend in the direction of stability.

The Stable Abstractions Principle (SAP) ?
Stable packages should be abstract packages.

So…. I spend most of my day typing C# code for the past several years. This is of course not to mention running dev teams to ‘get the job done’, being a husband, dad, etc. I also spend time writing Java code, Ruby code, when I need to - C++, etc, etc - i will spare the list. That all said - there is so much debate lately regarding dynamic vs static typing…. I think that there are some missed points in these debates as I have been experiencing while writing my C# to Java converter (lets call it Hydrogue).

Many of the ‘debates’ regarding static vs dyamic typing seem to have left out much of what my experience tells me are key differentiators. Most of the dynamic language fans say:

“Type errors are such a small part of the error spectrum - why be burdned by type constraints???. Focus on unit tests.” Sounds good - take away the ‘constraints’ of strong typing.

But:

1. Dynamic languages force you to know the implementation - or the type expected - how about that! This is the biggie in my mind. BREAKS ENCAPSULATION/ INFORMATION HIDING.
2. When data modeling - I WANT to know the types/ subtypes etc of aggregate objects (see 1st bullet too - I must go look around to see the ‘interface’ of an object/ sub-object)
3. Tools have a hard time helping
1. Refactoring support
2. Intellisense like support
4. “Duck typing is fine” - but it does NOT help me when I need to expect certain ‘interfaces’ will be passed into a routine. (related to bullets 1,2)

The worst of all of these has been point 1. Without knowing types of objects - I am constantly having to run around and look at routines innards to see what methods they will be calling on my objects I pass to them. If I pass an interface reference - this is effectively saying - you can call only these things on me - and I expect it. With out this notion - I need to go look inside and see what the client class will call…. thus breaking down encapsulation.

It is hopeful/ possible/ likely that a dynamic language IDE will support statement completion (Ruby Eclipse does MINIMALLY). When this happens - it will be beyond helpful. I find that even though it is ‘more code’ I can turn out more code in an automated fashion using IDEs that support refactoring, intellisense, AND INTELLIGENT find usages/ implementors, etc.

That all said - I LIKE Ruby. Writing Hydrogue has been fun, educational and useful. Just pouring over the C# language spec @ msdn has been worth the work as my understanding of the bowels of C# from the inside out have gotten all the more clear. The extra Ruby education has been great - and getting everyday back into Java has been great as well. I will just say that - either IDEs have to get smarter, or I do to be as productive with a dynamically typed language as I am with a strongly typed language.

My thought was, and continues to be - the right language for the right job. I am not convinced (as many others seem to be) that dynamic languages are ready to do the things that C#/ Java do (much less C++). Perhaps I will be more convinced to use Ruby for ‘bigger’ or ‘more complex’ applications eventually. I will keep working with Ruby and hopefully by the time the tools catch up - I can contribute to the community of developers that start with them…

Enough;

Chris

Inspired by an article linked @ SlashDot …

I got to thinking about developing software for end users, as I often do….

My current project is a desktop credit derivatives trading application that ~900 users globally use (not too many I realize - but enough to be interesting). When I 1st came on the project the 1st thing that struck me was how poorly designed the user interfaces was - it was NOT apparent how to use it at all. We did have the opportunity to work on that… I have spent the recent time working on a new ‘trade blotter’ and general UI application architecture. One of my primary goals is, and will continue to be - making the UI feel like home to the end users. Making the UI really support the habbits, quirks and needs of the end user in a way that is not just ’some fluff atop the “real” program’. The UI is the real program as far as a user goes. All the nice ‘backend processing’ in the world is great - 100% needed, but the UI is where you can get strong percieved wins from your end users.
Here are a few links for those folks that want to keep up on UI design practices and patterns. So many software developers consider the UI tier to be the fluff part that means the least. Unfortunately - the users (that pay for the development generally) think the opposite

welie.com
designinginterfaces.com (book site with refs)
Sari Laakso’s patterns
..newer Yahoo!s UI patterns site

I will also mention that after a few years of doing larger class desktop application/ smart client development - I have seen the same issues and constructs come up over and over. 2 frameworks abstract smart client/ rich client/ desktop applications extremely well.

The 1st is the latest Microsoft CAB (Composite UI Application Block). This specifies excellent abstractions for common rich client application needs. When I was going over the internals - again and again I found myself saying ‘yes - we did that too’ or ‘wow - we solved that issue differently - you guys did it better!’. I will also note the Infragistics 2006.1 works directly with the CAB. Excellent move on their behalf!

The other is the Eclipse RCP (Rich client platform). I have been really studying out the guts of eclipse - the RCP in particular (while reading - The Java Developer’s Guide to Eclipse, 2nd Edition). What an excellent set of APIs these folks have come up with. The plugin architecture and the notion of ‘contribution based extension’ are particularly excellent.

-Chris

useful programming ‘quick references’ for several languages….

If you jump into perl 1x per year - or the same for MFC, or the same for using VI, admin commands for solaris, and many more - this is for you

-Chris

Some free form thoughts:

For a long time - I have thought that
the web browser was interesting. It is a fairly primitive set of UI
components that you can declaratively ask to be rendered - via HTML/
CSS (for the most part). You also have the option of interactively programming to
the browser’s API - mostly in JavaScript. The powerful part was/ is
that you are sending text across the wire from 1 machine to the next
- declaring to the browser what to do…..

So - the issue is/
has been that the browser experience is not as ‘rich’ as a desktop
application … AJAX - SchmaeJax - I know… but it is not as rich -
period. Oh sure - there have been valiant efforts - Flash, Mozilla’s
XUL, etc - but in essence, but still - we are declaring our intent to
a web browser - an application of limited scope - inside a much more
complete operating system….

The next step is to do the much
same thing - send declarative intent - over the wire - BUT:

1)
To a richer rendering engine (the web browser in browser era)
2)
With a richer programmable API (the DOM API / browser API in browser
era)
3) With more robust programming language possibilities
(JavaScript in browser era)

So - we send declarative intent to
- the OS. This is accomplished with an extensible markup language
that can reach into more domains than HTML did/ can. HTML is a
limited domain markup language. One XML document can contain multiple
over-layed namespaces of information that can be consumed in
differently by different aspects of the interpreting application.

If the browser is just a subset of the
computer’s (OS’s) functionality that can have it’s behavior invoked/
declared, the end of that chain of logic is that the OS should just
allow it directly - the superset of functionality. With XAML -
Microsoft brings some of this to the table.

1)
richer rendering engine (the OS - WPF, Expressions stuff, GDI, etc. in the post-browser era)
2) richer programmable API (.Net framework in the post-browser era)
3) robust programming language possibilities
(C#, Vb.Net, etc.)

Granted -
security will need to be of central importance in this scenario -
where the OS can be so controlled- but that aside - this is the
logical step. I do not question this progression happening the
question is - what other vendor(s), OS’s, etc. will support this type
of idea? Maybe something like:

1)
richer rendering engine (Linux with some core rendering engine …. SVG based perhaps)

2) richer programmable API (KDE, QT, more abstraction of the raw Linux functionality from elsewhere)

3) robust programming language possibilities
(Java, Ruby, Something else…)

Interesting - I admit - these are fairly off the cuff thoughts, you never know what will happen.

What Microsoft is doing with
Expressions and that realm of stuff is also part of the next
generation of application development – breaking away from the
classic looking application. Flash is a beautiful looking thing in
browser world. It is still limited. An application with the full
power of your computer looking like a flash application could –
will be a lovely thing. Making 3d user interfaces will become real
soon. Making really animated – lush applications will be real soon.
In this space – an SVG player may come into play.

A Windows Virtual Machine?? I wonder if
at some point – computing resources (hard drives, memory, etc) will
be so commoditized that all OS’s will basically be able to simply
access a sort of grid of resources…. Then all “OS’s” will be
something like a virtual machine atop generic resources. They are
then just set of APIs for accessing truly common resources and
abstracting functionality into a software computer. The resources are
the same – the abstraction on top of them – the software is what
is worthy to developers. Java was a better abstraction of the
computer resources than C APIs (in my way of thinking) for
non-primitive operations. C# is even a slightly better set of
abstractions (delegates, events, etc are really better than Java –
I am sorry. I DO love Java – I am just being honest). Anyhow - it is
really not too far fetched to envision Windows or something from MS as
being a portable Virtual Machine that could run like a JVM etc….
anyhow………

Anyhow – I have rambled..
-Chris

From: sun
Why have code conventions? Code conventions are important to programmers for a number of reasons:

• 80% of the lifetime cost of a piece of software goes to maintenance.
• Hardly any software is maintained for its whole life by the original author.
• Code conventions improve the readability of the software, allowing engineers to understand new code more quickly and thoroughly.

From: My fav

• Avoidance of errors/bugs, especially the hard-to-find ones.
• Maintainability, by promoting some proven design principles.
• Maintainability, by requiring or recommending a certain unity of style.
• Performance, by dissuading wasteful practices.
• Rules and recommendations are given that promote reliability and maintainability.

From: ambysoft

From: macadamian

From: chris-lott

From: extremeprogramming.org