Bernadette Baker (shown on right; affectionately known as Bernie), literary agent, small business owner and friend made the local paper in an article titled Bound to books.  Here's a quick excerpt:

“I love Portland,” she says. “For our business it’s a really great place for us to be starting. If we were to go to New York right now, as a business, we would not only have to transplant our whole lives, but we would be competing in an environment that is already really competitive. In Portland we have an edge because there are a lot of creators here but not a lot of industry here. The publishers here are more niche, and it’s a small community.”

Baker believes that Portland and the surrounding area, full of talented, creative writers, is a natural place to develop more of a publishing industry.

Congrats Bernie.

Be sure to check out her site; www.bakersmark.com.

The other day I tried to add a simple "Remember me" checkbox to the login.aspx page for a site I'm working on.  Simple enough in theory that I didn't think much of it and gave myself an hour to add it in. 

Here's what I needed it to do:

• Pre-populate the txtUserName textbox of the last user IF they checked the "Remember me" checkbox.
• Remember the state of the "Remember me" checkbox so that the user doesn't have to check it each time they log in (or uncheck it).

Sounds simple enough right?  Just add a cookie and check it when login.aspx loads, right?  Wrong.

The problem became clear very early on; the cookies were being cleared when the user logged out.  Since my goal was to access the cookie BEFORE the user logged in, I could not rely on the cookie.  But I HAD to use a cookie, there was no way around it. 

So, after some searching and trial-and-errors, I came up with a simple solution: use JavaScript cookies.  Now it sounds like a bit of a hack but it's not really.  JavaScript has been able to read and write to cookies from the get go. 

So first we need to write some simple script that will read/write to cookies:

Next, we create 2 new custom methods; one to read the cookie when the page loads and the other to write/remove the cookie when the checkbox is checked:

Now, all that is left is to add an onload event to the body tag and an onclick event to the checkbox:

(note; since the checkbox value is not used anywhere but the client, I chose not to use a .NET server control)

Viola, you're done.  Simple, effective and it can be used by multiple browsers.

This is a quick test post using Windows Live Writer Beta. 

The blog engine I use (dasBlog 1.9) supports the Live Writer API and I'm liking the interface mainly due to the fact that it looks like I'm composing an email or normal document rather than posting to my blog.  I say this because more times than not, I post during work hours.

Another option I have since I use dasBlog, is the "mail to weblog" posting feature.  This feature allows me to post by simply sending an email to a preset email address that the blog engine monitors and posts when it receives it.  As much as I love this feature, the formatting is a bit off when I use Outlook.  If I had a phone with easy access to email, I would post quick features while on the road.  But for everyday posting its just not robust enough.

Which bring me back to Live Writer.  Along with the slick UI, there is the ability to save drafts and spell checking.  Long gone are the days when I type up a post, copy it into Word just to check my spelling. 

UPDATE: Two thumbs up... way up for this little item.  Not only did it keep the formatting exactly like I entered it but it also uploaded the image above for me.  I wasn't expecting that at all.  When I put it in I thought to myself "oh great, I'll have to upload the image manually".  It's that little touch that makes everything grand.

That's it! 

I've tried to keep the ad's down because I didn't want them to become to intrusive but the small ad at the top was just NOT cutting it.  Since I switched a few months back, my ad revenue dropped dramatically.  Now, after reading a top 10 ten list of google whores I'm changing my strategy -ad's out-the-ass!

Enjoy.

Recently I created my own custom macro object for dasblog 1.9 but ran into a slight problem; it acted like the dll I created wasn't there.  Following this article (Creating custom macros for dasBlog) to a "T" still faired no better.  Not wanting to spend too much time on this and thinking that I was doing something wrong, I emailed Scott Hansleman (one of the main contributers to dasBlog) to see if he could spot my problem quickly.  Scott was great and we corresponded for most of the day trying different things to try and solve it.  He took a special interest in this because he said that this was the second inquiry in the same week about this error.

2006-09-29 14:00:18 PM
1
Error:
Error executing Macro: System.ArgumentNullException: Value cannot be null. Parameter name: type at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes) at newtelligence.DasBlog.Web.Core.MacrosFactory.CreateCustomMacrosInstance(SharedBasePage page, Entry item, String name) at newtelligence.DasBlog.Web.Core.TemplateProcessor.ProcessTemplate(SharedBasePage page, Entry entry, String templateString, Control contentPlaceHolder, Macros macros)
while processing .

2006-09-29 14:00:18 PM
1
Error:
Error executing macro: Test("hello", 1)|Extras. Make sure it you're calling it in your BlogTemplate with paratheses like 'myMacro()'. Macros with parameter lists and overloads must be called in this way. Exception: System.MissingMemberException: Member newtelligence.DasBlog.Web.Core.Macros.Test not found. at newtelligence.DasBlog.Web.Core.TemplateProcessor.InvokeMacro(Object obj, String expression) at newtelligence.DasBlog.Web.Core.TemplateProcessor.ProcessTemplate(SharedBasePage page, Entry entry, String templateString, Control contentPlaceHolder, Macros macros)
while processing .

From the looks of everything, it seemed that dasBlog could not find my custom class.  But why?  I made sure the changes in the web.config were correct because I thought for sure that was where the problem was.

Scott was able to duplicate the error once, then realized that he forgot to put his macro dll into the bin folder.  Emailing me again, he asked - as nicely as possible I might add - if I had forgot to put the dll in the bin directory.  Nope, I replied and even sent a screen shot of the servers bin directory.  To top it off, I sent him my solution to see if he could find anything wrong with my code or references.

While he was working away on solving this (thinking that there was something wrong with the macro factory code) I switched gears to see if building the macro using .NET framework 1.1 had anything to do with it.  I say this because the article on how to create custom dasBlog macros was using the .NET framework 2.0 so I did the same; why not, if the article did it in 2.0 why couldn't I?

Well the 1.1 solution worked!  Just then, I got another email from Scott asking if I was running dasBlog under 2.0 or not.  You see, creating macros under the 2.0 framework NEEDS dasBlog to be running under the 2.0 framework as well... DUH (as I smack myself in the forehead).

The problem all along was not with my code, not with the blog engine code but rather with the fact that I was trying to run a macro intended for .NET 2.0 under the 1.1 framework.

2 solutions presented themselves: A) Switch dasBlog to run under 2.0 or B) create the macro under 1.1.  Why is B even an option?  Because it is backward compatible with 2.0.  That's right, the 1.1 macro has more flexibility if I want to distribute this dll to others who, for one reason or another, are still running dasBlog under the 1.1 framework.

In summary, if you are trying to create a custom dasBlog macro and run into a problem, check to see that your website is running under the same .NET framework version as your solution (or lower).

A big thanks to Scott Hanselman for taking his time to help me with solve this dilema.