Author: way0utwest

I heard about the Stackoverflow Dev Days earlier this year and thought it was an interesting idea. We had talked about doing a similar type event for SQLServerCentral, or even at my other company, SQLShare, but the logisitics and costs are substantial. As a way of researching the due diligence of such an event, I headed to Austin on Tuesday for the Austin Dev Days on Wednesday. A quick, 36 hour trip for me to see some great speakers and see how the event is run.

I had never been to Austin, and after a morning run (day 400!), I walked over to the Monarch Event Center. It’s a small facility, with about a 200 seat movie theater, an open space with a stage that could likely seat 300, and a few other rooms. I counted the numbers during the keynote and got to 162, and it seemed that a few more people walked in as the event was going on.

The format was a series of 50 minute talks. There were breaks between sessions, as well as a break for lunch. The doors didn’t open until just before 9, and everyone milled around in the lobby before then. No coffee, or food, provided then, so I had to duck around the corner for a cup of java.

Registration was simple. I’d bought a ticket on the web, and got a copy in email. I printed it out, and it had a bar code on it, which had me expecting some cool application to track who came. Instead when I went to the desk, someone looked at my ticket and marked my name off a list. Not so high-tech! Still it worked, and I got a DevDays bracelet and a blank name tag that I filled out with a sharpie. It was a low budget event, with limited SWAG and sponsors. Fog Creek Software and SmartBear had tables set up with a few people explaining their products.

The speaker list was interesting. I hadn’t heard of most of the speakers, which isn’t surprising since I’m not in the developer community as much as the SQL community. I wasn’t sure about some of the topics, but I was surprised in a few cases. Joel Spolsky, of Joel on Software, opened up with a humorous keynote that had people laughing. I’ve followed Joel’s writing for years, and heard him speak a few times. He’s funny, and interesting, and worth going to see if you get the chance.

The first talk was on Python, by a local Austin developer that does a lot of scientific computing. I wasn’t sure if I’d like the talk, but I found it interesting. The focus was on a 21 line snippet of Python code that implements a spell checker and suggests replacements for misspelled words. It’s kind of amazing to walk through that code, which was written by Peter Norvig of Google. It’s worth reading through his essay, and I was amazed. The talk was an intro to Python tutorial, and I found it very interesting. It finished with a demonstration of a real-time application analyzing the speaker’s voice in a few graphs written in Python. Very impressive. An image from his talk:

Other talks during the day were on various topics. CouchDB, which probably has a place, but I’m not sure is a great replacement for many relational engines. There was one on iPhone development where the speaker built a small clock application. It seemed that it isn’t much harder to target the iPhone than other platforms, but it does require working through some hassles with Apple. There was a talk on ASP.NET MVC, which seems like a good idea, but I’m still wary of the data binding. Joel also have a talk on FogBugz and Kiln, a new source control product they are hosting, and a short talk on StackOverflow. A good overview of jQuery was slipped in as well.

There was a talk at the end of the day on code reviews, which I almost skipped. I haven’t done them in years, and in some discussions with people at lunch, many others didn’t do them either. The speaker works for SmartBear, which sells code review tools, but the talk wasn’t about their tool. Instead it gave some good reasons why code reviews are good, and I found myself surprised by them. It was an entertaining, and informative talk.

There are lots of tweets about Dev Days, along with some pictures, if you’re interested. There are more events coming the rest of the month in other cities.

Overall it was a good trip, and I had a good idea of how the event might work for SQLServerCentral. I’m not sure if we’ll do one, but we have some things to discuss. We, meaning SQLServerCentral and Red Gate, plan to continue to support SQLSaturday, DevTeach, and various other events all around the US and other countries. We’ve sent speakers and money to both free and paid events, and hope to do more next year.

I saw a post recently where someone was asking how to separate out all indexes from the data into a separate NDF file. This was the same post that I wrote about recently with the thread myth.

The poster seemed confused on a couple points. The first was that he or she thought that they could separate out the clustered and non-clustered indexes from the data.  That’s alone makes me think that this user is not advanced enough to work with multiple filegroups if they don’t understand the table v clustered index structure.

The second thing was thinking a separate file improves performance if the indexes are moved. This can improve performance, but a couple things need to take place.

1. The indexes need to be heavily used at the same time as other data. You are trying to separate out items that are heavily used concurrently. If I need 1,000,000 rows from a structure (table or index) now and another 5,000,000 rows when that operation completes, I’m not helping things if I separate these items. If two users are actually accessing this data at the same time, or one user with a join, then separate files can help.
2. You need separate physical disks. A lot of people don’t think this through properly. It doesn’t mean two volumes or drive letters, and it doesn’t mean two LUNs on a SAN. It means separate physical storage devices. They can be HDDs, SSDs, or something else, but they need to be separate physical devices.

The user admitted this was something they heard, and would likely not separate things out. I think that’s a good move and should save them some headaches.

I’m out of the office today, in Austin, TX (yee-haw!) at the Stack Overflow Dev Days – Austin. There are a few more around the country coming up, and if you’re a developer, I’d go check it out, just for the speakers. I’m not sure you’ll learn a ton about how to be a better developer in any of these events, but I think you’ll be inspired.

That’s part of why I’m going. After all, the lineup for Austin has talks on

• python
• the iPhone
• FogBugz
• ASP.NET MVC
• jQuery
• Erlang/couchDB
• Code reviews

Of those, maybe 2 or 3 are applicable to my career. I’m not likely to pick up tips that I’ll use next week, though I may learn a thing or two that I could use in the future. There’s a better reason in my mind to go to an event like this, going to hear some well known and well respected speakers:

Being around smart people is exciting

It’s actually more than exciting; it’s inspiring to me. Coming away from an event like this I’m sure I’ll be excited again about my job, and I’ll have ideas that I can apply to my job. Or I’ll be thinking about how I might try something new in my job.

I’ll also be going to see how the format works. How they handle a one day event with multiple speakers to see if this is something that might work in the SQL Server world.

So I’ll be mostly out of touch today, and not responding to messages, but I’ll post some notes and updates when I get back and hopefully a few pictures.

Someone was asking about using multiple data files recently to try and increase performance. I had answered that unless you had separate physical disks that it wouldn’t matter.

However then I remembered hearing something about threads and files for I/O. I tjhought this was a myth, but I wasn’t sure. I searched around, and then pinged Gail Shaw since I know she does a lot of internals type investigation.

She confirmed this is a myth and sent me this reference: SQL Server Urban Legends Discussed. It’s from the Microsoft Customer Service engineers and discusses the origin of the myth and how things work.

The bottom line is that SQL Server uses a thread for each unique disk drive, not files. In SQL 2000, you can fool the system if the disk drives are volumes on the same physical disk. However in SQL 2005 the system checks to see if these are the same physical disk.

There are some caveats, but if you hear this rumor, dispel it. Let people know that multiple file groups (or files) only help if you have different physical I/O paths and drives.