Maxim Fridental

This Lisp performance is so serious I can call it a mass (watch in fullscreen):


Day of the Triffords from Andrew Sorensen on Vimeo.

According to Mike Harsh, they are looking at the following possible future features of OOB in Silverlight:

1. Features supporing OOB apps constantly running as a service (“in the tray”), such as a possiblity to change the tray icon dynamically or otherwise show
   a notification to the user. (http://videos.visitmix.com/MIX09/T45F, timecode 56:05)
2. Drag and Drop, File Associations and Command Line Arguments (same url, timecode 59:02)
3. Integration with the shell, ie. task bar and Jump lists of Windows 7 and Search (this and following starting from timecode 60:00)
4. Persistent Download Services (something like BITS)
5. Integration with HTML
6. Uninstall OOB apps from the context menu of the app icon.
7. Perhaps, a possibility to terminate the app programmatically from inside of it
8. A way to control detaching process (what components will be downloaded during detaching etc)
9. OOB support for Windows Mobile
10. Printing support
11. Database support for isolated storage
12. Perhaps the possibility to control the look of the window border.

My personal favorites are Download Manager, File Associations and Command Line arguments, and I have nothing else to wish for. Where can I vote for them? :)

In the past, I often wrote and spoke about the dangers of the C# private/internal/protected modifiers. Today, I’ve stumbled upon yet another case.

In Silverlight, UI controls have a property DataContext, which roughly corresponds to a model property in Smalltalk’s View classes. You set whatever you want to it, and then you can bind its properties to your UI parts using the {Binding} syntax in XAML.

Now imagine the situation, when the {Binding} is not sufficient. For example, you want to handle some error situations. “Piece of cake”, you may think, “I just write a handler to the DataContextChanged event”.

Nope. It is internal. According to Allen Chen, it is internal by design (http://silverlight.net/forums/t/13421.aspx). How in the world a developer at Microsoft can know if I need to access something or not!? Does he knows anything about my requirements, my customer, my architecture? So why does he think he is allowed to decide that?

Please, please, please do consider the following: use access restrictions very sparingly. You don’t know everything about how your code will be used in the future. If you’re concerned about a too large API surface, make the member protected – I could live with that, albeit I do believe that in this particular case such an important property deserves a better visibility. If you believe DataContext concept has to be replaced with some other architecture in the future – well, communicate it NOW and mark the DataContext property with the ObsoleteAttribute. But don’t hide a member just because you cannot think of any good usage. And don’t hide a member because you’re afraid it can be abused.

Ahem.

Okay.

There is a possibility for a change: you can vote here (please, really do!) and wait. If you’re really lucky, they integrate it in Silverlight 4, so it is only a couple of years you have to wait.

And, there  are two workarounds: a) do not use DataContext and create your own Model property instead or b) write your own SetDataContext method invoking an event and pray that all other devs in your team will use it instead of the DataContext setter.

Just finished reading a great book about project and product management. The author got an assignment at a chief constructor and director of a small engineering department in one of the factories.

Initially, they used a linear waterfall-like process, so it took months and years from begin of product development to creating a first fully working model, and another several years to organize the mass production.

Over a decade, the author had introduced a completely different, agile process, which key factors have been employee motivation, seeding and maintaining of a creative, competitive company culture, time-boxing, working in pairs, continuous integration, small incremental releases, customer on-site, testing from the very beginning, ergonomic and usability, unification and reuse, and over-disciplinary thinking. All this allowed them to shorten time to first model from a year down to stunning 45 days. Oh, and by the way, they managed to increase productivity of the mass production by 18 times. How cool is that!? But wait, there is more.

Continue reading “Grabin, Weapon of Victory”

Unbelievable, but I had to spend half an hour to find out this.

If you want to create your own ContentControl in Silverlight (for example, your custom Image control displaying a mirror), you can do it as follows:

1) Create a class inheriting from ContentControl.

2) In its ctor, write the following:

           DefaultStyleKey = GetType();

3) Create the folder “Themes”, put the file generic.xaml there and insert the following content:

<ResourceDictionary
  xmlns=”http://schemas.microsoft.com/winfx/2006/xaml/presentation”   
  xmlns:x=”http://schemas.microsoft.com/winfx/2006/xaml”
  xmlns:local=”clr-namespace:<yourNamespace>”
  >

    <Style TargetType=”local:<yourtype>“>
        <Setter Property=”Template”>
            <Setter.Value>
                <ControlTemplate TargetType=”local:<yourtype>“>
                    <Grid>                    
                        <ContentPresenter />
                    </Grid>
                </ControlTemplate>
            </Setter.Value>
        </Setter>
    </Style>
</ResourceDictionary>

Now you can implement your control as usual, and it will get the XAML above as its ContentTemplate by default.