sjh - mountain biking running linux vegan geek spice - mtb / vegan / running / linux / canberra / cycling / etc

Steven Hanley hackergotchi picture Steven
Hanley
About

email: sjh@svana.org

web: https://svana.org/sjh
twitter: https://twitter.com/sjhmtb
instagram: https://instagram.com/sjhmtb

Other online diaries:

Aaron Broughton,
Andrew Pollock,
Anthony Towns,
Chris Yeoh,
Martijn van Oosterhout,
Michael Davies,
Michael Still,
Tony Breeds,

Links:

Linux Weekly News,
XKCD,
Girl Genius,
Planet Linux Australia,
Bilbys,
CORC,

Canberra Weather: forecast, radar.

Subscribe: rss, rss2.0, atom

←November→
Mon Tue Wed Thu Fri Sat Sun
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

←2024→
Months
Jan Feb Mar
Apr May Jun
Jul Aug Sep
Oct NovDec

Categories:

Archive by month:

Mon, 25 Feb 2008

API design and error handling in code - 21:12
I am catching up on some posts on planet Gnome and I came across this post about error handling with g_malloc and a response agreeing with it. I find this interesting for a few reasons.

First it is true that putting in full error handling in code when using fairly standard libraries can take a lot of time, complexity and ugliness. However there should be some way somewhere to find out if errors happened I suggest, largely so you can deal with them if there is a situation they may be likely. Also understanding that libraries can fail in calls and what this means is important for coders, even if they do not handle them all. When marking assignments at uni I am keen to see that students have thought about error conditions and made the decision about what level of complexity to trade off against what likleyhood certain errors have of occurring.

The above issue with assignments however does tend to be students who are newer to programming than most free software hackers so there are considerations in both directions there. As for the other reason the above posts interest me, it is cool to see Cairo getting such props for great design again. Carl and co have done a stellar job with that library.

As I continue reading the planet I can see more entries in the thread.

[/comp/design] link

Thu, 01 Dec 2005

Open source cookie design attempt, what they missed - 17:44
Malcom Gladwell as is often the case can write a good article, this article I found linked from kottke concerns an attempt to develop a great diet cookie using a few different software development methodologies. On the whole the article is interesting to see an attempt at applying software development methodologies (eXtreme Programming, Cathedral, and Bazaar) to another problem space/industry. From my reading of the article I believe they misapplied the open source model to a large extent.

Gladwell is a great author and often writes interesting and entertaining articles as I have noted in the past on occasion, however coming from an open source geek perspective there are obvious points missed here that show how the open source methodology could have been better applied. For example the quote "Linus Torvald, the Norwegian hacker" shows two problems, Linus' surname has an s, and Linus originates from Finland. The guy who ran this multi methodology project, Steve Gundrum, got off on the right foot, talking with Mitch Kapor as to the viability of applying the open source methodology to this new problem space, however I would suggest the team established did not operate in the manner teams on successful open source projects tend to.

They established a team for the open source group by inviting 15 well known specialists in the related food industry to be involved and make suggestions that would be implemented by Gundrum's company. Asking these people to design the cookie in effect. During the project, when some arguments or difficulties arose there was no dispute arbitration mechanism or established way to make a final decision. Also no one was actually elected as a benevolent dictator, without one or both of those mechanisms I am not surprised the project suffered and many people involved came out of it not particularly happy with the results.

Using the Linux kernel as an example again I think a few things they missed are, lack of benevolent leader, a dispute arbitration mechanism based on something akin to show me the code, ie coming up with ideas or suggestions is not sufficient, it needs to be implemented, tested and proven to work in a satisfactory manner, also some specific specialising in areas may have helped, especially with such a large team. Looking at the goals of the project and dividing up components such that people who may better work on those aspects could have more control over them. However I think one of the biggest failings was the scratch an itch component of free software or passion for it. This project though possibly interesting to those involved was unlikely to inspire passion from them. A combination of technical ability and the passion for the project really does provide a lot of the groundwork for success in the open source world. Even those people paid full time to work on open source are generally still passionate about their work (Linus, Tridge, Rusty, Anton, etc).

The article does mention some of Joel Spolsky's (of Joel on Software) reservations about open source development, and admittedly they could be relevant, however they could also be disputed. The argument about lack of innovation and simply following the herd would be disputed I suggest by looking at the innovation happening in given problem spaces in open source. Some of the desktop software such as amaRok, f-spot or the gstreamer based Fluendo (admittedly this is a company, however it is open source development with Flumotion) are all doing things way ahead of and more interesting than other entries in that problem space worldwide. Sure there are problems that do not mix well with open source development, but a simple argument being made that there is no innovation in the open source would I think is quite narrow minded.

Looking at how close the open source cookie was in second place I suspect that with a better understanding of the methodology and applying it with a group of people that fit well to that mechanism would have somewhat improved results.

[/comp/design] link

Tue, 01 Mar 2005

How many programmers can you fit in a telephone booth? - 19:06
A few months ago Michael Davies wrote about the Fog Creek (Joel on Software) office design. The premise for Fog Creek was, they want to attract and keep the best and brightest programmers, thus they went to the effort of creating office space that would entice these people.

Today Mikal commented "It's impossible to work in a cubicle." suggesting that offices really do help a programmer with their work. I should admit one of the reasons I really like working at a University is they give you an office, Michael has an office here also, as a PhD student, however he does not have one at work as a senior software engineer.

Anyway this all ties in in an interesting manner also to something Lars Wirzenius wrote about recently. Having just read an IBM paper from 1978, "IBM's Santa Teresa Laboratory -- Architectural design for program development" (google can display an html version if you wish), Lars commented on how much it sucks that employers do not seem to think about the environment for programmers as much today as they did then.

I admit it does seem to lack sense for software companies, that base their business on producing good software (well one would hope they do that, though many do not appear to make that a primary goal) would forgo this sort of office plan so often. Michael Davies and Michael Still (both of whom I know personally and respect) both seem to agree with the ideas presented in the IBM paper or by Joel, I wonder how many others agree?

Oh and apparently some people have no idea where I got the title of this diary entry from. You obviously never participated in Telephone booth stuffing.

[/comp/design] link

Thu, 23 Dec 2004

Over designing standards - 22:55
Recently at some XML conference (XML Dev Con 2004) Tim Bray from Sun spoke about standards design. After my complaints yesterday concerning complex standards this seemed somewhat appropriate. In his presentation Bray said something along the lines of "Whenever people are complaining that a standard is too simple for their application, that's a good indication that the standard is going to be a hit" (source). He was also quoted as saying "If you don't have an urgent burning requirement for things right now. You ain't going to need it. Failed standards have too much stuff in them." (source)

Both these are relevant, both to standards design and simply to programming. Do not do premature design or try to design for features you imagine you may one day want to use. Extreme Programming though of course simply another selection of tools in the programmers toolbox (and not the second coming as some people seem to think) does have some good points. One of which is the avoidance of premature design or coding for "future" features. The ACAP standards yesterday struck me as over engineered for a few basic things to attach to IMAP, using my example of the need for an address book that is accessible with your email. If an email client was to implement an address book functionality in ACAP, it would still need to decide on the format of the address book data in ACAP, and other clients would need to implement this and agree on this also.

Anyway back to the subject of conferences, Rory was covering the XML conference in an amusing manner, and at one point for example paid quite a lot of attention to the shoes worn by a speaker. The shoes a speaker wears are obviously important and must be blogged or covered in some way at conferences. For linux.conf.au we will obviously need to ensure there is online coverage of what shoes speakers are wearing. Mikal will I am sure be keen to self nominate for this task of telling the world about the speakers shoes, even uploading some photographs of their shoes maybe. Lets hope the speakers understand and do not become too freaked out by this behaviour.

[/comp/design] link

Thu, 30 Sep 2004

Creative process of design - 18:06
While looking around at various blosxom plugins I found a link to warpedvisions as this person had some interesting blosxom plugins. Reading through some of their other entries I have decided I should read this blog regularly. Mostly due to their comments on design as a creative process when discussing Blog Zen.

Quoting from the entry

I just have to let the ideas percolate until my subconscious orders them, filtering it all into something better. This is how I've always done design, it just happens that Bradbury uncovered the mechanics of it for me. Forced design is why a lot of software is bad, that and all the compromise added to it. Well, there are probably other reasons commercial software sucks, like honesty and integrity, but that's not the point.

Bradbury also harps on the fact that he writes (and reads) endlessly, which is how he feeds his subconscious. He's right: that's how creativity works, it needs to be fed and cared for. I never realized it, but that's how my design process works, as it's really a creative force (versus a pedantic force). Pedantic may be the wrong word, but when designers attack a problem from the meticulous, anti-creative angle, the result is not cohesive -- and is often forced beyond the workable.

[/comp/design] link

home, email, rss, rss2.0, atom