Tuesday, May 22, 2007
After finding blogs like this that seem to be mirroring my own frustrations, I have decided to stick with what I know.
Spring.Net is a fantastic tool that is really, in the scheme of things, bloody easy to use.
Why was I hesitant to use Spring.Net? Firstly we were already using the SCSF, which uses CAB and the OB, so that was obviously my first preference (ie use something already in use!). However as mentioned it implementation fell right into the “taking to long to research and even get started” basket. Secondly, well, some companies are hesitant to use 3rd party tools, especially on critical aspects of business. Having that little “Microsoft” prefix on the assembly tends to give more peace of mind.
However the Spring framework has had such wide testing and I feel that I have given it a pretty good tyre kicking, so I feel happy to use it, hopefully the PM does to.
Monday, May 14, 2007
- By looking at a DB schema how do you know how well indexed the DB is?
- How do you know how many rows are in it?
- How do you know about it performance
I have always been of the opinion that you
- Normalise first, create a beautiful piece of art that is a nicely and appropriately normailised database.
- Add indexes.
- Write your sored procs.
- Check the performance on test data.
- Denormalise if nessecary, however if there were issues I would go over everything with a fine tooth comb first to ensure keys, indexes, constraints, triggers are all in place where appropriate, working as intended and not adding unessecary overhead. Then I would start denormalising.
Yes i am a fan of stored procs, especially for anything that actaully is DB intensive. As Gumble also points out (frequently) it adheres to a basic concept we use daily, encapsulation. Normal Objects and Layers/Tiers cant see into the next object/layer/tier, why should this be broken at the data access layer. Using SP's also (IMO) aids in security and data control (well it can, anyone can butcher code) ;). The OO coders should not have to know the underlying data structure, they know what they want, they just need a means to get it. The Dba may be adding a whole bunch of stuff that the OO boys dont need to about, inactive flags, triggers, loggin, other extra columns, how the data is retireved etc etc... also this mean performance is left in the DB world and can be easily tested with out any manged code interfering.
One thing i do prefer is isolation of tests, i dont want to not be able to test individual units. A stored proc is a unit, a BusObj --> Repository --> DA--> db --> DA --> Repository --> BusObj is not a very succinct unit. If i want to test that vertical i still can however i want to be able to break it down too.
Then there is the point of ORM's; I'm all for them, anything that gets rid of boring DA code, sweet! But sometime you have some complex resultsets and DB call that do not suit your run of the mill ORM's. I do believe for basic database and when fast turnover of code is of higher importances, then something like NHibernate (perhaps with AR) can be handy... but i think it needs to be reviewed on a case by case basis, unlike some of my peers who believe NHibernate is the silver for all solutions...
no doubt more will come...
Saturday, May 12, 2007
Its a VERY fast read, not a lot of overly conspetual stuff and very well written. Hopefully most of it is stuff you already do, fortunately i have worked with and been exposed to some very good coders and thankfully i have picked up their good practices so alot of this is confirmation of ideas.
Read it, you will either pick up lots of good practices or confirm you are doing things right. Either way its a book you can read in a weekend with out too much of a problem.
Monday, May 7, 2007
Yay silver light!
(from the must read blog of ScottGu )
Thursday, May 3, 2007
As we using .Net 3.0 Ndoc cant be used so its replacement sandcastle was our obvious option. Sandcastle being still a CTP is pretty clumsy to use, so here is some tips to get you going.
firstly check out the Gui or batch tools out there, some of them are pretty good. Check the codeplex stuff and SandcastleGUI.
Unfortunately this (specifically SandcastleGUI) wouldnt work for me as it tries to find DLLs that may be referenced even if not used (this may point to redundant ref in our code). as time was not on my side i decide to just run with the default console implementation.
...Anyway some tips.
Put all your Dll's in one directory. Even if this means copying them all into a holder directory for the means of the documentation exercise. This includes anything that the dll's may reference. Normally this is the case anyway, however with distributed systems, and gacs, and what not, it isnt always the case.
Assuming you install sandcastle in "C:\Program Files\Sandcastle" the below script will create your help file.
"C:\Program Files\Sandcastle\ProductionTools\MRefBuilder.exe" alpha.dll beta.dll gamma.dll /out:reflection.org
"C:\Program Files\Sandcastle\ProductionTools\XslTransform.exe" /xsl:"C:\Program Files\Sandcastle\ProductionTransforms\ApplyVSDocModel.xsl" reflection.org /xsl:"C:\Program Files\Sandcastle\ProductionTransforms\AddFriendlyFilenames.xsl" /out:reflection.xml
"C:\Program Files\Sandcastle\ProductionTools\XslTransform.exe" /xsl:"C:\Program Files\Sandcastle\ProductionTransforms\ReflectionToManifest.xsl" reflection.xml /out:manifest.xml
call "C:\Program Files\Sandcastle\Presentation\vs2005\copyOutput.bat"
"C:\Program Files\Sandcastle\ProductionTools\BuildAssembler.exe" /config:"C:\Program Files\Sandcastle\Presentation\vs2005\Configuration\sandcastle.config" manifest.xml
"C:\Program Files\Sandcastle\ProductionTools\XslTransform.exe" /xsl:"C:\Program Files\Sandcastle\ProductionTransforms\ReflectionToChmProject.xsl" reflection.xml /out:Output\test.hhp
"C:\Program Files\Sandcastle\ProductionTools\XslTransform.exe" /xsl:"C:\Program Files\Sandcastle\ProductionTransforms\createvstoc.xsl" reflection.xml /out:toc.xml
"C:\Program Files\Sandcastle\ProductionTools\XslTransform.exe" /xsl:"C:\Program Files\Sandcastle\ProductionTransforms\TocToChmContents.xsl" toc.xml /out:Output\test.hhc
"C:\Program Files\Sandcastle\ProductionTools\XslTransform.exe" /xsl:"C:\Program Files\Sandcastle\ProductionTransforms\ReflectionToChmIndex.xsl" reflection.xml /out:Output\test.hhk
"C:\Program Files\HTML Help Workshop\hhc.exe" output\test.hhp
The only change you would then need for this script is to put the names of the DLL's you actually want to document (ie replace alpha.dll beta.dll gamma.dll with your dll(s))... you may want to do this before running the batch file ;)
Copy and paste the script below into a text file make the dll name change on the first line sand save it as a batch file eg "documentation.bat". Save it in the same folder as your dll's and run it (click it).
This will give you an ultra generic help file, ala visual studio 2005 and all the rubbish .net 2.0 help files when it first came out.
I personally played with the xsl file to add in images etc to customise it a bit. i'm sure there are better ways to do it but i'm not spending any more time on some thing that i doubt anyone will ever read.
If you want them all spruced up, you probably want to check out the tools mentioned above.
EDIT: Sorry I fogot to mention that I dont name all of my XML Comment files "comments.xml"!
I usually name them the same as my dll's with an xml extension eg alpha.dll has the comment file alpha.xml. This means I had to make a change in the sandcastle config file ("C:\Program Files\Sandcastle\Presentation\vs2005\configuration\sandcastle.config" in my case) line 63 from
<data files=".\comments.xml" / >
< data files=".\*.xml" />
to allow for all of the xml files to be a part of the help (which is what you really want now isn't it!).
Just make sure there are only comment XML files (ie no other data xml files) in the directory or i guess it could go pear shaped. Alternatively perhaps name them *.dll.xml and use that as the data file filter.
To change the lines at the top & bottom of the main pages
[This topic is pre-release documentation and is subject to change in future releases. Blank topics are included as placeholders.]
Send comments about this topic to Microsoft.Edit the shared_content.xml file found below.
Wednesday, May 2, 2007
BA's who give innaccurate or incredibly loose requirements yet want you to build a something exactly how they or the customer want it...
PM's who want you to do something that will take 5 weeks to do it in 1 and after you pull uber over time to finish it they then think they were right, it did only take 1 week... and it your fault that it hasnt been tested properly or fully completed...
Sales people who promise the earth and have no idea what nightmares they are putting the team into.... etc etc
And poor old us. The developer gets to shoulder the brunt of it... well so we think. A couple of things happened today that got me thinking, if the average Dev could properly comunicate then alot of these issues could be reduced. Firstly if there is a technical person who will be directly involved in the dev at the time of scope to check everything is on the right track... that may help (in the last 12 months I have been gob smacked how often this doesn't happen). Hell, if the techincal person is presentable and articulate, let him/her come to the scope meetings or be involved in the sales process. Gee that sounds good! In my mind this is a double win, if handled properly. Then the major dev issues come up early, and if they dont, then it was missed by the dev anyway who can no longer point the finger.
Also picking your battles is always something we should be aware of. If you bitch and moan about everything, when i comes to a major issue the PM (or whoever) will just roll their eye's as if to say 'not this again'. Help the non devs to understand the business reason behind your arguement (delivery times & budgets are always good), after all you are suposed to be on the same side!
Its not all doom and gloom. I have been lucky enough to work with great teams such as Neotek, where although conversations got heated, they never got personal and it was always with the intent of making the code, product of processes better. Also the team i work with at Change are a very smart bunch for very different backgrounds where i would like to think we asa collective are learning alot from the others in the team (well I am!).
In short, just because you are a developer doesn't mean you have to be a nerd. Getting people on side with you early on is a big help when things get tight at the tail end of projects (or even just iterations!).
sorry just a bunch of random thoughts, but i thought i would throw them out. :)
One of the coolest thing is it is written by an up and coming software geek who is only 24 and has a healthy list of accomplishments already. Check out the work of Oren Eini (AKA Ayende Rahien) here