This year I attended SQL PASS in Seattle, Washington for the first time. The experience exceeded my expectations, and my expectations were high. If you know me at all you know that I'm typically guilty of holding exceedingly high expectations from anything training related so saying that the conference exceeded my expectations really is something.
The quality of the presentations given were all very high and the knowledge demonstrated by the speakers was beyond anything I've seen before. Without a doubt SQL PASS is where you go to meet the experts. I learned so much in-depth knowledge about advanced internals like workspace memory, IO, and residuals & predicates that the time and money it took to attend will be made back in the first week that I'm back at work. I thank everyone who gave their time and talent to SQL PASS as there's no doubt it takes a huge amount of effort to pull off something that great.
Now, I'm not saying everything was perfect. The big brother/sister program was a failure from my perspective. I never met either my big brother or anyone in my "first timer" group. I was where I was supposed to be, but so were about a thousand other people and there were rooms big enough to hold maybe half of that in a usable manner. I have no idea if my big brother even showed up - according to the group leaders I found he wasn't there. I can't say I was upset about it, but if I've got any feedback to offer for areas of improvement I think that would be it - fix that whole program or just kill it off. The first timer networking session with Don Gabor was well run though, and certainly valuable.
Overall it was a fantastic week in Seattle. I met some new people, reconnected with some others, learned a lot, and for the first time ever; felt a sense of community. I think it's the sense of community which has really left me feeling motivated. I want that feeling to continue and thus I've committed to posting up a technical series!
I've decided that not a lot of people know about the magic that is MSX - TSX SQL Agent setups and thus I'll be blogging a lot about that in the near future. It's my way of saying thanks and giving back to the SQL Server community that has given so much to me.
Sunday, 16 October 2011
Sunday, 1 May 2011
Moving On Up
I'm officially no longer a DBA today, I'm now a "Database Developer"!
In the work-sphere of Information Technology I think this is higher than a lowly administrator, but who knows? I've seen enough TSQL code in my 5 years as a DBA to know that there are a LOT of "database developers" who would be better off using Google to find their code. I'm not kidding but I wish I was.
I'm thrilled to know that this change means no more on-call or after hours maintenance. I look forward to being able to do whatever I want to do whenever I want to do it. My wife does too ;)
I'll take a good pay cut giving up the on-call ball & chain but since time is the only finite resource we've got it's therefore the most precious and I make the trade with no reservations at all.
I'm also really looking forward to being able to be creative again. When I started in IT creativity was a great asset but leaving now I feel it's more of a liability. Creative thinkers who can see and plan beyond the basics have an upward battle whenever they try to go above and beyond. It seems that the larger IT gets, the less flexible it gets. Creative solutions become harder and harder to implement and take more and more selling/politicing/nurturing than one can reasonably put out. When one can see how a more creative solution would work better for less money and with less management required but can't implement it for "soft" reasons it's very demotivating; almost depressing. Live in an environment like that for too long and one becomes bitter.
I'm absolutely thrilled to be moving into an environment where others are willing to listen when a creative idea comes forward and can be demonstrated. The ability to honestly and openly debate technical solutions with my peers on a daily basis has me grinning from ear to ear. It's like a dream come true.
In the work-sphere of Information Technology I think this is higher than a lowly administrator, but who knows? I've seen enough TSQL code in my 5 years as a DBA to know that there are a LOT of "database developers" who would be better off using Google to find their code. I'm not kidding but I wish I was.
I'm thrilled to know that this change means no more on-call or after hours maintenance. I look forward to being able to do whatever I want to do whenever I want to do it. My wife does too ;)
I'll take a good pay cut giving up the on-call ball & chain but since time is the only finite resource we've got it's therefore the most precious and I make the trade with no reservations at all.
I'm also really looking forward to being able to be creative again. When I started in IT creativity was a great asset but leaving now I feel it's more of a liability. Creative thinkers who can see and plan beyond the basics have an upward battle whenever they try to go above and beyond. It seems that the larger IT gets, the less flexible it gets. Creative solutions become harder and harder to implement and take more and more selling/politicing/nurturing than one can reasonably put out. When one can see how a more creative solution would work better for less money and with less management required but can't implement it for "soft" reasons it's very demotivating; almost depressing. Live in an environment like that for too long and one becomes bitter.
I'm absolutely thrilled to be moving into an environment where others are willing to listen when a creative idea comes forward and can be demonstrated. The ability to honestly and openly debate technical solutions with my peers on a daily basis has me grinning from ear to ear. It's like a dream come true.
Thursday, 2 September 2010
When You Can't Find a Hack, Make Your Own
I recently got wind of sweet deal on a Planet Eclipse eTek3 paintball marker and I took it. The gun is great. It's well designed, light, easy to use, and it's electronic.
Being me I naturally started to look into what upgrades, customizations, and hacks were available for it. I was surprised to find there were no hacks AT ALL to be found anywhere in Google for it. I figured at least people would be doing simple things like putting in circuits to simulate rapid trigger pulling... but nope; nothing out there. I did find all sorts of other parts I could spend large sums of money on to swap out the "board" (aka single sided PCB with a single MCU on it- this isn't rocket science) to something with more blinking lights and LCD's! Oooh boy! Oh no, wait. I'm not a 13 year old kid and I'm not dazzled by blinking lights and the ability to modify the colour of my OLED screen or -GASP- 2 MIPS!
All these wickedly overpriced and overhyped electronics did get me thinking so I opened up the marker and looked at the board.
I was pleasently surprised when I found that the heart of the stock board was a PIC18F1320 MCU (10 MIPS BTW). I know the PICs well and I immediately located the ICSP traces on the PCB. After a little rummaging around in the basement I found my USB Willem with ICSP header and wired the two together. I dumped the PIC and was not terribly surprised to find that the application code and bootloader were both read and write protected. I was more surprised to find that the on-chip eeprom memory was readable and writeable.
The hex values I saw were few enough that I thought they could easily map back to the variables the gun offered (trigger de-bounce, balls per second caps, dwell, shots to trigger auto-fire, etc.) so I reset the board to defaults, dumped the hex values and repeated the process making single changes. It was pretty easy to see what was what and I quickly figured out the math behind the hex -> real world value and the checksum routine. (8bit math FTW!)
Once I was pretty confident I could make a change and set the proper checksum I modified the values and wrote back to the PIC. I fired up the gun and verified that I had indeed changed the variable correctly (the firing mode to be safe) and I gave myself a pat on the back for spending about 4 hours to do what could be done with the board still in the gun in about 30 seconds. :p
The obvious goal was to see if I could put in a value that exceeded what the stock board would allow. For example, the stock board won't allow you to go over 15.4 balls per second in the ramping mode. An aftermarket board will go up to the theoretical physical limit of the gun which is ~25bps. I made the change, flashed the settings back, and fired up the gun. I was VERY excited to see the gun flash twice in the tens indicator proving that I had indeed just set the gun to shoot at 20bps - 4.6bps faster than "allowed"... for free.
Of course, just because the little blinking lights says it'll shoot 20bps doesn't mean it will so I loaded up some reballs and tested. WOW! 20bps is stupidly fast!
Up next: tweaking the values to make a full auto mode for the big game Sept 19 :D
P.S. I thought about detailing the entire hack along with how to decode the hex values and calculate the checksum but I think it's better not to. If you're not smart enough to read this post, do the work, and figure out the math on your own it's probably better off that you don't do it.
EDIT: Added links
Being me I naturally started to look into what upgrades, customizations, and hacks were available for it. I was surprised to find there were no hacks AT ALL to be found anywhere in Google for it. I figured at least people would be doing simple things like putting in circuits to simulate rapid trigger pulling... but nope; nothing out there. I did find all sorts of other parts I could spend large sums of money on to swap out the "board" (aka single sided PCB with a single MCU on it- this isn't rocket science) to something with more blinking lights and LCD's! Oooh boy! Oh no, wait. I'm not a 13 year old kid and I'm not dazzled by blinking lights and the ability to modify the colour of my OLED screen or -GASP- 2 MIPS!
All these wickedly overpriced and overhyped electronics did get me thinking so I opened up the marker and looked at the board.
I was pleasently surprised when I found that the heart of the stock board was a PIC18F1320 MCU (10 MIPS BTW). I know the PICs well and I immediately located the ICSP traces on the PCB. After a little rummaging around in the basement I found my USB Willem with ICSP header and wired the two together. I dumped the PIC and was not terribly surprised to find that the application code and bootloader were both read and write protected. I was more surprised to find that the on-chip eeprom memory was readable and writeable.
The hex values I saw were few enough that I thought they could easily map back to the variables the gun offered (trigger de-bounce, balls per second caps, dwell, shots to trigger auto-fire, etc.) so I reset the board to defaults, dumped the hex values and repeated the process making single changes. It was pretty easy to see what was what and I quickly figured out the math behind the hex -> real world value and the checksum routine. (8bit math FTW!)
Once I was pretty confident I could make a change and set the proper checksum I modified the values and wrote back to the PIC. I fired up the gun and verified that I had indeed changed the variable correctly (the firing mode to be safe) and I gave myself a pat on the back for spending about 4 hours to do what could be done with the board still in the gun in about 30 seconds. :p
The obvious goal was to see if I could put in a value that exceeded what the stock board would allow. For example, the stock board won't allow you to go over 15.4 balls per second in the ramping mode. An aftermarket board will go up to the theoretical physical limit of the gun which is ~25bps. I made the change, flashed the settings back, and fired up the gun. I was VERY excited to see the gun flash twice in the tens indicator proving that I had indeed just set the gun to shoot at 20bps - 4.6bps faster than "allowed"... for free.
Of course, just because the little blinking lights says it'll shoot 20bps doesn't mean it will so I loaded up some reballs and tested. WOW! 20bps is stupidly fast!
Up next: tweaking the values to make a full auto mode for the big game Sept 19 :D
P.S. I thought about detailing the entire hack along with how to decode the hex values and calculate the checksum but I think it's better not to. If you're not smart enough to read this post, do the work, and figure out the math on your own it's probably better off that you don't do it.
EDIT: Added links
Monday, 10 May 2010
Easy Workaround for Oracle Linked Server Problem with TIMESTAMP(6) Column
I've got a lot of SQL servers at work. And those servers link to a lot of other servers. MySQL, Oracle, SQL 2005, 2008, etc.
For the most part linked servers are frowned on from my perspective but I can't keep people from getting things done so they do get setup. Most of the time the four part naming convention works just fine although MySQL in particular seems to need OPENQUERY Oracle never has... until today.
For some reason running a query against an 11g R1 Oracle DB kept returning this:
Msg 7354, Level 16, State 1, Line 1557
The OLE DB provider "OraOLEDB.Oracle" for linked server "XYZSERVER01" supplied invalid metadata for column "CREATEDDATE". The data type is not supported.
The column type in Oracle was timestamp(6) and no matter of cast or convert would avoid the problem. Selecting without the offending column still produced the error. I was about to start looking for newer OraOLEDB drivers when I thought about the MySQL issue. I also did a little checking and found this KB:
SELECT
*
FROM OPENQUERY(XYZSERVER, 'SELECT COUNT(foobar) FROM XYZSCHEMA.XYZTABLE')
Worked great; problem solved :)
I'm also going to pose the solution to the forum post below as it seems to be related...
http://social.msdn.microsoft.com/Forums/en/transactsql/thread/fd1cb0c8-efb5-4a94-b00d-b2aeb91dd771
For the most part linked servers are frowned on from my perspective but I can't keep people from getting things done so they do get setup. Most of the time the four part naming convention works just fine although MySQL in particular seems to need OPENQUERY Oracle never has... until today.
For some reason running a query against an 11g R1 Oracle DB kept returning this:
Msg 7354, Level 16, State 1, Line 1557
The OLE DB provider "OraOLEDB.Oracle" for linked server "XYZSERVER01" supplied invalid metadata for column "CREATEDDATE". The data type is not supported.
The column type in Oracle was timestamp(6) and no matter of cast or convert would avoid the problem. Selecting without the offending column still produced the error. I was about to start looking for newer OraOLEDB drivers when I thought about the MySQL issue. I also did a little checking and found this KB:
SELECT
*
FROM OPENQUERY(XYZSERVER, 'SELECT COUNT(foobar) FROM XYZSCHEMA.XYZTABLE')
Worked great; problem solved :)
I'm also going to pose the solution to the forum post below as it seems to be related...
http://social.msdn.microsoft.com/Forums/en/transactsql/thread/fd1cb0c8-efb5-4a94-b00d-b2aeb91dd771
Subscribe to:
Posts (Atom)