Fabrice's weblog

Change tracking, the ADO.NET Entity Framework and DataSets

Andres Aguiar started an interesting discussion about disconnected operation and change tracking in the ADO.NET Entity Framework.

Andres regrets that the Entity Framework doesn't provide change tracking information:

This basically means that if you plan to build a multi-tier application with ADO.NET Orcas in the middle tier, you will need to hack your own change tracking mechanism in the client, send the whole changeset, and apply it in the middle tier. From this point of view, it's a huge step backwards, as that's something we already have with DataSets today. 

In a reply to Andres' post, Udi Dahan states that an application should not rely on change tracking information.

I believe that there are several kinds of applications and I don't think everybody must move to a unique kind of application. Some application don't require change tracking, others do. I've worked on applications that require it and Andres describes very well how they work in a subsequent post. One additional advantage of having state information is that you can display a collection of items (often details in a master-details relationship) in a grid, with changed items in italic, new items in bold and deleted items with strike-through text.
I don't understand why an SOA architecture wouldn't allow an UpdateOrder kind of command, but if it's the case, then a lot of applications are not compatible with SOA. If the ADO.NET Entity Framework or other mapping frameworks do not provide change information, then I'd say that DataSets are here to stay for a while...
I don't think there can be only one architecture for all applications. Both approaches described by Andres and Udi should coexist. If the ADO.NET Entity Framework doesn't provide support for change tracking, then another tool is need for some applications. If the the Entity Framework is open enough, then maybe extensions to it can add the support for change tracking?
 

Using LINQ to solve puzzles

The diagram below provided by Luke shows a mobile. It consists in a bunch of weights (A-M) hanging from a system of bars. Each weight has an integer value between 1 and 13, and the goal is to figure out what each weight must be for the the diagram below to balance correctly as shown:

                          |
                          |
              +--+--+--+--+--+--+--+
              |                    |
              |                    |
           +--+--+--+--+--+        |
           |     L        M        |
           |                       |
  +--+--+--+--+--+--+     +--+--+--+--+--+
  H              |  I     |  J        K  |
                 |        |              |
        +--+--+--+--+--+  |     +--+--+--+--+--+
        E              F  |     G              |
                          |                    |
              +--+--+--+--+--+  +--+--+--+--+--+--+
              A              B  C                 D

The puzzle can be solved relatively easily using a LINQ query:

var solveForWeights =
  from a in Enumerable.Range(1, 13)
  join b in Enumerable.Range(1, 13) on 4 * a equals b
  from c in Enumerable.Range(1, 13)
  join d in Enumerable.Range(1, 13) on 5 * c equals d
  from e in Enumerable.Range(1, 13)
  join f in Enumerable.Range(1, 13) on 3 * e equals 2 * f
  join g in Enumerable.Range(1, 13) on 2 * (c + d) equals 3 * g
  from h in Enumerable.Range(1, 13)
  join i in Enumerable.Range(1, 13) on 3 * h - 2 * (e + f) equals 3 * i
  from j in Enumerable.Range(1, 13)
  join k in Enumerable.Range(1, 13) on 3 * (a + b) + 2 * j - 2 * (g + c + d) equals k
  from l in Enumerable.Range(1, 13)
  join m in Enumerable.Range(1, 13) on (h + i + e + f) - l equals 4 * m
  where (4 * (l + m + h + i + e + f) == 3 * (j + k + g + a + b + c + d))
  select new { a, b, c, d, e, f, g, h, i, j, k, l, m,
               Total = a + b + c + d + e + f + g + h + i + j + k + l + m };

solveForWeights.ToList().ForEach(result => Console.WriteLine(result));

This is an interesting approach and an innovative use of LINQ! See the details in Luke's post. 

My experience writing the LINQ in Action book

As we are about to reach an important step with the LINQ in Action book that will make the first bits public, we start to look back at what we did and how it happened.

Steve, who is working on the book with me, says that writing a book is hard. Roy, who is working on his own book for the same publisher, says that writing a book is like developing software. I agree with both of them!

Let me try to expand on what Steve and Roy wrote and throw in my own experience:

• As with any other activity you're serious about, including programming, dedicated time and a quiet environment are required.
  You need to get in the flow and preserve the bubble so can actually produce something.
  
• Writing is like a full time job.
  As with software, if you are passionate about your work, you are always thinking about what you are writing or going to write, and how to improve it. If you are not a professional writer, you have to share your time with other projects. I'm used to this because I'm always juggling with several projects at the same time, but I guess it can become difficult to handle if your mind is not prepared to this.
  
• Defining the table of content (ToC) is the first step. It can take a while, but it's crucial for the rest of the project.
  The ToC should reflect all you want to tell to the reader, and how you want to communicate it. It's all about content, structure, and your book's story. As a writer, the ToC is your roadmap all along the way. A ToC is not perfect on the first shots. For LINQ in Action, we did more than 20 rewrites of the ToC before it reaches its current state. And it can still evolve a bit... We got what we wanted to tell defined pretty quickly, but finding the best way to organize it took some time.
• To get you started on a chapter, collect all the ideas you want to include in it, and throw them in. Don't worry if it looks like a bunch of wild ideas that don't seem to play well together. As you make progress on a chapter these ideas may fit in the flow. You can always decide as you go if you want to keep a topic, move it to another chapter or throw it away.
  
• Writing a book is not a linear task.
  Writing a book, even a technical one, is a creative work. It requires inspiration and this does not come all at once and in a continuous flow. Sometimes you'll be productive, other times you'll feel like you have wasted a lot of time writing just one page. At times, it's important to just let ideas come and what you want to write will end up emerging. Keep pushing to get things done, but allow some time for creativity.
• A book is not just a collection of chapters put together.
  A chapter is not a standalone piece of work. If it was, you'd be writing articles, not a book. A book's chapters are linked together and build one onto another. When you create the table of content, you define where chapters go because there is a logical order between them. But when actually writing a chapter, you'll find that you should refer the user to some previous chapter and expand an example that was introduced before. You should also let the reader know in advance if you'll get back to a subject later in the book.
  
• Not all chapters are the same.
  The kind of work can be very different from one chapter to another. Some chapters are about introducing a topic, some mainly provide code samples, some are more about theory, others are more about best practices, etc. Each chapter is a different story. Of course it's better if your chapters can mix all this together because it's better for digestion :-) Some chapters (most in fact) are very difficult to write because you need to find the right way to explain a specific topic and of course almost no information is available yet about it to help you out.
  
• A chapter does not represent a bounded unit of work.
  You can't start one chapter and write it from start to finish. A chapter requires several passes. You write a first draft; you start working on another chapter; your editor reviews your first chapter; you take the edits and comments into account; you resubmit your chapter for review; you get new ideas for your other chapter; you need to update your first chapter because Microsoft finally decided to release a new preview that breaks everything you have written so far; and so on.
  
• Refactor, refine, improve, rinse and repeat.
  When you finish (or so you think) your first chapter and you are happy with it, you are eager to send it out for review. You are confident that the content is great, the style better than anything else you have ever written so far, and you get ready to receive positive comments. Maybe someone will find some glitches here or there and suggestions for ways to improve a paragraph or a title, but it should be ok... After all, you spent a month on this chapter! What a disappointment when you have to realize that in fact it's not so great and you have more work to do on it than what you have done so far! A chapter is never finished in one shot, nor in two. A book requires a lot of work, a chapter requires a lot of work, a paragraph, a line, a caption all require work and work and work.
  
• Nothing is perfect in this world. Your book won't be either.
  As I wrote, you have to get back to each chapter again and again. But if you are perfectionist or if you listen to all the feedback you can get from all the reviewers, you can quickly feel overwhelmed and get crazy. Everything people will tell you is true and can be used to improve you book in wonderful ways. But this is your book. You write it. Reviewers review and can only make suggestions. You have to make choices, and at some point you have to stop working on a chapter and move on to the next one.
  You need to find the right examples, the best sentence. This is what can make a difference between a good book and a great book, but you can easily become a prisoner of your book. You may want to give as much information as possible, but you have to accept that it's not possible to cover all the details. Throw away some of what you wanted to cover. Keep what's essential and focus on it.
  
• Involving friends and other external reviewers in the process is good for your mental health.
  Working on a chapter is a lot of work and can be stressful because there are some deadlines to meet. If you can show to someone what you have so far, even if it's a draft, it can help you actually feel that you do have something done. Feedback helps you make progress in terms of quality of course because your reviewers can tell you what they think of your work, but it also keeps you going on.
  
• The reader is king.
  Never forget that you are not writing a book for yourself, but for the reader. Try to think like your reader. What does he know? What does he want to read? Would he be bored by your prose? Have you lost him in your convoluted explanations? Step back a bit and rewrite as if your reader was in front of you and he's reading above your shoulder. Stop once HE/SHE is ok with what you wrote :-)
  
• It always takes more time that you expected.
  It's just like with software projects. You think you can finish in time. You tend to ignore the difficulties ahead. Writing a book is hard, but more than that it's very time consuming! Of course it gets harder if you don't have time allocated to this activity. I have the luck to be able to keep time for writing. It's not as rewarding as doing consulting as far as money is concerned, of course. This is something you need to consider seriously if you plan to write a book. All in all it's an interesting challenge, but far too much time consuming.
  
• Things are lot harder if you are after a moving target.
  Writing a book is hard and takes time. But if that's not a big enough challenge for you, choose to write about an unreleased product or technology. LINQ is constantly evolving and the shape it will have in the end has started stabilizing only a few weeks ago. We started working on the book several months ago and information was missing on a lot of topics. We had to dig by ourself to understand the technology and investigate to find how things work. I guess that this almost always happens with technological books. Our work as authors is in part to find the information for the readers. It's hard work that adds to the actual writing work.
  
• The work varies a lot depending on your publisher.
  Each publisher has it's own processes and quality standards. I don't have experience with other publishers, but I find that Manning is very involved. They don't just take an author or a book and publish it. They guide you and make sure that your book is in good shape. They are also supportive and they are always available if you have questions and need advice. I can see that it's quite different with other publishers, some of which just expect you to deliver on time.
  

All this ends up a lot longer than I expected, but hopefully it will be useful for someone. It's time for me to get back to the chapter I need to finish...
Feel free to comment I you have a similar or a different experience.

Cross-posted from http://LinqInAction.net 

Great presentations involve a mix of passion and communication

Krzysztof Cwalina points to a fascinating presentation. Full of passion, content, and visual power. Very instructive. See by yourself.
This is one more great presentation from TED.

Update on the status of the LINQ in Action book

After several months of work, the project reaches a new milestone. Steve and I have the pleasure to announce that Jim Wooley has joined us. Jim will take care of the chapters about LINQ to SQL. With the new preview of Orcas, we'll be able to make a lot of progress because it contains support for almost all of LINQ's features, including LINQ to SQL.

If you are using LINQ in Visual Basic, I recommend that you check Jim's latest posts out. They show how to migrate a project from the May 2006 LINQ CTP to the March 2007 Orcas CTP, and explain how the order of the Select and Order By query clauses has changed.

The next step for the book will be its availability as part of Manning's Early Access Program (MEAP). With MEAP, you will get early access to the book, chapter by chapter, as soon as they become available. You will be able to choose between the PDF and ThoutReader formats, or both. After all chapters are released, you will be able to download the complete edited ebook. If you order the print edition, it will be shipped to you upon release, direct from the bindery, weeks before it is widely available elsewhere.
I'll keep you updated once this option is available. I really look forward to starting to make the result of our hard work public!