Blue Panda Week 1 Review

I finished my week one goals tonight, which means I’m on track. yay!  This week’s goals involved developing a complete user autherization system that implemented roles, registration, password changing, password recovery, user management admin interface, and full sitemap integration.  Other tasks included developing a set of nested master page templates, integrating the sitemap with roles autherization, and developing a structural stylesheet.

Thoughts:  This was insane.  I hit the normal learning curve that anyone hits with a new language, but overall this would have taken much, much longer and been less featureful and flexible in PHP.  Everything feels cleaner and less hackish than it did in PHP, I tend to believe this is because C# is OOP from the ground up, where as PHP has OOP as a half-hearted option.

What’s up in week 2?

Week two will be a lot of fun for nerdiness.  I’ll start building out some of the “guts.”  I’ll be utilizing normal OOP concepts.  The big stuff I’ll be using this week are abstract classes, interfaces, datagrids, repeaters, and building out a full DAL to support an n-tiered approach.  I’ll also be diving into using a few basic ajax controls, mainly the update panel. Photo uploading, image resizing, and storage are also probably going to happen in week 2 if things go as planned.

Week 2 is really a week of software engineering with some implementation thrown in.  Week 3 & 4 will be more implementation.  Week 5 will integrate with facebook.  Week 6 will involve report tools and dynamic image generation.  Week 7 will involve building my own classes revolving around the provider pattern and implementing those classes.

SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.Columns where TABLE_NAME = ‘YOUR_TABLE_NAME’;

I haven’t touched SQL Server in a couple of years since 90% of my database work is mySQL at the Tennessean. However, most of the career paths open to me appear to use SQL Server at some level, so I’m going to begin dedicating myself to relearning and brushing up on the SQL Server specifics through pursuit of some industry certifications and take some great blog-worthy notes while at I’m it.

Now for the excuses…
I’ve a had a crazy couple of weeks that have made it nearly impossible to post.  The first reason is working some crazy long weeks at the work…I was racking up between 20 and 30 hours overtime a week for a while.  The second reason is that my home computer (a laptop), broke and required some creative <a href=”http://www.epemag.wimborne.co.uk/solderfaq.htm”>soldering</a> to fix.  Lastly,  and most importantly (and sadly), my Papaw died suddenly and unexpectedly.

Papaw was very close to me, and its probably his fault I got interested in the technical stuff. He  was very smart, self-educated, highly technical, and hardworking man.  He was also very soft spoken,but strong-willed and moral.  I hope live up to his memory and legacy.

In a nutshell I had a death in the family, a broken computer, and crazy overtime and all of these  ended up in me putting blogging on the back burner.  Things are starting to settle down, so I should be back to blogging a couple times a week now.

Thanks for reading.

I admit it, I’m a cheap dreamer. I don’t aspire to the finer things in life like I should…I just want to be secure in life and have cool projects to work on. As far as cars go, I’ve always wanted these three vehicles - a DeLorean, a `57 Cadillac Ambulance, and a Baja Bug. DeLoreans are just cool, the Ambulance I want for the nerdiest of reasons, and the Baja Bug I want as a daily driver.

As fate would have it, there’s a Baja Bug for sale as I already mentioned. Here’s a list of reasons why I like it, followed by the reason I haven’t snatched it up yet.

1) Its affordable - For cars, $4000 isn’t really a lot of cash.

2) Its affordable to drive, Baja Bugs with stock engines get pretty good milage.

3) Its unique. You don’t see to many of them, and its almost required that you personalize your Baja in paint and bolt-ons. A vanilla Baja Bug paint job is unheard of.

4) It can offroad and out perform a jeep in almost every case, and for a fraction of the cost.

5) Its easy to repair and tinker with. Parts are cheap, and there’s so little that can go wrong that even very novice mechanics like myself can usually fix it. Air-cooled engines for the win.

6) This particular Baja needs a better Baja front end and suspension — I can totally do this, which would satisfy my need to tinker with after I got it. I’d also do some electrical work because I’m actually good at that, but that’s secondary (Don’t you think it would look cooler with a whip antenna?).

7) With a little love, they can go on living forever. Which is great because that’s what I intend to do (live forever )

Now for the reason I haven’t bought it…

I have truck that’s ok (even if it does guzzle gas ) and I have student loans that are more important than toys. I hate being responsible, but its very important that I get them paid off as quickly as possible. Besides, by the time they’re actually paid off the Chevy Volt will probably be on the market and I can buy a pure electric car anyway.

What’s coming up on MMcCann.com this week? I’ve got two entries scheduled. One is really long and about Product Requirements Documents (PRDs), the other is about taking the Risk Management stuff I learned from ROTC and applying it to civilian management/software development.

One of things I try to do, usually unofficially, is to do what they called an AAR (After Action Report) after I finish a project. In the military world, you perform AARs in a group setting after a mission and discuss what went right, what went wrong, what techniques and processes should be kept, and how to improve in the future.

If you’re honest and comfortable with the people you’re working with, this can be a great tool for process development and lead to smoother, better product development and launch in the future.

Here’s how I’ve conducted them in the past. Get everyone in a room, and start off listing a couple of things that went right — no matter how badly the project went. There’s a three point minimum here. I find that starting off with positives puts everyone into a more open mindset and helps them become less upset during the next phase, negatives.

In the next phase, talk about things that went wrong or things that can be improved. Spend as much time as you need here but don’t let it degrade into complaining or riding points into the ground. The goal is to find out what went wrong and how to improve it, there shouldn’t be any blame, attacking, or obsessing over any one point here.

Finally, go back and find a few more positive things. Ideally, your positives should either match or exceed the negatives. It is a lot easier to spot things that went wrong than it is things that went right, so this may require some initial coaching but once people get the hang of it and see that they have a voice in improving things they really will get into it.

Naturally, the most important step is after the AAR meeting where you analyze what is said and figure out how to apply changes to improve the processes in the future.

I would also like to mention that AARs sometimes devolve into day-long affairs. Speaking from experience, don’t let this happen. If you do, one of two things is going to happen. The first is that you’re going to get too much information and you won’t be able to make use of it all - and then people become frustrated in the long run. The second possibility is that people become frustrated that its taking so long, tempers can flare, feelings can get hurt, and then you don’t get anything useful. I like to keep them between an hour and hour and half at most.

I was hoping mySQL had some method of counting occurrences of a string within a string, but much to my chagrin it doesn’t have this. Luckily, Andrew Hanna posted a great custom mySQL function that does exactly this. For the sake of posterity and my own reference, I’ve posted his function below.

DROP FUNCTION IF EXISTS substrCount||
CREATE FUNCTION substrCount(s VARCHAR(255), ss VARCHAR(255)) RETURNS TINYINT(3) UNSIGNED LANGUAGE SQL NOT DETERMINISTIC READS SQL DATA
BEGIN
DECLARE count TINYINT(3) UNSIGNED;
DECLARE offset TINYINT(3) UNSIGNED;
DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET s = NULL;

SET count = 0;
SET offset = 1;

REPEAT
IF NOT ISNULL(s) AND offset > 0 THEN
SET offset = LOCATE(ss, s, offset);
IF offset > 0 THEN
SET count = count + 1;
SET offset = offset + 1;
END IF;
END IF;
UNTIL ISNULL(s) OR offset = 0 END REPEAT;

RETURN count;
END;

usage is this…

SELECT substrCount('/this/is/a/path', '/') `count`;

The super-trick…wrap it in the pre tag. Common sense, yeah…

1
2
3

function print_mm($val)
{
  echo '

';
  print_r($val);
  echo '

‘;
}

On a side note, I’m thinking about putting up some full classes/objects in the not
to distant future. I just need to go through them and make sure there’s no “secret”
business logic in them first. Look for the first few around the beginning of August.