Monday, May 17, 2010
I am a software developer but it is still very useful to understand SEO and it's ramifications when building a website.
The 15 minute SEO List is a good SEO cheatsheet.
Also the Google SEO Starter Guide is good.
Wednesday, May 12, 2010
Were I am contracting at right now has a new development domain. Because of IT security rules it is fairly isolated from the domain my computer normally logs into (for e-mail and such). I do use a VM to log directly into the domain but one of my co-workers found this command to run things on your box but in the other domain. Pretty cool.
For example this runs SQL Server Management Tool for SQL Server 2008:
runas /netonly /user:{domain}\{username} "C:\Program Files\Microsoft SQL Server\100\Tools\Binn\VSShell\Common7\IDE\ssms.exe"
And this runs visual studios:
runas /netonly /user:{domain}\{username} "C:\Program Files\Microsoft Visual Studio 9.0\Common7\IDE\devenv.exe"
It does not solve the problem I wanted to solve which would be to be able to assign Users/Groups in Team Explorer. It instead still uses the domain I am logged into's groups.
So this blog had a purpose at one point that does not know fit the bill so I am changing it.
Now it's purpose is to keep track of all the things I might need to know again but will certainly forget.
Wednesday, April 15, 2009
Check it out on
{codesqueeze}.
Thursday, March 26, 2009
In August of 2006 I was listening to the radio and stumbled across a guy named Dave Ramsey. The simplest way to distill Dave Ramsey down is: Get out of debt, stay out of debt, live beneath your means.
Before long my wife and I were both on board with it and we were budgeting and cutting our expenses. This created a really big problem for me because my wife had been waiting for a long time to intervene on my addiction. The budget gave her the perfect excuse.
My drug of choice...Technology books.
I used to go the library and just peruse the Technology section and ponder what book will be my choice. I bought at least one a month, and usually two. I almost always read them.
My wife hated that I "wasted" money on them. But all that knowledge in one place, hard bound, and shiny was impossible for me to resist.
But now I had a problem. Our agreed upon personal spending limit was going to be severely damaged by my book habit. If I continued on this track it was going to damage my other spending habit, eating out for lunch. There had to be a way.
At first, I tried the used book store.
The used book store is a great place to get cheap books on any subject, as long as that subject is a little out of date. In our world a little out of date is a lot out of date, bordering on useless. For example, I found a really great Prolog book, which I bought (I am not an addict, I do not have a problem), but try finding a good .Net 3.x book and you are going to be out of luck.
This was not the answer.
So I tried the library.
It was as bad or worse than the used bookstore. You trade free against cheap but you add on a time limit.
Still not an answer.
But then I remembered a trial I had done of O'Reilly Safari Books online. I had signed up for the trial, perused one book, and then went back to my hard back ways. But maybe Safari could be the methadone to my heroin a good substitute.
I was wrong. It was better.
Compared to the original drug it was more flexible, far cheaper, and does not take up nearly as much room in my basement.
- I now have thousands of titles to choose from and 75-100 new ones every month.
- I could dabble in a book, taking just the pieces I needed, without having to pay for the whole thing.
- Once I was done I could jettison the book from my shelf (after a month) and put another in its slot. It did not sit around and gather dust.
- I could search through tons of books and quickly pull up sources from one book to another.
- I no longer had to haul all of my "core" books with me to work.
- I could explore into other areas without worrying that I might not like what I find.
The only negative:
- It is not as easy to read while you are taking a bath. I like a nice hot bath and a good book. And yes, I prefer bubbles.
I have survived though (I read fiction instead).
Some would make the argument that all the information you could want is available somewhere on the Internet.
Now, I consider Google a close, personal friend but I have to say he has some shortcomings. The main one is, although he does know everything, he keeps that knowledge flung all over the place. It is difficult and time consuming to get it all together in one place. Even if you do, the resulting information is often less than coherent.
So, for my money nothing beats a book, especially for learning something new. A Book will concentrate on one subject and do so with, generally, a unified voice.
Except for my money I don't want a book, I want access to thousands.
Thursday, January 29, 2009
This morning I got up in the bitter cold to walk our new puppy. I did not want to do it, but if he does not get his exercise in he turns into a total spaz by the end of the day (instead of just a partial spaz).
When we were done walking I opened up my garage door to get back into the house using the keypad. Because it was so cold I was not patient enough for the door to go up completely before I went inside. Because it was so cold I had my hood pulled up so that my peripheral vision was completely shot. Add the two things together and you end up banging your head into the garage door.
Somewhat like this:
One thing I noticed is that when I broke the beam of the safety sensor it did not stop the door. If the door had been going down and I had done the same thing it would have stopped. For some reason this gave me a pause and made me think about the way software is specified.
I began to imagine a meeting long ago in some garage door manufacturing companies corporate office. It was your typically design meeting, guys in suits sitting around talking to a bunch of guys in Dockers.
“Look fellas”, said the main guy in a suit “we have this problem.” Here he would have paused to make sure he had their attention.
“People keep getting squashed by our doors. It’s a real issue. The shut the door and then walk under them, or their idiot kids do, or their idiot dogs, or their idiot Subaru hatchbacks do.”
“Or their grandmothers”, pipes up one of the guys in suits, the obvious suck up.
“Right”, says the main suit “So what we want you to do is to work up some kind of laser that when it gets broken it causes the door to go into reverse and stop squashing people.”
“Like bugs”, adds the suck up.
“A laser?”, asks one of the Docker’s kids.
“Yeah, you know, like in the movies where they rob the art gallery and cross the laser and the whole thing comes crashing down.”
“Like Entrapment”, says suck up, who then glazes over as he thinks about Catherine Zeta Jones.
“Exactly!”, says Mr. Main.
At this point a lot of the Docker's brigade is mad because the suits are trying to tell them how to solve the problem. Of course, it is pretty much exactly how they are going to do it, but still where do these guys get off telling them how to do that. And it is not a laser, it is an optical beam. But for all the grumbling they get to it.
On the first iteration the Docker crew does exactly what is asked. The plane of the “laser” gets crossed and the door throws itself into reverse. Except sometimes the plane gets crossed when the door is going down, which is great because it caused the door to go back up. However, when the door is going up crossing the plane causes it to shut without any way to stop it. So they go back to the drawing board and decide that what it really should do is just stop.
And then one brilliant engineer says “You know, there really is no reason to stop the door if the door is going up.”
And thus instead of giving myself a violent whack and knocking my storm trooper helmet all askew, I really just got a glancing blow. And even better the door did not reverse itself and squish me and/or the dog (although at this point I might have been ok with the latter).
I guess my point is: Specification is hard, let’s go shopping.
Wednesday, January 28, 2009
If you read enough about security in general you will hear the often touted principle of do not rely on security by obscurity. It even has its own Wikipedia page.
You see this advice thrown out a lot when somebody does something like embedding encryption keys in their code. The developers assumption is that the code will never be read by anyone and thus the key is safe. I have personally seen that one cracked in about one minute.
So the advice is good, you should not RELY on security by obscurity. It cannot be counted on.
However, does that mean you should never use obscurity at all?
A common example is code obfuscation. A lot of people will tell you there is no point because someone determined enough, or good enough, or who just has a lot of time to waste will be able to break it down. So absolutely, you should not rely on obfuscation to secure your application (i.e. key hiding).
But my immediate thought is: Why make it easy for them?
Why not cause them more hassle, even if it is not all that much. What is more, the additional hassle onto itself will serve as a deterrent for the less determined, or talented, or patient.
So I believe you should assume that any information you obscure will end up in the attacker’s hands no matter what you do. But, if there is nothing you can do about it (such as somebody reverse engineering your code), then you should obscure it anyway just to be a pain in their ass. It is not like they are going to thank you for making it easier for them.
Monday, December 29, 2008
Recently, I was asked to look into a performance issue we are having with a particular windows service when it is being communicated with a MMC snap-in we have developed. Essentially the snap-in communicates with the service using WCF to get the data that populates a particular form. When the form was loaded it could take between 10-30 seconds depending upon the data storage mechanisms on the backend.
Normally, figuring out what is going on with a Windows service can be a huge pain in the ass. Everything is being tossed out on a seperate thread and you have to figure out what causes it to do what and what else is going on.
Fortunately, I have
dynaTrace on my side!
So first thing I need to do is select my applications for instrumentation using the .Net Configuration Tool:
This basically lists every piece of managed code ever JIT'ed on my box. What was interesting to me is that I do not think the Microsoft Management Console (mmc.exe) is managed code. But, because it loads up my managed code it shows up in the list. Because of this I could see what is happening on the console side.
I also chose to instrument the Windows Service as well. The next thing you need to is determine the specific set of methods that are interesting in this scenario. Doing this is no small trick and deserves a post onto itself so in the end I had this being reported in dynaTrace.
The big contributed here was the code in the namespace that took 39 seconds to execute, but that is not what I am going to focus on for this article. While the developers were chunking on the code causing those issues I also noticed the GetDefaultCertificate code was taking 3 seconds or so.
The code is basically something like this:
internal static X509Certificate2 GetDefaultCertificate()
{
string certString = GetCertificateSetting();
if (string.IsNullOrEmpty(certString))
{
return null;
}
byte[] bytes = Convert.FromBase64String(certString);
X509Certificate2 cert = new X509Certificate2(bytes, "");
return cert;
}
My code Nazi alarm goes off immediately because this code should definitely be a property (if your method is named Getwhatever that is usually your first clue).
Leaving that be though, the thing I now know, because of dynaTrace, is that this psuedo-property is accessed 56 times, but does it really need to new'ed up each time?
Turns out that it does not. That the certString never changes through the course of an execution (it is held in an App.Config which cannot change). So this values should be set once and just referred to again and again like so:
internal static X509Certificate2 GetDefaultCertificate
{
get
{
if (m_certification == null)
{
string certString = GetCertificateSetting();
if (string.IsNullOrEmpty(certString))
{
return null;
}
byte[] bytes = Convert.FromBase64String(certString);
m_certification = new X509Certificate2(bytes, "");
}
return m_certification;
}
}
A very minor code change. But one that would have been very difficult to see as necessary without dynaTrace pointing it out to me.
Wednesday, December 24, 2008
My company recently purchased a software called dynaTrace to be used for performance diagnosis. It primarily started as a Java tool but they do support .Net as well. Since my company is entirely .Net based I will explain the product from that point of view.
The application works by using MSIL injection to put essentially a header and footer into each method you have instrumented in an application. If you do not know what MSIL Injection is here is a great overview on the PostSharp website, and here is a more detailed but not as accessible explanation of how to do it.
So as your applicaiton is running each instrumented method reports back to a diagnostic server which collects all the method calls and then strings them together. There is a client application that connects up to the server and lets you see what is going on in a particular execution. Each seperate transaction flow in your application, what dynaTrace calls a purepath, is knitted together so you can follow it all the way through.
The product can follow across web service, MSMQ, and remoting calls so that everything is seen together as one transaction. The current version cannot do WCF but their next release (hopefully 1st quarter 2009) will.
So, let's say you had an instrumented ASP.Net website that when some user makes a request, it calls a web service which is also instrumented, which then contacts the database. With dynaTrace we would see that as one request, it would be relatively transparent when the code executed across to the web service. The calls the web service makes to the database are seen because ADO.Net is instrumented, but the database server itself is not directly instrumented.
So now I can see the total time of the web request , all the pieces of it, and what database calls are made. With that information you can figure out what the big contributers are very easily.
Tuesday, December 09, 2008
Several blogs I follow have mentioned that SafeCode has released there Fundamental Practices for Secure Software Development guide. I had thought that this was released a while ago actually and the document is dated October 8th. Oh well, it is a good reference regardless.
The mission of SafeCode.org is "SAFECode is dedicated to increasing trust in information and communications technology products and services through the advancement of proven software assurance methods." They have a number of different organizations contributing to this effort, like Microsoft, EMC, Symantic and others.
I got to it by reading this article Secure Software Development Practices 'not rocket science'.