Hey guys! I'm here at code camp right now in CalState Fullerton and its been amazing. Kudos to the CodeCamp organizers!

Well.. i wast late abit.. so i wasnt able to listen to Woody and Michelle do their early morning speech(heheh, this is how one of the guys i met here in the camp described it). The registration was fast and really organized. I like how they have the parking directions posted everywhere because last year was a mess specially if you dont know the area(well, one can argue that if you can read parking lot signs then you wont have a problem since the SoCal codecamp website said that the parking for the event is on parking lot F).

One thing i noticed is that there is no schedule given to attendies. Last year they gave away papers containing schedules on where and when to find a specific talk. The good thing this year is that there is internet connectivity so you can check the posted schedule on the CodeCamp website which is non-existent last year.

I'll be updating this on every session i go to(hope i did this last year so that i could have warned people about not going to $%&*^* session(name encrypted to protect that persons ego) because he just reads slides and cant even give a good answer(sample response: "Uh, try searching that on the internet.. again i am just relaying to you what i have read online").

The notes below are from my scratchpad courtesy of Notepad++. This is a work in progress so dont bug me if theres typos on it. :D

9:00 - Mark Rosenberg's talk about Stored Procedure and below is the juice of his talk

[13 tips on  optimizing your stored procedures]
use stored procedures instead of heavy-duty querries
include set no count to on
call using fully qualified name
if you are returning a single integer user a return statement rather than returning one value as a record set
 Output value is for errors only, return value for values you want to be returned by the procedures.
SQL dot notations in 2005 helps in grouping objects in the database.
use the sp_executesql storedprocedure instead of execute
use the sp_executesql instead if temporary stored procedures
breakdown large stored procedures into smaller stored procedures
use @Table variables instead of #Table because #Table lives in tempdb and @table is created in memory.
avoid using ddl statements in your stored procedures
add with recompile option to create procedure statement if you know the query will change each time it id run
use the sql server profiler to determine which stored procedures have been recompiled to often
avoid using having clause
 << i think there are scenarios wherein a having clause is faster than a where clause.. so if you ask me i'll tell you that this suggestion is on a case to case basis.
use union all instead of union

#temp tables
dont use them
ok, sometimes bbut not often
 gettingresults from stored procedure(since you cant use recompile on them)
always create the taable then fill it(helps  with tempdb locking)can index (which can help performance)
dont use select into

@table variables
fster anf more efficient
not good for large datasets that would be saved to disk anyway
less table locking, logging
unfortunately no indexes, but you can have a primary key by using unique or primary key constraint.
much better during transactions
can only be used itn functions stored procedures and batches
when used in stored procedures there is less recompiling
cant apply alter table
cant use select into

dont use cursors if you can help it(use while clause instead)
filter as early in your stored procedure as possible
never select all the columns
sometimes a transaction can actually improve performance(but not often)

quote: "use print statements on querries too count performance" - i greatly disagree on this one.. i think its easier to look at it on the profiler plus adding print statements add clutter in your procedures.

10:15 - Robert Kozak's talk about Attribute Based Programming

He built a nice framework and demoed how to use the same set of classes to do different things. I love how he built his form by just mere UserControls and no code on the form itself. I agree with him when he said that seperation of concern is the way to go in builfing applications. I wasnt able to take down alot of notes because i was enamoured by the amount of cool stuff he was showcasing in his demo. i was able to take note of the third slide though.

 A properly designed framework will
    promote proper seperation between interface, implementation and user interface
    promote lose coupling and strong cohesion
    promote reusability of code(write once use everywhere)
    promotes RAD of production quality code
    wait theres more: automatic API for your application

1:00 - Bill Sheldon's ASP.NET Membership Customization << currently in progress