Marius Gheorghe

Building software : make it work, make it good, make it fast

AOP. Not really a fan

I'm not a fan of AOP. I think that in a well design (layered) system there shouldn't be any "cross cutting concerns". Each layer should deal with his responsibility/es. Security is always given as a example of "cross cutting concern".  But i disagree with this.....security is a top level "concern". There's no point in checking credentials/access rights  AT every level of the application.  Not to mention that usually the security features of a application usually permeate to the UI level (as an example.....if the user has the option to edit a record...if it doesn't have the rights to edit it you simply disable the button. If don't let him type and then go 2 layers below to check for rights and then you show a error message....that's bad UI).

Security should really be enforced in the "entry point" layer of the system (be it UI or service).

EntityFramework - the good, the bad and the ugly

Well,  i have been working with EF for a while and here are a few impressions :

the good :

- has UI (designer) tool for (automatic) mapping.

- offers support for advanced mapping (unfortunately in the first version only if you edit manually the xml mapping file).

- full LINQ integration (by far the biggest advantage).

 

the bad :

- on the persistence front,  it has support only for the "big brother" (in this case ObjectContext) which manages entity state and persist them. It doesn't offer a API to do "manual" operations. This makes it very awkward to use in ASP.NET (where most likely you'll have a ObjectContext per request and the entity state can't be tracked down automatically). From my point of view this is by far the biggest disadvantage of the API.

- support only for SqlServer.....i think it will be a while until we can use with something else.

- the MetadataWorkspace used for querying mapping data is a bit hard to use (this is especially bad considering that the first version of EF doesn't support POCO persistence).

 

the ugly:

- the VS  designer. I hate that crap. It gets unusable with many entitites and it generates all the code in a single file (nightmare for source control).

Plus it's  integrated in VS ( and in this case this IS a BAD thing).

More games

 

Resident Evil 5

I was pretty disappointed by this one actually. The Resident Evil series is defined by 2 important attributes : survival horror and clunky controls. In RE5 they decided to remove

the “horror” part and make a straight action game but they kept the clunky  controls. From a gameplay perspective RE5 is JUST a HD copy of RE4. The problem is that, while in RE4 the horror bits set up the atmosphere, RE5 looks like a shallow, broken (because of the controls) (HD) copy without those bits.

  

Wolverine

Over the top violence, silly storyline, great cut scenes and  a lot of bugs. Did i mentioned the over the top violence ? Must try.

 

 

Velvet Assassin

A good old stealth game set in WW2 played from a 3rd person perspective.

Pros :

- the atmosphere  is really great.

- graphics (really nice…especially the dark/light interplay).

- good stealth based gameplay ( i really missed this from the days of good old Thief)

Cons :

- use of firearms (the fact that you can use firearms and also the fact that aiming is a PITA )

- the last level can’t be played in stealth mode and the game simply turns into a crappy shooter.

- bad placement for checkpoints .

 

Conclusion : if you like stealth games then this is a must try.

efbog

efbog - the Entity Framework Business Object Generator is the project i mentioned  a while ago. Basically it generates DataBlock like business objects for Entity Framework. The project's page is here

Better software with 2 simple rules/patterns

I'm talking about :

- DRY (Don't Repeat Yourself) - a common source of bugs in any project is duplicated code. Code which does the same thing with different implementations. The easiest way to fix this is to enforce a certain project structure : for instance in a business application all entity related task must be implemented in a single class/place/system ( call it the repository pattern, call it business object, called it whatever it tickles your fancy ...).

- SOC (Separations of concerns) - SOC is the process of designing a system in which the functionality is segregated in clearly independent (and orthogonal )  layers. This might sound more familiar by the name of some popular SOC patterns : MVP (Model Viewer Presenter) and MCV (Model Controller Viewer).  Failure in implementing a/any form of SOC results in fragile, brittle, hard to maintain (and extend) software.

DataBlock. Stick a fork in it….it’s done.

  This is a post long overdue. I regularly get mail about DataBlock's future so i’m happy to say that (remaining bugs aside) …folks stick a fork in it cause it’s done.  I consider that i have achieved with DataBlock what i set out to do : a small, lean, separation of concerns enforced, easy to deploy, simple API  O/RM. The only thing that is missing now would be LINQ integration (unfortunately that’s a pretty big undertaking and i don’t really have time for this now….at least as a open source. If somebody is interested to sponsor this then contact me).

  So  i guess it’s safe to say that, while bugs will be fixed, no new features will be added.  A related project that i am planning is adding DataBlock business objects like API to Entity Framework. But that’s another story…

Learn XNA 3.0

I have became pretty interested in game development lately (as a hobby)  and so i've started learning XNA. The first step was to read "Learn XNA 3.0" which is a pretty good book on the subject (although the XNA API could have been explained a little more thoroughly).

Latest Resharper build

Wowed by the latest beta performance improvements i have installed it. While it is a bit snappier when loading a big solution, Resharper’s auto completion is hopelessly broken in this beta (it crashes a lot throwing a LookupWindow related exception….yeah yeah….i have reported it). I’m anxiously expecting the final release but frankly i am beginning  to think that no matter how great this tool is, some part(s) of it will always be broken (until now the loading time for big solutions was almost unbearable).

Crappy markup

The ASP.NET menu control is spiting out some truly crappy markup. It fails to work on IE8 (in standard mode), Safari, Chrome and Opera. Time to replace it with CSS+JS equivalent.

Nice accessibility feature

I noticed that the newly released IE8 has a nice accessibility feature. Basically  in the current URL the domain name is “painted” with another color making it very easy to spot.

Little little things :)

Haxe – the metalanguage

Haxe is a pretty interesting idea. Basically a language who’s compiler can spit out source code in JS/PHP/Flash/C++ . In theory this is very interesting, in practice it looks like you’ll end up writing a “solution” in (at least) 2 languages……the logic in Haxe and the things unsupported by Haxe libraries (like UI toolkit) in “other” language.

 

Somehow related, Parrot 1.0 is out (slashdotted now).

On REST and SOAP

     Despite what any REST fan would say, from the perspective of a OOP guy, SOAP makes much more sense. The invoked “complexity” of SOAP over REST is simply perceived complexity. If tools “shield” you from SOAP complexity then is SOAP complex ? The reality is that SOAP and REST accomplish the same thing but they operate on different levels . In SOAP case you have objects, methods, exceptions etc. In REST’s case you have a HTTP request and HTTP error codes (and yeah…it’s much nicer to get a SoapException describing the problem than to “remap” different error codes in your head for each request).

    From the perspective of the guy who must expose the service is much simple to “define” complex interactions with SOAP. Even the basic entity interaction (CRUD) is not so simple with REST because you’ll always need to expose multiple ways (with associated parameters) for GET (GetOrderByDate, GetOrderByCustomer, GetOrderByStatus etc). Even worse is exposing business logic errors with HTTP error codes.

So, i think that REST is fine for very simple “interactions” , for everything else go SOAP.