Sunday, October 05, 2003

Source: Ming the Mechanic Flemming says- I'm trying to practice noticing patterns, and writing them down. Here's one. In circumstances involving multiple humans, where one of the people has a level of influence or authority, and where there is a certain identifiable desirable activity that the other one or more people need to engage in, one of the simple sets of rules that the authority person can operate by are: If things are happening, don't change anything If things are not happening, change something. That is not always as self-evident as it sounds, so it can be useful to spell it out. It says to not mess with processes that are already doing the right thing. Despite that they might not be doing it the way you had in mind. If it ain't broke, don't fix it. And it says that if you aren't getting the desired result, you shouldn't just sit and wait, you need to do something, or change something, so that a different process takes place. I know this principle from my work as a counselor. There's a certain something that needs to take place with the client who comes in and sits in the other chair. They need to change for the better, they need to become more resourceful, they need to be more able to overcome their problems, they need to be happier, and look positively towards the future, etc. And there are certain components or steps that usually are part of that. They need to be willing to sit still long enough. They need to be able to be a little introspective and actually examine themselves and their thoughts and reactions. They need to be able to come to some realizations. And willing to change their mind and do things in a new way. It is my job as the counselor to make sure they're doing these things. If they already are, I don't have much to do. If they don't, I have to come up with a way of getting them back there. If the client sits down and keeps talking about the weather and last night's TV, then things aren't happening, and I need to come up with a way of switching us into a different track. But if they come in, sit down, and right away start getting into some deep and productive self-examination, which they then come out of with a big realization and a new more useful pattern in life, and a better outlook on the future - hats off to them, and I don't have to change anything. Makes sense? Or think about a strategy for entertaining a small child, while you're busy with other activities. If she's sitting down happily occupied with something that isn't dangerous to her, great, leave her alone. She's already entertained, so no need to change anything. But if she's suddenly bored and getting in your way, ok, it is time to change things. Which might mean to introduce something new and different. Hey, here's another toy, or, wow, you can draw with these pencils, or how about we go into the other room, or try to tie your shoe laces. Every good mother knows these things of course. It doesn't help to keep saying "don't bother me!" Get creative and bring in another factor that will make the child get interested, entertaining herself. After which you can happily leave her alone for a while. Keep some extra surprises in your bag for the next time the child gets bored, and you can do your job fairly easily. Said a different way: Don't keep doing things that aren't working. (even if you think they're the 'right' things to do) Keep doing things that ARE working. (even if they weren't supposed to be working that way) Duh! What gets in the way is usually fixed ideas about how things are 'supposed' to be done, and a failure to recognize whether the desirable outcome actually is or isn't taking place. Here's another way: If you aren't getting the desired result, DO something, anything. If you ARE getting the desired result, do nothing. Relax and enjoy it. and of course, all of this requires that you: Know what is the desired outcome in the circumstances you're in. [Ming the Mechanic] 12:16:46 PM    trackback []     Articulate []

You haven’t really experienced sheer hell until you have to debug a DTS package. SQL Server development is something completely different from the traditional 4GL languages like VB and C#, you have to think in rows and columns and joins. A lot of 4GL programmers are forced or simply want to get into writing T/SQL Stored Procedures and realize that it is a whole new ballgame. But one that is easy to master if you put the time in. So a lot of beginning SQL Server programmers who came over from the 4GL side ask me often at conferences, “How do I debug a DTS package?” The answer is “You don’t.” (Oh we are all so spoiled by setting a breakpoint in Visual Studio.)   Microsoft has publicly announced some of the new DTS features of Yukon at TechEd in Barcelona and will announce more at the PDC in LA later this month, so I won’t go there and besides Yukon will ship sometime over the rainbow. So let’s start thinking about SQL Server 2000.   First off, proper design of your package will only make debugging much easier. Use only Stored Procedures (with or without parameters) and if you have to use SQL dynamically utilize Views. This is because the more dependencies on “real” database objects, the easier it will be to track down your problem. Avoid ActiveX Scripts as much as you can-consider an Extended Stored Procedure that calls a DLL wrote yourself (or call the DLL with a CreateObject in your script if you must). For the actual debugging itself my advice to you is to take everything in steps. You can run each DTS package’s step individually just by right clicking on it in the designed and selecting “Execute Step” from the pop-up menu.  That is the first part. Then you can deconstruct the step manually and run those pieces in Query Analyzer. (In theory you can debug your stored procedure in Visual Studio too.) From there it gets easier, small bits and pieces of your step may or may not be working, so start looking at your select statements in QA. Before you know it, you will be in DTS debugging heck instead of hell. [Stephen Forte's WebBlog] 10:29:49 AM    trackback []     Articulate []

Source: Marc's Voice I've been trying to get David Temkin to start blogging for a while now. Hopefully if he starts to see results from me, Scoble and Sarah blogging about Laszlo - that'll tip the scale towards him finding the time.  I think he could easily become one of the leading A-list bloggers.... Anyway - it's great to see Scoble grokking Laszlo.  Wait till you see what's coming..... Here's Robert's post..... On Saturday Maryam and I were honored to meet David Temkin, CTO of Laszlo Systems. It was an informal meeting, just something fun I try to do with people I respect. (Translation: I'll meet anyone interesting who invites me). A little story first. A month ago Maryam and I were getting our new house repainted. She was looking for color ideas and Tena Carter told her "check out Behr's new color picker." Let me tell ya, that little color picker made Maryam's heart warm and she was interested to know that David and team had done that for Behr. Now you know what to blame for the goofy pinkish color in our bathroom. Anyway, David painted a rather interesting vision of the future of the Web. Laszlo's system is an interesting one and joins Java, XML, and Flash together to deliver compelling, interactive Web services. Laszlo is something I'm keeping my eye on. Oh, yeah, and Laszlo is coming to the PDC as well. I really wanna hear what they think about all the new stuff in Longhorn. [The Scobleizer Weblog] [Marc's Voice] 9:51:12 AM    trackback []     Articulate []