Grammar refresher – Using punctuation properly

I’ve found that I often use colons in technical documentation and emails, yet I’ve probably never ‘really’ understood quite how they or semicolons should be used.  I think my school days were after the golden age of English Grammar education (or maybe I just didn’t pay attention).


After reading this, I’m now clear on the picture.  I could rephrase that as follows (just to force a semicolon in):


I read this article; I’m now clear on the picture, and shall use semicolons to appear clever.

Learning through Anti-Patterns

I was gaining much (renewed) amusement through anti-patterns the other day when I took a look at Scott’s blog on ‘real world’ development approaches, and subsequently dug a bit further on management and development anti-patterns on Wikipedia.


You can also find a bit more info here.


It then struck me that although these are absolute classics that we’ve all seen (management ones ‘all the time’), I probably don’t know any developer (including myself) that could truly say they’ve never been guilty of at least one of these.  I’d go further and say that some of these anti-patterns can form an effective apprenticeship for software development, as you really need to know what not to do as much as what to do in regards to design and coding approaches.



  • Who hasn’t hard-coded?
  • Who hasn’t read an article on some cool way of doing things, then taken it all out of context and ended up doing something like error hiding, or mistaken delegation for poltergeists?
  • Who hasn’t thought (eugh – a world of pain will ensue if I try and get rid of this code) – the lava flow.

I could go on all day here as ‘so many’ of the Wikipedia anti-patterns ring true as something I’ve encountered (and still encounter) along the way.


Ultimately none have killed me so I guess therefore have made me stronger and hopefully a little wiser on what not to do.

SQL Server – Kill all users script

Found this the other day – for when you’re restoring SQL databases.  You need to kick out all current users right?


Run this little fella into your master database and away you go – just run this step before your restore.



CREATE PROCEDURE usp_KillUsers @dbname varchar(50as
SET NOCOUNT ON

DECLARE 
@strSQL varchar(255)
PRINT ‘Killing Users’
PRINT ‘—————–‘

CREATE table #tmpUsers(
spid 
int,
dbname 
varchar(50))

INSERT INTO #tmpUsers
SELECT 
[Process ID]    l.req_spid, db_name(l.rsc_dbid)
from master.dbo.syslockinfo l with (NOLOCK
where db_name(l.rsc_dbid) @dbname
group by l.req_spid, db_name(l.rsc_dbid)


DECLARE LoginCursor CURSOR
READ_ONLY
FOR SELECT spid, dbname FROM #tmpUsers WHERE dbname @dbname

DECLARE @spid varchar(10)
DECLARE @dbname2 varchar(40)
OPEN LoginCursor

FETCH NEXT FROM LoginCursor INTO @spid, @dbname2
WHILE (@@fetch_status <> –1)
BEGIN
    IF 
(@@fetch_status <> –2)
    
BEGIN
    PRINT 
‘Killing ‘ + @spid
    
SET @strSQL ‘KILL ‘ + @spid
    
EXEC (@strSQL)
    
END
    FETCH 
NEXT FROM LoginCursor INTO  @spid, @dbname2
END

CLOSE 
LoginCursor
DEALLOCATE LoginCursor

DROP table #tmpUsers



Colorized by: CarlosAg.CodeColorizer

Signs of Discontent? – Increased Food and Coffee

I like observing human behaviour at work and I’ve noticed recently that the amount of ‘junk’ food appearing in the dev pod has increased quite a bit.  People are also going for more coffee breaks (as far as I can see).  I may be imagining this, but I think it’s probably a good indicator of any or all of the following:



  • Boredom
  • Lack of enthusiasm for the current work
  • Need for stress relief (mucho long hours)

I’d have to admit the current project has its frustrations (integration work with a ‘less than extendable’ 3rd party product) and I’d probably rather be doing something else – so I’ll keep my eye on this and see what happens when the supplies run out!


I think there’s a bit of synergy here with the triangle of happiness.  My own experience is if you’re happy and engaged in what you’re doing then you often don’t even find the time to eat..