I'm very happy to say that I will be presenting at an upcoming Atlanta Silverlight Firestarter on August 22nd in Atlanta at Microsoft's office. The event is free to the public and will be an all day Saturday event for anyone interested in learning more about Silverlight. I'll be there with several great Silverlight developers in the area as well as a few guys I am currently working with at IQ.
Recently I was talking to a friend about Visual Studio 2010 - specifically about changes we were hoping to see. He had brought up how annoying it was to only be able to see 6-7 tabs in VS2008 before you had to use the dropdown arrow to navigate between source files. This problem is amplified even more with so many page types having corresponding codebehind files such as .xaml and .xaml.cs. I had told my friend that VS2010 was going to have wrapping tabs to fix this issue - I heard someone else voice this issue at a local VS2010 training event - but as of the last VS2010 beta there was no wrappable tabs ability.
Luckily Scott Hanselman tweeted about Tabs Studio - and it addresses both of the main issues with the built in tab control in Visual Studio - it allows wrappable tabs, and it groups your control parts together - what's more, the tabs are customizable with your own XAML.
(my custom tab style)
When I installed Tabs Studio I thought it was a cool idea, but after using it the last 2 weeks I'm hooked. Not having to look through all your open files for the corresponding XAML code behind goes a long way, and being able to maintain more than 8 open files (and have them easy to get to) makes dealing with large and modular solutions a breeze - and at $28 for a license you can't ask for much more.
Update: You can find the entire XAML definition here including how to change the close (X) icon, etc. for even more customization than shown in my example.
In my last blog entry I talked about how the new Bitmap API in Silverlight 3 gives you the ability to render controls to a WriteableBitmap, I also mentioned how it gives you direct access to editing pixels in a bitmap. I wanted to put together an example of what this ability can provide, and I wanted to show off how performant the get/put pixel abilities in Silverlight 3 actually are.
In the demo above you can see a fire algorithm (previously done in WPF and hacked up in Silverlight 2) as well as a text scroller - both of these are being rendered pixel by pixel. The bitmap the text scroller is manipulating was created by rendering a TextBlock with a drop shadow effect to a bitmap (read more on how to render text to an image here). By clicking on the demo you can see some simple elastic transitions being done on the rendered WriteableBitmaps - I was pretty impressed to see that even though tens of thousands of pixels are being manually rendered, the transitions performed very well (at least on my machine).
The ability to get/put pixels is exactly the sort of thing that will allow things like doom/quake/etc. to be ported to Silverlight - because you can bypass all XAML and just use a WriteableBitmap to manually render all of your UI at the pixel level.
One of the issues with getting and putting pixels with the Bitmap API in Silverlight 3 is that the direct pixel access is done by setting a pixel's color - which is an integer. Converting a Color to an Int when putting, or an Int to a Color when getting isn't exactly intuitive, so I wanted to post examples of both for others who might be giving this great new ability a whirl.
(more after the break..)
One of the new features in Silverlight 3 (released on Friday) is the Bitmap API which provides the ability to render UIElements to a bitmap and provides direct access to the pixel level information of bitmaps. This type of functionality is very useful in a handful of situations, but perhaps the most notable is the ability to cache out a rendering of a UserControl and make use of it in complex transitions to reduce overhead, or to facilitate editing images or processing images through filters, etc.
I did a few searches tonight to get started playing with the Bitmap API and found several examples, but unfortunately none of them had any source code attached, and were written against previous SL3 betas which had different method signatures relevant to the bitmap rendering, so I wanted to go ahead and post a simple example of rendering out a UIElement to a bitmap. This example shows the output of rendering a TextBlock at various font sizes and image sizes and setting the resultant bitmaps as the source for three equal sized Image UIElements.
(nothing exciting, at least for now)
In the attached code sample you'll see a method which creates a WriteableBitmap, and the resulting WriteableBitmap is set as the source for an Image UIElement. The code to render the bitmaps is very simple, the key (to not wasting your time) is to make sure that you always call Invalidate() on the WriteableBitmap before making use of it, otherwise you will never see anything in the created bitmaps. Here is the main rendering method:
(more after the break..)
I've been doing a bit of work at the new job on some custom panels relative to our project. In doing the work we have been talking a lot about the iPhone's main launcher panel and how the iPhone implements dragging and reordering of icons on the screen. I wanted to take what I have learned in working on those custom panels and apply it to actually recreating the iPhone's implementation - you can find what I came up with here:
This was my first week at a new gig as a full time Silverlight developer. I'm still getting into the flow of a totally new job, but this first week has been great. I am working with Corey Schuman over at IQ Interactive on a really neat project which I hope to brag about once it's public. Working with people in the design community and another Silverlight developer is going to exponentially help build up my Silverlight abilities.
I can't suggest enough that people who want to get into the Silverlight space get involved with your local communities - or start local groups if you don't have one in your area. Corey took the initiative to startup the Atlanta Silverlight Meetup Group just a few months ago, and there are already over a dozen people showing up for the meetups, and that is now leading towards an upcoming Atlanta Silverlight firestarter. This has served to encourage me to get out there and get more involved in the community as well - hopefully there will be more on that going forward.
I've heard several people tell me how Twitter is a waste of time, or is stupid, or things like that - but if your a developer and aren't on Twitter then you are really missing out in my opinion. In a very real way using Twitter is what helped me land this job - getting my name out there and having some back-and-forth with peers in relative fields.
A quick search on Linkedin shows that there are hundreds of thousands of folks out there labeled as a Software Engineer, tens of thousands labeled as a .Net Developer, but a search for Silverlight Developer turns up just a handful of people, and I am very happy to be on that list - I can't wait to see where it leads.
Today is my last day at my current job - it is the end of another chapter of my career. I don't want to overstate the significance of this job, but I must admit that this job opened my eyes to a lot of new things, and provided me tremendous amounts of opportunities to progress in my career. While I am incredibly eager to start my next opportunity - which I will post more about later - I will definitely miss many of my coworkers here, and I wanted to express my deep gratitude for their support and the opportunities afforded to me the last two years.
My soon-to-be-former employer is a gold certified Microsoft partner, and as such I had the privilege of using a ton of great Microsoft technologies, attending numerous training sessions put together by Microsoft, and in some cases working side by side with Microsoft reps on mission critical projects. Another great perk of this shop was their affinity for giving developers the time and resources to visit some of Microsoft's annual conferences - I myself got the chance to go to PDC 2008 on the company's dime - something which was a great opportunity for me. This shop is also quick to pick up on new Microsoft technologies, and that is what afforded me the opportunities to work in .Net 3.5, WPF, etc. - the breadth of technology used here (and used well) is something to be seen.
From a developers standpoint, this job was my first introduction to a real development shop. By that I mean a company with not just 5-10 developers, but several teams of developers, all of whom are proficient in a wide variety of technologies. Project management and code maintenance were crucial here, and as such I got to use a lot of things which many other developers may be familliar with, but perhaps don't rely on heavily. This included unit tests, acceptance tests, continuous builds, virtualization, sprint planning, sprint reviews, backlog planning and breakdowns, and several other processes that made all our teams and players work together and get things done. It was quite impressive to see how such a large development team is orchestrated to commit to the same projects without everything falling apart and ensuring code quality.
I can't say enough about this great development shop, and I wish everyone here and the company itself the best of luck going forward - I am sure we will stay in touch through the local code camps and user groups.
For those that don't know, I have been a Winforms dev since about 2001. Before that time I was just as interested in graphics and usability as I was in coding itself. While in college I was pursuing a computer science degree in class, but my free time wasn't spent coding in Java or reading books on operating systems, it was spent in Photoshop and Flash 4. In fact, I was doing more advanced stuff in Flash Actionscript at the time than I was doing in my college CS courses. I had hoped that when it came time to graduate from college I would be able to get aboard the Flash bandwagon - creating super cool UI's for the web - unfortunately the dot com bubble burst, and my coding abilities were what kept me gainfully employed.
Up until creating an entry for the Server Quest Silverlight contest I had never touched Silverlight. I was definitely aware of it, but I was a Winforms guy, not a web guy - so I was elbows deep learning WPF and Prism and doing WPF LOB work for my current employer - I had no plans of touching Silverlight. Now that I've finished my first major Silverlight app, Matchingo, I find myself questioning which direction I want to go next - do I go back to WPF, or do I keep on trucking in Silverlight?
(click 'Read More' below to keep reading)