I had a chance this week to do a simple basic presentation about algorithms to undergraduate students of Computer Engineering in Alazhar University in Cairo.

I enjoyed the time of the session. Both both an girls were amazing an interactive. I hope that I delivered this introduction about Algorithms properly to them.

More...

Last month, Friday 23rd April, I had a chance to present at Code Camp Reloaded event hold at Faculty of Engineering Ain Shams University in Cairo.

My presentation was about Exploring Design Patterns. I gave a general introduction about what’s design patterns and why they exist.

In this session I talked about different Design Patterns categories and explored 2 interesting design patterns:

• Decorator as example of structural patterns
• Strategy as example of behavioral patterns.

I also demonstrated the 2 patterns and showed examples from within .Net framework itself where these 2 patters are applied and used.

I uploaded code samples and presentation to my skydrive

Download Exploring Design Patterns

Note: I uploaded all my sessions to skydrive, you can explore them here

Introduction

You might hear of KiGG, the open source project that is currently live as http://dotnetshoutout.com. I wanted to expose part of KiGG data as an OData Service for read only. But I figured out that exposing raw KiGG schema might not be useful. So I had to choose between 2 options that were up to my mind:

• Build some views on the physical store -database-. Create a new entity data model for those views and use the new data model context for DataServiceContext.
• Use Entity Framework 4.0 conceptual model function feature with complex types to simulate views. It’s like building views on the conceptual model itself and not the store model.

I picked the 2nd option. The sample downloadable sample is available at the end of this post.

More...

Introduction

This is part 4 of this series which I don’t know when it will ends :o). In part 3 I started to to explore the Core of KiGG. In this part we are still inside the core, but we are going further deep to have a look inside the infrastructure.

I’m going to talk about infrastructure for the next couple of posts or maybe more. Because actually it contains the heart of KiGG. For me this is a really interesting topic, it is kind of like a hobby but whereas other people like swimming or playing Poker Online, I like investigating infrastructures. I hope that you find what I write interesting and informative.

More...

Introduction

In part 2, we explored KiGG project structure. I gave a short brief and summary about each project in the solution. And briefly discussed the relation between them.

In this part we are going to start going much deeper. Staring with the Core, and this might take several parts by itself as the Core is huge and contains lots of stuff that worth to be discussed.

More...

Introduction

In part 1 I talked about KiGG high level architecture. In this part I am going to talk about KiGG project structure and summarize the purpose of each project in the solution. I’ll not go into deep details of each project. I’ll save that for some other posts, just be patient with me and stay tuned.

More...

Introduction

In this multi part series I am going to explore KiGG design and architecture as well as projects structures.

At the beginning I would like to give a brief about KiGG History.

About KiGG

KiGG is similar to DotNetKicks, Digg and DZone. However it much closed to DotNetKicks and way smaller than DZone. KiGG was founded by Kazi Manzur Rashid and first introduced in his article on DotNetSlackers.com: Kigg - Building a Digg Clone with ASP.NET MVC, that was on Feb 2008. It was built with First ASP.NET MVC preview.

In early this year 2009 on January, Rashid was almost done with KiGG, however ASP.NET MVC 1.0 was not released yet. At this time Rashid announced DotNetShoutout.com as first live application based on KiGG. On March 2009 Rashid released version 2.2 of KiGG after the release of ASP.NET MVC 1.0.

I joined the team on April and start working with Entity Framework implementation for KiGG as well as supporting the project.

Thank you Rashid for giving me this opportunity.

More...

Introduction

One of the challenging things with current version of Entity Framework, its leakage of testability. Which means when you build an application or module (e.g. Repositories) that depends on entity framework, it will be very hard to unit test your code isolated from Entity Framework. This might lead to conduct Integration Testing which will require a connection and interaction with underlying data store (database).

You might think of using Mocking to mock or fake Entity Framework data store dependent calls. But sadly Moq and Rhino Mock mocking frameworks do not support this. And you’ll end up hitting the wall. Both frameworks are great useful and I personally use Moq for a while now and very happy with it. But no one can deny limitations when exist.

And personally I was able to overcome the limitation of the testability of Entity Framework while I was working in KiGG Entity Framework based models and repositories. But done that through unnecessary code refactoring and wrappers around none mockable classes such as sealed class EntityCollection<T>.

Finding a solution with TypeMock Isolator

In fact there is a solution, that will save you lots of workarounds and unnecessary code refactoring. You just need a full isolation framework. TypeMock Isolator provides this capability. It allows to mock sealed classes and classes that have private constructors, static methods, and much more.

TypeMock isolator makes it easy to simulate and break the dependencies of any object in your existing code. In that way, it doesn’t force you to think about how your design might need to change. –The Art of Unit Testing book page 132-

So, TypeMock isolator is a perfect mate for testing code that has dependencies on Entity Framework as how I am going to show now.

More...

I had few previous posts about DDD & TDD with Entity Framework that you might need to return to them before you proceed with this post. To summarize these posts, I was trying to build testable Models that is based on EF. But EF doesn't support Persistence Ignorance in its first version which make testing it in most cases require a database connection where you can test you code against it. My target was to build a testable models based on EF and that is independent of any underlying data source.

Introduction, Domain Model Review:

More...

I decided to provide some integration testing before proceeding as a proof of concept. In integration testing I will connect to the database and perform unit testing while connecting to the database.\

This unit test is almost identical to the one in my previous post. Except here I am testing the results that is coming out from EF and Database.

My target is to test IDataContext Implemented methods in NorthwindDataContext. Find below the Integration unit testing class. More...