I didn't have as much time to spend on day 2 as I did the first day, but I did get some things done. Mostly I read through some of the quickstarts and watched some of the videos at the Silverlight site. JD suggested to me that I keep a list of resources to help manage my thoughts. I've been saving interesting pages to del.icio.us with a Silverlight tag for a while now, but I think I'll definitely be more cognisant to save everything I run into. http://del.icio.us/mattcasto/silverlightProbably the most interesting thing that I found was Silverlight Pad, an online equivalent to XAML Pad. Looking at what's available there and making changes to see what happens is a great way to get a feel for what's going on. Labels: silverlight, sprint
For my first day of my 30 day learning sprint focusing on Microsoft Silverlight, I'm going to go through the Quickstarts on the community Silverlight website. Before starting with the Quickstarts, I had to set my machine up. Based on Scott Hanselman's post " VS 2008 and .NET 3.5 Beta 2 Releases Made Easy," I downloaded and installed the following: Then I got confused. I wasn't sure whether to start with 1.0 or 1.1. Silverlight 1.0 is at the release candidate stage with a go live license, so it seems like a safe bet. But with 1.1 I can program with c# on the client. I'm 95% more proficient with c# than with javascript, so this is a tough one. While digging around for more details, I found Jesse Liberty's blog posts about learning Silverlight from a .NET developer's perspective. Excellent! Not only is there are series with me as a target audience, but one that is a lot like my planned learning exercise, AND it's by the guy who wrote the book that I started my .NET learning with as well! Jesse's post about the differences between 1.0 and 1.1 lead me to the Silverlight Runtimes Matrix which shed some more light. I could deal with just using javascript for my initial learning, but when I saw that isolated storage wasn't supported in 1.0 that tipped the scale. I'm not sure exactly why ... it could be because one of the first cool demos I saw of Silverlight was how the isolated storage was shared between all browsers. I found the demo again on ExplosiveDog.com's " Silverlight Isolated Storage" post. I switched targets and downloaded the Silverlight 1.1 Alpha Refresh and Silverlight 1.1 SDK. One thing I'm still confused about is whether the 1.1 SDK is up to date with the 1.1 alpha refresh. I kind of doubt it because the search results on Microsoft Download have it listed with a date of 5/17/2007, while the Silverlight 1.0 SDK RC has a date of 7/27/2007. I decided to hold off on installing the 1.1 SDK, but I'd already installed the 1.0 SDK RC so we'll see what happens. At this point I've more than used up my first day's amount of time. Maybe later tonight I'll look at some of the samples in the quickstarts, but now my eyes are tired from staring at the monitor for too long. Too bad there aren't any books out yet, because I could really use some printed text at this point. Labels: silverlight, sprint
Today I've decided to start the 30 day learning sprint that I've been putting off for a while now. The technology that I've decided to learn is Microsoft Silverlight. This was my plan from a few months ago but procrastination lead me to put it off until now. For the next 30 days I am making a pledge to myself to spend at least an hour each day focusing solely on a task that will help me learn Silverlight. Whether that task is reading a tutorial or document, writing or debugging code, or anything else related, the point is that I commit to spending this amount of time each day on the goal. I hope that the one hour requirement will allow this to fit into my family life and schedule without being disruptive. Also, by writing this blog post I'm not only committing this to myself, but hopefully the public announcement will help me stay on task. (Plus, I can always come back and delete this post). I will also post one blog entry detailing what I planned on accomplishing for each day, how it went, and what the outcome was. Labels: silverlight, sprint
This is old news for most developers, but I'm throwing it out there anyway. I've known about Microsoft's LogParser for a long time now, but today is the first time I've actually used it. I needed to get some quick stats about the usage of some WCF services from an IIS log of an application recently put into production. I downloaded LogParser 2.2, googled and found some examples, experimented with some queries, and within 2 hours had a batch file that was creating two simple text file reports that would quickly tell you about service usage. Here's the batch file contents I created: @echo off if "%1" == "" goto reqparam @echo on
@echo * Getting total hits per service into %1_ServiceHits.txt
"C:\Program Files\Log Parser 2.2\logparser.exe" -i:iisw3c "SELECT DISTINCT cs-uri-stem AS Url, COUNT(*) AS Hits INTO %1_ServiceHits.txt FROM %1 WHERE (cs-uri-stem LIKE '%%.svc') GROUP BY Url ORDER BY Hits DESC" -o:NAT -rtp:-1
@echo * Getting hits per hour into %1_HitsPerHour.txt
"C:\Program Files\Log Parser 2.2\logparser.exe" -i:iisw3c "SELECT date, QUANTIZE(time, 3600) AS Hour, cs-uri-stem AS Url, COUNT(*) AS Hits INTO %1_HitsPerHour.txt FROM %1 WHERE (cs-uri-stem LIKE '%%.svc') GROUP BY date, Hour, Url ORDER BY date, Hour, URL" -o:NAT -rtp:-1
@echo off goto end :reqparam @echo Missing Parameter - IIS log filename :end And here's an example of the output: Url Hits ------------------------- ------ /AwesomeService.svc 208862 /SweetService.svc 133267 /GoodService.svc 41577 /MundaneService.svc 41271 /HappyService.svc 10300 /CrappyService.svc 2950 Just for fun, here's a command that will create a pie chart. "C:\Program Files\Log Parser 2.2\logparser.exe" -i:iisw3c "SELECT DISTINCT cs-uri-stem AS Url, COUNT(*) AS Hits INTO c:\temp\iisreport.gif FROM c:\temp\ex070730.log WHERE (cs-uri-stem LIKE '%.svc') GROUP BY Url ORDER BY Hits DESC" -chartType:PieExploded3D -chartTitle:"Service Hits" Which generated this image:  Its a little bit ugly because of the values put in front of the chart, but it wasn't worth it to me to spend the time figuring out which command line option would turn that off. * PS - I've noticed that the unofficial website for LogParser seems to be down. Bummer. Labels: tools
Christopher Hawkins' post Monday Consulting Questions: Three Reason Not to Work On-Site resonated deeply within me. As most things are, working on-site isn't a black and white issue. You have to take the bad with the good. One thing I've learned about working on-site is that you have to throw out your methodologies and adopt your client's. You won't be able to get the respect you need for your preferred practices, so you have to bend over. Another down side to working on-site is that you lose your sense of belonging. You are kind of like an employee of your client, but at most a second class version. You also have to conform to the rules, such as things listed in an employee handbook, for both your client and your employer. If you aren't independent, you also lose your connection with your real employer - your consulting company. It's really hard to maintain a connection with your company. I'm extremely fortunate that my employer does an excellent job at making me feel like I'm an owner of the company, and not just a stooge out in the world making them money. Another issue is who owns your equipment. I'd prefer to work on my own machine when I'm on-site, but usually decisions like that are beyond my control. The next best thing is to use portable apps to protect your privacy and reduce your footprint on your client's hardware. On the flip side, one of the good things about working on-site is that your client (usually) knows exactly what you've been working on and will be aware of the reasons behind delays or issues that pop up. If you're working on-site and you have the problem Christopher mentioned where the client thinks you're "just typing all day" then you've got other deeper issues that working off-site won't fix. Visibility is an important thing, as is being close to your clients. Working on-site gives you that visibility. Labels: misc
When I'm feeling especially paranoid, I worry that even my secure passwords are vulnerable to key loggers and other software that could be running on a computer. This is doubly true for public terminals. Also, as a consultant, I don't like to install applications on my work computer so I use portable applications off of a USB drive that I carry with my keys. Gizmo Richards' newsletter has a great article about improving password security in the June issue as part of a series about increasing security when using public terminals. So what can you do to improve your security when entering passwords?
Quite a lot actually. Of the many different options available to improve your password security to me the most attractive is to enter your passwords using a password manager like RoboForm2Go running from your own USB flash drive. The article also goes into alternative techniques to make entering a password more secure in order to obfuscate it from anyone snooping on you.  - Choose passwords with random characters that are long. This is standard password strength advise that is covered here and here.
- Look behind you for people/cameras that may be able to see what you're doing. Shield your keyboard if you're worried about visibility. You may feel silly about looking paranoid, but it only takes a few seconds and the only people would will even notice are ones that are trying to spy on you.
- Enter your password in a way other than just typing. This includes pasting from the clipboard, drag and drop from another place, use ALT+numpad combinations to insert letters, insert dummy characters and remove later, enter parts of your password in a different order, highlight and drag characters to another location, and maybe even using the character map to insert characters. Ideally you would use a few of these techniques together.
This information is useful even if you're not using portable apps, but worry about password strength and vulnerability. There will never be a totally foolproof method, but one of the best methods to increase security is to do things that make you less of a target. Just like pickpockets will target people who are more vulnerable, hackers and spies will target people using little to no security and ignore you because it would take too long to figure out what you're doing. Labels: security
As part of a significant refactoring effort, I was moving code from one project to another and accidentally made a change that resulted in a much different result than I expected. I'm getting a date from a database query, but that date column allows nulls. Here's what I had before: DateTime? someDate = (dataReader["DATE_COLUMN"]) != null ? Convert.ToDateTime(dataReader["DATE_COLUMN"]) : new DateTime?(); And here's what I ended up typing in my refactored code: DateTime? someDate = (dataReader["DATE_COLUMN"]) != null ? Convert.ToDateTime(dataReader["DATE_COLUMN"]) : default(DateTime); I didn't even realize I'd written the code differently, probably because they should have the same result, but they didn't. The first version, new DateTime?(), has the value null, while the second version, default(DateTime), has the value 1/1/0001. That's not even a valid date in SQL Server! The following code in a console application will demonstrate different default values. Console.WriteLine("new DateTime?() = {0}", new DateTime?()); Console.WriteLine("default(DateTime) = {0}", default(DateTime)); Console.WriteLine(); Console.WriteLine("new TimeSpan?() = {0}", new TimeSpan?()); Console.WriteLine("default(TimeSpan) = {0}", default(TimeSpan)); It looks like a new instance of a nullable object will always be null, while the default value for that type won't be null. Of course, I came to this conclusion with very limited tests, but it's good enough for me.  Labels: c#
I'm annoyed when sites require you to register in order to access certain parts. It's one thing to mandate authentication if a user is modifying or submitting content, but to for things like downloading sample code it is ridiculous. If you run into this situation, go to Bugmenot.com, type in the domain of the web site, then try one of the registered username/passwords. If you can't find one that works, you can register yourself, using a temporary email address of course, and submit your registration information to Bugmenot. Yet another victory for the web community. Labels: web
|