All posts by Julie

Vermont IT Job: Web Developer in Northern Vermont

Jobs

Senior Web Developer

Northern VT eCommerce client is actively seeking a Senior Web Developer to join their team.

You will be working in conjunction with interdepartmental groups focusing on deployment and support of multiple eCommerce product lines.

eCommerce experience is essential to successfully utilize all current and future features enabling a strategic advantage to their company.

Our client operates in fast paced varied environment which requires excellent written and verbal communication skills.  Candidates are expected to be flexible and tolerant of timelines and deadlines.

Daily Responsibilities:

         Develop new applications as identified by company goals and manage through packaged and customized applications.

         Maintain and enhance existing web applications.

         Perform unit and systems testing for web applications.

         Design and implement user driven templates, databases and interfaces.

         Develop database driven user interfaces.

         Develop external web portals.

         Must be a team player who is able to work independently and meet deadlines.

Key Skills:

         7+ Yrs Web Development

         Solid working knowledge: C#, Asp.Net, XML, PHP and other Open Source technologies

         Solid working knowledge: Microsoft SQL Server, Oracle

         Bachelor’s Degree

         Desired: Flash, JQuery, eCommerce Server, Photoshop

Perm Role:  80-90K

 

Contact:

Kim Coffin
FIT Solutions, LLC
"Providing IT Resources that FIT Your Business"

413-214-2552 (cell)
413-363-0204 (fax)

kcoffin@fitsolutions.us
http://www.linkedin.com/in/kimcoffin
www.fitsolutions.us

Programming Entity Framework e-book for $9.99 one day only!

Book

O’Reilly Media has placed the new edition of my book available  in their “Deal of the Day” program today. You can get the ebook version for only $9.99.

That’s TODAY only, though: Monday August 30, 2010.

Go to http://oreilly.com/catalog/9780596807269 and use the discount code DDPEF.

If you miss it today, you can get a 50% discount on the ebook from O’Reilly (not sure about a deadline) with the code MTKED. THat code is also good for a 40% discount on the print copy. However the MTKED discount code does not work everywhere. I’ve heard that people using the UK checkout are unable to use that.

If you want to get the book from Amazon, here is a direct link to Programming Entity Framework 2nd edition (for VS2010/EF4/.NET4)

Designing Repositories – Now I don’t feel so bad

Data Access

Last week I was working with a client and we were creating some repositories to use with EF4 entities in her application. I felt kinda dumb because I couldn’t reason out where to put a method to retrieve “child” data, e.g., GetEmployeesForCompany(Company company). The method not only retrieves the employees but attaches them to the company, returning a graph.

My conundrum was should the method call go in to a repository who’s root was Company or the one with the root, Employee?

So I tweeted it but thanks to the 140 char limit, simplified the method to GetEmployeesForCompany(int companyId).

I got a lot of responses very quickly and they went back and forth which only confused me more.

Not until I put them all in this table (below) did I see that generally people were leaning towards returning it from employee.

But the best response was: “The answer is that it depends upon what you’re building – and how it would make most sense to aggregate 😉 i.e. aggregates only make sense in CONTEXT.” Thanks Mikey! 🙂

In the end, I think that I won’t fail by choosing one over the other. The important thing, which for me is also a great benefit of creating repositories, is the fact that I have put some thought into where the method goes and am making an explicit choice that works for me. And that is the lesson I can leave my client with, along with another which I repeated a few times – “I’m not the expert on this topic. We’re just taking baby steps (in the right direction) here.”

Company Employee

only make sense on the Company class, so I’d say Company.

 Employee Repo!
I’d say Company Employee rep. Company is just a lookup parameter.
gsin u have emp and comp both as aggr. still, comp might restrict which emp it returns…so i’d put in comp Employee Repo!

I’d go with the company as the aggregate in this case.

 I’d go with Employees and calling it GetByCompany(string companyId)
EmloyeeRepo.GetAllForCompany(123
 

I generally go with the convention that a rep only returns the type it is associated with but takes any type as a parameter
  so if reps other than employees returned employees, it would be hard to predict where all the places are that return employees
  your getting a collection of employees and not dealing with a Company object at all, I would put it in employee rep
  employee repository… it’s returning employees
  I’d say employee. You want a collection of employees, not a collection of companies. Think of it as a slippery slope.
 

Since you are getting employee’s, I would put it in the EmployeeRepository.

The Acknowledgements in Programming Entity Framework 2nd Edition

Book

In a 900 page book, this was the only creative writing I got to do so I had some fun with it. 🙂

There are a lot of hyperlinks to push into here for the blog post, I will come back to that task later.

Acknowledgments


And now for the most rewarding writing task after completing over 800 pages of technical writing—thanking the Academy. My academy is a host of bright, generous, and dedicated geeks (and a few nongeeks) who have helped make this book the best it can be.

First nods go to the technical reviewers. These are the folks who were willing to read the book in its roughest format and provide feedback to help me make it more useful and comprehensible to you, the readers of the final version. The award for helping to keep me from exposing myself to humiliation over my nascent C# skills goes to Wesley Bakker, a Dutch developer who does code reviews for a living. I learned a lot from Wes and am grateful for his patience and kid-glove handling of my poor ego. I also had a number of EF and EF 4 newbies on board to help ensure that I didn’t make any leaps without bringing them along. You who are new to EF should thank them as well: Camey Combs, Suzanne Shushereba, Doug Holland, and John McConnell. Ward Bell’s brilliant architectural mind was displayed in comments that nearly exceeded my own text. He kept me honest and kept me thinking. Everyone should email Ward and beg him to write a book. I don’t care what the topic is. Ward has deep EF knowledge, as does Per Okvist, whose feedback was also invaluable. Two database gurus were enormously helpful: Bob Beauchemin and Anil Das. Their meticulous minds helped me in areas that reached much further than discussions about database specifics.

I also brought in some big guns to look at particular chapters in their area of expertise. Thanks so much to Greg Young, Bobby Johnson, Jarod Ferguson, and Mike Campbell for helping me with my education in persistence ignorance and related topics and for looking over the critical chapter on PI and testing to make sure that I had learned my lessons well. I was close, but they helped guide me where I had strayed. K. Scott Allen and Imar Spaanjaars, both ASP.NET gurus, provided some additional guidance and a read-through of a number of chapters.

And then there was the real editing—the organization and flow of the text. John Osborn, who was the editor on the first edition of this book, was engaged to edit this edition as well. It’s hard for me to express my gratitude for the incredible dedication  and expertise he provided. Even though I thought myself much more experienced this time around, John took every chapter and reorganized it, clarifying its focus and flow. He is an incredible editor and I was very lucky to have him work on my book again.

Along the way, of course, I had help from so many people at Microsoft on the Entity Framework team and beyond. There is no way I can list them all, but here’s my best shot (not in any special order): Danny Simmons, Elisa Flasko, Noam Ben-Ami, Diego Vega, Kati Iceva, Srikanth Mandadi, Alex James, Jarek Kowalski, Jeff Derstadt, Rowan Miller, Craig Lee, David Annesley-DeWinter, Adi Unnithan, Andrew Peters, Shyam Pather, and Tim Laverty. Forgive me if I’ve neglected to mention someone.

You’ll find that I have used (and recommended) a few additional tools throughout the book. The publishers generously provided me free licenses for which I’m grateful. The recommendations are because they are great tools, not because I didn’t have to pay for them. The tools include LINQPad, written by another O’Reilly author, Joseph Albahari; and ReSharper from JetBrains. ReSharper was my first line of defense for ensuring that my C# code wasn’t an embarrassment, while Wesley Bakker was my second. I learned so much from both of them. Entity Framework Profiler is an awesome tool for keeping track of what’s going on in your database when using Entity Framework. I also used two tools for producing images in this book. The first is Snagit from TechSmith, which was completely invaluable for capturing and editing screenshots. The second is Balsamiq Mockups, which enabled me to have a little fun creating mock-ups of application UIs in a number of chapters. Finally, thanks to Red Gate, a great company with many awesome tools. For this book, I used its .NET Reflector to inspect some assemblies,
and I’ve used their SQL Packager for creating a simple-to-install version of the sample databases for you to use.

My publisher has, as usual, provided great support for me. I had not one, but two editors—this is not the job of editing the book, but of counseling me and holding my hand throughout the process. Thanks to Laurel Ruma (who moved on to become O’Reilly’s über–Government 2.0 guru), and Mike Hendrickson who brings years of experience (not saying he’s old) for keeping me focused and helping me avoid being taken away in a funny white coat. I was also lucky to have Audrey Doyle as my copy editor again. She did an amazing job on the first edition, so I begged O’Reilly to contract her again. Lucky me, they did. (She is going to hate that last nonsentence; I dare you to leave it in, Audrey.)

If you read the Preface of my first book, you’ll be happy to know that this time around I have no heart-wrenching pet losses to report, so you can put away the tissues you may have prepared yourself with. In fact, we adopted a teenage Newfoundland dog named Sampson just as I began to write this edition. Thank goodness for his needed afternoon walks and his constantly entertaining personality, without which I’d have gone completely mad during the time I have been writing this book. You can meet this silly boy on my blog at http://thedatafarm.wpengine.com/blog/tags/Sampson.

Somehow I have managed to retain my patient husband, Rich Flynn, to whom I promised “don’t worry, never again” when I finished the first edition. He has just suffered through another year of spaghetti, dirty dishes, ravaged potato chip supplies, and having to cede a little more space in bed as my waistline expanded thanks to my life in the computer chair (and all those potato chips).

And finally, thanks to all of the incredible support that has come from the .NET community. I’m very proud of the first edition of the book, and each private “thank you” or complimentary public review on places like Amazon.com and your blogs has meant so much to me. This truly kept me going through what my Twitter followers know only too well was an arduous process in writing this second edition.

Oh, and to anyone who gave me chocolate…thanks!

Modified Description of Adding Inheritance into T4 Template from Chapter 18

Book

This is in reference to Programming Entity Framework 2nd Edition

When I originally wrote the directions for modifying the T4 template in Chapter 18 (Using POCOs and Self-Tracking Entities in WCF Services), I was working with the “almost” RTM version of the Microsoft’s POCO T4 template. Since my modified template continued to work after RTM, I never thought to revisit that text and discovered yesterday that it doesn’t follow the current version of the template and therefore the instrux are unclear & confusing.

My discovery did not come from a reader but was made when I was working with a client and wanted to make that same modification in her template.

When I originally wrote that description I was borrowing some code from the EntityObject template that had a dependency on a variable called ModelNamespace. But in the newer version of the POCO template, that variable is no longer used.

Here are the modified paragraphs and links to the templates that you can download from the book’s website.

read more at : http://learnentityframework.com/LearnEntityFramework/errata/modified-description-of-adding-inheritance-into-t4-template-from-chapter-18/