As you may know we started a Surface user group together with Cap Gemini and dotNed.
Below you find an impression of the first meeting we held at our office.
For more information about the Surface user group, you can contact me or any of the other founds of the user group.
Bye,
Bart
As you may know from my blog, we are pretty active on Surface. We develop and design for Surface and talk about it (a lot…). But, we are also trying to come up with some tagged objects, especially for Surface.
These objects (it is a photo of the real objects, not a render of their design) are tagged at the bottom so the Surface unit can detect which one is placed on the Surface unit.
These are trial objects, based on our company logo. We are evaluating the production process. E.g. we now know that the ‘neck’ of our logo is too fragile and we will have to redesign it to be more robust. Also, it is a bit too large to make a good object for the unit. But, we are learning along the way and I think the next batch with a bit of a redesigned object will be a lot better.
More designs will follow and these objects will be for sale. We are thinking of creating branch specific objects, but also some abstract, more versatile objects. They will have a fixed tag on the bottom (for now) which are routed out. There is no more need for that bit awkward sticker at the bottom of your object.
You will be able to buy these objects made from a synthetic material. They are solid though and feel pretty robust. You will be able to order these in wood, which will be hand made (and will have a higher price and a longer delivery time of course). We haven’t set the price yet, but they will be reasonably priced.
If you have any thought on this (suggestions for designs, material, otherwise) please let me know at bart.roozendaal@sevensteps.nl
Bye,
Bart
Through Twitter I stumbled upon this article: http://www.thejoyofcode.com/If_you_cant_beat_XAML_improve_it.aspx
I think it’s an interesting post. Below you find my comments on that post. Any thoughts on the issue?
I am a very experienced programmer and have worked on a great number of languages (C, Basic, Smalltalk, Pascal, Fortran, Cobol, C++,, C#). Recently I started working on WPF. And I am one of those developers that is experiencing more difficulty grasping WPF than I did with other languages.
I don't think that it's because of XAML per se though. I don't mind typing in long XML element names and attributes. I don't mind writing all the end tags. I don't mind typing at all. Visual Studio / DevExpress' CodeRush offers me all the aide that I need for that. Code completion, templates, short cuts, et cetera make that real easy.
What I do have problems with is the actual concepts in WPF. One thing that I find really difficult to learn and to accept really is the fact that one must/can implement a lot of functionality in the XAML, which in my mental model represents the display part of the application, not the code. I seem to be that old fashion developer that wants to type a=b if I want to assign the value of b to a.
WPF/XAML drives me away from that mental model and I'm very much aware of that. It is beginning to win its place in my brains, but it's taking longer than I thought. Even being aware that another mental model is needed for WPF doesn't make it easier for me.
Maybe XAML *is* for designers. That is why I'm trying to work more closely with our visual designer (i.e. having him learn Blend) and leave more of the work to him.
But, it's really new and sometimes hard to go this way. I'm so much used to being able to do everything in our software. That is no longer the case. I will get used to it, but it may take me a bit more time.
My 2cts worth.
Bye,
Bart
Update. Thanks to my new friend Josh Twist (http://www.thejoyofcode.com) I found out that a hotfix by Microsoft solves this issue. Based on the articles on his website I managed to tidy up my XAML-code to. You can find information about the hotfix at http://support.microsoft.com/kb/958017/ and download it from http://code.msdn.microsoft.com/KB958017/Release/ProjectReleases.aspx?ReleaseId=1719.
In a previous post I stated that Visual Studio never crashed on me. I have to take that back since it now happens to me a lot.
I am pretty sure that it is because I’m doing all kind of things wrong in my code (I still need to learn WPF), but VS should never crash because I mistype some code. Below is a code snippet from a XAML-file that crashes VS every time. If I open up the XAML file in MS Blend, I get an error message (probably pointing into the right direction of the error):
TargetType van ControlTemplate BoardPiece komt niet overeen met sjabloontype TagVisualization.
(which is Dutch for telling me the TargetType of the ControlType doesn’t match the TemplateType TagVisualization).
Below is the contents of the XAML file. IsAcceptingNewRelation is a user defined dependency property. I specified the Oase.BoardPiece type in the TargetType of the ControlTemplate for the code to solve the IsAcceptingNewRelation dependency property of my TagVisualization. There probably is another/proper way of doing that, but I’m getting WPF blind. Anyway, this crashes VS if I take it to the design mode.
1: <s:TagVisualization
2: xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
3: xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
4: xmlns:s="http://schemas.microsoft.com/surface/2008"
5: xmlns:local="clr-namespace:Oase"
6: xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
7: xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
8: x:Class="Oase.BoardPiece"
9: mc:Ignorable="d"
10: s:Contacts.ContactDown="TagVisualization_ContactDown"
11: s:Contacts.ContactChanged="TagVisualization_ContactChanged"
12: s:Contacts.ContactUp="TagVisualization_ContactUp"
13: >
14:
15: <s:TagVisualization.Resources>
16: <ImageBrush x:Key="tvBackground" Stretch="UniformToFill" Opacity="1" ImageSource="pack://application:,,,/Resources/speelstuk.png"/>
17: <ImageBrush x:Key="tvBackgroundHighlight" Stretch="UniformToFill" Opacity="1" ImageSource="pack://application:,,,/Resources/speelstukHighlight.png"/>
18: <ImageBrush x:Key="itemHomeBackground" Stretch="UniformToFill" Opacity="1" ImageSource="pack://application:,,,/Resources/home.png"/>
19: </s:TagVisualization.Resources>
20:
21: <s:TagVisualization.Template>
22: <ControlTemplate TargetType="{x:Type local:BoardPiece}">
23: <Grid x:Name="mainGrid" Width="126" Height="142" Background="{StaticResource tvBackground}" />
24:
25: <ControlTemplate.Triggers>
26: <Trigger Property="IsAcceptingNewRelation" Value="true">
27: <Setter TargetName="mainGrid" Property="Background" Value="{StaticResource tvBackgroundHighlight}" />
28: </Trigger>
29: <Trigger Property="IsAcceptingNewRelation" Value="false">
30: <Setter TargetName="mainGrid" Property="Background" Value="{StaticResource tvBackground}" />
31: </Trigger>
32: </ControlTemplate.Triggers>
33: </ControlTemplate>
34: </s:TagVisualization.Template>
35:
36: </s:TagVisualization>
If anyone out there know how I can prevent VS from crashing (probably by pointing out what part of WPF I don’t understand here …) it’s much appreciated if you tell me :-)
Bye,
Bart
As mentioned before I’m starting the (re)design for our upcoming major release. This is an exciting time because we will be using a couple of new techniques here. One of which is DevExpress’ XPO, eXpress Persistent Objects.
I had done some tests before, but now the real work starts I find that typing the object model rather than drawing is a big down side for XPO. I’m afraid that in this day and age you really need a visual modeller.
That said, I’ve bitten the bullet and started the design. I took that a bit light-hearted and thought I would have done that in a couple of hours. You know, thinking: “what do I need to do different compared to our current object model? It’s all been done and we know exactly what we want”.
Not, I can tell you. I find that rethinking over the object model brings up a couple of flaws that only become apparent if you don’t think of databases anymore. If you think in objects only, you experience another kind of designing entirely. I’ve been object modelling for quite some time, but doing it for real while reverse engineering a larger model is quite different to what I did before.
But, the reason I started this post is I wanted to share my first unit test with you. I was looking in the XPO software for a ‘model checker’. Since XPO is about storing data, and you need to specify the object relations using ‘code’, I suspected I might have mistyped something somewhere and wanted to check of all was well.
That’s quite easily done, using a unit test. It’s ever so simple, but helps you to check the object model while designing. Just make the test project your current project, add a reference to the assembly that holds your XPO model (everyone puts that in a separate assembly, right?) and run the test when you want to check your model.
This is the single line test that has been my friend for today:
[TestMethod]
public void CheckValidityOfDicationary()
{
new ReflectionDictionary().GetDataStoreSchema(typeof(S7XPO_Base).Assembly);
}
Replace S7XPO_Base with any of your persistent classes and you’re off. If there is an error, an exception is thrown and your test will fail, telling you exactly where the problem is.
Hope this is of use to anyone. It certainly helped me a lot.
Bye,
Bart
http://apparchguide.codeplex.com/
I am in the middle of redesigning our software and was thinking through some major parts of our software design. We notice the number of clients grow, the size of the companies that uses our software gets larger (Microsoft, SAP, Google, Unit4Agresso, Shell are all companies that use our software) and the number of topics in the Sevensteps projects increase. Our software was designed for documentation projects of around 5000 topics per project (we have projects that are over 400.000 topics in size, but performance is an issue there) and I want to redesign (part of) our software to accommodate larger projects.
Another reason for redesigning is that we currently support one rich client interface. And I want to extend that with a content API (which will give access to the information from, let’s say, an ASP.Net application) and some light weight, web based interfaces. Some other parts of the software could do with a looking over too.
Going all over the net for some background information, I stumbled on the Microsoft Application Architecture Guide 2.0. I’ve now read the first 2 chapters and already got some very valuable information. I find that most things discussed, I already know about and have some experience with. But, to see them listed helps a lot.
I will be reading the next 300 pages or so to see how the topics are elaborated on. I’m not a very keen IT book reader, but will make an exception this time. Anyone looking for some guidance in designing (Microsoft based) software might find it a valuable resource too. If after reading I think a follow up is required, I will do so of course.
Bye,
Bart
Thanks for all your comments to my post about switching from Delphi to C#. Although I didn’t intend to stir up that discussion again, I would like to answer some of the questions and suggestions raised/
I appreciate everyone telling me about teaching C# programmers Delphi. I know it's not too hard; I've done it myself :-) But, the number of programmers out there does reflect the popularity of a platform, doesn't it? And some applicants bluntly told me they didn’t want to work in Delphi. They obviously didn’t get the job, but it did make me think a bit.
But, the lack of programmers wasn't the main reason for us to switch at all. Despite somewhat (...) critical sounds about Microsoft (some of which I tend to kind of share) there is a lot of development in the Microsoft world. Way more than in the Delphi world. Some may be good, some may be not so good or terrible, fact is that there is a lot of effort put in the MS platform.
What really did it for me were two things.
(1) We had to wait for Delphi 2009 for Unicode support, which (IMHO of course) is a major misjudgement. I haven't been able to deliver Unicode software, even though there was a bit of pressure out there. I know for a fact that I did lose sales because of that.
(2) About the same time Delphi 2009 (and Prism) came out, I attended the Microsoft PDC. It opened my eyes regarding to the scale of things. One may not like MS being enormous in size, but there are so many exciting things going on out there, that it made me decide to go the other way.
In fact, I particularly went to check out MS Surface. Just one of those things that MS can do and Embarcadero won’t. That’s not to hold against them, and it doesn’t have anything to do with my choice for C# really, but it did tell me that there was a lot more going on than I really wanted to realize.
Just a quick note on quality of tools: I was getting used to Delphi crashing on me several times a day. It was getting to a point that I did take that into account when starting a days work. I am so glad that is over: Visual Studio hasn’t crashed on me once since I started using it. Not a real argument for the choice either, but I’m glad that’s out of the way.
I will always love Delphi and will be programming in it for the next couple of years, I’m sure. But for the next few generations of our software engine, C#/.Net will be the platform of choice.
Now, that still doesn’t solve those designing issues for me :-) Guess I’ll have to do some investigation.
Bye,
Bart
Posts
All Comments
