It’s cool to see some of the UI enhancements coming to the Linux desktop. Seth Nickell has a writeup – including screenshots and (more importantly) videos.
Another OS has hardware accelerated graphics, and whilst it’s not something that’s going to sell an OS, it’s certainly (very attractive) icing on the cake.
The other day I mentioned Boo (still not sure on the capitalisation). Now Ed Dumbhill (one of the guys behind Mono: A Developers Notebook) has voiced his disappointment with the recent IronPython 0.7 release – particularly the seemingly closed development process and the fact that it doesn’t work with Mono – then goes on to extol the virtues of Boo.
Looks like I found Boo at the right time…
Web projects in Visual Studio .NET can be be a real pain. They’re linked with the virtual directory they’re running in, which make sharing projects harder work. It also means that a) your solutions are created in C:\Inetpub\wwwroot (unless you create your virtual directory first) and b) you can’t open your solution unless IIS is running. Not good.
This is – of course – another way.
I’ve seen various articles on converting Class Libraries into Web Projects (and vice versa), but Fritz Onion has prepared a good piece on how to do it.
Someday I’ll actually get round to trying this…
Found this via Robert MacEwan. It appears there may be be some problems with packaging Mono on Debian that may not get resolved in the near future.
I guess us debianites will just have to continue using the source…
While I’m thinking about it though, Ubuntu is managing to package Mono, so is Debian being too picky? I don’t really know enough about it so I’ll shut up now.
…did I scare you?
I’ve been aware of del.icio.us for quite a while now, but I’ve not really used it. Aq’s post about using it prompted me to look at it again, and I’m finding myself using it a lot now – especially thanks to the Firefox extension.
As well as posting my own bookmarks (go on, see if you can guess my username) I find it useful to browse some of the tag feeds – I’ve got several tags and users feeds listed in Bloglines.
Whilst browsing the Mono tag feed I came across BOO which describes itself as:
Boo is a new object oriented statically typed programming language for the Common Language Infrastructure with a python inspired syntax and a special focus on language and compiler extensibility.
It looks interesting, to say the least. Syntactially similar to Python but designed for the CLI. Go take a look at the mainfesto, language features and some recipes.
It’ll be interesting to see what some of my python loving friends make of the language. I know there is IronPython, but BOO is a new implementation – not adapting the old to fit the new.
Another thing to add to my (never ending) to-do list!
Aq. has more comments on my post about Bob’s hero post but I still don’t think he gets it1.
It has nothing (directly) to with the tools. Large, complex applications can be written with other languages/frameworks, but inversely .NET can be used to write small, simple applications. The main thing is that .NET encourages you to write large, complex applications. All of the articles, help etc. are geared towards n-tier design and interoperability. Once you get into this frame of mind it can be difficult to see the wood for the trees – you’re so focused on implementing things properly that you forget to do it simply.
The reason that Bob thinks Frank is a hero is not because he does wonderful things with non .NET technologies, but because he does them any technologies at all. Frank focuses on what makes makes his applications good rather than what makes an good application.
People in the .NET world rave about .Text because of it’s design. When I looked at it I found it overly complex. The same is true of FlexWiki – good, but too damn complex! They may be excellent pieces of application design, but I find them to be over-engineered.
At the other end of the scale… I wrote a wiki the other day in C# (running on Mono) in Vim, via a SSH connection to my Linode. It weighs in at 183 lines, of which about half are blank (I like clean code me).
Yes, yes I know it’s not going to win a prize for being the shortest wiki – it doesn’t even attempt (yet) to obey all of the “Wiki Principles”http://c2.com/cgi/wiki?WikiPrinciples but it works and that’s what’s important. I’ve written smaller apps, and I’ve written much bigger apps, but my point is that C#/.NET/Mono does not force me choose either.
This is where the .NET and Mono communities can help each other. .NET has a doctrine of n-tier and enterprise level applications, whilst the Mono guys are coming from the UNIX background of lots of small, interconnected tools. The .NET guys can help Mono in the enterprise arena, and the Mono guys can help .NET developers think about simplicity.
1 Except of course he does (see “here:http://www.kryogenix.org/days/2005/03/21/aspnet#au1111596084.32 as well), but I felt the rest of the post was too good to discard.
Found this on O’Reilly’s ONDotNet.com:
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.
It’s an interesting read.
Bob Reselman (The Coding Slave guy) has a post entitled Who’s a new hero? where he descibes Frank, the other developer at his current employer. Frank is the kind of guy who gets things done with very limited resources. He was also the only developer before Bob got there.
It’s my own fault for point the post out to him, but Aq blames the tools and not the person wielding them. Bob’s post is neither a criticism of .NET nor an endorsement of other tools – I’m disappointed Aq chose to interpret it that way.
My take on this is that Bob is (probably) used to developing larger scale applications and hence much more likely to be bogged down with all the trappings that come with such projects: requirements, reviews etc. Frank is probably used to working much more loosely. If Frank chose to use .NET he may be even more productive, and if Bob designed the solution with Frank’s toolset in mind he may find his solutions simpler.
Of course if you forced .NET on Frank and stopped Bob from using it the productivity of both would go down the drain.
Short post pulling together some bit & peices surrounding the new Xbox…
Xbox.com are providing video and audio (MP3, WMA) feeds of J Allard’s keynote address. They’ve also got a demo video and screenshots of the Xbox Guide – what appears to be a common interface to Live, media and other content which will be available regardless of the game you are currently playing.
Gamespy have been gleaning information from GDC attendees & developers, and have posted (purely speculative, but interesting nonetheless) information about the hardware and Live integration and Gamer Profiles.
Gamer Profiles sound cool from a configuration point of view – it’s frustrating to have to set your name and control preferences for each game. I also like the idea of the gamer achievements as it proves you’ve done what you claim to.
Joystiq have a photo of what they reckon the new hardware will look like. Engadget refute this, citing a trusted source that this is a prototype. Seeing as the photo corresponds with an earlier Engadget posting, it certainly looks legitimate even if it’s not the final hardware.
Not sure about the handle, but it’s certainly not as ugly as the original PS2 or even the original Xbox.
Personally, based on the comments coming from Microsoft about how they see the next Xbox as being part of the whole home media experience, I’d expect it to be more DVD player looking than this design, but seeing as there’s some weird and wonderful looking DVD players out there who knows…
Tycho from Penny Arcade says:
More interesting even than the raw numbers are the policies they plan to implement for developers, which they suggest are things like compulsory live functionality, custom soundtracks, widescreen, and 720p.
…and he’s got it dead right. I’ve commented in the past how much I like Xbox Live, but since then I’ve grown frustrated with the way that each game implements it slightly (sometimes completely) differently. Don’t get me wrong – the service is still great, it’s just not consistant depending on the game you are playing. The same was true for custom soundtracks – great idea but too few games implemented it. If they can enforce these policies successfully, then it will be great for gamers.
I’ve started working on a few OSS projects of my own – one’s in the planning stage and another is in the code-now-plan-later stage – and it got me thinking…
When should you start talking about your projects?
I know that the OSS philosphy is to “release early, release often” but how soon is too soon?
Take the project that’s still in planning – if I start talking about it now, others may contribute to the planning and help make a better end-product. On the other hand, it may get so involved trying to satisfy all the contributors that we never get round to writing a single line of code – look at all the DBA projects on SourceForge. Another problem is that whoever is contributing may have a very different idea of how things should be, which is at odds with your original idea and may lead to you losing interest in what is (or rather now was) your project.
Now take the second project I mentioned, which currently exists purely as proof-of-concept, and has no real plan other than seeing if my (extremely rough) ideas pan out. With a bit more work, it will be at the stage where I can start letting people play with it, and then comes the problem with the code-now-plan-later strategy – what do I really want it do?
Here’s my take on things…
Ask yourself this question:
Only start a project if it is something you really want to do. Not because you think others will use it or do the work for you.
Now you need to…
If you’re got an itch, write down some ideas before you scratch it. It doesn’t matter how pretty or well laid out they are – you don’t need a complete requirements document here, just as rough idea of where you’re going. In Mike Gunderloy’s book Coder To Developer he describes the idea of the Elevator Pitch – essentially describing your idea in as brief, but complete (and compelling) way as possible. We’re not talking a one-liner here, but simple, brief bullet points that describe the main reasons the software should exist. Not “Create a new IM client”, but “Create a new IM client that supports A/B/C protocols, and X/Y/Z features”. The original idea behind the Elevator Pitch is that you only have a thirty second or so ride to sell your idea, but you should also see it as an opportunity to define an initial vision or (shudder) mission statement for the project – something that instantly gives people an idea of what you are trying to achieve and something you can refer back to when you feel you’re drifting off course.
Now it’s time to…
Now you know exactly what you’re trying to achieve, you’ve got two options:
If you’re an organised person (I’m not, though I’d like to be) you’ll prefer the first option, but most people will take the second. That’s fine, just make sure that a) you’re still focusing on your original idea and b) you’re not getting distracted by implementation details. The main disadvantages to coding before planning are that you’ll rarely create the plan (as there’s far more interesting things to do), and if you do, you’ll most likely discover that you could have done things much better so you then have to go back and change things. You’re also far more likely to become of victim of feature creep. This is different from scope creep where the requirements keep expanding – this where you’re adding features to the project without any clear idea of how they or evn if they fit in with your original idea.
Of course, the best advice is to do both – plan and implement your application at the same time. The secret to doing this successfully is to keep them in sync – don’t let your coding get ahead of the plan, and don’t neglect the code to fine-tune details that may get discarded or prove unfeasible during implementation.
Unless you’ve got an idea that you really have no idea how to implement, work by yourself (or with one or two others, but make sure they are people you can work with – not strangers in IRC or on a mailing list) and quietly until you’ve got something people can play with. If during this time you discard the project, then you’ve not wasted anyones time but your own. Once you’ve got something tangible, then release it to the world and (hopefully) start taking contributions.
My final piece of advice is that if others are contributing to your project, don’t ignore them or the project. People will only contribute as long as they feel their contributions are being paid attention to. Even if someone propose a feature that you don’t want to use, let them know why – don’t just discard it.
If – at a later date – you are no longer interested in the project, either let someone else maintain it or let people know it is no longer maintained.
So, in a nutshell – don’t talk about your projects until there is something to see/feel, and don’t neglect your project once it has been released.
Although I’ve really been talking about OSS projects here, the same ideas about the “Elevator Pitch” and simultaneous planning & implementation can be applied to proprietary/commercial projects. I make extensive use use of the latter in my day job, and when done properly works very well. Obviously it doesn’t suit all projects, but for smaller applications it produces results far quicker than traditional methodologies.
If you’re looking for a tool to help you achieve this, look no further than Trac. It’s tight integration of the wiki, Subversion, and tickets makes for a very organic development process, and allows easy maintenance of the plans and documentation by all members of the development team. Again this is a professional recommendation as I use it to manage all of my projects in my day job, as well as a few of my personal/professional projects.