8 Thoughts from Alt.Net Israel

Every alt.net meeting is exciting for me. This time it was the 4th one since we started doing this three years ago in Israel.

The final discussion we had was how to get more people into alt.net. Here are a few points that came up during the discussion.

1. The numbers of people coming really doesn’t change that much. It’s mostly the same people, and mostly the same people are active in the discussions.
2. The name alt.net is a bit misleading. For one, it has acquired an elitist aroma,  which may rub people the wrong way. Most of the sessions were not on .net technology. They were about processes, lessons learned, ALM, architecture, leadership and motivation. We could have easily build a software conf, that would interest people from Java, C++. Ruby etc.
3. Only, we don’t know who the leaders in the local Java/Ruby/etc scene. We don’t know about the communities there. We’re still in our .net pond community-wise.
4. The good thing about small numbers is that we fit in a couple of offices. Bigger conferences would either lose the un-conference mentality, and would require bigger places, which requires money. Apparently, for IDCC, it was hard getting both space and sponsors. The sponsors should pay money, not just give give-aways.
5. While having a couple of “superstars” in the community, having them is not enough to get people on a Friday morning to an all-day discussion about software development. Star power helps in bigger conferences, where people know what they’ll hear about in advance.
6. We got some feedback from people who considered coming for the first time, and either didn’t or overcame the fear of entering what seems like a closed group. If people ever hear of alt.net, the exclusive club aura may keep people out.
7. Who do we want in our community?  Ken, one of the organizers, described that we need more active people, who can contribute. These are the people who read blogs, especially of others in the community, like Ayende’s or Roy’s (or even this blog).I can attest to the fact that I’m always learning new stuff, and people are open and curious. I definitely want more of those around.
8. Where are they? Do they come from user groups? Well, most of them don’t. When I gave the unit testing talk in the SharePoint user group a few months ago, the not so big crowd were definitely not there yet. Regular talks in the different Microsoft-run user groups sometimes draw some potential, but mostly not. People come to hear from Microsoft, not to discuss alternatives, raise questions, and get help.

Is it possible that the numbers we see are real? Maybe the community has peaked? That would be sad – as great as the members are, we may be building our own echo chamber. It didn’t do any good for the international alt.net scene.

Maybe the best way is to drop the alt.net name, start looking for people in other fields and rebuild it anew.

Things that work: Write down everything

Sometimes things I do actually work.So I thought of putting them in writing. Best case scenario, you, the reader, might get something out from them. Worst case – I made you laugh or just feel pity. It’s a win-win either way.

There is an overarching theme here: process analysis. These are things that I become aware of, analyzed and improved on. Sometimes, the improvement is to throw things away and do a 90-degrees left.

I’ll start with writing. This is something I’ve learned that works for me over the last year. When writing, either a blog post, technical content, presentations, or any other stream of thoughts, I find it useful to put everything that pops into mind at the time on paper/keyboard. Anything.

This may seem trivial, but it has improved my output tremendously. Before, I have reworded, reformatted, imagined -  all in my head, before putting it in words. I now write whatever I think of.

I realized I can’t hold in my head too much. That was hard to admit. Still is.

One benefit is that I usually don’t get stuck. Sometimes, I’d write a word, knowing it’s not perfect, good, or just plain rubbish. I write it anyway and continue. In the end I go back and refactor. It costs – knowingly using words I’ll never use (what a waste!).  (for example, this sentence started out as: “I need to actively and with control to write things that may not be even coherent”).

Only recently I’ve made the connection to a unit testing behavior (of course) I used to practice. I wrote down empty tests, place holders for things I knew I would need to test later. Even as I would concentrate on one test, and an idea for a test case came to mind, I’d add the place holder and continue.

Writing down stuff and moving on – it’s a controlled behavior. I expect since I’m a visual kind of guy, moving letters around works for me -  spreading everything on the page, and then refactoring, rearranging and getting the best from it.

Gil Zilberfeld

CSI: Microsoft

Some people think that by blaming Microsoft, I’ve removed the responsibility of self development from the developers themselves. These are two separate things.

Developers who want to expand their horizon, enhance their craftsmanship, will find ways to do that. And because there are so many sources, they will probably not get it just from Microsoft.

But we few, we happy few, are the minority. Most developers are not looking to expand their knowledge. So how do they solve their problems? They go to Microsoft.

It may look weird, but if I’m using a tool or technology from Microsoft, I expect it to work. I expect working examples, and I expect support. While you and I won’t even think going to Microsoft for help (Google it first!), most people see their MSDN subscription as insurance – MS will give the answers!

And Microsoft, wanting to retain its leadership in tools and technology (because all technologies require Windows, which makes MS lots of money)  obliges. They create lots of info – support forums, how-tos, videos, Channel 9, team blogs, and even has a group that tells us how to develop better (Patterns & Practices ). And with all these channels, developers learn to rely on Microsoft for the solutions and practices.

Only a few jump off. Those that do become better programmers. The majority is left behind, gets accustomed to solving problems the Microsoft way.

And after whole this, I want to get back to my original point. There’s a symbiosis inside the Microsoft ecosystem – developers requiring solution and guidance and MS giving it back. But it all revolves around the technology platforms. If we recall for just one moment our place – we’re there to solve business problems – we find that (apart from self development) we make our livelihood by mastering the technology.

With the rate of technologies flying out of Redmond, some more stable than others, to master one or more requires to find, debug and solve problems in that technology. And this is where I was going – to be proficient in the technology, you need to be a better debugger.

Sure, it helps if you’re a better developer. It’s great if you are. But MS is responsible for the way the ecosystem works, encouraging devs to be CSI investigators, rather than preventing the crime in the first place.

Gil Zilberfeld

Why Microsoft Makes Bad Programmers

After the LIDNUG presentation, we stayed online to discuss unit testing experiences. A couple of things stayed with me from that talk. One: we’re (we developers) are obsessed with tooling and technology (you didn’t expect hard news here, right?). Our main focus should be about solving the business problem first. But, us geeks, we like to know more about the how, rather than the why.

The second is that Microsoft, by providing better and better VS experience,  and a couple of great technologies, created less and less gifted programmers, and more professional debuggers. And I mean the people, not the tools.

Microsoft is not the only culprit (hey, it’s true around the software world). With our obsession for tools and technology (which MS provided), we needed better tools for getting ourselves out of more and more messes. So MS obliged, and gave us better debuggers, and for that we became proficient at excavating software problems.  

If we chose the road less travelled, we would be working on eliminating bugs before they happen. This of course falls under the jurisdiction of better programming.

So the next time someone asks: why isn’t TDD catching on? You can blame Microsoft, or their tools, or the software industry in general. Tell’em I said so.

What can you do? Now, that’s your responsibility and what makes you a professional. 

Think about your code before you write it. Make sure it works. Review it. Think about where the bugs can hide, and leave traps for them, to catch them when they rear their ugly head.

Program better.

Gil Zilberfeld

Secrets of an online presentation

Last week I gave my “unit testing in the wild” presentation on LIDNUG. It was nice, and once the recording is up I’ll get all the info. But I wanted to talk about the experience.

First of all: people, I’ve hit the jackpot. I’ve hit on one of the best ways to extract gold out of lead. Almost. I’ve figured how to make time to prepare for the presentation: Traffic.

Ok, I’m sure people did that before cars, like riding their horse and carriage and practicing their PowerPoint pitch. They probably had more time. But for the 21st century,  in which I spend 1.5-2 hrs a day in commute – this is no longer podcast listening time – it’s talk to yourself time. Sure you look weird, but it’s great practice time. Repeat, repeat, and try not to bump into the car in front.

The how-to: I print my slides with notes, and start talking to the steering wheel. Basically simple. Allow yourself to get excited, it really helps.

Back to the presentation. Man, it’s hard getting no feedback. Online is usually bad enough when you have to rely on vocal feedback, when people talk to you (this happens when I do an online demo). But an online broadcast- no online feedback at all.

Since you don’t know how you’re doing without feedback, you need to control and modify what you’re doing, or go with the flow and do your best. Since I find doing 2 things at a time quite problematic, I go with the flow.

Finally, I’ll go to the beginning – selecting the topic. I went through a couple of thinking cycles here. I could do basic unit testing stuff, or advanced. I could also do a lap around the Typemock tools.

I finally decided to look at unit  testing differently – solving different unit testing problems. This was no longer about the tools (which of course were presented), but about: hey, you may have bumped into this once, next time, here’s how you go around it.

If you attended, give me a shoutout, and give me feedback. If not, I hope the recording will be up soon so you can do that as well.

Gil Zilberfeld

Presenting at LIDNUG this Thursday

I’ll be presenting on the next LIDNUG’s online presentation, Thursday, July 22nd, 11:00AM to 12:30PM PDT/PST (GMT-8). My presentation will be about “Unit testing in the wild”. I’ll show how to test real code, that happens to be in real life.

Expect the unexpected. Ok, and code examples in different technologies, like SharePoint, WCF and ASP.Net, with the help of Typemock tools.

Come one, come all (I prefer all), it’s free. You can RSVP and read more about it in this page.

Gil Zilberfeld (that cute guy on the right)

Battle of the framework: Testing a Webpart

Time to see the difference between Moles and Isolator code. Let’s start with the code under test (a webpart):

public class NewMessagesCountWebPart : WebPart
{
    private Label lblNewMessages;

    protected void CreateChildControls(int i)
    {
        CreateChildControls();
    }   
    protected override void CreateChildControls()
    {
        lblNewMessages = new Label();
        lblNewMessages.Text = GetMessageNumberText();

        this.Controls.Add(lblNewMessages);
        base.CreateChildControls();
    }

    private string GetMessageNumberText()
    {
        using (SPSite site = new SPSite("http://sharepoint.typemock.com"))
        {
            using (SPWeb web = site.OpenWeb())
            {
                SPList messages = web.Lists["Messages"];
                int numberOfItems = messages.ItemCount;
                if (numberOfItems == 0)
                {
                    return "No new messages.";   
                }
                else
                {
                    return "New messages: " + numberOfItems;
                }
            }
        }
    }
}

Obviously, the problem is the private GetMessageNumberText method. Let’s see how Moles handles the faking. Take a deep breath:

[HostType("moles")]
[TestMethod]
public void GetMessageNumberText_ZeroMessages_NoNewMessagesText()
{
    // Arrange
    MSPSite.ConstructorString = (site, url) =>
    {
        new MSPSite(site)
        {
            OpenWeb = () => new MSPWeb()
            {
                ListsGet = () => new MSPListCollection()
                {
                    ItemGetString = (nameList) => 
                        new MSPList()
                    {
                        ItemCountGet = () => { return 0; }
                    }
                },
                Dispose = () => { }
            },
            Dispose = () => { }
        };
    };

    // Act
    NewMessagesCountWebPart webPart = new NewMessagesCountWebPart();
    string result = (string) 
        typeof(NewMessagesCountWebPart)
        .GetMethod("GetMessageNumberText", 
            BindingFlags.Instance | BindingFlags.NonPublic)
        .Invoke(webPart, null);

    // Assert
    Assert.AreEqual("No new messages.", result);
}

Notice the Lambda manipulation, and man, if you get it wrong, you need to dig deep. Another thing to note is the need to specify the empty implementation for the Dispose methods. The implementation is to throw if not specified. Finally, there’s the reflection use for invoking the method under test, not so big deal, but something you need to understand as well.

Behold the Isolator test:

[TestMethod]
public void GetMessageNumberText_ZeroMessages_NoNewMessagesText()
{
    // Arrange
    var fakeSite = Isolate.Fake.Instance<SPSite>();
    Isolate.Swap.NextInstance<SPSite>().With(fakeSite);
    Isolate.WhenCalled(() => 
        fakeSite.OpenWeb().Lists["Messages"].ItemCount)
        .WillReturn(0);

    // Act
    NewMessagesCountWebPart webPart = new NewMessagesCountWebPart();
    string result = (string) Isolate.Invoke.Method(webPart, "GetMessageNumberText");
    // Assert
    Assert.AreEqual("No new messages.", result);
    
}

I like this better.