This blog is on hiatus while I make the most of the opportunity living in and travelling around Europe. If you're here because of an issue or suggestion for CKS:DEV (Quick Deploy), please log it directly on the CodePlex site.
|
|
18/01/2010 Hi All, In the last couple of months, there’s been a hive of activity around tooling for SharePoint 2010 developers, much of which has been fuelled by the fantastic extensible model the Visual Studio team has given us. First out of the block in this space (to my knowledge) was Waldek Mastykarz, with a variety of different extensions including a parameterized deployment step, and some funky Server Explorer additions. Then, just before Christmas, we announced SPVSX – SharePoint 2010 Visual Studio Extensions, a collection of extensions built by myself and colleague Wes Hackett, with our key features being several new Project Item templates along with some comprehensive Quick Deploy and Auto Quick Deploy options. Finally, a couple of weeks ago Wouter van Vugt announced his awesome SharePoint Dev Tools, which among other things include a Sandboxed Visual Web Part, SharePoint References tab, and additional Quick Deploy options. In a testament to the power of the SharePoint community, the four of us have got together over the last couple of weeks and realised the potential benefits in merging our efforts, both in order to avoid duplicating functionality as well as to provide the highest quality set of development tools possible. We’ve also realised that our individual versions were quite closely aligned: we are all incredibly passionate about improving developer productivity, for new and experienced SharePoint developers alike. To this end, it is my pleasure, in conjunction with the other members of the team to announce the Community Kit for SharePoint: Development Tools Edition! For those of you who like acronyms, CKS:DEV is our preferred short form, and please follow and tag us on twitter as #cksdev. Our project site is up now at CodePlex: http://cksdev.codeplex.com/, and we also have a space on http://www.communitykitforsharepoint.org/dev. Happy times! 
Why the Community Kit? Shortly after the 2007 wave of products hit, the Community Kit for SharePoint and its various releases (such as Enhanced Blog Edition) were a fantastic resource for both extensions and reference projects/accelerators, with some great ideas coming out of it. However, I think it’s fair to say (without meaning any disrespect at all to the previous teams!) that in recent times there hasn’t been much output from CKS, and there is the perception among many I’ve asked that the ongoing development and usefulness of CKS has stagnated a little. For the 2010 wave, the Community Kit is back again, but with a renewed focus on quality and ongoing development/support. As it became clear that the Community Kit team shared our general vision, it made a lot of sense for us to not only merge with each other but also come under the Community Kit banner. There’s some fantastic work already underway in the CKS 2010 initiative, and it is our pleasure to be a part of it. Next Steps for CKS:DEV We’re currently in the process of merging and consolidating our various code bases into a single tool, and will shortly be providing an initial release that contains mostly the same functionality as can be found in the individual releases linked above. In the meantime, you can continue to download those individual releases and evaluate their use for SharePoint 2010 development. After the initial release, we’ll look to prioritise the huge list of ideas with a general goal of having the ultimate tool out in line with the RTM of SharePoint 2010. For this, we need you! – please give us any and all of your suggestions for Visual Studio enhancements and extensions that will improve productivity for SharePoint Developers via the Discussion Board on the CKS:DEV CodePlex site. We’ll also be expanding the team as we move forward, and at this time it’s also my pleasure to welcome Todd Bleeker and Paul Schaeflin on board, two MVPs who hopefully need little introduction. As a team we’re crazily excited about taking over the world with these tools, and at the end of the day, helping make SharePoint development easier, more consistent, and dare I say it: fun. :) Matt 31/12/2009Hi All,
Happy Holidays! Hope you are merry, safe, and well fed wherever you are this Christmas and New Year.
For my part, I'm in the middle of a 2 week tour of Eastern Europe covering Prague, Vienna, Bratislava, Budapest, and Krakow. Happy times!
I'll be finishing off the SPVSX Quick Deploy blog posts, as well as working on adding some great new features to SPVSX in the New Year. I'm also looking forward to speaking in the UK for the first time at some point in 2010, and meeting more awesome SharePoint folks at all the various SUGUK and other events throughout the year.
Here's to a happy 2010 for you and yours, and remember - Work to Live, not Live to Work!
:) Matt 17/12/2009Hello World, This is the first in a short series of posts to follow-up from my earlier blog announcing the alpha release of SPVSX – a collection of extensions for the SharePoint development tools built into Visual Studio 2010. Whereas yesterday’s post gave an overview of the full contents of the release including work from other team members, these posts intend to provide some more detail on the bits I worked on and am passionate about, namely Quick Deploy. Here’s what I’ll be covering: - Background and Approach <—You are here!
- Quick Deploying a Project or Solution via Deployment Configurations and Steps (coming soon)
- Quick Deploying on demand via the context menus (coming soon)
- Auto Quick Deploy – The Real Moneymaker (coming soon)
- Other Quick Deploy features (coming soon)
- Known Limitations and Future Ideas (coming soon)
Background and Approach Err… Quick Deploy!? One of my primary focuses with SharePoint has always been around productive development practices. SharePoint often frustrates old-school ASP.NET developers due to the additional need to “deploy” one’s compiled code and other artefacts up into the SharePoint system, a process that can cost tens of minutes to hours over your average week. The goal behind Quick Deploy techniques is simple: to make this deployment as fast as possible for certain development (not production!) scenarios, thus supporting the usual rapid iterative build-test-fix-repeat cycle that developers go through. A common example is when you make a change to a single line of code in an ASCX file – that file can simply be copied into the CONTROLTEMPLATES folder of the 12 hive without needing to redeploy the WSP, having the exact same result (for local development purposes). Deploying 50 such changes to this file of the course of a day may cost an hour with a full WSP upgrade (deactivate/retract/delete/add/deploy/activate), but only 10 seconds with a quick copy. [Numbers entirely fabricated for self-serving purposes!] Another common example is around changing a single line of code in a web part – here all that needs to happen to your newly built DLL is to reinstall it into the GAC. This is never a 5 second job due to the need to recycle application pools, but it’s at least much better with a Quick Deploy when compared with a full WSP upgrade. Quick Deploying without a 12 structure? In the 2007 wave, most of the development community seemed to settle on either WSPBuilder or STSDEV, both for their ability to automatically build a WSP from a simple 12 hive structure, but also for their support for productive development scenarios. WSPBuilder had “Copy to 12” and “Copy to GAC”, while STSDEV (my personal choice) had flexible build configurations including “DebugQuickCopy” and “DebugRefreshAssemblyInGac”. In both cases, the Quick Copy functionality was a simple case of xcopying a folder from the solution to the old SharePoint root directory (12 hive). Developers really liked the replication of the 12 hive inside a Visual Studio project, and this also made it really easy to get Quick Deploy happening. Earlier this year, Microsoft released a major update to their own tooling in the form of the VSeWSS 1.3 CTP, which through my previous life I had the good fortune of working on. We added Quick Deploy into the toolkit, though it was a trickier beast given the lack of “12 hive” structure in the project. The approach taken was to discover and process what would have been normally packaged in the WSP, but to then Quick Copy this instead. Further, as VSeWSS was known for processing files at package time, the Quick Deploy operations had to wait for the WSP to be built before they could reliably deploy the files from the hidden /pkg folder. Those of you who tried integrating VSeWSS with source control will hopefully have discovered that little beauty of a folder at some point, because without it, your source control wasn’t complete! With the SharePoint 2010 tooling, Microsoft have made huge investments in providing a more intuitive way of selecting items for packaging (Package and Feature designers), as well as more straightforward grouping of SharePoint artefacts into “SharePoint Items” (SPIs). This is all great stuff, but fundamentally the same difficulty comes when thinking about Quick Deploy – there is no SharePoint Root/14 Hive folder in the solution to simply copy across, and just as in VSeWSS, files in the solution are processed before being packaged into a WSP into a /pkg folder for the purpose of substituting tokens. This all happens a lot less magically than before (there is nothing in the /pkg folder you would need to source control for example), but it still happens. Hence in SPVSX, Quick Deploy uses a very similar philosophy and approach to that of VSeWSS, and this is the #1 thing to remember when working with it: SPVSX Quick Deploy will only ever deploy SPIs that you have included in a feature, or a package. Behind the scenes, this is necessary because when an item is not packaged, it is not possible to substitute tokens such as $SharePoint.Package.Name$ before quick copying them into the 14 hive. Yes, I’ve had to deal with all that stuff folks, and it was a bit of a mind boggler when considering exceptional scenarios like SPIs that are included in multiple features, some of which may be in other projects in the solution. I’m fairly confident that even in Alpha I have caught all those scenarios, and the Quick Deploy mechanism should be pretty robust. Despite this, I believe the approach also works well from a philosophical standpoint, in that SPVSX Quick Deploy is as close to a “full” deployment as possible. If you’ve forgotten to include an item for packaging, then Quick Deploy won’t hide this from you, and failing fast is always a good thing. When Not to Use Quick Deploy In the hands of a noob SharePoint developer, Quick Deploy can be a dangerous thing, especially if expecations are that it will work every time. I suspect this is why it wasn’t included in the SharePoint 2010 tooling out-of-the-box, tooling which is geared towards less experienced developers (though is no less suitable now for old hats). In any case, I would be doing a public disservice if I suggested you use Quick Deploy all the time. It’s useful for scenarios such as: - Updating a binary into the GAC or BIN folders when you’ve already deployed the items in SharePoint that rely on that binary (such as a web part, code behind, or feature receiver)
- Updating a ghosted/uncustomised file from your solution into the SharePoint Root/14 Hive, where that change will be picked up immediately by SharePoint
- Deploying front-end enhancements that are not cached such as JavaScript and CSS.
It’s not so useful for scenarios such as: - Updating an item in the SharePoint Root that needs further processing before SharePoint will read it, such as Feature.xml
- Updating an item where a Feature must be reactivated as part of testing
- Updating an item where more work is required inside SharePoint to complete deployment.
This is by no means a complete list, though to be honest there are not many scenarios where I don’t think Quick Deploy can be used even to get you half the way there in half the time. But the important thing is that you need to understand these edge cases and the implications of Quick Deploy, or at least accept the following rule: If Quick Deploy fails and you’re not sure why, just revert to a full Deploy. Closely related to this is my final disclaimer, which I hope is obvious: Always test your code with a full Deploy before release. Tune in next blog in the series, where I’ll provide a walkthrough on using the custom Quick Deploy configurations and steps, including some pretty pictures. :) Matt 16/12/2009Hi All, [First: I’ll spare you the obligatory “excuse for lack of blogging” post and just get into the detail of what I’ve been up to!] I’ve been pretty impressed by the out-of-the box support for SharePoint developers in Visual Studio 2010. Microsoft have done a fantastic job of not only improving the tools from the 2007 versions, but making them extensible and open such that the community can drop by to fill in the gaps. To this end, I’m excited to announce the Alpha release of SPVSX – a collection of extensions for improving on and extending the out-of-the-box SharePoint tooling support in Visual Studio 2010. What’s In The Alpha? The Alpha release includes the following functionality: Deployment - Quick Deploy (similar to Copy to 12 and Copy to GAC in old-school WSPBuilder and VSeWSS 1.3)
- Quick Deploy Custom Deployment Steps and Configurations
 - Project and Solution-level Quick Deploy (without changing deployment configuration)
- Copy to SharePoint Root at File and SharePoint Item (SPI)-level (right-click in Solution Explorer)
- Auto Copy to SharePoint Root when saving a file (e.g. auto deploy a change to an ASCX)
- Auto Copy to GAC/BIN when building a project
- Restart IIS
- Recycle app pools
- Attach to IIS worker processes
 
New item templates - Custom Action (basic)
- Hide Custom Action (basic)
- Custom Action Group (basic)
- Delegate Control (basic)
Server Explorer extensions - Web part gallery listing
- Import Content Type into current project (stub - full feature to come in beta)
- Display Custom Action Groups (stub - full feature to come in beta)
- Display Custom Actions (stub - full feature to come in beta)
- Display Hide Custom Actions (stub - full feature to come in beta)
Where Are The Bits? The easiest way to install SPVSX is to browse the Online Gallery within the Extension Manager (Tools Menu) of Visual Studio 2010. Simply search for SPVSX, click “Download” then “Install”. App Store for DEVS, eat your heart out! You can also find them in the Visual Studio Gallery, or visit our CodePlex site to peek at the source. It’s all open, and it’s all free. The usual disclaimer applies: this is an alpha release, so is expected to have a few gremlins. Please do provide feedback, suggestions, and bug reports via the CodePlex site, and if you’re interested in getting involved in coding or testing, please let us know. Credits and Next Steps This release is the culmination of a month’s worth of late nights particularly between myself (Quick Deployment bits) and Wes Hackett (Item Templates and Explorer Extensions), a colleague at Content and Code. Thanks also to Glyn Clough and Martin Hatch for chipping in with ideas and icons. As a team, we’ll continue to develop on, blog about, and provide support for the tooling in the upcoming months. In other words, we don’t want this to be one of those “CodePlex graveyard” projects, and we hope you’ll give it a try and provide feedback to help us make this work. Over the next few weeks we’ll be blogging and tweeting (#spvsx) in more detail about the various features, as well as the process of extending the SharePoint tooling itself. Merry Christmas, and Enjoy! :) Matt 8/09/2009Howdy Folks, This is the first in a series of short posts where I’ll attempt to cover the DebugApp trick as demoed in my session at TechEd NZ 2008 (yes, that was a year ago for those of you scoring at home!), but also at various other user group sessions I’ve run over the last year. I’ve posted a brief explanation on this before, but it was pretty unsatisfactory as an introduction to the magic world of DebugApping. Here’s the whole series: - Part 1 – What, and Why DebugApp? (This Post)
- Part 2 – Creating and debugging with a DebugApp (Coming Soon)
- Part 3 – Using the DebugApp for Productive Web Part Development (Coming Later)
Part 1: What, and Why DebugApp? The Elevator Pitch The DebugApp trick improves productivity in SharePoint Development, by providing an F5 debugging experience regardless of the development toolkit being used, but also as a means to rapidly develop visual web parts (web parts with user controls in them) without requiring that the user control be updated into the “12 hive” or that the application pool or IIS be recycled. This allows a more rapid dev-build-test-repeat cycle than is typical with standard web part development. The Great Productivity Loss As many of us have learnt over the years, SharePoint Development is not exactly “productive” when compared with traditional ASP.NET web application development. The main reason for this is the addition of an (expensive) deployment step to a “virtualised” infrastructure – rather than simply compiling a web site and then testing the changes in a browser, we need to build our code, create a WSP (assuming you’re following “best practice”), then get that WSP deployed up into SharePoint itself. Even if you’re using some form of rapid deployment technique (such as WSP Builder “Copy to 12”, or Quick Deploy in VSeWSS 1.3), that additional step still does exist and it adds time. Over a million builds, that time added up represents a significant cost, let alone the frustration caused by not having as rapid a build-test-repeat cycle as we might be used to. I’ve heard many an innocent non-SharePointy ASP.NET developer swear quite profusely over this issue. Those that understand all the other benefits SharePoint can give are generally patient, but those that don’t absolutely hate it. In addition to this general loss of time when deploying code, there can also be a loss of productivity when building Web Parts in SharePoint (the most typical of customisations) simply due to the way they are constructed. Like Web Controls, Web Parts are “all code behind” – you build up a control tree in code, rather than working with a visual design surface that does a lot of the donkey work for you (and I’m ignoring performance implications here). Who really wants to spend their days writing code like this? (real live excerpt from MSDN) : protected override void CreateChildControls()
{
//Create text box
newTitle = new TextBox();
newTitle.Text = "";
Controls.Add(newTitle);
//Create button
saveTitle = new Button();
saveTitle.Text = "Set Web Part Title";
saveTitle.Click += new EventHandler(saveTitle_click);
Controls.Add(saveTitle);
} Though a trivial example, the point is that complex UI is pretty difficult to achieve just in code behind. To get around this, a lot of us develop User Controls (ASCX files) that we then load into a Web Part with one simple line of code: Controls.Add(Page.LoadControl(“/_layouts/controltemplates/MyFolder/MyUserControl.ascx”)); This way, we can use a visual design surface to create our UI, and gain productivity in the process (again ignoring the performance cost of LoadControl()), which may be a concern in some cases but often isn’t). This is exactly the technique that the well-known “Smart Part” uses, and without any offence to the amazing Jan Tielens, at the core of it it really isn’t any smarter in what it does than the above. So what’s the problem? Well, if building a lot of User Controls to get around the annoyance of building code-behind interfaces, you still have the “slow deployment” issue. Your ASCX file must get itself into the /12/Template/ControlTemplates directory, and the binary containing your code behind must get itself into the GAC. This is where Our Saviour the DebugApp comes in, at least during highly iterative development. The DebugApp Trick At a high level, the DebugApp works as follows: - A Web Application project (which I call a DebugApp) is added to your Visual Studio solution containing other projects with the usual SharePoint stuff such as Features and custom ASPX pages.
- This DebugApp’s .CSPROJ file exists on the file system in the same folder as the root of the SharePoint web application you are primarily developing against, e.g. C:\inetpub\wwwroot\wss\VirtualDirectories\sharepoint80.
- Rather than using the “Visual Studio Development Server” (aka Cassini) for this web application, you set the Debug URL to be the root of your SharePoint site, e.g. http://localhost, and make DebugApp a StartUp project.
- The fact that you have the DebugApp as StartUp project in your solution means that when you hit F5, Visual Studio will attach to the w3wp.exe process corresponding to your SharePoint web application and automatically throw you into Debug mode. F5 debug without VSeWSS, “Attach to Process”, or other techniques – tick!
- The fact that your DebugApp .CSPROJ is located at the root of your SharePoint web application means that any ASCX files you add into that DebugApp can be referenced simply by “/MyUserControl.ascx” rather than needing them to exist in the 12 Hive CONTROLTEMPLATES folder. Thus for development (but not release) purposes, you can create User Controls/ASCX files in the DebugApp project that are built as if they were in a standard Web App, and load those into web parts using the “SmartPart” technique, or into other ASPX pages using the standard methods. Any change you make into any of these ASCX files is immediately reflected in the Web Part without any additional deployment, and any build of code is updating only a bin folder DLL without any IIS reset or forced recycle needed – it happens a lot quicker, trust me.
Now this may all seem a bit convoluted, and the lawyer on my shoulder also reminds you that this method is not particularly supported nor clever in some scenarios. But over the last couple of years this trick has saved me hours upon hours of development time, especially when I’m in that highly iterative dev-test-repeat cycle. Join me next post in the series, and I’ll walk through creating a DebugApp from scratch and getting it to work as above. :) Matt 17/08/2009Well, it's been a while. Hi, I'm Matt! You might remember me from such blog series as, "One Blog A Day Before Christmas 2008", or perhaps as "that guy who once said in a User Group presentation that he loved SharePoint more than his girlfriend". Sorry to say it, but I'm back!
Once upon a time, over 4 months ago, I embarked on an epic journey to relocate life from Christchurch to London, via pretty much every city that exists along the way. It was a fantastic time, a good story to tell the Grandkids, and it involved ZERO SharePoint, which to be honest was rather refreshing.
Some of you have asked me: "why didn't you stop off at a few user groups and present?!" And though that may well have been a nice thing to do, it wasn't the focus of our trip, and that's not how I roll. Work is work, play is play (most of the time), and for me it's that simple.
In any case, I'm here in the fantastic, crazy, mixing bowl that is London now, and having given myself a few weeks to settle in and focus on stuff more important than this blog, it's time to ramp back up and pretend I know a thing or two about SharePoint once again. Yes, Dear Reader, not only am I back, but I'm as boring as ever!
Tune in over the next few weeks as I attempt to post some final tidbits of SharePoint 2007 usefuleness before The Biggest Event Of The Year - and I don't mean the final season of LOST. Yes, SharePoint 2010 is around the corner, so buckle up - it's going to be a fun ride.
:) Matt 22/02/2009Hi Folks,
In my last act with the Christchurch SharePoint User Group (C-SPUG) before the Big OE, I'm presenting a demo-driven session this Tuesday on the Data Form Web Part and SharePoint Designer. Full details below as per the C-SPUG announcement - hope to see you there!
Cheers,
Matt
How to become a SharePoint Hero with SharePoint Designer and the Data Form Web Part
If you thought that SharePoint Designer was just the “next version of FrontPage”, then you’re missing out on the heroics that can be performed using SharePoint Designer and the Data Form Web Part, all without writing a single line of code. The Data Form Web Part is known as “the most powerful web part in SharePoint”, and empowers IT professionals to customize SharePoint in ways that are not possible through the browser.
Join Matt for a demo-oriented, informal, PowerPoint-less session that may include:
- SharePoint Designer and Data Form Web Part basics
- Changing the look and feel of out-of-the-box list views
- Adapting out-of-the-box list and library forms
- Exposing data from other enterprise systems including SQL databases (without a line of code!)
- Creating mash-ups using multiple data sources
- Conditional formatting, web part connections, and editable data views
- A number of terribly bad jokes.
This will be Matt’s final presentation at the SharePoint User Group prior to departing for his OE.
Prizes: Several oversized t-shirts, and a secret giveaway courtesy of Microsoft.
Intended Audience: Information Workers, Business Analysts, IT Professionals, and Managers are guaranteed to all come away with a fresh perspective on what’s possible with SharePoint, and empowered to do so themselves with the Data Form Web Part. Developers should also add the Data Form Web Part to their toolkit, and/or understand why no-code customisation of SharePoint with the Data Form Web Part will put them out of work!
Presented By: Matt Smith, Intergen
Matt has worked in the collaboration, knowledge, and document management space for over 8 years, the last two of which have been exclusively with SharePoint. Matt specialises in SharePoint customisation, and has a particular focus on productive and effective development practices. Matt was a key member of Intergen’s team responsible for one of the largest SharePoint implementations in the South Island, as well as a key member of the team building the next version of Microsoft’s Visual Studio Extensions for SharePoint.
As a community evangelist for SharePoint, Matt started the Christchurch SharePoint User’s Group in late 2007. Matt has spoken at local and national SharePoint and .NET user group events, as well as at TechEd NZ in 2008. Matt was recently awarded Microsoft MVP status for his contributions to the community.
Date: Tuesday, 24 February 2009
Time: Snacks + Refreshments from 5:30PM, Talk from 6:00PM to 7:00PM
Location: Canterbury Innovation Incubator (CII), 200 Armagh Street. The CII is diagonally opposite the Centennial Leisure Centre, and parks are usually available along Armagh Street or Oxford Terrace. If the roller door at the venue is down, please enter through the small “hobbit” door within the roller door itself. Contact Gary on 021-266-0753 if you have trouble accessing the venue. 20/02/2009Hello Again, World!
So, quite a few of you (2 people in fact, including my Mum) have been asking what the heck's going on with this blog, especially after such a flurry of activity before Christmas (you do remember the one-blog-per-day-until-Christmas saga, don't you?)
Well... as it turns out I have quite a few things to communicate to the world. Might as well get started with the big one:
I'm moving to London!
This has been in the planning for over six months now, and has nothing to do with the MVP award (in fact, it's terrible timing, as I will explain below). We leave on March 27, and have three months of travel planned through (in this order): Thailand, Cambodia, Vietnam, China, Hong Kong, China, Mongolia, Russia, and then Europe. I've never been to any of those places, let alone anywhere else for longer than a month - suffice to say I'm excited, a bit nervous, (lucky), and, well, did I mention excited?
It's likely we will be in London for at least a year, but it could be as much as five. As Shihad would say, "I guess we'll have to Wait and See".
Next up:
I'm attending the MVP summit!
I'll be at the summit in Seattle in a couple of weeks. I'm really looking forward to meeting everyone, participating in the infamous paintball event, and checking out the Office 14 goodness.
As an aside, one of the impacts of attending the summit is that we were forced to move out of our house earlier, last week in fact. I'm sure those of you who have done it before could have told me this, but the sheer amount of crap one builds up over the years is absolutely ridiculous. It's also incredibily easy to underestimate the time, effort and stress involved in shifting, rennovating for a shift, selling, packing, and so on... ugh! I've definitely learnt a thing or two about minimalism after this experience.
Blog Hiatus
With all the tasks and minutae of the shift, the added time out of the summit, and the global recession (compulsory mention, isn't it?), I made a decision a few weeks back that it wasn't going to be possible to blog much, if at all, before I left for the UK. This was a difficult choice, as I have some pretty ace content backlogged that I'd love to share with you, but I hope you'll agree that spending some quality time with my family before the shift is a much higher priority, aside from all the other organisational tidbits. Nevertheless, I'm sorry I haven't communicated this earlier, especially after all those promises before Christmas.
So... this blog will now be on hiatus until June, when I land in London. I will be blogging my entire trip on a personal blog if any of you are interested, and I'll provide the URL closer to the time :)
Community Contributions: Q1 and Q2 2009
As mentioned above, the timing of the MVP award wasn't ideal, as I have a strong desire to continue contributing to the community, and to get a few new community projects underway. The shift and in-the-wilderness-OE has limited what I'm able to do for this first half of the year.
Despite the blog being on hiatus, my focus for contributing in Q1 has/will be to present as much as possible. I'm speaking at the following events:
- Christchurch SharePoint User Group, Tuesday 24 February: Becoming a SharePoint Hero with SharePoint Designer and the Data View Web Part
- Dunedin .NET User Group, Thursday 19 March: Introduction to SharePoint and SharePoint Development
- Invercargill .NET User Group, Friday 20 March: Introduction to SharePoint and SharePoint Development
- Christchurch .NET User Group, Wednesday 25 February: New Features of Visual Studio Extensions for WSS 1.3 (Lightning Talk)
My presentation at C-SPUG on 24 February also marks the end of my involvement with the Christchurch SharePoint User Group (for now) - sad times! I started the group back in October 2007 and have enjoyed every moment of co-ordinating it and seeing the community grow. Gary Payne is taking over... good luck Gary!
Last, but certainly not least:
I Developed Some of VSeWSS 1.3
In a case of irony gone mad, over December and early January I was part of Intergen Wellington's team working on the next version of Microsoft's Visual Studio Extensions for Windows SharePoint Services, 1.3. The irony relates to my session at TechEd last year, where I presented "alternatives" to VSeWSS that worked around some of its limitations, particularly the lack of productive builds. So it was with delight that I was able to work on improving some of these limitations, including the following features:
- Quick Deploy menu
- Package/Retract commands
- Deployment Conflict Resolution
- Less magic in Site Definition projects
It's certainly comparable to community tools such as STSDEV and WSPBuilder in the "productive builds" category now. However, the fundamental architecture and structure of VSeWSS projects remains the same... so there's still no replication of the 12-hive structure in Solution Explorer. Some folks like that, and some folks don't.
Life, Chapter One: The End
Matt V1.0 is finished.
See you in London!
:) Matt 4/01/2009
 Wow, talk about an unexpected, and humbling start to the new year!
Today I received the news that I'm a SharePoint Server MVP for 2009. I'm very honoured to be given this award alongside so many incredibly clever and devoted people, all of whom I have an infinite amount of respect and admiration for.
Thank you to all those in the community, the Christchurch and New Zealand SharePoint User Groups, and in Microsoft who have helped me in my journey to this point. I want to send a special thanks to Chan and OJ who have been incredibly supportive and helpful over the last couple of years, as well as to Darryl and Jonathan at Microsoft NZ, both of whom have been very supportive not only of the Christchurch SharePoint User Group but also of me personally, including the opportunity to speak at TechEd for the first time last year. Thanks so much also to Gary, my partner-in-crime at the C-SPUG.
I'm looking forward to continuing with, and also ramping up my contributions to the community this year. As I'll be out of New Zealand for at least 6 months, I'm going to have to do some of this in different ways to last year - but I have some exciting community projects to ramp up and look forward to speaking at user groups wherever possible. As I also mentioned in the pre-Christmas-post, I'm also looking forward to ramping up this blog with some in-depth content, so please stay tuned :)
I seem to be looking forward to a lot... but I'm also really looking forward to meeting new friends, as well as sharing a drink with a few old ones (watch out Bob and Ben!) at the MVP summit in March. Happy Times!
:) Matt 24/12/2008Well, folks, we did it. You, me, and the code that continues to post random comments on my non-CAPTCHA-protected SharePoint blog (missed that on the vNext Wishlist!): we made it this far together.
For those of you lucky enough to miss it all, here's the recap: waaaay back on November 3rd I promised to post once per day until Christmas. And here we are, 50 posts later (I'm not counting this one!), and it happened. Somehow.
Now I think you'll agree that "quantity not quality" prevailed, particularly in the last month where my insane work schedule (which I look forward to spilling the NDA beans on soon) prevented anything but 10 minutes a day with my bloggery cap on. Nevertheless, it was a fun exercise, and like a good wee completer-finisher, I ticked all the boxes. We made it to Mordor, folks, and we threw the stupid ring in.
Now if I was to pick my favourite three posts, they would be:
- Day 3 - Critical Success Factors: Don't Confuse Your Roles and Skillsets
- Day 10 - Critical Success Factors: Don't Expect Your Developers To Be SharePoint Rockstars Overnight
- Day 32 - vNext Wishlist: Introducing the Web Application Hive (and the followup on Day 33)
I probably had the most fun writing those. You were probably the most bored, right!?
Seriously... though the one-blog-per-day was a nice challenge, it was ultimately limiting, and I look forward to contributing some more in-depth posts in the new year without any arbitrary time constraints and rules. I'm not sure if I will continue The Week That Was (anyone interested?) but I will aim to post about once a week with something of value.
I hope you and yours have a great Christmas and a relaxing New Year. Other than the fact that I'm working right through (yes, on the mysterious NDA project!), I'm going to stay well away from this computer thing. Thanks for reading this year, and I hope to see you in 2009.
:) Matt  |
|
|
|
Kia Ora, and welcome to my blog. I'm an independent software developer/consultant (MCP/MCTS) specialising in SharePoint and related technologies. As a community evangelist for SharePoint, I started and (until my recent move to London) co-ordinated the Christchurch SharePoint User Group in New Zealand.
Aside from being passionate about SharePoint, Software Development Process, Knowledge Management, and Product Development, I'm also a music freak with a budget recording studio and a scary obsession for the Red Hot Chili Peppers.
The opinions expressed on this website are my own, and in no way reflect those of my current or previous employer(s), client(s), or Microsoft. In other words: blame me!
E-mail: matt@mattsmith.co.nz
|
|
|
|
|
|
|
|