Aug 14, 2011

Beware the yield return

Stumbled on a weird performance issue the other day at work. We were seeing abnormal calls from the middleware to the database, and there were a lot of them.

I fumbled around in the code and found a bunch of yield returns. I was under the impression that the yield return was like a lazy initialize and that returning using yield meant that the IEnumerable would be evaluated once and then cached.

Boy, was I mistaken.

Turns out that the yield return and IEnumerable does not have any built in caching. To cache the results you have to call ToList on the IEnumerable and use the resulting List. If not, the block with yield return will be evaluated every time you traverse the IEnumerable variable. More like a delegate than a lazy initialized variable. For me, the delegate was accessing the database and it was used in more than one place.

Try this code as an example:

using System; 
using System.Collections.Generic; 
using System.Threading; 

namespace ConsoleApplication2 
{ 
    class Program 
    { 
        static void Main(string[] args) 
        { 
            var list = IterateRand.GetRandomNumbers(); 

            foreach (var v in list) 
            { 
                Console.WriteLine(v); 
            } 

            // Sleep so the Random is seeded with a new value
            Thread.Sleep(100); 

            Console.WriteLine(); 
            foreach (var v in list) 
            { 
                Console.WriteLine(v); 
            } 
        } 
    } 
    static class IterateRand 
    { 
        public static IEnumerable GetRandomNumbers() 
        { 
            var rand = new Random(); 
            for (int i = 0; i < 10; i++) 
            { 
                yield return rand.NextDouble(); 
            } 
        } 
    } 
} 
You should get two completely different sets of random numbers. It's fine as long as the consuming code is written in such a way that the IEnumerable is only used once. I'll have to be more careful how I use yield return in the future.


May 25, 2011

CakePHP Auth Conventions

CakePHP is something new that I'm picking up. My first exposure to web frameworks was Ruby on Rails. Like Rails, the Cake mantra is convention over configuration. It's an awesome way to program. You can save hours of work if you know what the conventions are and follow them. Even bypassing the conventions is not a superhuman effort, usually a few lines of configuration.

One issue I had with Cake was implementing controller authorization. As you might expect it's because I didn't know and follow convention.

I set up my AppController class to use the Auth module and set the mode to 'controller' in beforeFilter. That meant that each controller had to have isAuthorized function defined.

I knew that most of my controllers were going to be uniform in the rights granted to anonymous users, so I coded the isAuthorized method in the AppController too.

class AppController extends Controller {
    var $components = array('Auth', 'Session');
    var $uses = array('Role');

    function beforeFilter() {
        $this->Auth->authorize = 'controller';
    }

    function isAuthorized() {
        if (strcmp($this->action, "index") == 0 || strcmp($this->action, "view") == 0) {
            return true;
        }
        $user = $this->Auth->user('role_id');
        $admin = $this->Role->findByName('Admin');
        $admin = $admin['Role']['id'];
        if ($user == $admin) {
            return true;
        }
        else {
            return false;
        }
    }
}

I thought I'd allowed access to any "index" and "view" action program wide by always returning true from isAuthorized if those actions were requested. Admins had all CRUD rights and regular users had no additional rights over the anonymous users. Sub classes would further refine these rights if necessary.

The scheme didn't work as I expected though because the anonymous users seemed to be getting blocked from all actions, while regular users had the expected rights. Admins were also behaving as expected.

I had to modify my controller to this

class AppController extends Controller {
    var $components = array('Auth', 'Session');
    var $uses = array('Role');

    function beforeFilter() {
        $this->Auth->authorize = 'controller';
        $this->Auth->allow('view', 'index');
    }

    # defaulting all controllers to allow user access to view and index
    # anonymous access to be allowed by subclasses
    function isAuthorized() {
        $user = $this->Auth->user('role_id');
        $admin = $this->Role->findByName('Admin');
        $admin = $admin['Role']['id'];
        if ($user == $admin) {
            return true;
        }
        else {
            return false;
        }
    }
}

In the beforeFilter I had to specifically enable the actions I wanted open to anonymous use. I guess the Auth component will default to not authorize before checking the isAuthorized function if the session does not contain a user.

Spent a few hours tracking that down using pr($this->Auth->user()) calls and die to trace program flow.

May 18, 2011

WPF Binding not working? Check the Output Window

Took me a long time and hours of frustration troubleshooting WPF binding failures to finally find a silver bullet. Actually, this stuff is all over the place on the net, but for whatever reason, not mentioned in many WPF books.

If you are expecting to see a binding when you start your WPF application, but the value never changes, or is default, or the bound listview is empty when it should have data, check the output window in Visual Studio while you debug.

Bindings in WPF are best-efforts only by the framework. Not really sure why. I sometimes wish a giant unhandled exception error would show up instead of silent failure. Nevertheless...

Here's a sample error message you might find there.

Let's say you have the following XAML layed out and you're trying to bind a listview to a 'Parameters' ObservableCollection member of the control data context. But when you filled out the XAML, it was misspelled.

<DockPanel>
  <Label DockPanel.Dock="Top" Style="{StaticResource LayoutLabel}">Parameter Selection</Label>
  <Border  Style="{StaticResource LayoutBorder}">
    <ScrollViewer DockPanel.Dock="Bottom">
      <ListView View="{DynamicResource ParameterView}" ItemsSource="{Binding Path=Parametrs}"/>
    </ScrollViewer>
  </Border>
</DockPanel>

Now when you debug, the members of the 'Parameters' ObservableCollection don't appear in the listview. Go and check the output window and you might see this in the output window
System.Windows.Data Error: 39 : BindingExpression path error: 'Parametrs' property not found on 'object' ''OrderedEnumerable`2' (HashCode=57007955)'. BindingExpression:Path=Parametrs; DataItem='OrderedEnumerable`2' (HashCode=57007955); target element is 'ListView' (Name=''); target property is 'ItemsSource' (type 'IEnumerable')
Lots of gobbledygook, but clearly in this message WPF is complaining that binding cannot be made with a Parametr property. It shouldn't be too hard to find the trouble with this information.

More often than not, it's not a spelling mistake, but a plain mismatch between the object being searched by WPF and the binding path given.

Example being if the aforementioned control had a datacontext set to 'MyObject' but the class of 'MyObject' doesn't have a 'Parameters' property at all.

May 14, 2011

Cool Places to Build Stuff

A survey of Software developers finds very narrow focus in what motivates. Even the most hardened veteran still gets tingles when building something new and learning.

If you haven't read 'Drive' by Daniel Pink yet, you should get on that. His insights are very true for us software people. Just a fantastic book. If you are feeling unmotivated by your decent paying job, get this book for some possible explanations.

Bottom line, it's very cool to build stuff. Along that vein, I've been visiting this blog a lot in the past few days. It seems to be written directly for me. I'm a shutterbug, a product review addict, and software professional (which they seem to have a requirement for).

I found a job listing on the site and it sounds like a wicked cool place to work. Lots of building stuff, very few meetings.

But the most interesting part isn't the description of themselves in the job listing, but their use of coding challenge to evaluate new candidates. It doesn't appear to be one of those high pressure 'code while we watch' type deals. Rather, you download the challenge data and produce a solution. Email them a link and your resume when you're done.

I might just do that.

Apr 29, 2011

Seth Godin Quote Post

A refreshing outlook on "My boss won't let me". You have to overcome this attitude to do something useful.
When we say, "my boss won't let me," what we're often saying is, "my boss wants great results, but she's not willing to let me take initiative without responsibility."
I'd be shocked if any smart boss took a different approach. Who's going to give you authority without responsibility
Thanks for the daily inspiration Seth.

Apr 22, 2011

Better Than Any Software Developer Compensation Package

I saw this promise in a Software Developer Wanted ad today
We promise you’ll never spend more than an hour a week in meetings.
Heady promise. Still, I know lots of developers who would go for this. At least, they will take a second look at the posting when they read that they aren't really expected to attend too many meetings.


Very clever ad. They definitely know their demographic.

Apr 17, 2011

Promote Your Code: Software Development in Small Environments

Working with a large team of Professional Software Developers is a bit of a dream come true. We take code seriously and we all love to see beautiful structure and design. Code maintainability is utmost on our list of priorities. Well designed and highly maintainable code is the mark of Professional Software Developers.

I used to work in much smaller enterprises where the need for a real Professional Software Developer wasn't recognized. In those places, code was produced by 'affiliated professionals' as I call them. Engineers, Scientists, even Junior Software Developers. In short, people capable of making code, but not trained how to handle software process.

I remember a manager asking us for a code review once. Code reviews should be de rigeur at any company producing code, although in practice is not widely adopted. Anyway, we had no idea what he was talking about. I suspect the manager didn't either. It was probably a due-diligence thing. Papers that needed signing.

We did the best we could. A bunch of us code guys borrowed code guys from other projects to review our code independently. It was a nightmare to gather materials in time for pre-meeting review, prepare a walk-through for the other team, then try to schedule everyone in the meeting.

When we finally got everyone together and started our walkthrough, it was obvious that the other code guys hadn't even cracked open the material we sent. The whole meeting was a bust. We sat for an hour describing basically what our product was supposed to do. Not good use of review time. Although the managers papers got signed!

If we'd had a Professional Software Developer around, I can imagine that the review process would have been a lot more productive. For example, we would've known that reviews that are more frequent and much smaller are far more effective than one huge review of thousands of lines at the end of a development cycle. Who can understand the mess created when code guys are left to their own architectural devices for 6 months? We also would've known how to handle the ego challenges of critical review of a developers artwork.

Still, the Kings Ransom that true professionals are paid is a little off-putting for businesses that don't specialize in software. Maybe there's not really enough there to employ such a professional full-time. It's too bad that a company struggling with software can't bring in Professional Software Developers part time, just to lend their expertise on process and architecture.

Or can they?

Why not drop me a line at the contact page?