Slashdot Mirror

A few weeks ago you had a chance to ask author, entrepreneur, and software developer Jeff Atwood about founding Stack Overflow and the Stack Exchange Network, as well as his new endeavor, the Discourse open-source discussion platform. Below you will find his answers to your questions. Magic wand
by Anonymous Coward

If you had a magic wand to make one change in technology right now, what would it be?

Atwood: Users would not have to generate, remember, enter, or ever think about passwords again. Computers would automatically know who the user is through a combination of ambient biometrics plus physical possession of some kind of device. Like, say, a smartphone.

Passwords are the enemy. And the users, because we are the idiots put in charge of making up the passwords. But mostly, it's the *goddamn passwords*.



Why did you choose Microsoft Platform for SE?
by Sadsfae

I don't see many large, high profile sites running an entire Microsoft Windows stack nowadays (IIS/SQL Server, etc) but Stack Exchange is one of them.

What were the reasons behind choosing a full Microsoft stack versus any of the Open Source alternatives which seem much more prevalent, especially in start-ups and smaller businesses for web presence?

Atwood: Mostly, C# is what I knew and what I was skilled in -- and I'm a great fan of its primary architect Anders Hejsberg who also created Turbo Pascal and Delphi. Performance was a goal, too, and since C# is a compiled language it's *extremely* fast. I think you can see for yourself that Stack Overflow is absurdly fast. Having switched to Ruby with the Discourse project, I can also testify that Ruby .. is, uh ... not ... absurdly fast.

The only downside of the .NET environment is, honestly, the SQL Server licensing costs which can be quite extreme at scale. There is movement to make .NET more open source. Plus the long running mono effort.

The main weakness of .NET is that it's not great for open source projects, though that has changed a bit over the last few years. It never really made sense to open source Stack Overflow -- ask yourself, how many Stack Overflow clones have flourished? Why is that? As a closed source project, the performance, great language design, and scaling of C# worked for us.

I made different choices for Discourse which *was* designed to be an open source project, a tool that is widely applicable to many communities, from day zero.



History of StackExchange
by unencode200x

A question on the history of Stack Exchange. What was the original idea that drove you to make StackExchange and how has it evolved or added since?

Atwood: Do you remember a site called Experts-Exchange? No? That means we succeeded at our original goal.

The basic concept was to do a 100% community driven Q&A that had elements of:

- Wikipedia (all the articles are always up to date and not dead tombstones from six years ago).
- Reddit (voting up the good information and voting down the bad information).
- Blogs (ownership, curation, and responsibility for content that has your name on it).
- Videogames (the Xbox 360 Achievements system, points, and ways of encouraging and incentivizing positive community behavior that are fun).

Where everything we build together is creative commons, and belongs to all of us, since you guys and gals are the ones doing all the work in the system!



Reputation mechanisms & scientific quality
by Anonymous Coward

Jeff, have you thought about how to use reputation mechanisms to improve the quality of published scientific results? I'm asking in the context of John P. A. Ioannidis' famous paper.

It seems to me one fix for this (horrible) problem might be an online reputation mechanism where scientists could rate the reproducibility of published results. Thoughts? (thanks for inventing Stack Exchange - you've done the world a big favor).

Atwood: It certainly seems applicable. The Stack engine works best for systems of data, fact, and science -- or at least a "tome of knowledge" -- where you can actually verify an answer (or five answers) as plausibly correct. You can see which topics do best on the Stack engine in the Stack Exchange directory, with a massive, Jupiter sized Stack Overflow right at the top.

There's always more than one way to do it, of course, but when you start getting dozens or hundreds of "answers" you don't have Q&A, you have a discussion with no clear answers, just opinions.



User Reputation, Moderating, and Discourse
by T.E.D.

I think its probably inarguable that the biggest innovation StackOverflow brought to the web was the centrality of reputation and user moderation to its design. Sure, our own /. had done something similar years before, and it was hardly the first either, but no website I know of had before taken it to its logical conclusion in quite the way SO does. This effectively "crowdsourced" a lot of traditional website administrative activities, which turned out to be an incredibly powerful idea. Practically all the functionality of SO is built around the concept.

So when I saw you were tackling online message boards, I expected the same kind of thing. But browsing around a typical Discourse thread, I'm not seeing that at all. Sure, users can "heart" posts, but all that does is bump a small counter next to the heart. There is no way to tell at a glance which posts users found the best and/or worst. Higher rated posts don't sort to the top, or get bigger or anything. As a result, I don't even see that feature used much. Certainly its nothing like SO, where post voting is the central activity. It also seems like moderation on Discourse is designed to be done by administrators, not users. I don't see any facility for users getting moderation privs as they gain reputation. Compared to SO, Discourse seems kind of, well, like a big step backwards in interactivity.

I'm sure I'm missing something here. What is it? Or did you really decide SO's centering of its design around users and their opinion on posts was a mistake, or perhaps just not a good fit for a more generalized discussion board?

Atwood: Sorting a conversation by votes is a pretty effective way to destroy conversation. How can you follow the logical flow of back and forth, chronological dialog when the ground is constantly shifting underneath you as posts get voted up or down? You can't.

Stack is a system of technical Q&A, where opinions are fascinating, and all, but they are completely trumped by facts, data, and science. Stack only tolerates the minimum amount of discussion necessary to get the best questions and the best answers. The goal isn't for people to talk to each other, the goal is for people to *answer the damn question*. Ideally with the aforementioned facts, data, and science, so our peers can objectively decide if the answer is correct and works.

Discourse, on the other hand, is explicitly a system of discussion and opinion. There is no right and wrong. You can't tell me my opinion that Wolverine is the coolest X-Man is wrong. Long after people have forgotten what exactly was said, they will remember how you made them feel. That's what the like (heart) action is about, and why it is featured so prominently: empathy. Discourse is a system of empathy.

We do have user trust levels in Discourse, it's just less obvious, because we're playing a different kind of game. Compare that with Stack, where your reputation number and badge counts appear prominently next to your name every time you post. Trust me, people *do* notice when you like their post. And if they see your post got 20 likes whereas their post only got two, or none, they absolutely notice that too. Discourse is more of a collaborative game, where Stack is an explicitly competitive game, and that's why the score is so prominent. The best way to motivate a programmer is to tell them someone else did it better. Don't try to race sheep, don't try to herd race horses.

There may not be re-ordering by votes in Discourse, as there is in Stack Overflow, but there is a summary mode for topics when they reach 50 or more replies. If you'd like to see this in action, visit a longer topic and press the "Summarize Topic" button at the top near the estimated read time, or as I like to call it, the TL;DR button. Then you'll see only the "best" 10 percent of that long topic. That factors in a lot of data from each post such as likes, incoming and outgoing links to the post, the number of times it has been read, total read time (we track actual on-screen read time for all posts in Discourse), number of times it has been bookmarked, number of replies, and so on. You can also expand context above (in reply to) and below (replies) for each post as needed. Or you can expand the collapsed gaps as needed. Try it, you just need a long topic with over 50 replies to see it in action.



Cargo cult programming and Stack Overflow
by Anonymous Coward

I don't mean to minimize StackOverflow's contribution to the online knowledge base, because it's a great tool when used properly. I'm a systems guy and Server Fault is often more useful than vendor support for looking up strange error messages and possible troubleshooting routes. But, there are a lot of low skill programmers and sysadmins out there who lean on these tools way too much. How do you feel about these properties contributing to the crappy cargo cult programming and sysadmin work we see in our field?

Atwood: Stack is a system of peer education at its core. The key insight is realizing that crappy programmers hurt all of us, and it's our job to learn from each other so that we have less terrible code and terrible coders to deal with in the future. Even if that terrible coder is us!

The best way to learn a topic is to teach it to someone else. That is the skill at the heart of the Stack engine. It works at three levels:

1. Selfish. I need the answer to this question or I may get fired. Give me the answer. This is ideally handled through a good search result. They get what they need.

2. Self Improvement. I want to get reputation and prove to my peers that I know what I am doing. The more I learn, the better I am at my job, the more skilled I am, and the more job satisfaction / money / prestige I can gain.

3. Advancement of our craft. Programming, physics, and math will be here long after we are all dead. It's an honor to help move science forward together as much as we can together in our lifetime, so that future programmers, physicists, and mathematicians can stand on our shoulders and do amazing, incredible things for the future of humanity.

It's fine for people to play the game at level one, because they are also helping others learn and work their way up the skill ladder. If someone is learning, and someone is teaching, we all win.



Rampant closure of questions
by WaffleMonster

From time to time I search stackoverflow for easy answers and I would say about 20% of the time the question has been closed even though it is the reason I went to stackoverflow in the first place. In most of these instances a useful answer was also provided before closure. So my question to you is simply what gives.

The most common reason for closure I run into is that the people closing it don't have any domain clue what is being asked and appear to assume if they don't understand nobody else does either.

Another common reason for closure is the "duplicate" question meme in which nuance is overlooked and questions are marked as duplicates because the people doing the marking failed to understand or appreciate the difference. This is very annoying.

Less common but equally annoying issues are closure due to chatter about domain specific algorithms not being "programming questions" or even more amusing someone posting a question that is more specifically addressed by one of a hundred different stack exchanges even though it is still on topic.

Atwood: Remember that Stack is for questions that can be explicitly answered, *not* discussion. It's not a place for "what's the best way to.." opinion sinkholes. Humans love this kind of stuff because they are social animals, and there's nothing wrong with wanting to have a discussion -- you just need to have that discussion elsewhere, because you can't have it on Stack Overflow.

We're strict about this because we've seen what happens when systems are not explicit about their goals. This way lies madness. This way lies Yahoo Answers. In Stack's case the goal is *learning*. And I do not mean accidental, random, meandering, oh-hey-check-out-this-crazy-thing-I-saw-on-Reddit learning, but highly efficient, directed learning where you are a classroom, not a social club.

Duplicates are a hard problem, for sure. That's the one place I felt we didn't make a ton of progress in my four years there, unfortunately. Human beings have the incredibly annoying habit of asking the same questions using completely and utterly different words. They're really good at it. And it is true that over time there are more and more questions and answers on Stack Overflow, so the minefield of "is this a duplicate of...?" is only getting bigger over time. It is a super hard problem. If you have specific ideas of how to handle duplicates better, don't hesitate to ask or search some of the existing topics there.

Remember, Stack Overflow is governed by programmers just like you, you are a citizen of its community just like me, and you get a say in what happens there. You could even be elected a moderator by participating in the yearly elections. So if you don't like the way things work, it's like any other democracy -- make your voice heard, vote, campaign, or run for office.



Relevance of old answers
by Scottingham

As SO ages, some of the offered solutions are no longer valid. Are there currently plans to automate some way of validating old answers automatically? This problem seems to be a larger problem with forums in general. Do you have any musings regarding aging forums?

Atwood: Anyone, even anonymous users, can suggest an edit to any question or answer on any Stack Exchange site. It is like Wikipedia in that regard. Once two other users with sufficient reputation approve the edit it goes through. Alternately, if you earn enough reputation, you can make direct edits yourself.

If you see information that's out of date, edit it to make it more up to date! Be the change you want to see, and all that.



Signal To Noise: Trolls
by Anonymous Coward

In reading your work for years and seeing your various contributions, it seems like you are fascinated with filtering out the most useful information. In many of your blog posts the insight is not yours but rather a conglomeration of chosen useful quotes and sources. I very much appreciate this. My question for you is how do you handle critical feedback vs trolls when dealing with communities. For example, the down button is often a disagree button rather than a negative point. How do you deal with mixed opinions?

To use a real life personal example, TEF noted how he felt you were suggesting that people shouldn't play around to learn. Yet, the way he said it was clearly inflammatory. How do you separate the legitimate concern and critical feedback from the troll who doesn't want to listen to your response?

Atwood: There is a reason we don't have a "dislike" or "downvote" in Discourse. How can an opinion be wrong? It can be rude, offensive, misinformed, misguided, or just plumb crazy -- but it can't be objectively *wrong*. Often the way you judge posts in Discourse is by their *lack* of likes. If nobody feels strongly enough about your reply to push the heart button on it, and 'co-sign' it with their name in public, that says something.

As for separating legitimate criticism from trolling, I don't know that actual trolls, by the strict definition of the word troll, are that common. I think bad faith makes itself quite clear in the tone and delivery of the criticism. Are you saying this in the hope that we can both learn something from the interaction, or are you saying it because you want to hurt or shame or denigrate or discredit me? Truth alone, as it turns out, isn't the whole truth. How you say something matters.

Bad faith is especially visible to the audience, who has no stake in the argument, and can be surprisingly objective in judging authenticity. One of the most striking things about the early days of Stack Overflow was seeing how people would not upvote cruelty. They wouldn't necessarily downvote it, mind you, but overt cruelty and meanness in an answer was never an effective way to get upvotes and reputation even if the technical information was sound. The best way to win an argument isn't to convince the other person, necessarily -- good luck with that -- but to convince everyone who is watching. And you will never convince an audience watching you be cruel to another person.

In life, being cruel to others may achieve some short term goals, but it is *never* a winning long term strategy. And I think that is exactly how it should be.



How do you have a good debate online?
by AmiMoJo

It seems like the internet is mostly a terrible place to have debates. Many forums quickly become echo chambers for people who want to be as offensive as possible just to prove that they can exercise their free speech rights. Other times debates are derailed by cheap tactics like being deliberately offensive to derail the arguments and bog everyone down in accusations that they are "SJWs". Ad-hominems and obvious logical fallacies seem to be the norm.

How do you plan to avoid this happening? So far no-one seems to have found a way.

Atwood: We have a few tricks up our sleeve at Discourse. We try to teach communities not just how the software works, but how human beings should work, with stuff like our Universal Rules of Civilized Discourse which is prominently featured in every install of Discourse and of course Creative Commons licensed.

I believe in the “Just in Time" theory of human behavior where we try to reach you at the exact moment you start typing your first post with the TL;DR version of those rules. And the most important rule of all for empathy is a simple one: hey, there's another person on the other side of that screen. Not just an abstract name, an avatar, a collection of pixels, but a real live human being, just like you.

I don't know if we can weaponize empathy but I'd sure like to try. Not every space has to be open to everyone, unless you work for Facebook or Twitter. Sometimes the point of having your own community is being able to close the door on people who demonstrate that they can't behave themselves in your house. Live with wolves, and you learn to howl.



Stackoverflow in hindsight
by jez9999

In hindsight, would you have reduced the scope of on-topic questions for Stackoverflow to where it's at today when you started the site knowing what you do now, and do you think it would've made the site less popular?

Atwood: Much of the strictness of Stack Overflow evolved as a side effect of the reputation system. Once you have a reputation score, you want to protect that score, and nothing devalues your own reputation more than seeing some other programmer get 300 reputation points from a humorous answer containing nothing but an XKCD comic. Anyone can post an XKCD comic; that takes no particular competence or knowledge. So the evolution in strictness -- peer reputation should come from expression of *skill*, not funny anecdotes -- was largely driven by the community, not by anyone employed at Stack Overflow.

Even knowing what I already knew, which is that putting a number next to someone's name will cause them to do whatever it takes to make that number go up -- I didn't anticipate how strong this effect would be. But ultimately I agree with it, and I think systems should trend to slightly increasing strictness over time as they grow bigger. Big cities have different problems than small cities, and they need more structure.

jones_supa writes: Version 4.0.0 of Mono, the FOSS implementation of the .NET Framework, has been released. This is the first release of Mono that replaces various components of Mono with code that was released by Microsoft under the MIT license. Microsoft itself is working towards .NET Core: a redistributable and re-imagined version of .NET, which has two code drops: CoreFX and CoreCLR. Mono at this point continues to provide an API that tracks the .NET desktop/server version. This means that most of the Mono code that has been integrated from Microsoft comes from the ReferenceSource code drop. Mono's C# compiler now also defaults to C# 6.0.

adeelarshad82 writes "Adobe's principal product manager Mike Chambers announced that Adobe is no longer investing in iPhone-based Flash development. The move comes after Apple put out a new draft of its iPhone developer program license, which banned private APIs and required apps to be written in Objective-C, C, C++, or JavaScript as executed by the iPhone OS WebKit engine. According to Chambers, Adobe will still provide the ability to target the iPhone and iPad in Flash CS5, but the company is not currently planning any additional investments in that feature." Daring Fireball points out approvingly Apple's rebuttal to the claim that Flash is an open format, however convenient it might be for iPad owners. Related: The new app policy seems to be inconsistently enforced. Reader wilsonthecat writes "Novell have released a new press release in response to Apple's announcement that none-C/C++/Objective-C based iPhone application development breaks their SDK terms. The press release names several apps that have made it past app review process since the new Apple SDK agreement."

An anonymous reader writes "Novell has unveiled some of the fruits of its technical collaboration with Microsoft in the form of Moonlight 1.0, a Firefox plug-in which will allow Linux users to access Microsoft Silverlight content. Officially created by the Mono project, it is available for all Linux distributions, including openSUSE, SUSE Linux Enterprise, Fedora, Red Hat and Ubuntu. Also included in Moonlight is the Windows Media pack, with support for Windows Media Video, Windows Media Audio and MP3 files."

An anonymous reader writes "Novell has unveiled some of the fruits of its technical collaboration with Microsoft in the form of Moonlight 1.0, a Firefox plug-in which will allow Linux users to access Microsoft Silverlight content. Officially created by the Mono project, it is available for all Linux distributions, including openSUSE, SUSE Linux Enterprise, Fedora, Red Hat and Ubuntu. Also included in Moonlight is the Windows Media pack, with support for Windows Media Video, Windows Media Audio and MP3 files."

adrian.henke writes "After four years of development, 115K lines of source code, and 6,434 commits, Jonathan Pobst announces that Mono's WinForms 2.0 implementation is now complete. This announcement has been long awaited by any .NET WinForms developer who has ever tried to get an applications to work on Linux using Mono."

Today Microsoft announced the release of Silverlight 1.0 for Windows and Mac OS X. This cross-browser, cross-platform browser plug-in is fully supported and competes directly with Adobe Flash. Included in this release was the promise from Microsoft to support the 100% compatible Linux version, called Moonlight.

DuncanE asks: "We are looking at migrating an old legacy database application to a newer web based framework for the front end. For me the two obvious choices are ASP.net vs Java Server Faces. CodeGuru has side by side look at both, but does anyone have any real world comparisons? ASP.net appears to be MS only, which is a concern, depending on how mature mod_mono has become." Which framework would you prefer to use? Under what situations and conditions would you recommend the use of the other?

jg21 writes "In this opinion piece, Simeon Simeonov contemplates what truly new programming models have emerged recently, and nominates two: RIAs and what he calls 'composite applications' (i.e. using Java, .NET or any other programming language). He notes that Microsoft will be trying to achieve RIAs in Avalon, but that it's late out of the gate. He also cites David Heinemeier Hansson's Ruby on Rails project as showing great promise. 'As both a technologist and an investor I'm excited about the future,' Simeonov concludes. It's a thoughtful piece, infectious in its quiet enthusiasm. But what new models are missing from his essay?"

MxTxL writes "EWeek is reporting here about a plugin for Visual Studio.Net, called Grasshopper, that allows web applications that once only ran on IIS to be run on Tomcat or other J2EE platforms. The Mainsoft Developer Zone has more details on how it works but basically it converts the MS Intermediate Language into Java bytecode. The developer is also a supporter of the Mono Project."

LeninZhiv writes "It's perhaps the most controversial project in the open source world, but this mostly stems from misunderstanding: Mono, the open source development platform based upon Microsoft's .NET framework. Immediate reactions from many dubious Linux developers have ranged from confusion over its connection with .NET to wondering what the benefits of developing under it are. Throughout the course of its four years of intense development, sponsored by Novell, Mono founder Miguel de Icaza has had to frequently clarify the .NET issue and sell the community on it. In this new interview, Howard Wen asks Miguel to explain himself one more time."

Eugenia writes "OSNews posted an article accounting the applications created in GTK# the past 8 months, since the release of Mono 1.0. While many of them are still in their infancy, it's clear that the platform had a healthy progress, with 'super-hits' like Tomboy, F-spot, MonoDevelop, Muine & Blam! and other, less known gems, like SportsTracker, PolarViewer, MooTag, GFax, GIB, Sonance and Bluefunk. The 2.0 version of Mono is expected around May, but the developers advised distros and users to upgrade to Mono 1.1.4 despite being a beta."

spectre_be writes "Davyd Madeley wrote a Sneak Peek at Gnome 2.10, scheduled for release on the March 9, 2005. Looks like the new release-policy is starting to pay of, as several existing utilities get enhancements and a couple of new ones are added. Also (finally) a mozilla-stylee type-ahead find has been implemented in Gnome's Open/Save dialog. Together with OpenOffice.org 2.0's scheduled release and Novell's Mono coming up to speed, will 2005 prove to be the year of Gnome?" Update: 01/18 01:40 GMT by T : Oops - the "2-point" got chopped off in the headline; still a while until GNOME 10.

vertigo writes "I am reasonably proficient in C and C++ as well as the more common scripting languages, but i always felt the lack of a sweet spot between the hard and fast low-level programming languages and the loosely typed scripting languages. Lately, my interest in the Mono project has been growing. The C# language appears to offer just that sweet spot between power and productivity I've been looking for, and its class libraries like Gtk# seem to provide the programmer with a very clean and intuitive API." Read on for vertigo's review of Mono: A Developer's Handbook from O'Reilly. Mono: A Developer's Handbook author Edd Dumbill and Niel M. Bornstein pages 278 publisher O'Reilly Media, Inc. rating 8 reviewer vertigo ISBN 0596007922 summary An introduction to programming with Mono

When learning a new language such as C#, or working with a new development environment such as Mono, it usually takes some time before you get up to speed in developing programs. Wading through the reference documentation and reading other people's source code often provides much-needed information on how to do certain things. Both, however, are very time consuming and tedious.

Enter Mono: A Developer's Notebook. This book provides a series of task-driven chapters which are thin on theory, but rich on practical content and example code. The featured code snippets are, in contrast to ones in books that teach theory and concepts, not solely designed to illustrate a specific theoretical aspect of programming. Each one is designed to perform a useful task that is essential in day-to-day application programming. What sets this book apart from the multitude of .NET books already available on the market? In order to answer this question it is neccesary to provide a short introduction on Mono.

Mono is essentially an open source cross-platform implementation of Microsoft's .NET development framework and implements the API's which are standardized by ECMA. It is, however, not an exact clone. Besides providing a (partially implemented) stack that provides compatibility with Microsoft's .NET API's, Mono adds a whole new API-stack of its own, consisting of open source technologies such as the Gtk+ toolkit and the Gecko HTML rendering engine. This makes it possible to develop cross-platform applications based on open source technology while (mostly) compiling from a single code-base. In contrast to most .NET books available on the market, which focus primarily on Microsoft's API's in the context of Visual Studio.NET, this book concentrates on the basic ECMA API's and Mono's own open source stack. A complete coverage of .NET and the Mono architecture is outside of this review's scope, so for more information you are advised to check the Mono Project's website.

Before we dive deeper into the content of the book, a short introduction on the Developer's Notebook series by O'Reilly may be useful. The books in this series are styled to resemble the kind of notebooks college students carry around during their classes in which to take notes or, more commonly, draw caricatures of their teachers. The 'notebook' theme persists throughout the look-and-feel of the book. The 278-page thick paperback has a glossy blue cover, complete with faux post-it note and coffee-stains. Inside, the pages are not clean white but lined like the pages found in math notebooks. In the margin, useful comments are scribbled in a font that resembles handwriting. At first I suspected that the 'busy' look would distract from the content, but in practice this was no problem, thanks to the thick black typewriter font in which the bulk of the text is printed.

The chapters in this book are referred to as labs. Each of them focuses on a specific set of tasks and/or features and is divided into several paragraphs. Most paragraphs consist of a number of standard sections following a rigid formula that help you understand a certain aspect of working with Mono. The most common sections are:

• How do I do that?: Often using a liberal amount of practical code, this section shows how to accomplish the task at hand, for example working with files.
• How it works: In this section, the code and concepts involved in the previous section are explained more in depth, step by step.
• What about...: Offers a short focus on more advanced topics or pitfalls.
• Where to learn more: If you are craving more information after reading the previous sections, you are often offered a helping hand on where to find more information, providing url's to relevant documentation such as MSDN and other websites.

The first chapter, Getting Mono Running, describes how to get Mono up and running on Linux, Windows or Mac OS X, and how to compile from source on other platforms. The installation instructions for Windows only describe how to install Mono and Gtk#. Integration of Gtk# only in an existing Visual Studio.Net installation falls outside of the scope of the book, but a recent blog entry offers some hints on how to accomplish this. Besides installation, the first chapter offers a short description of the individual tools that make up the mono development. After installation, you will want some kind of editor or IDE to work with. Both the MonoDevelop IDE and several other ways of integrating Mono into your existing environment as a Java or Windows developer are covered. Finally, the community is an important aspect of every open source project. Ways of interacting with the community as well as a guide on how to submit bugs and links to some working Mono/C# applications are part of this chapter.

The C# introduction in the second chapter, Getting Started with C#, is tailored towards people who have at least some proficiency in using an object-oriented language such as C++ or Java. Some differences between C#, Java and C++ are discussed, as well as the differences between value- and reference types, the basics of error handling, working with assemblies and more. Concepts such as classes, methods, inheritance and namespaces are assumed to be known territory. If you have no previous programming experience, Mono: A Developer's Notebook is only useful in combination with a book that teaches programming with C# such as The C# Programming Language by Anders Hejlsberg.

An important part of any modern language is its class libraries. The third chapter, Core .NET, provides an introduction to the standard Framework Library Classes, which describes essential everyday tasks that are part of every program, such as working with files, strings, searching for text patterns and handling collections of data. Besides those basic functions, the chapter also dives deeper into the internals of a compiled assembly, the handling of processes and easy multitasking using threads. Finally, the last paragraph explains how to use a .NET version of the JUnit Java Unit testing framework, Nunit, to test your code.

Developing Gtk-applications with Mono and C# is remarkably easy. Chapter 4, Gtk#, describes the basics of writing Gtk# applications. First, it's neccesary to remark that Gtk# might be a bit of a misnomer. Besides the raw Gtk+ toolkit functionality, Gtk# also includes most of the Gnome libraries like gconf, the gnome canvas, libglade and more. Chapter 4 describes functionality available in the Gtk namespace, the basic Gtk+ toolkit. Gtk+ is a constraints-based toolkit, which means that widgets are not positioned using absolute pixel coordinates but rather on basis of their logical relation to each other. This can be a bit confusing for novices, but this chapter provides a good introduction to the basic principles of writing layouts using Gtk#. The authors provide descriptions of essential operations that almost every application needs, such as creating menus and drawing pixmaps (or more advanced things like using the treeview widget and drag-and-drop), assisted by easy-to-read code snippets.

While chapter 4 introduces basic Gtk# functionality, chapter 5, Advanced Gtk#, delves deeper into more advanced features of the Gtk# library which also include functionality outside of the basic Gtk-namespace, such as the Gnome libraries. Working with Gnome button toolbars, the Glade user interface designer, storing your application settings in Gconf, setting up some preferences through the use of a wizard/druid, asynchronous operations and threading to increase responsiveness of your application while performing background tasks, rendering HTML in your application using the Gecko rendering engine and internationalisation and translation of applications are all described in this chapter.

The use of XML is tightly integrated throughout the Mono framework. It is, for example, the underlying format of the messages that web services use to communicate using the SOAP and XML-RPC protocols. The 6th chapter, Processing XML, describes the XML functionality available in Mono. It starts off by simple operations, reading and writing to an XML-file using relevant examples such as RSS and Dashboard clue-packets. It then proceeds to describe how to modify XML in memory, how to navigate and transform XML using Xpath and XSLT, how to constrain XML in several ways and how to serialize and deserialize objects into and from their XML representation. As in previous chapters, the information density is very high so it might take several reads to grok everything explained. The code examples and accompanying text however are very clear and concise.

The 7th chapter called Networking, Remoting, and Web Services describes the networking functionality available in Mono. The chapter starts off with ASP.NET. Mono's stand-alone XSP webserver and Apache integration with mod_mono are discussed, as well as the basics of writing a web application using ASP.NET's code-behind functionality which enables web applications to completely seperate presentation from the underlying code. Communication using plain tcp/ip, remoting using binary serialized objects and invoking remote procedures using XML-RPC as an alternative to SOAP are also described in this chapter. You might want to encrypt the data you send over the network, so a basic description of the Mono cryptographic API is provided. Finally, a short introduction to database handling using ADO.NET concludes chapter 7.

The 8th and last chapter titled Cutting Edge Mono starts off with an introduction on how to use the GNU Automake, Autoconf and the pkg-config tools to create an easy to build source package of your project. It then proceeds to describe various pitfalls and considerations in case you want to write cross-platform applications using Mono, such as filesystem layout, configuration storage and the calling of native code using p/invoke. A particularly cool project is IKVM, which translates Java bytecode into the Common Intermediate Language bytecode Mono uses. This enables Mono to run Java applications and allows Java and Mono code to inter-operate. A short introduction on the use of IKVM is provided, as well as some code examples on how to call Mono assemblies from Java and use the Java class libraries from within Mono applications. The chapter ends with some other cutting-edge functionality, like how to run a development version of Mono, a preview of the Generics (templates in c++) implementation available as featured in C# 2.0 and how to write Mono programs in Basic.

What is missing? The book doesn't contain a reference section on any of the described API's. If you need detailed information on the C# language specification or an API reference you will need to consult external resources such as the documentation provided with Mono, MSDN, or a separate book covering the topic to make optimal use of the information contained in this book. Fortunately, the book kindly provides pointers on where to find those. The information-density is much higher than you would expect from a book this size. This means the information contained in it is terse. Many topics are treated in a only a couple of pages and the book doesn't take time to explain a lot of programming concepts. The information gets you 'on the road' quickly however, which is exactly what this book is supposed to do.

The strength of this book is that it fills the gap between the earlier-mentioned reference documentation and the need to go out and try to read sourcecode to find out how a particular thing is done. The writing style is clear, concise and neutral. Some topics are clarified by the use of screenshots, which is especially useful in the chapters dealing with Gtk# widgets. All in all, if you are a developer with previous experience in object-oriented programming, Mono: A Developer's Notebook will provide you with an excellent introduction into many of the aspects of working with Mono, its associated libraries and programs.

More information and a sample chapter can be found at the book's homepage.

You can purchase Mono: A Developer's Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

vertigo writes "I am reasonably proficient in C and C++ as well as the more common scripting languages, but i always felt the lack of a sweet spot between the hard and fast low-level programming languages and the loosely typed scripting languages. Lately, my interest in the Mono project has been growing. The C# language appears to offer just that sweet spot between power and productivity I've been looking for, and its class libraries like Gtk# seem to provide the programmer with a very clean and intuitive API." Read on for vertigo's review of Mono: A Developer's Handbook from O'Reilly. Mono: A Developer's Handbook author Edd Dumbill and Niel M. Bornstein pages 278 publisher O'Reilly Media, Inc. rating 8 reviewer vertigo ISBN 0596007922 summary An introduction to programming with Mono

When learning a new language such as C#, or working with a new development environment such as Mono, it usually takes some time before you get up to speed in developing programs. Wading through the reference documentation and reading other people's source code often provides much-needed information on how to do certain things. Both, however, are very time consuming and tedious.

Enter Mono: A Developer's Notebook. This book provides a series of task-driven chapters which are thin on theory, but rich on practical content and example code. The featured code snippets are, in contrast to ones in books that teach theory and concepts, not solely designed to illustrate a specific theoretical aspect of programming. Each one is designed to perform a useful task that is essential in day-to-day application programming. What sets this book apart from the multitude of .NET books already available on the market? In order to answer this question it is neccesary to provide a short introduction on Mono.

Mono is essentially an open source cross-platform implementation of Microsoft's .NET development framework and implements the API's which are standardized by ECMA. It is, however, not an exact clone. Besides providing a (partially implemented) stack that provides compatibility with Microsoft's .NET API's, Mono adds a whole new API-stack of its own, consisting of open source technologies such as the Gtk+ toolkit and the Gecko HTML rendering engine. This makes it possible to develop cross-platform applications based on open source technology while (mostly) compiling from a single code-base. In contrast to most .NET books available on the market, which focus primarily on Microsoft's API's in the context of Visual Studio.NET, this book concentrates on the basic ECMA API's and Mono's own open source stack. A complete coverage of .NET and the Mono architecture is outside of this review's scope, so for more information you are advised to check the Mono Project's website.

Before we dive deeper into the content of the book, a short introduction on the Developer's Notebook series by O'Reilly may be useful. The books in this series are styled to resemble the kind of notebooks college students carry around during their classes in which to take notes or, more commonly, draw caricatures of their teachers. The 'notebook' theme persists throughout the look-and-feel of the book. The 278-page thick paperback has a glossy blue cover, complete with faux post-it note and coffee-stains. Inside, the pages are not clean white but lined like the pages found in math notebooks. In the margin, useful comments are scribbled in a font that resembles handwriting. At first I suspected that the 'busy' look would distract from the content, but in practice this was no problem, thanks to the thick black typewriter font in which the bulk of the text is printed.

The chapters in this book are referred to as labs. Each of them focuses on a specific set of tasks and/or features and is divided into several paragraphs. Most paragraphs consist of a number of standard sections following a rigid formula that help you understand a certain aspect of working with Mono. The most common sections are:

• How do I do that?: Often using a liberal amount of practical code, this section shows how to accomplish the task at hand, for example working with files.
• How it works: In this section, the code and concepts involved in the previous section are explained more in depth, step by step.
• What about...: Offers a short focus on more advanced topics or pitfalls.
• Where to learn more: If you are craving more information after reading the previous sections, you are often offered a helping hand on where to find more information, providing url's to relevant documentation such as MSDN and other websites.

The first chapter, Getting Mono Running, describes how to get Mono up and running on Linux, Windows or Mac OS X, and how to compile from source on other platforms. The installation instructions for Windows only describe how to install Mono and Gtk#. Integration of Gtk# only in an existing Visual Studio.Net installation falls outside of the scope of the book, but a recent blog entry offers some hints on how to accomplish this. Besides installation, the first chapter offers a short description of the individual tools that make up the mono development. After installation, you will want some kind of editor or IDE to work with. Both the MonoDevelop IDE and several other ways of integrating Mono into your existing environment as a Java or Windows developer are covered. Finally, the community is an important aspect of every open source project. Ways of interacting with the community as well as a guide on how to submit bugs and links to some working Mono/C# applications are part of this chapter.

The C# introduction in the second chapter, Getting Started with C#, is tailored towards people who have at least some proficiency in using an object-oriented language such as C++ or Java. Some differences between C#, Java and C++ are discussed, as well as the differences between value- and reference types, the basics of error handling, working with assemblies and more. Concepts such as classes, methods, inheritance and namespaces are assumed to be known territory. If you have no previous programming experience, Mono: A Developer's Notebook is only useful in combination with a book that teaches programming with C# such as The C# Programming Language by Anders Hejlsberg.

An important part of any modern language is its class libraries. The third chapter, Core .NET, provides an introduction to the standard Framework Library Classes, which describes essential everyday tasks that are part of every program, such as working with files, strings, searching for text patterns and handling collections of data. Besides those basic functions, the chapter also dives deeper into the internals of a compiled assembly, the handling of processes and easy multitasking using threads. Finally, the last paragraph explains how to use a .NET version of the JUnit Java Unit testing framework, Nunit, to test your code.

Developing Gtk-applications with Mono and C# is remarkably easy. Chapter 4, Gtk#, describes the basics of writing Gtk# applications. First, it's neccesary to remark that Gtk# might be a bit of a misnomer. Besides the raw Gtk+ toolkit functionality, Gtk# also includes most of the Gnome libraries like gconf, the gnome canvas, libglade and more. Chapter 4 describes functionality available in the Gtk namespace, the basic Gtk+ toolkit. Gtk+ is a constraints-based toolkit, which means that widgets are not positioned using absolute pixel coordinates but rather on basis of their logical relation to each other. This can be a bit confusing for novices, but this chapter provides a good introduction to the basic principles of writing layouts using Gtk#. The authors provide descriptions of essential operations that almost every application needs, such as creating menus and drawing pixmaps (or more advanced things like using the treeview widget and drag-and-drop), assisted by easy-to-read code snippets.

While chapter 4 introduces basic Gtk# functionality, chapter 5, Advanced Gtk#, delves deeper into more advanced features of the Gtk# library which also include functionality outside of the basic Gtk-namespace, such as the Gnome libraries. Working with Gnome button toolbars, the Glade user interface designer, storing your application settings in Gconf, setting up some preferences through the use of a wizard/druid, asynchronous operations and threading to increase responsiveness of your application while performing background tasks, rendering HTML in your application using the Gecko rendering engine and internationalisation and translation of applications are all described in this chapter.

The use of XML is tightly integrated throughout the Mono framework. It is, for example, the underlying format of the messages that web services use to communicate using the SOAP and XML-RPC protocols. The 6th chapter, Processing XML, describes the XML functionality available in Mono. It starts off by simple operations, reading and writing to an XML-file using relevant examples such as RSS and Dashboard clue-packets. It then proceeds to describe how to modify XML in memory, how to navigate and transform XML using Xpath and XSLT, how to constrain XML in several ways and how to serialize and deserialize objects into and from their XML representation. As in previous chapters, the information density is very high so it might take several reads to grok everything explained. The code examples and accompanying text however are very clear and concise.

The 7th chapter called Networking, Remoting, and Web Services describes the networking functionality available in Mono. The chapter starts off with ASP.NET. Mono's stand-alone XSP webserver and Apache integration with mod_mono are discussed, as well as the basics of writing a web application using ASP.NET's code-behind functionality which enables web applications to completely seperate presentation from the underlying code. Communication using plain tcp/ip, remoting using binary serialized objects and invoking remote procedures using XML-RPC as an alternative to SOAP are also described in this chapter. You might want to encrypt the data you send over the network, so a basic description of the Mono cryptographic API is provided. Finally, a short introduction to database handling using ADO.NET concludes chapter 7.

The 8th and last chapter titled Cutting Edge Mono starts off with an introduction on how to use the GNU Automake, Autoconf and the pkg-config tools to create an easy to build source package of your project. It then proceeds to describe various pitfalls and considerations in case you want to write cross-platform applications using Mono, such as filesystem layout, configuration storage and the calling of native code using p/invoke. A particularly cool project is IKVM, which translates Java bytecode into the Common Intermediate Language bytecode Mono uses. This enables Mono to run Java applications and allows Java and Mono code to inter-operate. A short introduction on the use of IKVM is provided, as well as some code examples on how to call Mono assemblies from Java and use the Java class libraries from within Mono applications. The chapter ends with some other cutting-edge functionality, like how to run a development version of Mono, a preview of the Generics (templates in c++) implementation available as featured in C# 2.0 and how to write Mono programs in Basic.

What is missing? The book doesn't contain a reference section on any of the described API's. If you need detailed information on the C# language specification or an API reference you will need to consult external resources such as the documentation provided with Mono, MSDN, or a separate book covering the topic to make optimal use of the information contained in this book. Fortunately, the book kindly provides pointers on where to find those. The information-density is much higher than you would expect from a book this size. This means the information contained in it is terse. Many topics are treated in a only a couple of pages and the book doesn't take time to explain a lot of programming concepts. The information gets you 'on the road' quickly however, which is exactly what this book is supposed to do.

The strength of this book is that it fills the gap between the earlier-mentioned reference documentation and the need to go out and try to read sourcecode to find out how a particular thing is done. The writing style is clear, concise and neutral. Some topics are clarified by the use of screenshots, which is especially useful in the chapters dealing with Gtk# widgets. All in all, if you are a developer with previous experience in object-oriented programming, Mono: A Developer's Notebook will provide you with an excellent introduction into many of the aspects of working with Mono, its associated libraries and programs.

More information and a sample chapter can be found at the book's homepage.

You can purchase Mono: A Developer's Handbook from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

troop23 writes "A blog posting by Benjamin J. J. Voigt says this "The University of Potsdam has a project to develop a .NET VM for the Lego Mindstorms system. Lego Mindstorms just got a higher priority on my shopping list!" While the thought of using .Net to program Lego Mindstorms may not be palatable, having a mainstream dev environment sure is." Perhaps Mono would work just as well.

Gentu writes "OSNews posted some exclusive screenshots of a new project in the Mono community: Cocoa#. Apparently there are a couple of Apple engineers helping out the project that allows developers to create graphical Cocoa applications under Mac OS X using the C#, Python or Basic language. Mono seems to be doing well in the Windows land too, allowing developers to use GTK# instead of Windows.Forms to create multi-platform apps."

Gentu writes "OSNews posted some exclusive screenshots of a new project in the Mono community: Cocoa#. Apparently there are a couple of Apple engineers helping out the project that allows developers to create graphical Cocoa applications under Mac OS X using the C#, Python or Basic language. Mono seems to be doing well in the Windows land too, allowing developers to use GTK# instead of Windows.Forms to create multi-platform apps."

prostoalex writes "Technology Review has a feature story on Miguel de Icaza, currently Novell VP of Product Technology, but more known as the leader of Gnome and Mono projects. Miguel is the man Don Box would like to see joining Microsoft for his "amazing amount of raw energy". If you read through the Technology review article, you will see that de Icaza was actually turned down by Microsoft at some point."

Sunspire writes "IronPython, a Python implementation for the .NET and Mono platforms, has just released its latest version, IronPython-0.6. Touted features include speed, with IronPython being supposedly faster than the native C version of Python, and CLR integration giving full access to the .NET and Mono libraries while still being fully dynamic like regular Python. Is Python, Mono and GTK# the new killer combo for rapid Linux desktop application development?" We previously covered IronPython back in May.

theblackdeer writes "Just poking around the go-mono.com Mono website; it's now the multi-colored mono-project.com. Even better, it updated before my eyes to include the 1.0 release. Screenshots are (slightly) updated, too. Mono 1.0 includes the Mono Develop IDE (based on SharpDevelop, I believe). Download now and start your GTK# engines!" Alliante adds "You can download the Release Notes and the Packages on their website."

theblackdeer writes "Just poking around the go-mono.com Mono website; it's now the multi-colored mono-project.com. Even better, it updated before my eyes to include the 1.0 release. Screenshots are (slightly) updated, too. Mono 1.0 includes the Mono Develop IDE (based on SharpDevelop, I believe). Download now and start your GTK# engines!" Alliante adds "You can download the Release Notes and the Packages on their website."

theblackdeer writes "Just poking around the go-mono.com Mono website; it's now the multi-colored mono-project.com. Even better, it updated before my eyes to include the 1.0 release. Screenshots are (slightly) updated, too. Mono 1.0 includes the Mono Develop IDE (based on SharpDevelop, I believe). Download now and start your GTK# engines!" Alliante adds "You can download the Release Notes and the Packages on their website."

steve_deobald writes "The Mono team just released Beta 3, the final beta before we see the 1.0 release candidate and final. Binary packages can be had for Red Hat, Fedora, and SuSE. Although not officially released, the new website is up and running. Also of note, MonoDevelop 0.4 was recently released, and has RPMs available for the first time."