Scott Bellware [MVP]

Scott Bellware [MVP]

Home
Contact

The Lounge

Syndication

Archives

Sort by: Most Recent | Most Viewed | Most Commented

SetUp and Teardown Methods in Test Classes

Jim Newkirk is blogging about the down side of setup and teardown methods in test classes, and why you shouldn't use them. Setup and teardown methods attract entropy faster than an outsource programmer with his first patterns book. Jim's new framework , xUnit.NET doesn't have primitives for...

Published Fri, Sep 21 2007 10:39 PM by ScottBellware

Filed under: Agile, Test-Driven Development, Design, Solubility
SOA, BI, Events, and Push

Arnon talks about event-based BI: http://www.infoq.com/articles/BI-and-SOA This is exactly what I've been thinking about for our Rails / .NET integrated solution. I thought that this architecture would be received as heresy. I'm stoked to see that folks like Arnon are out in front (of my efforts...

Published Fri, Sep 21 2007 11:27 AM by ScottBellware

Filed under: Design
My Credo

I never believe that anything I do is correct until I subject it to the to inquiry, "How is this wrong?" I believe that everything I do is suspect. This is my point of departure for every single line of code I write. Over the past few years this inquiry has become instinctual.

Published Wed, Sep 12 2007 1:46 AM by ScottBellware

Filed under: Agile, Design
Write Specs to the Experience Rather than the Implementation

This post is a place-holder for a longer post with examples, but I've been sitting on this one for months, so I thought I'd just toss it out there for what its worth. Unit testing practices often make no bones with writing test names that describe the implementation. You see signs of this when...

Published Sun, Sep 9 2007 9:29 PM by ScottBellware

Filed under: Agile, Behavior-Driven Development
TDD is About Not Knowing

The greatest obstruction to grokking Test-Driven Development is the assertion that a developer makes to himself about how right his plans are for a solution. The essence of TDD is a suspension of our belief that we know what we're doing, and a submission to a structured process of exploration and...

Published Sun, Sep 9 2007 7:32 PM by ScottBellware

Filed under: Agile, Test-Driven Development, Design
Agile Doesn't Have the Answers

Agile doesn't have a One True Answer for software development. Agile gives you a structured way to seek feedback on your on-going exploration. A predisposition to believe in a One True Answer for anything is one of the worst hindrances to grokking agile development. Because many methodologies that...

Published Sun, Sep 9 2007 7:03 PM by ScottBellware

Filed under: Agile
Smurf... er, Scrum

I started doing something recently that I wish in retrospect hadn't occurred to me, because now I can't stop. I was at a presentation recently where the speaker used to word "scrum" as a prefix for everything that his team does. At some point it occurred to me that, for some folks,...

Published Sun, Sep 9 2007 6:32 PM by ScottBellware

Filed under: Agile
Yesterday's Agile

Been thinking about what's next for agile development... TDD is still young, but not as young as it was. BDD is creating greater artifact, process, and team unification opportunities for test-first programming in an agile process. Some of tomorrow's practices are already starting to appear, but...

Published Sun, Sep 2 2007 11:16 PM by ScottBellware

Filed under: Agile, Commentary
Monorail vs. Rails Isn't a Meaningful Question

Monorail vs. Rails doesn't seem like much of an interesting question. In our work recently at Dovetail, we found that a much more interesting question is something like, "Should we be building forms-over-data web apps on .NET?" If I have to build a web app on .NET, I'd use Monorail...

Published Tue, Aug 7 2007 8:55 PM by ScottBellware

Filed under: Ruby and Rails, Web, Design
Accountability: Behavior-Driven Development's Other Leg

Accountability is a huge part of agile development. Behavior-Driven Development (BDD) drives accountability deep into development by having developers maintain the language of the business through the continuum of development process artifacts from user stories, through specifications, and into the application...

Published Tue, Aug 7 2007 2:23 AM by ScottBellware

Filed under: Agile, Behavior-Driven Development, Design
Is this What it Means to be an MVP?

John commented: Dude, if you're going to continue to take potshots at MS every chance you get, why do you want to be a *Microsoft* Valued Professional? You're not valuable to them at all at this point. It's like a BMW dealership hiring someone that wants to talk about Mercedes all of the...

Published Wed, Jul 18 2007 1:58 AM by ScottBellware

Filed under: Community, Commentary
Are Rails' Model Objects "View Model Objects"? (and some questions about non-generic subdomains)

Should we assume that the model objects that we build and use in user interfaces to be reusable in other application layers and services? I'm still chewing on the idea of Ruby on Rails as a web front end to a clean data model where the heavy-lifting, enterprisey part of the app is written on .NET...

Published Tue, Jul 17 2007 12:06 AM by ScottBellware

Filed under: Ruby and Rails, Design
Considering Ruby on Rails and Interop: Developer Skills

We sell an enterprise product, and that product is customized by our customers. More precisely, our product is customized by day coders. If I put Monorail and Windsor in their hands and tell them to go forth and code IoC and ORM with NHibernate after giving them some guidance and training, will they...

Published Mon, Jul 16 2007 12:06 AM by ScottBellware

Filed under: Ruby and Rails, Design
Considering Ruby on Rails and Interop: Model Code and Data Access

I'm concerned that if I build my application's front end on Ruby on Rails that I'll end up needing to create and maintain yet another model layer and data access layer for the parts of the application that don't run in the web process, like out-of-process event processing services, for...

Published Sun, Jul 15 2007 10:43 PM by ScottBellware

Filed under: Ruby and Rails, Design
Considering Ruby on Rails and Interop: Transactions

My usual reason for outright dismissing an app with a Rails front end centers on System.Transactions ability to continue a distributed transaction that was started in a web app process into a workflow. Since WF supports System.Transactions through compensating activities, I don't want to give up...

Published Sun, Jul 15 2007 1:10 PM by ScottBellware

Filed under: Ruby and Rails, Design

1 2 Next >

About CodeBetter.Com

CodeBetter.Com FAQ
Our Mission
Advertisers should contact Brendan

Subscribe

Google Reader or Homepage
del.icio.us CodeBetter.com Latest Items
Add to My Yahoo!
Subscribe with Bloglines
Subscribe in NewsGator Online
Subscribe with myFeedster
Add to My AOL
Furl CodeBetter.com Latest Items
Subscribe in Rojo

Member Projects

Sarasota Web Design - David Hayden
Patterns & Practices - David Hayden
dotMath - Steve Hebert
Structure Map - Jeremy D. Miller
StoryTeller - Jeremy D. Miller
The Code Wiki - Karl Seguin

Friends of CodeBetter.Com

Red-Gate Tools For SQL and .NET
Telerik
ComponentArt
VistaDB
JetBrains - ReSharper
Beyond Compare
.NET Memory Profiler
NDepend
Ruby In Steel
SlickEdit
SmartInspect .NET Logging
NGEDIT: ViEmu and Codekana
LiteAccounting.Com
DevExpress
Fixx
NHibernate Profiler
AForge.NET
Unfuddle
Balsamiq Mockups
Scrumy <-- NEW Friend!

Community Server (Commercial Edition)

Scott Bellware [MVP]

Sponsors

The Lounge

Syndication

Recent Posts

Tags

Archives

Advertisement

SetUp and Teardown Methods in Test Classes

SOA, BI, Events, and Push

My Credo

Write Specs to the Experience Rather than the Implementation

TDD is About Not Knowing

Agile Doesn't Have the Answers

Smurf... er, Scrum

Yesterday's Agile

Monorail vs. Rails Isn't a Meaningful Question

Accountability: Behavior-Driven Development's Other Leg

Is this What it Means to be an MVP?

Are Rails' Model Objects "View Model Objects"? (and some questions about non-generic subdomains)

Considering Ruby on Rails and Interop: Developer Skills

Considering Ruby on Rails and Interop: Model Code and Data Access

Considering Ruby on Rails and Interop: Transactions