Published book: A Crash Course in Reasoning

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/reason.htm]

Clear reasoning is essential for developers. So, I'm proud to have finished publishing a book "A Crash Course in Reasoning".

 

 

It's a fast read (170+ pages), in plain language. Really it's intended for high school and college students who are looking at basic reasoning skills (i.e. I have kids and I'd like them to eventually read it). However, developers may get a kick out of it too. It covers a broad spread of topics:

• Chapter 1: Introduction

• Chapter 2: Objective Reality

• Chapter 3: Premises

• Chapter 4: Logic

• Chapter 5: Epistemology

• Chapter 6: Communication

• Chapter 7: Psychology

• Chapter 8: Learning

• Chapter 9: Conclusion

Official abstract:

Using images, tables, and constant examples, this book provides a practical and plain-English introduction to reasoning. We start by emphasizing the importance of objective reality. We then explore the different types of premises (definitions, observations, given facts, assumptions, and opinions) that can be built on this rock-solid foundation. From those premises, we can make logical inferences (both deductive and inductive) to arrive at conclusions. We strengthen this process by explaining several epistemological issues. Once the reasoning is clear in our own head, then we can communicate it to others. As we deal with other people, we’ll also need to deal with the psychological aspects that people inevitably bring with them. Finally, thinking clearly for ourselves and with others, we’ll want to apply everything we’ve discussed to increasing our learning and problem solving abilities.

This page will contain updates for the book.

MVC troubleshooting: If the controller doesn't have a controller factory...

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/mvc_troubleshooting_if_the_controller_doesnt_have_a_contro.htm]

I was toying around with the MVC pattern, and I kept getting this error while doing a tutorial:

 

'TaskList.Controllers.HomeController'. If the controller doesn't have a controller factory, ensure that it has a parameterless public constructor.
 

I'm no MVC expert, so I had to poke around a little. Ultimately, what seemed to fix it was making the database connection key in web.config match the key in the auto-generated dbml code.

 

The dbml code was failing on this line (in a file like "*.designer.cs"):

public TaskListDataContext() :
base(global::System.Configuration.ConfigurationManager.ConnectionStrings["TaskListDBConnectionString"].ConnectionString,

mappingSource)
{
    OnCreated();
}

I had modiefied my web.config, so there was no ConnectionString setting for "TaskListDBConnectionString", so that returned null, hence it failed. I needed to update web.config to something like so:

 

   

    name="TaskListDBConnectionString"

    connectionString="your_connection_here"

    providerName="System.Data.SqlClient"/>

 

To troubleshoot, I started stubbing out things one at a time - making an empty solution, downloading the final code, comparing the differences, etc...

 

"I prefer my way of doing it to your way of not doing it"

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/i_prefer_my_way_of_doing_it_to_your_way_of_not_doing_it.htm]

I once heard this quote - I forget the context or who said it - but I really like it. Software Engineering is full of second-guessers and Monday-morning quarterbacks. Many projects seem to have that pessimist who snubs the teams' attempt to do something because it's not as good as that "perfect past project" that they were on. There's something to be said for the developer who just gets it done - even if the code isn't the best.

More Xml Design Patterns

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/more_xml_design_patterns.htm]

 

Last month I mentioned some tips for structuring xml, which could be seen as the start of primitive Xml Design Patterns. Here are three more ideas.

 

Strongly-typed nodes

 

Say you have a node, which can have several different groups of attributes. For example, you're making a test automation DSL, and you need to assert that various conditions are met. You may have a basic assert, a correct-page assert, and a text-search assert:

The schema for this becomes messy - you'll have one node (Assert) with all possible attributes. Your interpreter will need to infer which action to take based on the current attributes. Validating the xml file also becomes error-prone. It's doable, but messy. Compare that to this:

.Page pageName="myPage.aspx" />

.Text textToFind="EmpId123" isRegex="false" isCaseSensitive="false" />

This approach has essentially three nodes: Assert, Assert.Page, and Assert.Text. This effectively gives you "strongly-typed nodes". Your interpreter instantly knows which type of node, and therefore what action it expects and how to validate its attributes. Your schema becomes simpler because each node type has only the relevant attributes. This isn't always the best approach, but it can be a good one in certain cases.

 

 

Serializing complex objects to attribute strings

 

You can serialize almost any object to Xml, but the question is what is the best way to do it? For example, you could serialize an array as a bunch of nodes:

   

        12

        35.5

        40

        9

   

However, this is somewhat bloated. A more concise way is to serialize it to a string, and then store the results in an attribute:

You could serialize an array as a CSV list: "1,2,3".

You could serialize a name-value pair: "name1=value1;name2=value2" (this is what MSBuild does)

You could even have a mini DSL, like the Silverlight path expressions: "M 10,100 C 10,300 300,-200 300,100".

 

The main thing this approach requires is an easy way to serialize and deserialize the object to a string. If you've got that, then this technique becomes very reasonable.

 

 

Abstract complex objects to inner content

 

Silverlight uses Xaml markup to describe the UI. Xaml allows a lot of style markup.

 

You can create a simple ellipse, shading the entire thing a solid blue.

Fill="Blue" />

However, you can also give it a more advanced two-color gradient shade by abstracting the "Fill" markup to the inner nodes of the ellipse. Specifying a single attribute is great when you can serialize all the necessary info to a single string, else you can leverage the more-powerful inner xml nodes (per a Jesse Liberty tutorial).

   
     
        
        
     
  

This allows the best of both worlds - the single-line common case, and the more advanced case.

LCNUG: Gorking the ASP.NET MVC Framework

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/lcnug_gorking_the_aspnet_mvc_framework.htm]

Yesterday, Derik Whittaker presented at the LCNUG about the MVC pattern. I had a last-minute family emergency come up, so I couldn't make it, but it looked good.

This is the fifth presentation at the LCNUG, almost half a year. It's been great to see the new group up and running.

Real life: the leaking window

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/real_life_the_leaking_window.htm]

House repairs provide a lot of good software analogies. Once during a big rain storm, our window started leaking. It was a newly installed window, and it had never leaked before. Well, obviously a leaky window can become a huge problem if left unfixed. So, I went out sometime later, sprayed the window with the hose to try to get an idea of where the leak is (I was not, and still am not, a house repair expert), and to my great frustration - the window did not leak. Of course I wanted to reproduce the problem, narrow it down to the exact cause, and then make a quick fix - just like I would in a software project. I didn't want to rebuild the whole thing.

So, here is a "critical feature bug" (the leaky window), which occurred in "production" (during the actual rainstorm), but I cannot reproduce in my "development environment" (sunny day with my spraying the window with a hose). It was a non-reproducible bug. However, I couldn't just ignore it or look the other way, I needed to ensure that it didn't happen again (given that it's my house, I need to take "ownership" of the "project"). It's the kind of thing that drives a software project mad.

In this case, I just 'blindly" resealed things - checked the siding, exterior frame, interior, etc... And the window never leaked since. If it does end up leaking again, then I'll probably need to call an expert, much like how some doomed software projects sometimes call in a star consultant to troubleshoot their obscure bugs.

Xml Design Patterns

[This was originally posted at http://timstall.dotnetdevelopersjournal.com/xml_design_patterns.htm]

Xml is the defacto way to store data in files - whether it's build instructions as an MSBuild script, a Domain Specific Language based on code-generating from an xml file,  a config file, or something else.

 

So, your xml files are storing lots of mission-critical information. They're getting huge, being modified by tons of developers, and getting hard to maintain. It's time to refactor them. Here are several ideas to refactor your xml files (much of this is demonstrated in MSBuild):

• Create a variables section. For example, MSBuild has a  section, where each inner node can define a new variable. You can then reference those variables elsewhere throughout your script like so: $(myVar).

• Allow importing of files. Often you'll want to either split a big file into smaller ones, or reuse a single file many times (for example, put all your global variables into a separate file, and then re-import it everywhere).

• Related to this, allow chunks of xml to be automatically included in other chunks with some sort of "include" syntax. In other words, ensure that the xml file itself is refactored. MSBuild allows you to call other targets with a task. Or, say you have a test script that's generated from xml, and every test needs to repeat your "login routine". Define the login routine in one xml snippet, and allow it to be re-included in all the other snippets.

• Have the xml structured to automatically determine relationships. For example, if you have a parent-child relationship of data (here is the menu, here are all the pages accessible from that one menu), then consider using Xml's natural hierarchy (a

  node with a bunch of child nodes). You could also use the natural order of the xml nodes to determine the natural sequence that the data appears (like the order of the pages).

• Provide some way of an extension method or hook. In MSBuild, you can define your own custom tasks and dynamically load them.

• Create special syntax for domain-specific concepts. For example, the MassDataHandler takes xml snippets, and converts them to SQL insert statements to assist with database unit testing. A common problem for inserting SQL statements is handling the identity columns. In this case, if you prefix the value with an '@', the MassDataHandler automatically knows to go lookup its identity value.

• Create templates for default values, which other xml nodes can override. For example, the MassDataHandler allows you to run SQL inserts, one xml node per database row. But say five rows all have the same values for something (like they're all children of the same parent), then it provides the ability to have a "default row" which defines the default values. Other xml nodes can then override these default values.

I guess you could say there are design patterns for good xml. As Xml becomes more and more prevalent, I expect that "Xml Design Patterns" to become more prevalent too.