SQL Saturday 145 (BNA): I Haz a Sad

(Yes, I speak in airport IDENTs, leave me alone!)

This is not the post about our local SQL Saturday that I wanted you to read, nor is it the one that I wanted to write. I’m barely even getting to write and post this within the week that I intended to. Alas, sometimes we have to do things we don’t want to do. Yay, being a grown-up!

The Plan

Pretty much: See what Tammy wrote. We were going to have some #sqlfamily out on Thursday for dinner, do the usual Friday pre-SQL Saturday things (Speaker Dinner, etc), then on Saturday, Tammy and I were going to co-present a session targeted at accidental or otherwise new-to-SQL Server folks. This was going to be the third time she’s presented at a SQL Saturday, and was going to be my first time speaking.

Although as of last weekend, I was horribly nervous about this already and still feverishly working to get all of the details of my part of the session together, I was really looking forward to this. It was going to be a nice way for me to present for the first time, as I could rely on Tammy’s experience doing this at SQL Saturdays and the internal training she has been doing at her company. Hopefully after this, I’d have some confidence and would be able to start doing something on my own. You know; theoretically…

That WAS the Plan

As I have mentioned before, Tammy’s Grandma had been in the hospital for a couple of months now, recovering from heart surgery. Although there had been some stretches of good days (some really good), she passed last weekend. It wasn’t necessarily unexpected, but it was somewhat sudden. Dealing and coping with that wouldn’t have affected the plan very much, except Tammy’s brother & new wife were still on their honeymoon, and wouldn’t be back until middle of this week. With services delayed until late in the week, we realized that having that on Friday just wasn’t going to fit with speaking on Saturday very well.

Unfortunately, we had to cancel our speaking slot in Nashville. And, just about everything else, for that matter. I still feel really bad about having to do this to the local chapter leaders. I feel bad that it was our local chapter that this happened to! I also hated that we had to cancel what was going to be my first time speaking; now I’m probably going to be cursed 😉 . I know that this is one of those things that comes up nothing can really be done about it, but it doesn’t mean I have to be happy about it. Last weekend I commented that I was about every emotion but “happy” about the entire thing.

But it’s OK. Things are better for Grandma now. We’re hoping to be able to make it back into town to see our Nerd Family at/after the after party tonight. I feel like a bit of a heel for showing up to the party after not speaking at the event, but we won’t eat any of your food 😀 .

Now…

So, today, Saturday, SQL Saturday 145 is in-progress, and when this posts, we’re likely in the car somewhere along US 31 or I-65 (hopefully actually moving and not stopped by a cop 😉 ). Not sure how many people will see this before tonight, but we hope to see some of you then.

We’re sorry, we’ll see y’all soon, and hope you don’t hate us now.

Recap: SQL Saturday 160 (AZO) and Some Other Driving

This trip to Kalamazoo was, at first, supposed to be the front end of an epic road trip involving SQL Saturday 160 and SQL Saturday 149 in MSP. Those plans wound up scrapped when Tammy’s brother announced his wedding date on the same day as 149. Instead of spending the week between visiting friends & family in NW Indiana and doing stuff in Chicago, we only did some of those things; for the most part spending time in/around Indianapolis. It wasn’t all bad, as we were able to spend more time with some people than we otherwise would have; those people just weren’t #SQLFamily 😉 .

SQL Saturday 160 was the second SQL Saturday that Tammy submitted a session to. The first was Kansas City back at the beginning of August (159). The one that started it all was kind of a non-standard submission: Long story short, Andy Galbraith (blog | @DBA_ANDY) said on Twitter that they had five (or so) speaker slots still available and anyone interested should submit a session. I more-or-less threw Tammy under the bus publically on this, she did submit her “SSRS for Nubs” (not really its name) session, and it was accepted. Yay, speaker!

Driving

Packed car

I could say that we had a bunch of extra stuff for Tammy’s mom, which is true, but we still pack like a family of four going on a month-long trip to Europe

We steamed away from the house on Thursday morning. Left so early because we were going to stop for a bit in Indianapolis to visit Tammy’s Grandma, who is still in the hospital recovering from open-heart bypass surgery. We wouldn’t have otherwise been able to get to Kalamazoo in time for the Speaker’s dinner if we had waited to leave & do all of that on Friday.

After eight hours-and-change in the car, including my first-ever speeding ticket while driving through Louisville (because I wasn’t paying attention to what I was doing), we made it to Kalamazoo and checked into the water-logged hotel. Turns out something happened to a sprinkler head on the third floor, and drenched half the hotel (and by “something”, I mean, “some guest allegedly broke it”). This means that half of the people staying in the hotel that weekend were going to have to be moved somewhere else. Probably the only thing that got us a room for the weekend was the fact that we got there on Thursday instead of Friday. Everyone who had a reservation had a room in one of two other hotels (one of which wasn’t part of their chain), so that was good.

The Good Stuff

Friday was a nice, relaxing day, where we didn’t actually do much. We kind of needed that.

Had the Speaker’s Dinner Friday night at Tim Ford’s (blog | @SQLAgentMan) place. I love Tim, and after this weekend, pretty much his whole family, too. He had a head-start on that, being a fellow Pentax shooter and all. We had been to a SQL Saturday Speaker Dinner once before, ahead of Nashville’s first SQL Saturday two years ago (they had invited volunteers to it), but this is the first one where we were actually there as a speaker (well, Tammy’s the speaker; I’m just Demo Tech Support). I’m still not quite used to being one of the “cool kids” yet, so I spent some time simply weirded out by being where I was with who I was Friday night.

Saturday itself went really well from my perspective. We didn’t get to the venue as early as I would have liked (my fault), but it was a great venue and there was even some breakfast available! I went to a session in every time slot, as there was interesting stuff for me, and it’s not like I had to sit around and be nervous about speaking later.

My favorite session (criteria: general “interestingness” of the topic/session and how many detailed bits of info I learn and can take away) is probably a toss-up between David Giard’s (blog | @DavidGiard) Data Visualization and Allen White’s (blog | @SQLRunr) “Manage SQL Server 2012 on Server Core w/ PowerShell”.

David’s was nice, because it’s full of little ways to improve data visualization that might not seem so obvious until they’re pointed out…at least not for me. I maybe got more “don’t”s than “do”s out of it, but that’s still OK. Some of the “don’t”s are really good. I especially like David’s use of Charles Joseph Minard’s chart of Napoleon’s army during the French invasion of Russia in 1812. Full res of the chart is on Wikimedia here, and is inlined in the Wikipedia page on the invasion itself. The chart is sweet, because it shows so many different pieces of info all at the same time in a fairly easy-to-understand and interpret package. Lots can be learned about data visualization from that one single chart.

I got a lot out of Allen’s session, although possibly not what he exactly has in mind. I’ve recently begun building a new test environment at the house, self-contained on a Dell PowerEdge 2950 that I picked up a few weeks ago. My intent with this is to do everything all ultra-modern. The metal has Server 2012 Core installed on it, running Hyper-V. Everything will be virtualized in that environment. I’m doing this for a couple of main reasons, but I realize that talking about it too much here is fairly off-topic, so I’m going to skip it for now. Anyway, I was a fan of just watching Allen work within Server Core, because although I’ve got our server set up from that standpoint, there was a lot of Googling semi-randomly, running either legacy commands or PS snippets that I barely understood. I have everything written down that I ran, but now I understand a little more of it. Additionally, I know what I need to set up SQL 2012 on Core, which is a task that is coming up after everything going on in the next month or so calms down (that’s another blog post, too).

Tammy participated in the Women in Technology lunch panel discussion, which I think is the first one of those I’ve gone to (not sure how/why). This particular one didn’t have a specific topic to discuss, which led to a lot of varied conversations. There were a couple of audience members who got specific answers to questions that they had, which was really cool to see.

Tammy’s presentation was in the last slot of the day, which led to a slightly tough crowd. It went well though, with one minor hiccup. I like her presentation in general, and so far she’s been getting good feedback on it. Although this is only the second SQL Saturday it’s been done at, she’s given basically the same training to a couple hundred people internally at her company, so the content is fairly refined. It’s done in SSRS 2008 R2 at the moment, and we’ve talked about upgrading the demo to 2012. For right now, it’s going to stay where it’s at, because we don’t get the feeling that 2012 has reached enough of a critical mass, especially considering the intended audience of this session. In fact, one of the attendees in the session asked a question related to running reports against 2005 instances, because they’re currently stuck there and can’t upgrade.

Beer

The after-event was held at the Kalamazoo Beer Exchange. I know very little about this place, other than they have a lot of beers on tap, whose prices are all driven by demand within 15-minute chunks. I hoped this would be good for us, because of our propensity to drink Porters & Stouts. Due to the number of taps they had (and that we’re in Michigan), I also hoped for a good selection of said beers! I wasn’t really disappointed on either point.

Tammy and I both had Dark Horse (Marshall, MI) Thirsty Trout Porters to start out with. I was a big fan based on its name alone, just because it’s a big giant mouthful. I thought it was good. Didn’t write any notes or anything, but I classify it as “definitely a porter”, which all but guarantees I’ll like it. One of the things the KBE has is one cask beer available. When we were there, it was Arcadia Brewing’s (Battle Creek, MI) Baltic Porter. This stuff out of the cask was ri-dic-ulous. Have no idea what it tastes like out of a bottle, and I don’t know if I’d ever even want to after having it like this. It was really that good.

Unfortunately, we didn’t get to see how their food is, because there was a slight fiasco with getting seating. Apparently the place doesn’t take reservations (which I can understand), and have limited space for even medium-sized (not to mention large) groups (which I can also understand). Long story short on that is we didn’t get to eat there, as some of us basically decided to bail and head back to Tim’s house. Good times were had by all, on all accounts. #SQLCAH

This is one of the best SQL Saturdays we’ve been to but we honestly haven’t been to all that many, so I feel like I’m not saying much.

Back to the Driving

Mostly at the last minute on Sunday, we decided to go to Chicago for the afternoon. I love Chicago. I also love driving to/in Chicago.

It was refreshing to blast up the Dan Ryan at 80 behind a BMW 6 and not have to work too hard to do it, even though traffic wasn’t exactly light. See, Tennessee drivers don’t exactly “get” the whole “keep right except to pass” thing (or, in the form of Kerry’s Driving Rule Number Two, as applied to Multi-Lane Interstates: Only be as far left as your speed and traffic dictate). In fact, when traffic is light-to-light/moderate, the lane where it’s easiest to go fast is usually the far right (#1) lane. Once to a certain point, no clear winner emerges—either you have to just take the speed you can get, or expend a lot of effort—and greatly increase your risk—to weave around in traffic. Bonus points for the guy going 10 under the limit in Lane 1 during rush hour. So, driving on a five lane wide slab of concrete where things work like they’re supposed to is pretty high on my list of favorite things to do.

Did I mention I got a speeding ticket in Louisville on our way up on Thursday? The first one I’ve ever gotten? Because I was spending more time looking at airplanes than paying attention to how fast I was going and the Edge goes fast kinda easy? Yeah. That. Everything makes sense now, doesn’t it? 😉

Steaks at Michael Jordan's

This happened…

Anyway, walked around some there, got our Sunday night steak at Michael Jordan’s restaurant (convenient more than anything), took some pictures, and took the Skyway back to Indiana.

Then more driving, we stopped at my parents’ place, spent some time in Lafayette to see some friends and some other family (and get a DenPop), then time in Kokomo and Indianapolis, Tammy’s brother’s wedding, etc, etc, back to the Osburn Hideaway just in time for Sunday steaks again.

All in all, a really good trip. I’m pretty happy for the time off, even if we were really busy most of the time. It’s always so nice to sleep in our own bed after a trip like this. I don’t know how some of our #SQLFamily do as much traveling as they do. You guys are crazy. And awesome. But possibly mostly crazy.

Pictures

SQL Saturday 160

Chicago/Indiana/Assorted Flatness; Also, giant turbines

T-SQL Tuesday #30: A DBA’s Ethics

T-SQL Tuesday 30
#30: Deep T-SQL Tuesday or Deepest T-SQL Tuesday?

Chris Shaw (blog | @SQLShaw) brings us T-SQL Tuesday this month. His topic of choice is “A DBA’s Ethics”, which is a pretty deep subject! I feel like this post goes off the rails a little bit compared to the direction of the invitation post, but I had something happen last week that really made me think about this topic in a specific way.

Chris says, “Don’t consumers and business owners have to trust someone at some time with their data?” This is a line that I have clung to in the past; at some point, it has to come down to trust. Since I feel this to be true, it makes me somewhat crabby when regulations & whatnot seem to step in the way of that trust, possibly making it hard for someone like a DBA to do their job due to data or system access restrictions. I do believe that there are times and places for regulations like this, and after what I learned last week, I’m probably more on the side of these types of security regulations than I was before.

NPR to the Rescue

See, I wasn’t even sure if I was going to write a post this month or not. I wasn’t sure what I wanted to talk about or if I was even going to be able to get enough coherent thoughts together. But then, one day last week, I was minding my own business (more or less), driving home from work, listening to WPLN, as I am wont to do, when this story came on. To very roughly summarize for those not interested in spending 18:34 listening (I do recommend listening to or reading the story):

  • Father is upset as his son is convicted of bank fraud.
  • Asks younger son to promise to never get into that kind of trouble.
  • Younger son promises.
  • Younger son starts own business.
  • Realizes one day company is under water.
  • One thing leads to another and 22 years after The Promise, said younger son is convicted of same crime as older brother.

I was interested in where this story would go… I mean, why do otherwise “good” people do “bad” things? At the beginning, I thought that somehow research was going to say that doing bad things “runs in the family” (the older/younger brother angle). As the story progressed into the part where Toby Groves begins asking employees to help, and they agreed, I started to think about how there’s no way I would do such a thing…and how could these people?

When the story got to its punch line, it made me think about how this topic related to DBAs:

We like to help each other, especially people we identify with. And when we are helping people, we really don’t see what we are doing as unethical.

A couple questions developed in my head when I heard it, and as I thought about it more, the questions only got more complex:

  • Are we, as DBAs (or DBA-type folks) at all immune to this type of thinking?
  • Would a DBA be more willing to help another DBA specifically? If so, how thin can we split that hair?
  • What about supplying data for audits? Does that change the thought process?
  • Does having an ethics statement really do any good?

I don’t have answers to these questions—not sure anybody does—but they make for interesting things to think about.

If Only I Had a Psychology Degree

I know the first question I have listed there seems pretty pretentious, but I wound up there due to specific reasons. Of course DBAs like to help other people; that’s not what I’m saying. What I am saying is weighing “helping people” while still operating within “the rules” is kind of what we do. I’ve spent a fair amount of time working directly with developers both on projects and to get projects deployed to Production systems. Although it is nice to be able to tell coworkers “that’s all OK”, that isn’t what we get paid to do; instead, more often than not, we’re paid to say No. Not because we don’t like people or enjoy it, it’s because we are trusted (there that is again) to apply “the rules” objectively to everything we are involved in or are supposed to approve for deployment. These “rules” can be administrative procedures, architectural/design policies, or even something simple like scheduling. Because of the nature of what it is we do, we are used to taking a step back, away from the people involved, to ensure that we do the right thing.

Does making decisions like that on a day-to-day basis make a person able to apply that same objectivity to every situation they ever encounter? Who knows? What about if the situation was changed a bit? DBAs (and sysadmins, for that matter), tend to rag on developers a little bit; usually in a good-natured way. But, I believe that, for the most part, DBAs and Developers are fundamentally two different kinds of people—we tend to think and act differently (and that’s OK). So, what happens if a fellow DBA comes to us with a problem or the results of a mistake and are looking for a way to fix it quietly or sweep it under the rug? Since we identify with the fellow DBA more so than, say, a developer, are we more likely to go along with the cowboy fix, as is pointed to by the study in the NPR story? I mean, if one doesn’t truly stop and think about what is going and what is being asked of them, it’s easy to simply think, “oh, Jim-Bob’s a DBA over on the Production team, surely he wouldn’t want to do anything outside of policy…”

What about the audit situation? This can go both ways: on one hand, one wants to help the auditor do their job by getting them the data they’re asking for. On the other hand, you may be wanting to help your team (or yourself!) out by possibly not supplying everything involved in a request. It’s easy to sit here and office chair quarterback the scenario, but that’s the point—it’s easy when you’re not in the situation  yourself, in the same mindset (or lack thereof), staring the same consequences in the face. Thoughts and actions only count when…well…when they actually count.

This is where doubts about ethics statements begin to creep into my head. It’s easy to read through SANS’s Code of Ethics that Chris pointed out on this fine Tuesday and laugh, being like, “yeah, like I’d ever knowingly hurt someone’s reputation or look up the boss’s salary in the HR DB.” The problem is that opportunity or request might not come up on a Tuesday morning while we’re sitting around reading blog posts over our second cup of coffee—it might come up while you’re having an exceptionally bad day, and all you want to do is make at least one person happy. Before you know it, you might have gone off and done something illegal, or at the very least, ethically questionable.

Does having a company, community, or personal code of ethics keep this from happening? The way I interpret the reported study’s results, I would have to say no. Of course, that’s not true for everyone or every situation—it depends! It depends on a lot of things. So many things, in fact, that it’s completely within the realm of possibility that having such a code and reading it regularly to remind ourselves of the covered items could just cause the right synapse to fire in the right situation to keep us from doing something stupid. Does that make it worth the effort? Probably.

I have to say, though, historically, I’ve gotten crabby about things like this that get formalized. I always ask “Really?!”, because I feel like I’m pretty hard-wired in this department and get a little offended by having a code of ethics thrust upon me. I have to say that I’m a a little afraid after hearing the NPR story that there’s a chance I would let things get out of control before I realized what’s going on. At the same time, though, I realize that having that fear and being alert to it is probably about the best way to safeguard against doing unethical things in the first place.

But…

There’s still a problem here. The problem is that we’re not perfect. Insidious things creep in at the corners without us noticing. Even though we’re trained and practiced in recognizing when something abnormal is going on and to see through the glossy surface down to the gritty details, things can still go horribly wrong due to being stuck in those details and missing the big picture.

I don’t know about you guys, but that NPR story freaks me out a little bit. Do I believe what I said above, about DBAs being used to making similar decisions, makes us immune to this type of “sympathy think” (pardon me while I make up words again)? No! I’m worried I go around every day a hair’s breadth away from starting something highly unfortunate just because I wasn’t paying enough attention or thinking the right way about a task.

Sure, talking about a DBA’s ethics is a little bit different than talking about mortgage fraud, but the fundamental decision is the same: Could what I am about to do hurt myself or someone else? It’s hard to think about that question at every turn throughout the course of the day, but apparently we need to, because once again, our animal brains are being a pain in the butt.

T-SQL Tuesday #28: Jack of All Trades Crew, Checking In

T-SQL Tuesday—always a good option for helping to get back on the blogging horse.

TSQL Tuesday #28
T-SQL Tuesday #28

This month is hosted by Argenis Fernandez (blog | @DBArgenis), a SQL Server MCM & a #SQLFamily member that I have yet to meet. His topic of choice is “Jack of All Trades, Master of None?”, which is right up my alley, because for pretty much my entire IT career, that phrase has described me. It still does, right this second, but I’m trying to get over that. More on that coming.

Because I should be able to use them to frame out a good story (and because I’m cheap), I’m going to work with the list of questions Argenis has in his invitation post.

Are you specialized? On something? Or anything at all?

Am I anything at all? No, not really, thanks for asking! 😀

Anyway… it’s not really safe or fair to answer whether or not I’m specialized with anything but a firm “no.” I’ve been this way from day one. I don’t know that it’s been a conscious decision to get to this point more than it just happened as a result of being driven by a desire to know how everything works. Sometimes that leads to depth in weird places, which can come in handy while watching Jeopardy! on TV.

My non-specialization situation at the moment includes the capabilities of a decent SQL Server DBA, being what I’ll call “serviceable” when it comes to data modeling, and could still be a sysadmin if push came to shove, in a day job in which I have become the go-to ETL Developer. It’s a little weird, I admit. But, all of those other things help with the current focus. The ETL job is slow, you say? Well, is the server on the floor? Is the latency over the WAN link 700 ms per round trip? All of my other skills help, and that is what I think is the best part of being a jack-of-all-trades: It’s possible to know just enough to answer a lot of your own questions!

I’ve said it before, but another thing I like about knowing a little bit about a lot is you can make friends/commiserate with almost everyone in the IT department.

Are you the SQL Guy at work? Or the one who does everything?

Due to the size of company that I work for, there are very few “Guys” at work—everyone has a specific job (or sometimes jobs) that they do. Basically…near-insect-grade specialization. There’s not room for a jack-of-all trades at larger organizations, in my experience, with the possible exception of smaller, autonomous groups.

Having spent time in one of those smaller, autonomous groups within a larger organization, I was a little bit of the guy who does everything. My whole team was, actually. We were “Windows System Admins”, who ran just about everything except Exchange and the MSFT monitoring platform du jour, plus Citrix to boot. Although each of us had our strong points, pretty much all of us could get through whatever needed to be done and have things work when we were done. I think that just goes along with being a “sysadmin”—being a jack-of-all-trades is almost a necessity. Need to know hardware? Check. Security theory AND implementation? Yep. IIS (Apache as necessary)? Probably. Networking? You betcha. SQL was just one of the things that I did while there, although I did do a lot of it.

Do you code? And configure wireless routers at work also?

Hell no. I mean… not if I can help it. See, when I started in IT for real, I knew one whole programming language: Visual Basic 6. Two classes in school on it, and that was it. I wrote a little print queue viewer/management app while a student (hey, it was deployed on 2000+ machines!), but no real experience. To this day, VB6 is the only real (“real”) programming language I know. Not having a strong coding background does cause some problems occasionally, especially when talking to Developers who are used to DBAs coming up through those ranks. I definitely don’t know much about software engineering theory, and that’s where it shows up the most.

As part of the afore-mentioned sysadmin gig, I wrote a command-line only VB app as an automated interface between a couple of systems, but I’m not exactly proud of that moment, for a number of reasons. The one that applies here is one of the downfalls of being a jack-of-all-trades: it’s easy to cowboy up and do quick-and-dirty things off to the side, because you can. Perhaps even more dangerous: because no-one else can.What happens as soon as you’re done? Well, if you’re not careful, it winds up in Production, and then it becomes a support nightmare; if not for you, it will be for a coworker or the next guy. Either of which may some day hate you when their phone rings at 0300 because the wrong piece of duct tape fell off your masterpiece. I think being a jack-of-all-trades can be a good thing, as long as one of those trades is holding onto whatever processes and standards are in place…and if there aren’t any of those, hopefully one of said trades is coming up with some good organizational processes and standards!

As for the wireless router configuration bit—I try to keep that at home. Pretty sure the network guys wouldn’t like me messing around with those things. Just because I [used to] know Cisco IOS, doesn’t mean I should use it. That brings us to another good specific skill that a jack-of-all-trades should have: Knowing when to sit quietly. This goes for both wireless routers and writing anything in VB6 that has a prayer of ever seeing real, actual production use.

If you had to pick one thing to specialize on, what would it be?

Yeah, about that… All the above said, I actually am going to try to specialize on something. Of course, it isn’t enough to say I’m going to specialize on SQL Server. There’s too much in the product now. I’m going back to the thing that got me truly interested in the prospects of becoming a Data Pro in the first place: Business Intelligence. Unfortunately, I don’t think it’s safe to make that a goal, either. Just the BI side of the SQL Server platform is becoming too broad and too feature-rich to come to grips with. I’m going to have to be content with possibly not knowing anything at all about Reporting Services to focus on what I really want to do: Analysis Services. I actually want to be able to do most of the architecture work surrounding big BI projects, from start to finish (except for SSRS!), but I’m afraid that even just SSAS, including all of its new related technologies, could turn out to be too much.

That, though, is a journey that I hope we can all share in. Because I’m nice like that.

Other Thoughts

Being mechanically wired more than anything, it’s not quite as easy for me to tear down a piece of T-SQL as it is, say, the battery operated toys I used to take apart…Or a carburetor. But thanks to the Internet, it’s easy for me to read about and learn from someone who is more adept at doing that sort of thing. This shows two more helpful skills for a jack-of-all-trades: Being able to read and learn is a really important one, and being able (and willing) to share back out is another good one. You never what kind of DBA trying to configure Exchange you’re going to help out.

PASS Summit 2012 To-Do

Diners Drive-ins and Dives was on the TV just now (it was the first episode I’ve seen of the day, so I hadn’t gotten to the point of stabbing myself in the eyes yet), and Guy was at a place in Seattle that we want to put on a list of things to do this year. Tammy said we should start a list in a folder somewhere, and I thought why not mumble to the world about it.

So, here’s a random list of things that we’re going to try to do when we’re out in Seattle this year, along with a stab at when we might be doing it. Obviously these can all be #SQLFamily events, unless otherwise noted.

Oh, and of course, if anyone knows anything about these places and it would actually be a bad idea to do/visit any of them, please feel free to let us know!

  • Slim’s Last Chance Chili Shack & Watering Hole (1st Ave South, ~Georgetown); Probably hit this place on the way into town due to its location
  • “The spice place”; That’s all I’ve got about it. I seem to recall hearing about this once before, but this is all I’ve got right now

Will add to this as time goes on…