Beef Stroganoff with Greek Yogurt

Posted by Steven on August 27, 2011 None comments

Last night for dinner I made stroganoff for the first time in about a year or so. I made the traditional version with slices of beef served over noodles rather than the more cassarole-like version with ground beef mixed in with the noodles. For something different, I used Chobani greek yogurt (the plain flavor) instead of the normal sour cream to finish off the sauce. The recipe is sized for 2-3 servings (with sauce left over) so for a family dinner just double it.

Note: I omitted the mushrooms this time around because I was making it for someone who doesn’t like them. I would probably use about 6-8 baby portabella mushrooms, chopped to taste, and added about the same time as the beef.

Ingredients (all measurements are approximate):

1lb grass-fed half sirloin

2 1/2 cups beef stock

3 tablespoons extra virgin olive oil (I actually didn’t measure this)

1 large shallot (or 2 small, or 1/2 an onion)

3 medium size cloves of garlic

1 bay leaf

parsley and thyme to taste

1-2 tablespoons of flour (depending on how the stock cooks down)

6oz cup plain Chobani

1/2 lb noodles (I used farfalle for a different look)

Instructions

  1. Get a pan with a large surface area and put it on medium heat. Put in a comfortable amount of olive oil. When that gets up to temperature, put in the shallots and garlic.
  2. Slice the sirloin into strips or chunks of even thickness. Add to the pan.
  3. When the sirloin is browned on both sides, reduce the heat and add the stock, the bay leaf, and a pinch of thyme and parsley.
  4. Cook the noodles however you normally would.
  5. When the beef has simmered about 30 minutes, remove it. The stock may need a tablespoon of flour to thicken it. I also transferred it from the large pan to a 1 quart saucepan.
  6. Add the greek yogurt to the sauce and mix.
  7. Put noodles on a plate, lay several strips of beef over it, and top with the sauce.

Some thoughts re: my recent work

Posted by Steven on April 26, 2011 None comments

So I’m going to be deliberately vague as I don’t want to give away anything work would be mad for, but  I wanted to talk a little about what I’ve been playing with the last month or two. The background of this is I am developing a Service Layer based on the REST architecture over most of the data layer and some of the business layer. I’m also developing a dashboard/portal site that is going to make use of all these various services.

There are really 2 main divisions of the codebase for the project, aside from the services themselves:

  • the portal site/framework
  • portlet implementations

It goes without saying that I’m programming to interfaces, so I’ve got a couple of interfaces with some properties, methods, and extension methods that anyone can implement to make a “portlet” to work in my site. In my MVC3 application I use reflection to scan the bin directory and set up routes for any http resource object that implements IPortal. The idea is everything needed for a portlet (css, javascript, the html or json or whatever it needs to render itself) comes from this wcf resource through a jquery ajax call. I’m still wiring up all the javascript, but I have all the server-side stuff working end-to-end.

These http resource objects are created using the new HTTP stack Microsoft has been working on (WCF Web API), which I really like working with. I tried OpenRasta but some of its routing annoyed the crap out of me (I have some use cases where I want to be retrieving the same System.Type as a return value for more than one method in a resource, which it *didn’t* let me do). One of the things I like the best about the new stack is that it exposes places in the http call stack to attach custom behavior, through channels and formatters.

The formatters are probably the coolest addition, because they provide a way to attach cross-cutting concerns – taking a return value from a service operation and serializing it in some manner – in a modular and configurable way. For example, it ships with XML and JSON serializers so you can get any object back as xml or a json array. It makes use of the built-in content negotiation in the http spec to map content types in the “accept” header to the serialization/deserialization mechansim and lets your code stay clean and just return an object.

I’ll post tomorrow about my adaptation of an excellent blog post about instantiating the Razor view engine within code to create a HTML formatter – I updated it to work with the latest preview, created an interface for “templatable” types, and have it load the template from an embedded resource in whatever DLL you define the model type.

Good at programming does not mean good at teamwork

Posted by Steven on April 26, 2011 None comments

Another oldie but goodie from the startup days, in the same vein as the rant on process, this time lamenting the lack of teamwork and leadership that was the other side of the coin:

I think one of the most annoying things I’ve dealt with so far are people that are very good at programming but very very bad at anything related to teamwork. Its mildly annoying when its a peer, it is devastating when it is someone in a position of power over you.  The kind of people that are supposed to provide leadership and direction, but would rather sit in the corner and program. I don’t know if its a sense of superiority, a lack of trust, or just an introverted personality type, but someone like that really has no business leading a team.

Which would you prefer to be your team leader/development manager/boss – someone who lets their superior dictate everything to be done, doesn’t take any interest in what the team is doing, and works on their own without really communicating with everyone else? Or someone who is engaging and responsive to the team, tries to keep abreast of what’s going on with their work, and does what they can to coordinate development activities?

In my mind, the things that make a good developer are much more than being a good programmer. All you need to be a good programmer is to know enough about programming to not make too many mistakes, follow some best practices, and do your work. Yeah. That’s it. So learn Java, C++,.NET, whatever. Read some books like Code Complete, the Gang of Four, Pragmatic Programmer, Joel on Software, and synthesize your own set of beliefs about software development. Then take the next step – don’t be a programmer, be a development team member. Don’t just focus on your bugs, your requirements, your work. Focus on the team, on the product. Work with your fellow developers. Listen to their ideas, share your ideas, collaborate. If your work is similar to another team members’, take the time to talk to him or her to figure out if you can pool your work. Don’t live in the corner.

One of the things that I like so much about Scrum is the idea of the Scrum Master role. They serve as the overseer of the development process, but are there to deal with the problems that the development team come across rather than micromanage the developers. In my mind, that is one of the most important things a good leader does – coordinates their people, finds out what is hindering the team, and working to remove those hindrances. Rather than getting annoyed with their team members for coming with questions or problems, and snapping at them to use google to find the answer, a good leader should never hesitate to take the time to sit down with someone and make sure they gain an understanding of how to best solve their problem.

Of course, when you sit in your corner and don’t interact with the rest of the developers, you don’t have to take responsibility for any problems.

An old rant on “process”

Posted by Steven on April 26, 2011 1 comments

Back in 2007/2008, I was working at a startup. It didn’t go well. Here is one of the rants I wrote.

The backstory: I had been advocating using Scrum to help us manage what was an increasing amount of scope creep, release pushbacks, and the assorted problems that come from running a startup half cocked.

The other devs and I were trying to manage the chaos by keeping each other up to date and every few days looking at the list of work items (because we didn’t *quite* have a backlog… except we kind of did). This list of items was even divided into releases (does that sound like a sprint backlog to you?). We tried to keep each other up to date on an almost daily (… daily scrum?) basis. So why didn’t we go the last few steps and actually jump on scrum?

Lack of management buy-in. The founder gave lip service to trying out scrum, threw me on the spot to present it to everyone during a weekly status meeting (after previously shutting me down on it), then promptly didn’t bother to try to fill the scrum master role (and he was really the only one empowered to do it).

Anyways, that turned into a separate rant, but here is my at-the-time griping about the startup:

Back in the dark ages, when people talked about “Process” in software development, they meant Waterfall. A lot of people that learned to be programmers in the 90s and earlier have this idea that process is all this hideous up-front work, regimented development, and tons of overhead during the entire escapade. They fear process. They think it slows them down and that they are smarter and better than big companies because they use an ad-hoc development procedure that basically consists of throwing man-hours at a problem until its solved, but hey it achieves some results sooner than the big company because they just finished their detailed design phase and are beginning development.

See, the thing is, the idea of process has come a long way since the days when waterfall was the only model. There are enough different process models that nobody really has an excuse to throw away effort in the name of moving quicker. If you really want to develop quickly and be responsive to changing requirements, try using one of the Agile methodologies like Xtreme Programming or Scrum. Scrum is really really nice. It emphasizes communication and just a smidgeon of organization without forcing 10 tons of documentation for each decision or development action.

Would you rather be on a team where nobody talked to each other, people were randomly assigned bugs with no regard to their strengths but merely their availability to do something, no thought was given to scoping features so last-minute additions cause releases to slip a week or more from their hopeful schedule, and planning is discouraged because its more important to get broken functionality there to fix later, and sometimes people don’t even know a release is planned to happen overnight until they are chastised going out the door that night? Or one where releases are expected on a 2-4 week regular cycle, developers take on responsibility for the features they choose and believe they can complete in the cycle, people take a little time to plan their work, and everyone meets daily for a few minutes to talk about where they are and what problems need to be addressed so everyone is on the same page? That’s the difference between Scrum and nothing.

Hmm. A little bit of time to communicate with everyone, every day? A half-day of planning every 3 weeks? Nooo! Run! It’s process!

Starting this up again

Posted by Steven on April 21, 2011 None comments

So I’m getting a blog set up again. This is going to serve as kind of a place to stick things I want to write about, so there will be posts about music, food, and probably a lot of software development stuff.