| Comments

i've gotten a few comments privately about some questions and thought i'd offer some opinions here.

first, regarding my flickr/tagging plugins.  again, i've chosen codeplex to be my source of distribution/collaboration and i'm just waiting for project approval -- hopefully i'll get it shortly and then the plugins will be up there in no time.

now, on to the hacking :-)

i should point out that is beta right now and they've acknowledged more work to come.  still, it's an awesome tool and kudos to the team, especially joe for championing some of my feedback :-).  because it is beta, things may change -- so heads up now.  also, my suggestions below are "as-is" and have not been verified, tested, or any other synonym you could think of that has to do with ensuring things work.  these are merely some suggestions...implementing them may cause unknown issues and you shouldn't blame the windows live writer team, only yourself for listening to me :-)

Q: "how does windows live writer detect my blog?"
A: great question.  writer originated from the planet krypton...shortly after superman left and before it exploded.  that brief time gave it the super-power of blog detection.  but really, it's a method called ' and if you dig deep enough in the WindowsLive.Writer.BlogClient assembly you'll see ..Detection.RsdServiceDetector with some interesting methods. 

Q: "it didn't detect my blog type even though i use MetaWebLog API"
A: ah, mine neither...but i didn't expect it to.  why?  that's easy.  MetaWebLog API is just that, an API...it doesn't belong to any particular blog engine or product and in fact, many implement it.  but each implement in their own way/location.  .Text/subtext use <blog>/services/metablogapi.aspx; typo uses <blog>/backend/xmlrpc to access it.  so there isn't really a way for writer to intuitively detect api-based blogging engines.  sure, they could have a config file that could likely look at some commonality of *known* engines and map to their default api locations, but that would grow, who would maintain it, etc....just not very trustworthy.  UPDATE: i forgot to correct myself.  you can, of course, implement the RSD link in your blog and then it should be fine...

Q: "my blog provider isn't supported, this thing sucks and i won't use it"
A: ouch, that hurts.  it doesn't suck.  in fact it is quite good and extensible.  your blog provider doesn't work?  hmm...what one are you using?!  likely it implements a common api and you can find the url for it.  but okay, i'll give you the benefit of the doubt...maybe you're using something crazy like or something.  let's take a look at how you might start implementing support.  caveat: again, this is my opinion and as-is. 

1) first, ensure that you've at least run writer one time.  heck even create a free blog on spaces to try it out.  if you don't run it once, don't bother going to step 2
2) next (did you run it first yet?) look in your user settings directory (on xp that is your 'document and settings folder'; on vista it is your 'appdata' folder) and look for the 'windows live writer' folders, namely one called 'resourcecache' -- did you find it?  go to step 3.
3) dig deeper into resourcecache until you get to the windowslive\writer\blogclient\providers folder...take a look at that little gem :-)
4) add your entry to the bottom...ensuring a guid and a unique reportingKey value.  NOTE: writer may implement more that overwrite this and in fact if your wanting to know where these definitions come from, you could snoop a bit further.

once you do this, you'll notice the wizard now has your blog in there.  now, that's all fine and dandy but of course, that's just the ui, you'd of course have to ensure that your blog engine supports the posting apis, etc.  in fact, this is only a quick hack i noticed and now that i think about it, i think you'll have to do a bit more...so take a look at BlogClient as well.

Q: how do i build a plugin?
A: first, get the SDK.  then start playing around.  here's the quick and dirty.  a contentsource is the simplest type, you provide some mechanism to get or play around with data, user input, whatever -- then the end result is content you send back to writer...that's it.  this is what i'll call a one-way implementation...if the user made an error, they'd have to delete and start over.  for some situations that is fine.  the other type is a smart content source.  this is like the windows live local map and image implementations that are there in writer.  you can play around with user input, yada yada, but when you also click back in the editable area, the side panel turns into an edit view of that content source.  this is the powerful one, but takes a bit more time and forethought...

so there's some quick answers to some questions i got...

| Comments

it's official! for the past few weeks i've been able to use a new tool just released, called windows live writer.  at it's core, writer is a blogging client (i'm sure there will be other uses for it in the future, but for now, this is what i use it for).  after seeing the announcement of the tool, i was skeptic.  YABC is what i thought (yet another blogging client, for those not familiar with the YA* acronyms).


but i bleed windows blue, so i installed it.  i should point out at this point that i amwas a blogjet user and gladly paid for it as it iswas a great tool for me having all the features i needed.  i loved it.  really.

my initial reaction to writer was 'sweet' -- until i started digging into features.  the writing experience was great and familiar, and the style preview in real time is great.  but i quickly noticed some lacking features.  i pinged the team and pointed them out.  after going back and forth, i was happy to see they started to trickle in to the daily teams.  it was great to see the agility of this writer team and willingness to take feedback.

i then noticed a few glaring missing things: integration with tagging, integration with flickr, etc. -- the things i loved about blogjet.  have no fear, writer has a plugin model and is extensible.  sweet.  after reviewing the sdk i came up with a flickr plugin that allows you to look at your flickr images (or others) and insert a reference to it.  yeah, it's simple, but that's what i loved about blogjet's simplicity as well.  the great thing is that the writer extensibility layer is .net -- nice! 

i wrote a quick and dirty tagging plugin as well that allows you to template some items.  i suspect this will be replaced by a much better one, but for now it does the job for me.  here's a screen shot of the tagging plugin:


and i also wrote a flickr image plugin that looks like this:


i would encourage you to download writer now and start using it -- take it for a spin...i think you'll like it -- and the extensible model.  give the team feedback.  let me know if you have any questions.  write plugins.  I hope to have my plugins available on codeplex as soon as the project gets approved.  please subscribe to this blog to know when that happens.

what are you waiting for? 

| Comments

well, amidst the scurry and comments of yesterday's rails security issue and resulting patch debacle, today, yet another new version is released and patches for the previous versions.

the *MUST UPGRADE* patch of yesterday didn't even appear to fix the issue.  sure, this happens, but maybe if some subtlty was exhibited and some of the feedback (unfortunately after the fact) was leveraged, it could have been avoided and a correct patch along with the full disclosure could have been implemented.

with today's new release, it caused me pause of the growing pains of this rails community.  several things happened today: a notice of a new release (second w/in < 24 hours), a notice of a move of the trac server, and a notice of a security mailing list (a suggestion from a community member).  the rails community is growing and this incident and the way it was/was not handled (depending on who you ask) is evidence of the struggles we all face, regardless of technology, in building communities around open source projects and the unfortunate byproducts at times of design/lead by community.

| Comments

...and nobody knows what it is.  warning: this is a long post, but sit back and read it -- it is quite telling IMO.

while reading some of my email list posts this evening, i came across a post on the ruby on rails forum:

This is a MANDATORY upgrade for anyone not running on a very recent edge (which isn't affected by this). If you have a public Rails site, you MUST upgrade to Rails 1.1.5. The security issue is severe and you do not want to be caught unpatched.

The issue is in fact of such a criticality that we're not going to dig into the specifics. No need to arm would-be assailants.

So upgrade today, not tomorrow. We've made sure that Rails 1.1.5 is fully drop-in compatible with 1.1.4. It only includes a handful of bug fixes and no new features.

For the third time: This is not like "sure, I should be flooshing my teeth". This is "yes, I will wear my helmet as I try to go 100mph on a motorcycle through downtown in rush hour". It's not a suggestion, it's a prescription. So get to it!

probably the most interesting part being the 'such a criticality that we're not going to dig into the specifics.'  this has caused quite a heated debate in the comments on the blog...i've picked some of the interesting comments to repost as i thought were particularly interesting, important and to me shows some of the leadership collisions in that community...here are some of my favorites (you can read the full post and comments on the ruby on rails weblog):

This WARRANTS full explanation! If there is need enough to alarm the
people that use the product then there is certainly a need to provide
disclosure of some sort of what the problem is.

This "attitude" to some degree diminishes the value of Rails. It
suddenly took a very cool framework and set it back because of the
unprofessional way in which a problem was handled. I firmly believe
that you can judge a company (or person or product) not by the way they
handle things when things are going well, but by the way they handle
things when things go wrong. In business, and life, things go wrong.
Handle it properly. This is not the proper way to handle an issue as
serious as it sounds.

Provide the details. COMMUNICATE to people so they know WHAT the
problem is and what their exposure is. NEVER put out a generic
statement like this - it is almost as bad as hiding the problem

Leeto wrote:

A rather humorous patch announcement you have here. Declaring an upgrade as mandatory without offering the public so much as a single glimpse as to what is wrong? You say the security hole is gaping… but you offer no proof of concept or exploit explanation.

No one should be expecting you to be posting pre-compiled code that script kiddies could utilize, but no one should be taking your concern for security seriously without a full disclosure of what is wrong.

FM wrote:

You’ve got to be kidding. When has security through obscurity ever worked? We run quite a few semi-public (ie, heavy-use critical internal applications) here and we can’t afford to just upgrade without knowing what the problem is. Sure we could dig through changesets, and we probably will, but not fully disclosing a critical security problem is very bad practice.

Daniel expressed concern while selling Rails to his organization:

I second the points made by DGM and DW. I’m in the process of convincing my boss about using Rails for our next major project. I have had big hope in the success, but this makes me uncertain if that is a road I can recommend.

perhaps what is somewhat disturbing is the comments from some of the core leadership and the tone...after the infamous 'f-you' slide at railsconf, DHH offers some opinions of his own on the blog, can you spot the sarcasm?:

DHH wrote (speaking of the need to patch):

Daniel, there’s no rush if you don’t mind having the security leak. Just as nobody is forcing you to upgrade Windows every week with the latest security fixes. Of course, not doing so greatly exposes you to the exploits of those holes. I think most people would appreciate the urgency and “rush” to get a fix out and applied in a hurry.

If you are aware of any other web platforms with major adoption that has never seen a security fix release, I’d love to hear about it. That must be a truly fantastic team that we’d love to learn from.

Chris Mear responded:

It’s not the mere fact that there is a security release, it’s the fact that there’s a security release and you won’t tell us what it addresses, so we’re unable to make that decision about whether we should apply it or not.

Instead, we have to take your word that this is super-important.

bougyman comments:

Nothing is abnormal about a framework this large having a vulnerability from time to time. But corporations cannot make decisions for deployment based on the (lack of) information provided in this announcement. We love the rails environment and have been pleased with most aspects of the software delivery. However, when the rubber hits the road (real world security), procedures have been Horrible. Partial disclosure doesn’t give those who are running applications enough information to come up with a workaround (like using a webserver filter language to disallow the malformed request) and certainly not enough ammunition to convince a Suit that an immediate software upgrade is necessary. ... Not maintaining an informative, coherent policy and procedure for releasing these announcements and patches could not only keep rails from being adopted in such managed environments, but flat-out get it pulled and replaced in those which it has already found its way. Including mine.

there are a lot of positive comments as well -- pointing out the patch worked fine, and a few people helping others upgrade (and on windows as well!), but it was very intriguing to me to see some pretty logical posts regarding full disclosure and how the community leadership is reacting to those comments...i wonder if DHH has an f-you post in his draft folder of his blog client :-)

| Comments

okay, i'm slightly ashamed to admit it, but today i finally saw the visual studio team edition for database professionals in action.  vsts expert rich Hundhausen was demoing to a customer and i wanted to tag along to see this new feature set available to the team system family.

after 40 minutes of seeing some of the simple features all i could say was: cool.

seriously.  it was so simplistic, yet so necessary and needed for the db developer world.  here's a run-down of some of the features i saw today:

  • creating db schemas by reverse engineering
  • diff'ing schemas to other projects *and* other databases (note: you can do this without having to setup a project, reverese engineer anything etc)
  • schema compares
  • build and deploy implementations with msbuild
  • data generation plans -- this was cool, a true data gen built into the product (which can be a part of a build plan as well to always start with a consistent state) -- can use static info, or retrieve data from a database, or you can set parameters, regex, etc., etc.
  • unit testing of db scripts (pre, test, post scripts)
  • source control integration with the vsts policies, etc.

it seriously put a little geeky grin on my face.  i got back to the office and downloaded it immediately (you can get ctp4 from here).  i'd encourage you to take a look and play around with it.

and as we know, the easiest way to learn is to teach.  i'm giving a demo at the next sql server user group meeting in my area!