I recently had to whip up a small application to demonstrate the programmatic interface for silverlight 1.1. Using a tag cloud as a suitable project, I quickly became aware of the difficulty of X-Y only positioning for that type of scenario.
I came up with a solution using the 'ActualHeight' and 'ActualWidth' properties:
string[] tags = new string[] { "asp.net", "sqlServer", "bookies", "babaganoush", "frankie", "johnnie" };
double currentX = 0;
double currentY = 0;
double highestHeight = 0;
foreach (string tag in tags)
{
TextBlock tagblock = new TextBlock();
tagblock.Text = tag;
tagblock.FontFamily = "Verdana";
tagblock.FontSize = 10;
tagblock.Foreground = new SolidColorBrush(Colors.Black);
tagblock.MouseEnter += new MouseEventHandler(Tag_MouseEnter);
tagblock.MouseLeave += new EventHandler(Tag_MouseLeave);
highestHeight = (tagblock.ActualHeight > highestHeight) ? tagblock.ActualHeight : highestHeight;
if ((currentX != 0) && (currentX + tagblock.ActualWidth > this.TagCloudCanvas.Width))
{
// reset width & go to the next line
currentX = 0;
currentY = currentY + highestHeight + 5;
highestHeight = 0;
}
tagblock.SetValue(Canvas.LeftProperty, currentX);
tagblock.SetValue(Canvas.TopProperty, currentY);
this.TagCloudCanvas.Children.Add(tagblock);
currentX = currentX + tagblock.ActualWidth + 5;
}
HTH!
I was reading a post today regarding whether or not the community could trust us (Microsoft) in regards to the rapport framework.
A very well written article, it struck many points that I had not considered as of yet and that will be quite useful in the days to come.
The topic of Open-Source was flitting about in the comments and the thing that occurred to me (*again*) is that if the software that we produce here wasn't worth the money to pay for, nobody would be buying it. The fact that Microsoft protects its investments with patented work, much in the same way that any business would, should not surprise.
So I'm going to guess then, that the main complaint is that software shouldn't be able to be patented. I'll await replies to see if I've really missed the mark here, but in closing I'll say that to change the rules after the patents have been issued is a bit untowards. At what point then would all patentable items be up for the same danger?
I was talking with a colleague of mine the other idea about an idea I had surrounding information gathering: brain dump. <disclaimer>I haven't spent a lot of time searching about to see if it's been done yet, but nonetheless, I feel it's worthwhile to mention it.</disclaimer>
Basically, the idea spawned after I was talking with Korby about aquiring some land out in the mountains. A Washington native, very versed in different aspects of the terrain, he had a lot to offer. He also showed me a nifty web tool from Chelan county that allows you to drill in to loads of publicly available information on specific land plots; very cool.
Thus came the idea: wouldn't it be nice to: pull everything about land management, aquisition, community activities, etc. etc. from a trusted source programatically so that it'd be a button click / url away from me at any time anywhere I can access the web. Offline availability / download-ability / etc. is a phase 2 idea.
With tagging, and the coming availability of trust / recognition systems, this idea is not too far off from at least an alpha.
Well, the short answer is (i think): you can't. Early on in my search for the answer, I ran across this article on w3schools stating that you can either:
-
create your stylesheet explicitly in the <head> element of the page (<head><style>blar blar blar...)
-
reference a common stylesheet in the <head> element of the page (<head><link href="style.css" blar blar blar...)
-
inline the style qualities on the elements in question (<p style="background:red;">this isn't so hot...</p>)
Well, I thought that I'd fiddle around anyways to just see what I could find and got all excited when I saw the 'src' sub attribute of the style property on a div tag:
<
div style="src:url(StyleSheet.css)">
Unfortunately that is only for the url of the font to download. :( I was really hoping to avoid inline for the scenario I need to implement but I might just have to. Any help would be appreciated.
Thanks to my friendly office mate, I was informed of the latest service pack for studio developers running vista.
http://www.microsoft.com/downloads/details.aspx?FamilyID=90e2942d-3ad1-4873-a2ee-4acc0aace5b6&DisplayLang=en
Just got through the install so I don't have any sound feedback on it yet. If I notice anything notable, I'll be sure to mention it here.
As mentioned in his latest post, I'm accompanying my boss and some coworkers to this year's Boise Code Camp next weekend. Having never been to a BCC event in the past, I'm excited at the prospect - also 'cos I'll be helping out with one of Doug's presentations (Test Driven Development Using VSTS). In addition to some of the TDD basics, hopefully we'll have time to get over some of the helpful tidbits we've picked up here and there (best ways to view new tests in the vsdmi, creating checkin policies, etc). If not, it'll still be a good track to somebody who's either looking for more info in TDD or somebody that knows what it is but hasn't yet incorporated it into VSTS.
Wednesday this week, I was fortunate in that one of my teammates arranged for Mike Cohen, a known agile guru, to come and present his estimating & planning course to our group. He was a great teacher who presented well and the material was good - so 2 thumbs up.
One of the interesting topics that came up was measuring units of work (hours, points, bananas, etc). In one exercise he had the class divide into two groups bent on proving why one method was better than the other (the two we were using at the time were 'Ideal Days' and 'Story Points'). I found it was easier to argue the 'ideal day' due to: the familiarity of the concept 'day' and touting the ease at which an ideal day (or collection of) was converted to actual days (say, for mgmt or mktg), easier learning curve, etc.
All in all, a good use of my group's time - I'm glad we have the ability to take a day here and there to learn together.
Today brought about the architectural decision that our suite of refactored community apps would be represented in RESTful manner. For what that means to us in the short and skinny is that our application endpoint (say Blogs) would be exposed in such a fashion that depending on the URL that we send to it, we'll get either HTML, XML or RSS, with the adoption of other formats (JSON) potentially coming in later releases.
As it is a great decision IMHO, the timeliness of it being so near to our deadline and the fact that our team has not yet implemented a RESTful app has a couple of people concerned but I think that in the end, all will be happy we made the leap. Hopefully, I'll have URLs for these types of things in the betaplace coming forth so that the mashers can start fiddling around with them.
Having been involved in several, several-hour planning meetings in the last few days, I thought I'd share some experience-based advice.
- Make sure that there is a driver; someone who:
- plans the meeting (determines what will be the result of the meeting and usually provides the following information)
- sets the agenda. Critical for all but the most trivial of meetings. Provides a track to keep conversation on, ensure time is being spent in interest of and so forth.
- sets expectations of attendees. A brainstorming session about the new profile API signatures would not need as much preparation work as say, a sprint post-mortem, where you want to spend the meeting time going over what went well and what didn't; not figuring out during the meeting what went well and what didn't.
- lays the ground rules (i.e. "No laptops during meeting session", "Speaking privileges are obtained only by physical contact with the magic-speaking-wand", etc. etc.)
- keeps things on track. Use the agenda to make sure that you are getting out of the meeting what you signed up to get out of it. If topic strays from what's most important, you have a great way of cracking people on the knuckles.
- Don't be afraid to hit the brakes
- If the meeting is a wash (perhaps somebody else set up the meeting and it is being poorly executed), feel free to determine what it will take to get things back on course and, if necessary, postpone the meeting.
For those interested in sprucing up there development experience with C# in VS (03 || 05), check out
ReSharper. It was brought to my attention by
my boss, who I believe heard about it through the grapevine via the CodePlex gang. I'm pretty excited to give it a try as there are lots of nice features to be utilized (2 minutes to go on the trial install). If there are any significant epiphanies reached whilst using it (limited, of course, to work-specific epiphanies that is) they'll be posted here.
One of the first things I learned in a role as a developer was to never fall in love with my code; aka make it 'my baby'. It took a little while to actually get there, but now I am usually one of the first to peg my babies as 'ugly,' as I know most all of their faults already.
Midway into my current project (which is being developed in an agile approach and is targeted for 'beta' quality), I'm slightly struggling with ugly-baby syndrome again. Mainly, we're trying to get something shipped so that the teams who will be utlizing it can give us the detailed feedback that we (*collectively*) aren't taking the time to gather beforehand. Mainly, it's the non-visible stuff that I am having having difficulty putting off until a later iteration (instrumentation, security, etc.). It's stuff that you know you'll have to end up doing eventually, but you don't want to waste time doing it on features that might be refactored or cut.
It's an interesting approach, but definitely different than the waterfall approach I was schooled in and then later conditioned in whilst developing in an enterprise IT group. Overall, I'd have to say that I am enjoying it, but I do laugh every time I think of the day that our little baby beta will be born into a critical environment only to highlight what Ma & Pa did and didn't do right.
Recently in my current PIP (project-in-progress), I needed to take a collection of string values in the middle-tier and insert/update them as records in my database via a stored proc. In the past, I've used a delimited string and a split-like table function to accomplish this. Not wanting to go down that route again, my SDET and I decided to make use of the XmlDataType option available in Sql Server 2005.
using XmlDataType as a parameter
Great, so we're going to take a chunk of Xml, now what? Next steps were to determine the schema of the input, where it would be validated and when to create the xml.
I decided to put the schema in the schema collection of the database and validate the input as it came in to the stored proc. I did this mainly because I noticed that if I didn't specify a schema on the xml parameter of the sp, it wouldn't throw an exception when invalid xml came through, it simply just didn't get the data out of it as it was supposed to (no surprise there, really).
In generating the actual Xml to send to the stored procedure, I waited until the last possible moment in the call chain (in the SqlParameter preparation of the corresponding method in my middle-tier C# code). I did this particularly to simplify the calls up the stream (which eventually were exposed via a service API).
disclaimer: as I am new to working with Xml in T-SQL, I am by no means saying that this is the very best way to go about this. In fact, if there are improvements/modifications that you'd make, I'd welcome hearing them.
t-sql
-- necessary for use in build scripts
IF EXISTS (SELECT * FROM sys.objects WHERE object_id = OBJECT_ID(N'[dbo].[InsertCreditCardClaims]') AND type in (N'P', N'PC'))
BEGIN
DROP PROCEDURE [dbo].[CreateUpdateCreditCard]
IF EXISTS (SELECT * FROM sys.xml_schema_collections WHERE [name] = 'ClaimsSchemaCollection')
BEGIN
DROP XML SCHEMA COLLECTION ClaimsSchemaCollection
END
END
-- create the schema
CREATE XML SCHEMA COLLECTION ClaimsSchemaCollection AS
N'<?xml version="1.0" encoding="utf-16"?>
<xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified" xmlns:xs="http://www.w3.org/2001/XMLSchema">
<xs:element name="Root">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="unbounded" name="claim">
<xs:complexType>
<xs:attribute name="text" type="xs:string" use="required" />
<xs:attribute name="isVisible" type="xs:boolean" use="required" />
</xs:complexType>
</xs:element>
</xs:sequence>
</xs:complexType>
</xs:element>
</xs:schema>' ;
GO
-- create the proc
CREATE PROCEDURE [dbo].[InsertCreditCardClaims]
@CreditCardId uniqueidentifier,
@Claims xml (ClaimsSchemaCollection)
AS
SET NOCOUNT ON
INSERT INTO Claims (ClaimText, IsVisible, CreditCardId)
SELECT T.c.value('./@text', 'varchar(max)'),
T.c.value('./@isVisible', 'bit'),
@CreditCardId
FROM @Claims.nodes('/Root/claim') T(c)
GO
c# (from the CreditCard business component)
…
if (claims != null)
{
parameters[4] = GetClaimsParameter(claims).InnerXml;
}
else
{
parameters[4] = DBNull.Value;
}
…
…
/// <summary>
/// This method takes an array of strings and returns
/// an XmlDocument of the appropriate type for use in
/// the InsertCreditCardClaims stored procedure
/// </summary>
/// <param name="claims">array of claims</param>
/// <returns>XmlDocument of claims</returns>
static private XmlDocument GetClaimsParameter(string[] claims)
{
XmlDocument claimsXml = new XmlDocument();
XmlElement root = claimsXml.CreateElement("Root");
claimsXml.AppendChild(root);
foreach (string claim in claims)
{
root.AppendChild(CreateNewClaimNode(claimsXml, claim));
}
return claimsXml;
}
/// <summary>
/// This method creates an claim node with the given text
/// in the XmlDocument sent to the method
/// </summary>
/// <param name="doc">xmlDocument to create the node in</param>
/// <param name="claimText">text of the claim</param>
/// <returns>xml node</returns>
static private XmlNode CreateNewClaimNode(XmlDocument doc, string claimText)
{
XmlNode node = doc.CreateElement("claim");
XmlAttribute text = doc.CreateAttribute("text");
text.Value = claimText;
node.Attributes.Append(text);
XmlAttribute visible = doc.CreateAttribute("isVisible");
visible.Value = "true";
node.Attributes.Append(visible);
return node;
}
…
So, the hot topic of 'profile' came up today over lunch (as well as the various interpretations of the acronym 'phat'). Basically, for our community sites, which profiling solution should we use? MSN, the underlying technology platform that is going to be replacing our blogs, chats, etc, or do we roll _another_ one? For the project that I'm currently working on 'community reputation', the elements that we'll be caring about will be fairly closely tied with a user's 'profile'. As the standard profile elements typically include things like 'username', 'publishedEmail' 'emailVisibility', etc. etc, I'm not too personally concerned with which 'profile' solution we use. Rather, I think that we should write a mashup service on top of whichever profile services the folks in our communities are using (be it the tech spaces on MSDN or the personal kit over on MSN). This would allow a user to lump all their personal pivot info from the various (at this time) points a person may be 'profiled', into one place.
I'm curious to know what the communities think about this - would you want to be able to sign in once at an MS property and be able to link/edit your disparate profile data in one location? Thoughts very much appreciated.
So today I needed to find out how full-text searches work in SqlServer 05. Luckily, I found a good deal of information out on MSDN (http://msdn2.microsoft.com/en-us/library/ms142571.aspx) that was particulary helpful.
One point of interest that came up for me was the thesaurus (http://msdn2.microsoft.com/en-us/library/ms142491.aspx). For example, the ability for a configurable, per-language mechanism that allows synonym matching in search terms (search for "shoe" and you may want the user to see records that contain "loafer" or "boot").
The one thing I thought was a bit funky was that (from what I could tell in a one-day cursory study) there was no mgmt studio editor for this information (which is stored in xml files). After a brief perusal about the web, I haven't found any add-on's either.
I'm thinking that some sort of interface would most likely be beneficial for the application owners (ie - be able to CRUD this type of information on the fly rather than go through a release cycle) so perhaps I'll run it past the PMs, if we implement this type of search. It certainly wouldn't be that difficult a thing to put together.
Just implemented the DAB today for the project I'm working on and was quite impressed at the simplicity of the process. After all the fun with last years CTP for the Whidbey beta, I was expecting a bit more trouble, but it went really smoothly.
What I had in previously was just a small sqlClient-centric utility project that basically had a couple of helper methods (which looked _alot_ like the old block's signatures). The thought to not use the blocks initially was in maintaining the 'only code what you need' agile mantra, though the project SDET and I agreed that consuming libraries didn't really count.
I also liked seeing the abstract factory pattern being used even though this project will most likely never see anything but SqlServer on the backend.
http://msdn.microsoft.com/practices/
