One web comic I commonly read is xkcd. It is a great comic that has a lot of good computer as well as just nerdy jokes. It has a great comic about SQL injection attacks and why you need to sanitize your database inputs. This is a lesson in what to not name your child.
I hope that everyone who reads this gets this joke. Quite amazing. This comic is full of great stuff like this. Try to not waste your day reading this grade A material.
With some recent efforts from an excellent designer named Craig Palenshus, everyone's favorite regular expression library has received a nice visual upgrade. You'll notice the site is much cleaner and more presentable now. The overall design is excellent IMHO. The site seems to be much easier to use and navigate. The links are more clearly defined and laid out. The page is not quite so cluttered. In the past the site had been added to and altered plenty of times, and this created layers of clutter and bad layouts. Steve Smith and I have taken some time to fix some of the bugs from the previous system as well as getting some of Craig's alterations functioning well.
A long time ago on web site far, far away there was a regular expression tester that worked pretty well. Since then the client side tester broke, but no one really had the time to fix it. With the advent of the new look for the site soon coming, it was important to make sure that all aspects were functioning within the operational standards. One man, Brendan Enrick, set out on an adventure to complete the regular expression tester. It received an overhaul from its previous design. It not only works as it previously did, but the client side testing seems to functioning once again within normal parameters.
Ok so in all seriousness, I fixed up the regular expression tester on RegExLib. Let me know if you find any bugs or problems with it, and I'll see what I can do to clean them up. I hope you enjoy the new layout of that page. It worked pretty well for me. I've used it a bunch of times since I updated it. I find it a lot easier to use. I hope you feel the same way.
RegExLib has come a long way since Steve Smith first created the site in ASP.NET 1.0, and it has seen a couple of big layout changes. The first incarnation of RegExLib was red. The site has been green for the past few years, and it is staying that way for its new look.
This is how the site looked near its first incarnation. This is the site back in 2003 when it was still wide and red. It was originally part of ASPSmith. This is the first view of the library as its own web site. As you will notice it was reasonably well designed. The basic layout of the site is nice. The search results aren't very clean, but they work for their purpose.
Later the site received a new design of Thomas Johansen. That layout remained for plenty of years, and it received many minor changes over the years of use. This is the nice green layout everyone has been seeing for years.
Now after trimming the fat off of the site, it is a tall, lean page with plenty to offer its users. Sections of the pages are grouped together nicely with headings. There is spacing to allow users to clearly see and use elements on the page. The RSS feed is being powered by FeedBurner so you can now see how many others are subscribing to the regular expressions on the site.
The site is more usable in my opinion. I have a much easier time reading and working with the pages on the site. I think this visual upgrade is also a very strong usability upgrade as well. I recommend you check out the new design of RegExLib.
Let us know what you think!
A lot of times I just want a simple solution to my problem. I'd like to type 2 lines of code instead of 5. Python has plenty of problems, but one of my favorites assets of the Python language is the ability to Unpack tuples from functions. So lets say that I want to return three values from my function. I just separate them by commas and it works. I then in my function call just list each variable to which those values correspond separated by commas and away I go.
# Logic Goes Here
return name, location, cost
hotelName, hotelLocation, hotelCost = GetBestHotel()
Isn't that a neat trick. I just listed each variable and Python unpacked that tuple (basically an array) and it put each of the values in the correct variables. No extra variable declarations and I didn't have to have an assignment statement for each of the values being returned. Now that is convenience. This is obviously a very specialized little feature, but I do enjoy having it available. It is always good to know of the useful tricks of any language you use.
I recently authored an article for ASP Alliance in which I describe the basics of how interfaces work and how to use and create them in C#. I tried not to describe in great detail exactly how everything works, because that will prevent beginners from understanding how interfaces may be used. I plan to write further about this topic, but I think it a mistake to begin with even an intermediate description of a topic without at least giving a beginners explanation first. I'll be doing some more advanced examples for my next article on interfaces, so look forward to one in the not too distant future.
I am not sure how the rest of you feel, but I think that interfaces are an amazing tool. I try to use interfaces when possible, because it makes code much more maintainable.
Let me know what you think and any suggestions for future articles.
As always, thanks for reading!
It is common to obtain variables with a type which is not the desired one. Considering that plenty of times there will be variables passed using the object data type, it is important to be able to cast your variables into more usable types. Say for example you're passed a variable as an object. You probably want to be able to access properties or methods of this object, so you will need to cast it into another class. The simple way of doing this is to use code similar to this.
DataTable myData = (DataTable)dataSource;
This works well, but is slightly more dangerous than it needs to be. The problem I have with casting it in this way is that the variable dataSource might not be a DataTable, and if this is the case we will throw an exception. Yes, we could wrap a try-catch block around this code, but I prefer to avoid exceptions when possible instead of catching them.
If we use the as statement we will be able to achieve the same result and just need a little bit of checking for an error. This way if our code is in an exceptional case we can handle it ourselves instead of having the overhead of a try-catch block. If the as statement receives an invalid cast it does not throw an exception. Instead of throwing the exception it merely places the null value instead. Since we receive the null value if the cast fails, we are now able to simply check for the null value.
DataTable myData = dataSource as DataTable;
if (myData != null)
// Perform work here
// Error handling code goes here. Perhaps a message of some kind.
As you can see we're able to avoid our exception and handle it without using a try-catch block. I am not advocating programs without these try-catch blocks. I am merely saying that I find it better to avoid catching exceptions that could have been avoided in the first place. I think some people become excessive with try-catch blocks. I've seen plenty of people write code which doesn't check strings for validity they instead just try working with them and if an exception occurs they catch it and respond. I think it is simply crazy.
Have a great day! Happy casting!
I often write queries in SQL Server Management Studio to find different bits of information about which I am curious. This is quite easy and I discover a lot of useful and interesting things this way. You might ask why I am writing this blog post. I'll first say that I try to share these little tidbits with others. Sure I could bring people over to my computer and show them these nifty collections of data with certain meanings, but that would just be silly. I need to store it elsewhere and email it.
Maybe I'm just going about things the wrong way, but I've tried to copy and paste from SSMS into Outlook and that doesn't usually work well. Outlook doesn't seem to figure out that I would like my data pasted as a table, so I usually throw it into Excel first. Doing this will get my data into a nice tabular format.
Now that I've finally gotten my tabular data into a table everything is great. Right? No. I lose once again. I don't have the column names with my data so I end up with something like this and without column names people will not know what I am trying to tell them.
So then I have to go and type out column names so that the people I send this to know what it is. Now for this example it wouldn't be too bad, but sometimes I'll be sending 10 columns worth of data and that is just annoying. I wish I could just copy out of SQL Server and have it pull column names at least then my Excel trick would at least work. If anyone knows a nice easy way to just copy out of SSMS please let me know it would make things so much easier.
Perhaps you can find some elusive option names similarly to Copy All Data With Column Names, because I sure as hell haven't found it.
In case you are wondering those column names are; FirstName, MiddleName, LastName, Phone, SomeValue, SomeOtherValue.
I have a few friends in college who are learning C# on the side. I've been answering their questions when they ask. One interesting question was regarding access modifiers. I was asked which access modifiers are used by default in certain situations when there is not one specified.
First I'll quickly remind everyone of the access modifiers and what has permission to access them.
private - Any members of the same class have access.
protected - Any members of the same class or any derived class have access.
internal - All code in the same assembly. This means that it doesn't matter where the code is in the assembly. It can be in any class as long as it is inside of the same assembly it has access.
public - EVERYTHING HAS ACCESS!
When you define a data type of some kind (class, struct, enum, etc.) you need not specify an access modifier, but be aware that the default will be internal. This means that anything else in the assembly has access to it. There is very little sense for it to be private, because that would mean that only it has access to itself which means it would never do anything. Since we like the default permission to be as restrictive as possible it makes sense that the default is internal.
The other code with access modifiers are the members of the types we were just discussing. Since these are within a type private makes sense for them, and since we like keeping this locked down by default they use the private access modifier if no other is specified. This means they are only accessible by other members of the same thing. So a class might have a private member function and that function can only be called by other members of the class; functions, properties, etc.
Protected is probably my favorite access modifier to use, but since it is less restrictive it is not the default. This is because pretty much any time protected can be used so can private so private will be the default. Public is just way to open to be the default and C# doesn't want to encourage programmers to have everything be public. That is just a bad way to write code.
Don't get locked out because you don't know the default access modifier. Make sure you key in to the correct way of writing your code.
Have fun writing code with access modifiers!
Recently I've started using CodeRush™ with Refactor!™ Pro after being defeated in a programming competition at DevConnections by Sarah (a hired model) at the DevExpress booth. There should be two recordings of my painful defeat. Steve Smith made one and Carl Franklin made the other recording of my battle. Just for the record Steve faced her days earlier when she was still learning and he also lost.
Overall I've found the tools to be extremely useful. They make a lot of tasks quick and painless. Classes, methods, and properties are extremely quick to write now. Refactoring catches me off guard sometimes, but I am often pleasantly surprised.
For simplicity I was calling a method inside of a foreach loop. I did this because I didn't need the collection except that I was performing an action on each of the returned elements in the collection. When I realized that I needed to perform an extra action with that collection I decided I would move it from the foreach loop.
At first I had a foreach loop similar to this one.
As you can see my foreach loop is using a MembershipUserCollection returned from a function and is going to loop through each MembershipUser. It is at this point I decide to refactor and pull the GetUsers method out of there and I am going to make a variable to store this collection. I highlight then cut the method and paste in in the line above and this is what I get.
It knew what I was trying to do! It created the collection and even inserted the variable into the foreach loop for me. When I then rename the variable it also changed it in the foreach loop for me which was quite nice. I didn't even have to check and see what type of collection it was returning before creating the variable. That might have been a generic list, but it didn't matter because the tool figured it out for me and filled in the rest. I was amazed.
There is one annoyance that bugs me though. I have habits I've gotten in to while writing code. I don't like hitting ctrl+space to bring up intellisense. I prefer removing a comma or a parenthesis and typing it again. This works very well without having any extra tools installed. It also works well most of the time. I've only run into a problem a few times.
I start out with code that looks like this. There is a long function call so I keep the parameters below the function.
Now I want to get intellisense back just to confirm the first parameter or maybe to see the overloads for this function so I delete the "(" and put it back in place and I get the following.
Now it has added in an extra ")" that I did not want. I wish it could have seen that my function was complete and I was at the start. Sure that might have been convenient if my code wasn't already written, but in this instance it got annoying. Visual Studio got confused and gave me nice red squiggly lines. DOH! Not too terrible. Most of the time the tools work well there are just a few quirks like this that get me sometimes. Perhaps this blog post will help get the ball rolling to make this product smarter and better able to see what I'm doing. Overall I think the tool is excellent.
If you're interested in buying any cool software from Dev Express I recommend you check out Steve Smith's Dev Express Tech Summit blog post. He mentions a good discount code there that will get you 10%. His coupon code is SMITH07 you can use it to save 10% when you buy great programming tools from DevExpress.
There are plenty of AJAX tools being used everyday. The AJAX Control Toolkit can be likened to a pack of Bertie Bott's Every Flavor Beans; there are far too many choices. Some tools you'll love and some are as useless to you as an earwax flavored bean. Likely no individual developer will find a use for every control in the toolkit, but there is one which I think has a simple use which can be applied to nearly all sites; the TextBoxWatermark control.
When using the TextBoxWatermark control a developer is able to easily place text inside of a TextBox for a user to see. In my experience I've noticed that users tend to read as little text as they can when using forms. It is also difficult sometimes to write necessary information within strict size constraints. Plenty of text boxes require a title on the left so a user know what to type in the box, and then there might be another message below giving more specific instructions.
My personal favorite method for using this control is to place the title of the TextBox to the left and then placing an example in the TextBox as a watermark. This gives the user a nice example which cannot be easily ignored. Overall a very useful control. It is also very simple to use.
<ajaxToolkit:TextBoxWatermarkExtender ID="TextBoxWatermarkExtender1" runat="server"
<asp:TextBox ID="TextBox1" runat="server" />
Using this control it is simple and easy to pass along great information to the user which he or she cannot ignore. It can also make a form look more professional. I am not saying that the TextBoxWatermark is the only useful control. Most of the tools are very useful, but some have some obscure uses. Some of them I know when people use them I just think they shouldn't use them.
Earlier today I downloaded IronPython, and I've tested it out a little bit. The command line interpreter is nice and works pretty painlessly whether you are compiling the source or just executing the binaries. Python is a great language IMHO. Just like every language that has ever been written, it has a few problems. Python emphasizes short readable code.
IronPython's interpreter, ipy, allows interactive sessions as well as execution of files. It acts very similarly to Python's Official interpreter, IDLE. This makes transitioning easy for someone who already knows how to program using the Python language.
I sat down and took a couple of seconds writing a simple fibonacci number program to print out the first 10 fibonacci numbers as an example of how Python code is used.
if number == 0:
elif number == 1:
return fib(number-1) + fib(number-2)
for i in range(10):
If this code is in the file fib.py I can execute it using the following command.
It generates the following output.
People have integrated IronPython into Visual Studio as well, and I'll soon look into doing that as well. I like how simply and easily I am able to create this little program. Now with IronPython I also have access to the .NET Framework's libraries.