It is my great pleasure to invite you to the fourth ALT.NET Israel unconference, which will take place in September, Thursday-Friday (2-3/09/2010).

You can register to the conference here.

This is merely a simple observation. I had a chance to talk with a few people recently, and I heard something that really bothered me. Sadly, this is not a new thing, but it is still extremely annoying and disrespectful.

Basically, the problem is that concerns that are being brought up are dismissed as unrealistic, idealist and non workable in the real world. The people who bring up those concerns are also dismissed as radical tree huggers with no concept of how to build things in the field.

The reason that I think this is stupid, insulting and disrespectful is that a lot of the people bringing up those concerns are real world practitioners. It is more than just merely annoying to hear that.

Calling a raised problem an idealist issue or a perfectionist problem is an eventual guarantee that the feedback and concerns being brought up will dry up. And that the next feedback received will be in terms that aren’t favorable.

Notes from alt.net parallel session.

• Locality doesn't matter
• Locks / syncronization are cheap
• Higher parallelism equates to faster code
• All actors see the same state
• Parallel programming is easy

Last week I participated in ALT.Net Seattle, which was quite interesting. It used the same open spaces format as most ALT.Net conference, and I can honestly say that it was a good experience to most of the attendees.

It did not, however, had the same style of interaction. One of the things that I really enjoyed in the previous ALT.Net conferences is the level of interaction and participation. In this instance, I think that a majority of the people arrived mostly to soak in the information. That changed the dynamics of the conference, and it was quite visible in all the sessions that I was part of.

Just to be clear, I am not saying that it was bad, or that you must participate, I am pointing out a difference between the current conference and the previous ones.

I think that something like that is inevitable as the community grows, because at this stage in the game we are moving from the early adopters to the pragmatists. The problem is that we are currently in that gap, where the ideas only begin to go through:

It is my hope that when we finish cross this chasm, we will be able to return back to the same style of interaction that we have had in the past. The problem is, as I see it, that currently too many of the attendees felt uncomfortable to speak. Once again it was the case of the best conversations happening in the hallways and at dinners, when people could relax.

I think that as we see the people in the wider community gain experience and confidence, we will go back into the same vibrant discussions and learning. In the meanwhile, I intend to do my best to push the community forward toward that time.

It was a good conference, even if the highlight for me was the air hockey table talk.

It works :-)

I am writing about documentation at the moment, and I found myself writing the following:

I don’t think that I can emphasize enough how important it is to have a good first impression in the DSL. It can literally make or break your project. We should make above reasonable efforts to ensure that the first impression of the user from our system would be positive.

This includes investing time in building good looking UI, and snappy graphics. They might not actually have a lot of value for the project from a technical perspective, not even from the point of day to day usage in some cases, but they are crucially important from social engineering perspective.

A project that looks good is pleasant to use, easier to demo and in general easier to get funding for.

This also includes the documentation, if we can do something in a short amount of time; we get a level of trust from the users. “Hey, I can make it go bang!” is important to gain acceptance. The first stage should be a very easy one, even if you have to design to enable that specifically.

After reading that, I quickly added this as well:

Note, however, that you should be wary of creating a demoware project, one that is strictly focused on demoing well, and not actually add value in real world conditions. Such projects may demo well, and get funding and support, but they tend to fall into the land of tortureware very rapidly, making things harder to do, instead of easier.

Beware of the demoware.

I am going to give a workshop or two at the ALT.Net Austin in the end of October. Those will be free (as in beer) and will be recorded & available on the net afterward. Right now I want to do on on writing DSLs, but I have another which is basically blank at the moment. I have too many subjects that I can talk about, and too many levels at which I can talk about them.

So, this is your chance to help me. If you are going to be there, what would you like to have a workshop about?

And no, a question like NHibernate is not acceptable, it is  too broad. Are we talking about NHibernate best practices, high scalability, tips and tricks or advance usages. I can do a three hours workshop on any of them.

Suggestions?

The girls in the picture are responsible for business development SQLink and GotFriends.

Just to set the record straight, per their request.

Here are the videos that were posted so far from the ALT.Net ISrael:

• Alt.net Israel - Hallway chat - performance
• Alt.net Israel - Refactoring
• Alt.net Israel - Distributed Caching
• Alt.net Israel - Dynamic Languages & DSLs
• Alt.net Israel - SOA in the real world
• Alt.net Israel - Closing Talk

This is my 3,500th post, wow! Looks like there is some future in this blogging business after all.

On Thursday evening and Friday we had the first ALT.Net Israel conference. I would like to thanks the attendees, for a really awesome couple of days.

The sponsors, Sela Group, Red Gate, Type Mock, JetBrains and SQLink, also deserve a round of applause.

I had fun. I am not sure what happened, but I arrived in the morning and suddenly it was over. Didn't feel any time pass at all.

I was honestly surprised by both the amount of people that have arrived and the quality of discussion that we had. I have hoped, but had hard time believing that this would happen. I am not sure where everyone was hiding before, but I hope (and am certain) that we will be able to create a strong community and keep this going.

We managed to get a lot of what went there on tape, and we are currently uploading stuff so the rest of the community will be able to watch it as well. I am looking forward to seeing Udi's reaction to the mess we did of the SOA session, in particular :-)

I am still in the process of uploading the videos I took, hopefully it will be finished by the time you read this post. You can get them at this address: http://www.viddler.com/explore/ayende/videos/

I repeat, awesome event.

The registration for ALT.NET Israel is now open. You will need an OpenID (I use myopenid.com) to register. We are limited to 50 seats for the first event. First come first served. Worst case scenario you go into the waiting list.

Please only register if you are serious about attending.

The event takes place in two parts: Thursday eve. from 18:.30 to 20.30 and then the full day on friday (9-17.00). more details on the site.

Yeah!

We are going to have an ALT.Net conference in Israel in a few weeks. More specifically:

Thursday 7th, at 18:30-20:30: planning meeting, following a walk to a nearby pub or coffee shop to socialise.

Friday 8th, at 09:30-16:30: sessions.

The conference will be held at the SQLink offices in Ramat Gan.

Ken Egozi was kind enough to not only prod me & Roy moving, but to arrange the location.

Agenda:

That is really up to the people who attend.  We will be following an open spaces format, similar to the other alt.net conferences in the UK, USA and Canada, where the agenda is decided by the conference participants.  Anyone can lead sessions on particular topics of interest, participate as an attendee or just hang around and chat with interesting people.

Our sponsors:

Registration is not open yet, I'll post again when it is.

About a year and a half ago, I start an exciting new project (there is a demo of the actual project here). The actual application is fairly complex, and has some it gave me the chance to explore some very interesting ideas. Rhino Security is a generalization of the security scheme used in this project, and it is pretty much the driving force for Rhino Igloo. But that is not what I want to talk about.

What I do want to talk about is the infrastructure that we used for the project. We used IoC, OR/M, AoP, MVC and many other buzz worthy TLD. It was the first time that I had the chance in implementing real high end complexity reduction techniques. I left the team 10 months ago. In the meantime, the application was under active development, got a few new team members and had two major releases.

I am really proud of that system.

A few weeks ago I got a phone call from the current team lead, asking me about the windsor.boo file that is sitting there. The last time anyone touched it was shortly after I left, after which, it just... existed. I had the chance to do a code review on the new stuff that the team developed, about three months ago. I couldn't find any real difference between the code develop before and after I left.

Anyway, I had to spend 15 minutes on the phone, explaining the process that was going on there. Before I left (and during the time I was the team lead), I made sure that I passed on all the knowledge that I had about the system, the design decisions and the overall picture. However, there was a period of nearly three months in which I forgot that we even had this infrastructure, because we hadn't have to deal with it for that time period. After I left...

• 9 months.
• 2 major releases.
• Zero issues with the infrastructure.

I asked the team lead what she thinks about that. Since it is her project now, and if she thinks that it was the right decision to make. She love the infrastructure, and wouldn't hear about using a lower end solution. Most of what we did was actually going over the file and explaining historical decisions, for that matter.

As an additional data point, I was able to look at a piece of code I have last seen over a year ago and figure out not only what it does, but the how and why of it with no ramp up time.

I consider this a success.

That was the topic under discussion in the first ALT.Net talks today. There weren't that many people at the talk, but it was very focused and useful.

In general, there aren't that many ways of funding OSS projects. Note that I am talking here from the perspective of the developers who does the actual work, and how they get compensated for their time and effort. This exclude reasons such as scratching an itch, or as a hobby.

• The OSS work is useful for the day-to-day work of the developer. This is by far the more common model in the .Net world. Most OSS developers tend to do so because supporting the project supports whatever they actually trying to do.
• Reputation building - being part of OSS project usually means that you get a good reputation as a result. This can be useful in getting a job, as an example.
• Contracting / training / support. This seems to be a very common model in the Java world. There are only a few projects in .Net that are working in this approach.
• Donations - nice in theory, doesn't work in practice.
• Grants - someone who needs a feature pays for it being included. I had several leads in the past, but nothing that ever got to actual money exchanging hands.
• Work for hire - Some entity that hire a developer to work on an OSS project. SvnBridge is a good example of that. The difference between this and the previous entry is that this is not necessarily something that the dev was initially involved at.

The session was focused on two subjects, how we can increase awareness, and how we can fund OSS projects. I think that the ALT.Net community is doing a lot best practices, approaches and techniques and the tools that can be used to support those. We recently had several articles in mainstream media about from members in the ALT.Net community, as a simple example. We can do more, like reaching out to the user groups, talking more about it, doing entry level tutorials, etc. But that is more related to adoption of OSS tools, not to funding them, which was the major topic for the session.

When we are talking about funding OSS projects, we have to make a distinction in what we are talking about. We can fund the OSS project itself, and we can fund OSS developers. I feel that a large part of the session was spent making this distinction.

The major difference is in what you are trying to achieve. I use OSS projects to help me do my work, I don't need them as a source of income. They are a tool. Getting paid to work on them is fun and would be lovely, but tat is not actually something that I spend a lot of time thinking about. A lot of the suggestions that we had at the talk all involved OSS developers making considerable investment in time, money & risk for the goal of furthering OSS development.

Sorry, it doesn't work that way. At least not for me. I am getting paid to write code. Incidentally, at this point in time I am actually getting paid to write OSS code, which I consider as a really nice perk, but not something that is in any way required.

When we are talking about funding OSS projects, I am actually thinking on the other side. Funding the project itself. however, is something that I would like to focus on. The best way I know of actually getting things done is to actually pay for it to be done. Working for free works if and only if the task is fun. If it isn't, it isn't going to happen. If you want something from an OSS project, put your money where your demands are.

You want more documentation for doing X, pay for it. You want feature Y, likewise. And by paying for it, I mean anything from offering money to submitting a patch to adding to the documentation.

It is a very simple concept. And the best one I can think of.

I was a blast, I had a lot of fun, some incredibly interesting conversations, and got to meet a lot of the members of the community that I have only knew by email alias before.

We had some really good discussions today, and I got to clarify some thoughts that have been luring in the back of my mind for a while now. After the ALT.Net conf officially ended, we started hanging around, swapping stories. Somehow it got to 8 PM, I am not sure how. Roy took a bunch of us that remained to dinner at a nice place. I haven't had a drop of alcohol today (unlike the entire last week), but I am feeling more drunk than on any other day.

I would like to take this opportunity to thank TypeMock for sponsoring the dinner. It was wonderful, although I have trouble walking and / or thinking.

Doing MVP Summit and ALT.Net, back to back, is a real tiring experience.

That said, got a lot of stuff to think of, and will probably generate quite a few blog posts.

Thanks for all those who attended, for creating such a rich discussion.

Special thanks to the sponsors, Version One, ThoughtWorks, Microsoft P&P, DigiPen, DevTeach, InfoQ and CodeBetter!

I think that yesterday was absolutely wonderful. It did feel like I spent about 5 hours straight talking, however. The DSL talk was interesting, and gave me much to think of (and might actually kick start the book again!), great fun.

I think that my liver died at some point last night. MVP Summit + ALT.Net are not friendly to it. No time to recover.

Recently I had a few conversations about tooling, lack thereof and the impact that this has on the overall system.

I don’t think that someone can argue that starting from scratch is a very good idea in most scenarios. This is especially true when you are talking about any significantly complicate system, which we all do.

There is still a place for quick & dirty solutions, but that is for throwaway utilities. Hell, even calc.exe isn’t simple (arbitrary precision numbers) anymore.

Therefore, I am constantly surprise by people that chose to go without. I could understand that if they chose that path out of ignorance, but all too often a conscious decision.

It is based on reasons such as: “It would take me too long to get approval to buy this tool”, or “I have to go through the Proper Channels to use that tool”.

I don’t like those reasons, but they are real, and I had encountered them several times.

By now you have probably understood that I have firm opinions about how to go about building successful software systems.

Those opinions are backed by the tools that I am using, but are not constrained to them (just check the commit logs when I am doing something new J ).

So, where is this headed?

Right now I am working on top of the  Naked CLR, which means that I am mostly cannot use my usual stack. This is not fun, and I assure you that I bitch about this more than enough.

Nevertheless, the inaccessibility of my usual stack doesn’t mean that I can just ignore my experience so far. I have the aforementioned opinions for a reason.

IoC and AoP are two simple concepts that I have embraced whole heartedly. Auto registration and letting the application figure it out is paramount to the way I develop software.

I tried to do it otherwise, and I have myself constrained and annoyed.

How do I solve this issue? By using Field Expedients replacements.

What do I mean by that?

A container, auto registration, method interception and AoP are fairly easy to build. You can take a look at those implementations, to get some ideas.

I implore you, however, that you will not use those. They are replacements, hacks and temporary. They are there so I can work using familiar methods and practices, although not using my familiar tools.

If you’ll tell me the implementation is bad, I’ll agree. But it is there, and it can be used. As a scaffolding if nothing else, but it can be used.

This post is mostly to note that not having the tools is not a good enough reason. You can build the tools.

This post is written to make a point that most people seems to miss. You don’t need to get it perfect. You don’t need to drop down to assembly to get every erg of speed you need. You don’t need it to be functional for the general case, you don’t even need it to be pretty.

The so called container that I have created is a good candidate for the Daily WTF.

I think that it took about 4 hours overall to build everything that I needed. I didn’t build it all in one go, just as I needed it. You can actually take a look at the history and see how it went.

Don’t mistake what I am saying, however. I am calling those Field Expedients for a reason. They are crutches, and are not nearly as capable as the real things. But they are close enough, and I am told that I am good at mocking.

A while ago I suggested a logo for ALT.Net, which I really liked, but had copyright issues. Since then, I had commissioned the creation of a new logo, using the same ideas, which can be used without copy right issues.

This is not the official logo, there isn't any to my knowledge, but it express the way I think about ALT.Net very well.

The logos are:

And:

You may use and modify the logos under the Creative Commons Non Commercial license.

I put all the raw images in this location, which can be used to adapt the images.

Have fun.

This is a public service announcement, the registration for ALT.Net Seattle is now open.

There are 150 spots available: first come, first served.

That had me in stitches, and no, it is not a typo:

 I read Ayende's blog rabidly

In the ALT.Net mailing list, we are having a discussion about the CAB and OB. Part of this discussion include this dialog between me and Brad Wilson.

Brad: If you're simply angry because we had the audacity to make our own object factory with DI, then I can't help you; the fact that P&P did ObjectBuilder does not invalidate any other object factory and/or DI container.

Ayende: No, it doesn't. But it is a waste of time and effort.

Brad: In all seriousness: why should you care if I waste my time?

That question prompt this post, because I have so many reasons to car.

If Brad was a private person, I wouldn't care.

But, when Bard is doing this for something that is going to be released with a "Microsoft" in its name, I care quite a bit.

• I care because it means that people are going to get a product that is a duplication of work already done elsewhere, usually with less maturity and flexibility.
• I care because people are choosing Microsoft blindly, and that puts MS in a position of considerable responsibility.
• I care because I see this as continued rejection of the community efforts and hard work.
• I care because it, frankly, shows contempt to anything except what is coming from Microsoft.
• I care because it so often ends up causing me grief.
• I care because it is doing disservice to the community.

I was looking at the traffic numbers for the ALT.Net, and I wasn't quite sure that I should believe them:

This has got to be the most active group that I have ever taken part at, and about 90% of the discussions there are interesting. The signal to noise ratio is simply amazing.

Of course, the mere quantity of information presents a problem:

This discussion came up in the ALT.Net mailing list, it reflects my own thinking so much, I had to quote it:

> Some of the largest software development shops in the world would disagree with you

Chad Myers: Most of the largest software development shops would disagree with me on a lot of things. They tend to be top-heavy, waterfall-laden
dysfunctional bureaucratic/political nightmares, too. Many of the largest shops also still have mainframes and COBOL systems for which
they no longer have the original source code for (I know of at least one). They're mostly concerned with protecting middle management and how
they can shave 1% more off of software development by offshoring to Indian or Brazil too. So I'm not too worried that they disagree with me :)

Charlie Poolie, on the ALT.Net mailing list:

So one reaction I had to Alt.NET was that it was a group of folks who don't do stupid things: sort of like forming a club for people who don't play
in traffic or don't juggle sharp instruments.
Oddly, as others have pointed out to me, such a group is actually needed in the .NET world.

ROTFL.

We are discussing the ideal IDE on the Alt.Net mailing list, I thought that it would be interesting to gather all the requirements in one place.

I made some minimal attempt to reduce duplication, and to put the interesting parts, but check the discussion, it is still going on. This is not a list of "what is wrong with VS", it is a list of things that we want to see in an IDE (or not see in an IDE :-) ). IDE is defined as the place where I write code / debug /test.

Good quotes:

• I want to be a train speeding full steam and have this IDE laying track just in front of me until such time as I tell it I want to go a different direction.
• I just want a lightening fast intelligent editor that will let me choose to add on the features I care about. I don't want to have to deal with lag time.
• Give me something like TextMate for .NET. Build it on managed code. Make the AST model/API sensible and self-evident. Provide a user-centricity driven plugin model - no abstracterbation for programmers with technology fetishes. Plain, simple, self-evident. Extensibility and usability for the merest of mere mortals.
• So, do you really need Snippet Compiler with ReSharper editing features and debugger?

And now to the real stuff that was mentioned:

• Coding:
• Syntax highlighting
• Intellisense (I may think I am a jedi but true zen is to talk to the machine and have it put forth the words before you)
• Code Browsing
• Refactoring
• Treat Warnings as Errors as not negotiable (always enabled).
• i want it to be geared towards the keyboard developer.
• Text manipulation:
• Regex manipulation of the text.
• Debugger, good one.
• Edit and continue
• Testing integration
• Setting up all the required stuff, what is compiled, embedded, etc.
• Preferably it should read my build script and work on top of that.
• i want the build system to be pluggable
• i want a light project structure. If anything is going to be stored in a file it needs to be in a readable form and would preferable have a lightweight API that ships with it.
• Source control integration - nice, but not really a must have, I use tortoise for that.
• Some opinions said that SCM should not be in the IDE.
• Extensible
• Should be able to add a new language easily.
• Should offer me the AST of the code when I build a plugin.
• Make it have a light version, where you can unplug stuff you find unnecessary. ??
• So as far as an IDE is concerned I want to do everything from inside it like deployments
• Smarts:
• Error highlighting (errors, warnings, test failures, bad practices, ...)
• A Code Smell detection system (users could extend it with CQL)
• i want it to give me visual cues to interesting code constructs
• All existing R# features
• IDE support for effect analysis (Chapter 11 of Working Effectively with Lagacy Code).
• automatically correct these issues: flase > false, reslut = result, retrun = return
• User interface:
• Full screen ability
• Background compilation as you type (I hate waiting for VS to compile my solutions all the time).
• Code searching:
• A very fast way to get from the current function you are in to any caller or to any function the function is calling (and class definitions, ...)
• Ability to instantly search for a specific artifact (kind of like google / windows live search). As I type it in, I see the filtered results. This is NOT the find feature.
• Misc:
• The ability to have 2 people working in separate window panes on the same file (one person typing on the local keyboard/mouse, the other in a remote desktop); both visible in the same environment.
• IDE installation < 100Mb
• Shell integration would be nice. and available from the keyboard (think launchy)
• For windows PowerShell integration would be nice too.
• How about an IDE that doesn’t lock up when the source control is unavailable ;)
• better multiple monitor support.
• Configuration screens that don’t give me a headache
• Responsive:
• I am willing to pay for a quad core computer with 16 GB RAM, and use that for only programming. But it _must_ be responsive. (I used VS.Net on such a system, it crawled!)
• FAST FAST FAST
• Designers:
• i don't want any of the overhead of a designer.
• Designers that don’t break or no designers at all
• Built in (no separate window) reflector
• I should be able to CTRL+B from the method to the code or to the disassembled code.
• Release cycle:
• I want an IDE which is released early and often. And I want an IDE built by a team which is responsive to community feedback. The rest is just details.
• Multiple Releases a year, constant improvement.