Afgelopen week heb ik een naamswijziging aangevraagd voor het bedrijf dat ik onlangs ben gestart. M’n bedrijf, Freezco.com, heeft nu 2 weken onder die naam geopereerd en is nu officieel omgedoopt tot de naam Vinit. Het grootste voordeel hiervan is, is dat deze naam redelijk uniek is.

Hij wordt namelijk nog niet door een ander bedrijf gebruikt, hierdoor is de kans klein dat er in een later stadium problemen optreden met namen en domeinen.

Tegelijkertijd met de omdoping van de naam heb ik de domeinen vinit.nl en vinit.mobi aangevraagd. Binnenkort zal de bedrijf website op vinit.nl te vinden zijn. Ook zal er ter zijner tijd een pocket pc variant komen welke op vinit.mobi zal kunnen worden bekeken. Nu ik toch domeinen aan het aanvragen was, heb ik ook maar jan-v.mobi aangevraagd. Binnenkort zal dit weblog dus ook te volgen zijn op de pocket pc, aangezien ik hier ook een mobiele variant voor ga maken.

Toch weer goed voor m’n mobiele ervaring. Ook had ik nog freezco.mobi kunnen aanvragen, maar het domein freezco.com zal ik in het vervolg niet meer of minder gaan gebruiken.
Oorspronkelijk, 9 jaar geleden, was het de bedoeling hier m’n bedrijf website op te maken, maar dat is nu dus veranderd. Vandaag heb ik met m’n nieuwe designer het een en ander doorgenomen. Zelf ben ik blij dat hij wat voor mij kan en wil betekenen. Binnenkort dus meer over de ontwikkelingen in het kers verse bedrijf Vinit.

Eindelijk dan weer fit thuis. Gistermiddag ben ik weer in Lemmer aangekomen vanaf m’n vakantie adres in Antwerpen.

Samen met Martijn ben ik daar 3 dagen geweest om vakantie te vieren. Afgelopen woensdag zijn we rond 11 uur vertrokken vanuit Lemmer. De rit duurde niet zo heel lang, aangezien er rond dat tijdstip eigenlijk geen files zijn. Bij de grens hebben we de route navigatie aan gezet, waardoor we in 1x goed reden naar het hotel.

Het hotel was niet echt breed, maar de kamer waar wij op zaten was wel king-size. 2x een 1,5-persoons bed, enorm veel loopruimte, een badkamer en een losse toiletruimte. Hier weren we wel mee verrast. Dit kwam waarschijnlijk omdat het verblijf redelijk last-minute was geboekt. Het maakt niet uit, wij waren er in ieder geval behoorlijk tevreden mee. Het hotel was op ongeveer 2 minuten loop afstand van het centrum gelokaliseerd. We hoefde dus niet een taxi of metro te nemen om op stap te kunnen. Nou ja, wat doe je de eerste uren dat je in een nieuwe stad bent?

Juist, je gaat de leukste kroegen op zoeken waar je veel bier kunt nuttigen. Nou, er zijn veel gezellige kroegjes, restaurants, bistro’s en dergelijke in het centrum van Antwerpen. Nadeel was wel dat er op woensdag helemaal niets te doen is. De stad leek wel uitgestorven. In de meeste kroegjes zaten alleen maar wat personeelsleden aan de bar.

De afgelopen tijd merkte ik op dat de grootte van een bepaalde database waar ik vaak mee werk behoorlijk groot wordt in korte tijd. Om te onderzoeken aan welke tabel dit te wijten was moest ik weten hoe groot iedere tabel was. Dit kan uiteraard door de eigenschappen van iedere tabel op te vragen, maar als je meer dan 50 tabellen hebt duurt dit veel te lang.
Dat moet ook automatisch kunnen. Ik hoefde niet lang te zoeken voor een script dat ik zocht. Ene Zxtreme had al een mooi script on-line geplaast, te bezichtigen op deze website: https://www.planet-source-code.com/vb/scripts/ShowCode.asp?txtCodeId=732&lngWId=5.

Hiermee kun je precies zien hoe groot (in KB’s) je tabellen zijn. Eigenlijk komt het er op neer dat je een soortgelijke query als die van hieronder moet uitvoeren.

DECLARE @TempTabel TABLE ( [Name] NVARCHAR(255), [Rows] INT, [TabelGrootte] NVARCHAR(50), [Used] NVARCHAR(50), [IndexUsed] NVARCHAR(50), [Unused] NVARCHAR(50) ) 
INSERT INTO @TempTabel EXEC sp_msforeachtable 'sp_spaceused "?"' SELECT * FROM @TempTabel

Zodra je dit in je database doet krijg je per tabel precies te zien wat de grootte er van is. Wel handig. Zo kwam ik er vandaag achter dat er een historie tabel veel oude data bevatte dat wel weg kon.

Vandaag ben ik veel interessante artikelen tegen gekomen op het internet. Een daarvan is een LINQ to SQL performance test. Blijkbaar had Derik Whittaker wat tijd over en heeft een performance test gedaan met verschillende manieren van de data-access op te bouwen. Het volledige artikel is op z’n weblog te lezen: https://devlicio.us/blogs/derik_whittaker/archive/2008/03/14/playing-with-linq2sql-and-various-performance-tests.aspx

Z’n conclusie is dat wanneer je een generieke DataContext gebruikt in je code, je enorm veel performance verlies hebt. Het hoe en waarom is hij nog niet achter, maar de uitvoer is ongeveer 7x langzamer dan wanneer je een ‘goede’ DataContext gebruikt.
In dit bovenste voorbeeld wordt een generieke DataContext gebruikt, de tweede een specifieke welke alleen voor de betreffende tabel kan worden gebruikt.

DataContext db = new DataContext(new SqlConnection(connectionString)); 
IEnumerable sports = from s in db.GetTable() 
select s;

SportsDemoDataContext db = new SportsDemoDataContext(new SqlConnection(connectionString)); 
IEnumerable sports = from s in db.Sports 
select s;

Na 10.000 keer de query uit te voeren blijkt dat het 2e voorbeeld met een gemiddelde van 13022 miliseconden wordt uitgevoerd en het 1e voorbeeld met een gemiddelde van 78042 miliseconden wordt uitgevoerd.
Een behoorlijk verschil dus. Zelf maak ik ook gebruik van zo’n generieke DataContext uit het eerste voorbeeld. Dit omdat je dat mooi in je Base.cs kunt opnemen. In de eerstvolgende performance-tuning update zal ik dit aanpassen zodat iedere klasse z’n eigen, juiste, DataContext krijgt.
Het is toch mooi dat sommige mensen hier de tijd voor nemen om te testen. Zelf zou ik dat namelijk nooit doen, maar ik doe er wel weer m’n voordeel mee.

Vandaag kwam ik een website met een vette applicatie tegen, namelijk LINQpad. Zoals de naam misschien wel doet vermoeden, kun je met deze ‘pad’ zelf LINQ queries maken en uitvoeren. Deze applicatie ondersteunt LINQ to SQL, LINQ to XML en LINQ to Objects. Door het uitvoeren van verschillende queries (op je eigen data) kijken of het resultaat dat je krijgt gewenst is. Zo kun je dus mooi oefenen om de LINQ-syntax te beheersen. De website is te bereiken op http://www.linqpad.net/

Sinds afgelopen week is er een nieuw gratis magazine verkrijgbaar, namelijk TechNet Magazine. Dit blad bestaat al geruime tijd in het buitenland, maar nu is dan ook de nederlandse versie verschenen van het blad. Ik kreeg de eerste editie geleverd bij m’n .Net Magazine. Dit keer stond Windows Server 2008 centraal, maar ook andere onderdelen, zoals SharePoint en Visual Studio en .Net wordt hierin behandeld. Ik heb het even doorgebladerd en het lijkt wel redelijk luchtig geschreven. Ongeveer net zoals het .Net Magazine. Je kunt het dus lezen zonder dat je er een middag voor uit hoeft te trekken om alles te kunnen begrijpen. Aanmelden kan via de link https://www.microsoft.nl/technetmagazine. Het blad verschijnt 6x per jaar. Wel jammer dat al die bladen ongeveer tegelijkertijd uit komen. Nu had ik in 1 week het MSDN Magazine, .Net magazine en het TechNet magazine. Een beetje teveel van het goede dus. Ik hoef me in ieder geval dus niet te vervelen.

Afgelopen week kwam ik in m’n RSS-feeds een mooi artikel tegen met daarin enkele richtlijnen hoe en wanneer je LINQ kunt gebruiken. Om eerlijk te zijn heb ik het alleen maar even snel door gescanned, omdat ik nogal druk ben de laatste tijd, maar het lijkt me een interessant stukje om te lezen. De link van het artikel is https://blogs.msdn.com/mirceat/archive/2008/03/13/linq-framework-design-guidelines.aspx. Zodra ik zelf tijd heb zal ik het ook doorlezen, maar dat zit er vandaag waarschijnlijk niet meer in.

Afgelopen week las ik iets over tabel fragmentatie. Hier had ik eigenlijk nog nooit van gehoord. Wel van bestandsfragmentatie en dergelijke, maar nog nooit dat tabellen ook gefragmenteerd kunnen raken.
Op zich wel logisch natuurlijk als er veel in wordt gewijzigd.
Belangrijke punten waaraan je tabel fragmentatie aan kunt herkennen zijn:

• Langzame performance
• Veel disk activiteit
• Weinig gebruik van caching

Fragmentatie treedt op wanneer er data wordt gewijzigd met INSERT, UPDATE en DELETE statements.
Deze queries kunnen ervoor zorgen dat er ‘gaten’ in de pages van SQL ontstaan. Met de query DBCC SHOWCONTIG` kun je controleren hoeveel fragmentatie in de tabellen van je database is.

Zelf was ik geschokt toen ik de resultaten zag. Er was nu al redelijk wat fragmentatie ontstaan in de tabellen van dit weblog. Dit is dan wel in de ontwikkel omgeving, maar toch.
Om de fragmentatie te reduceren kan er gebruik worden gemaakt van twee populaire queries, namelijk DBCC INDEXDEFRAG en DBCC DBREINDEX.
Deze twee statements kunnen in een Maintenance Plan worden opgenomen die bijvoorbeeld iedere week of maand (afhankelijk van het gebruik van de database) kan worden uitgevoerd. Zodoende blijven de indexen up-to-date en zal de fragmentatie minimaal blijven. Belangrijk om te weten is dat het DBCC SHOWCONTIG-statement in SQL Server 2005 is vervangen door sys.dm_db_index_physical_stats

Onlangs heb ik iets ‘uitgevonden’ bij het maken van LINQ-queries. Deze queries worden namelijk uitgevoerd zodra je een item zoekt in de verzameling van objecten, dus eigenlijk pas in een foreach-loop.

Ik had een ‘kleine’ fout gemaakt tijdens het ontwikkelen van dit weblog, waardoor het voor kon komen dat de database meer dan 7000x in een kwartier kon worden aangeroepen als er 2 gebruikers 20 pagina’s bekeken. Dat is natuurlijk niet echt bevorderlijk voor de performance, waardoor je soms wel tussen de 10 en 30 seconden moest wachten voordat er een pagina zichtbaar was.

Nadat ik dit design issue er uit had gewerkt, waardoor de database een stuk minder wordt aangeroepen en de performance dus ook is verhoogd, ben ik op zoek gegaan hoe ik LINQ-queries direct kan uitvoeren. Dit blijkt niet zo enorm lastig te zijn. Je kunt de query gelijk in een array zetten, waardoor alle objecten gelijk worden opgehaald, dus de database wordt aangeroepen. Nadat de objecten in de array staan zal de database niet nogmaals te hoeven worden aangeroepen.
Bij deze een voorbeeld query van zo’n cast.

var query = (from collectie in dataContext.GetTable() orderby collectie.Item.CreatieDD ascending select collectie).ToArray();

Een voordeel hiervan is dat alle database acties in de DAL blijven. Nog wel belangrijk om te weten is dat er nog steeds een IEnumerable wordt teruggegeven. Je hoeft dus verder niets in je code te wijzigen.

Vandaag ben ik afgestapt van ReSharper, mede omdat dit Visual Studio enorm vertraagd. Ook denk ik dat het de oorzaak is dat m’n VS2008 installatie corrupt is geraakt. Het crashed bij het aanpassen van CSS-bestanden en heeft (nog) geen LINQ support. Nu draai ik dus weer VS2008 zonder ReSharper. Qua performance is het systeem nu wel vooruit gegaan. De reden waarom ik ReSharper had geinstalleerd was de IntelliSense, aangezien deze anders werkt in VS2008. Met de standaard instellingen moet je continu op [Ctrl]+[Spatie] indrukken om het menu te zien. Dit wil ik niet. Ik wil continu na een .-teken het IntelliSense menu zien. Liever ook bij het invoeren van variabelen, zoals je ook in VS2003 en VS2005 had. Die bood ReSharper. Nu ik die software niet meer heb moest ik dus zelf bij de instellingen van VS2008 op zoek. Uiteindelijk heb ik gevonden hoe ik IntelliSense iets beter kan laten presteren. Als je in VS naar Tools|Options|Text Editor gaat zie je daar 3 checkboxes die aangevinkt kunnen worden. Nadat je dit hebt gedaan verschijnt IntelliSense nadat je een .-teken hebt ingevoerd. Zelf heb ik nog niet gevonden hoe ik het standaard op kan laten komen wanneer ik variabelen intik. Dat is wel jammer, maar het werkt zo in ieder geval iets minder frustrerend. Wel raar dat ze dit in VS2008 zo enorm hebben gewijzigd. Het zal wel met performance of zo hebben te maken. Jammer, aangezien ik graag gebruik maak van IntelliSense.