Monday, November 21, 2005

Apple hardware resell value

In case you didn't believe that Apple hardware keeps its value, head over to craigslist where everything is super cheap and you can even get a Piano's for free, but the Apple hardware still sells for a more then fair price. So next time you buy a whole new computer to run Linux it probably would be well worth your investment to pick up an Apple computer. With Apple soon to sell x86 hardware, spending a little more now for the Apple logo means you can re-sell it for way ($500+ easily) more in two years then x86 hardware which seems to depreciate like cars (the moment you own it it is worth 1/2 as much used and only goes down). If Windows ran fine on the new Apple hardware it would be interesting to see if lease companies leased Apple hardware (to run Windows) for a lot less then Dell hardware because they can actually resell it for a good chunk of change after the three years is up.

Wednesday, November 16, 2005

Type Managers and KDE

Today was a fun day. The past week I have been putting together an article on Type Managers. The article was really meant for here as a blog entry, but it grew and grew and I ended up making a full article that I put on my website. After debating the name over and over I finally kept it the way it was. Just to see if it would get accepted I submitted it to Slashdot and hey cool it was accepted. :) Type Manager on Slashdot. Putting it up on Slashdot is a fun test of my website. I made a static html page and had Apache temporarily forward the php page to the html page. The server seemed to survive just fine. What makes this even more interesting is that I signed up for Google Analytics the other day so I eagerly await to see what amusing stats it gives me tomorrow. Over on Slashdot most people (like normally there) didn't care to discuss the idea, but liked to talk about how the name was a bad choice or that it was obvious. My feelings aren't hurt though sense they weren't my primary target and I got to test out some of my website stuff in the process. Now, done with the /. part of this post and on onto the real part. The reason I wrote the article was for you, the KDE developers.

Those on kdedevelopers.org might have noticed some similar polls the last few weeks asking about managers that they use. Such as How do you manager your music more then %60 use amarok and another 15% use Juk or iTunes. When I asked about photos similar results for digiKam. So people on /. can yell all they want about managing there files only on the filesystem, but that is your fringe user. I use KMail to manage e-mail, Juk for music, digiKam for photos, and akregator for rss feeds. When I used aKregator and iTunes for the first time I knew that I was seeing something special even if I couldn't put my finger on it then. Putting together the article on type managers was very interesting. For example *today* Konq meets most of the file manager spec that I put together, but you wouldn't know about half of the features because the interface is so cluttered. A number of us in the last six months have discussed separating Konq the file manager and Konq the all in one viewer/web browser. Putting together this article solidifies my belief that this is the right direction to take Konq (the file manager).

The article isn't just for Konq, KMail, amarok, and digiKam. There are many other Type Manager applications in KDE such as akregator and kdevelop. One of the original goals of the article was to make the list of features that a type manager should have. This way KDE applications that are type managers can see the list and understand what they are missing that would really benefit their users.

Juk has excellent meta editing and does a fantastic job of separating the file system from the user, and it has a good search interface, but it doesn't have the import export functionality like amarok has. Could this be why amarok is doing better? It is almost the opposite with amarok. amarok has good search, import and export, but not good abstraction or as good meta editing (in my personal opinion). I have said this before, but just to reiterate here I plan on integrating audiocd into Juk and amarok and once that is done i'll move KAudioCreator into extragear and perhaps retire it.

There are other Type Managers that KDE doesn't have at all. We don't have a movie manager that I know of. There are a number of movie tools such as dvd ripper, encoding, transcending, burners, and so on. You can probably think of a few more Type Managers that KDE doesn't have (add to the comments). So if you are looking to make a KDE application here might be a perfect idea to tackle.
One thing I noticed when looking around is that you don't want to call your Type Manager a manager on your website. Users don't want to manage music, they want to play with their files! That is why iTunes is a Music Jukebox and iPhoto is a photo organizer. The name of your Type Manager shouldn't include "Manager" in its name nor should you use the word manager when describing your application for end users on your website :)

Another feature that is very KDE specific has to do with the last feature I listed under Type Managers. That had to do with the interface that they provide. In OS X if you have iPhotos installed your desktop background applet will automatically let you select photos from your photo collection and in iPhotos when viewing a slideshow you can select a song to play from iTunes. This feature of Type Managers I think as a desktop KDE can really take advantage of to provide real value to us and our users.

End users like using Type Managers, they make their life easier through many different means that compliment each other. If KDE [type manager] applications integrate more Type Manager features I do believe that they will get more users.

Type Manager

The Problem

We need to first go back to the middle of the nineties for a short history lesson. Users had DOS, Windows 3.11, and the Macintosh. These operating systems came with a simple useable file manager, but back then there weren't many files to manage either. Very quickly there was a market for file manager applications that had all sorts of features beyond file manipulation, image slideshows, text editing, hex editing, process management. You might have bought one yourself. No application was complete until it integrated e-mail somehow. Of course this type of application could not grow forever and we ended for the most part with file managers that didn't do everything very well.

While FileManager++'s were being created tools began to show up and get new features left and right. There are tools for everything, from ripping a CD and rotating images to converting Word Perfect documents to PDF. Over time these tools grew just like the file managers had. CD drive applications such as Nero are a good example. Today they rip CDs, burn audio CDs, burn DVD movies, create ISO images, let you browse ISO images and many more features all related to the CD drive (but not to each other). The real kicker is that today you do not use that CD application by itself but several tools in combination.

User goals

When I buy a CD my goal is to put the music on my mp3 player. To do that I might have to go through a dozen different smaller tasks before I can achieve my goal. It is not unrealistic just a few years ago (or even today for some people) to first rip the wav file, then encode to a desired format, add id3 tags via cddb, store the files in some home grown system, and finally transfer the files to the mp3 player. These might be all completely different tools. These days with iTunes you plug in your iPod, put in your CD, click Rip and come back in five minutes.

iTunes is a Music File Manager. You drop in your music files and iTunes automatically puts it where it wants on your filesystem. You can even configure this in its preferences, but not that you would care because when you want to access the music you will use iTunes. iTunes and a music file managers are able to provide features above and beyond what a normal file manager could. It can read meta information such as the id3 tags, rating, show covers, and provide links on the web about the artists. Music managers can of course play the file, but also you can rip CDs and burn musical CDs. When iTunes first came out one of the very surprising things I heard was how people who had spent years carefully crafting a system for managing their music didn't mind giving up that control to iTunes. And those who had just dumped every mp3 into one folder loved their new management that iTunes gave them as part of the application.

iTunes lets you do everything related to music files in a interface perfect for managing music files. If you tried to use iTunes interface for managing your photos you would be laughed at because it just wouldn't work. If you have Linux you can of use digiKam, another Type Manager, made for photos of course.

Type Managers

Type Managers are intentional interfaces for files that have similar or the same type of data. The type in Type Manager literally refers to a set of mime types such as images, videos, music, or e-mails. Type Manager applications are not new, in fact you probably have been using one since you got an internet connection. No it is not a web browser, but your e-mail client. E-mail clients let you manage countless e-mail files in an interface that well suited for e-mail messages. Depending upon how your client stores your messages (one fat file or as separate files) you can use your file manager to view, sort, find, etc your e-mails. Type Manager applications are file managers in disguise. They present a user interface for a specific file type. They also do something much more useful. They often do the file management for the user. Many users like to save things to the desktop and they just let it sit there, they don't actually manage the files. Yes, some users do enjoy managing their files, but if given the option don't mind having an application do it for them.

One of the key features that will make Type Managers successful is the number of tools that are integrated for that file type. For the Unix users out there, think of what small tools you would use on images. Basic editing with mogrify, information with identify, exif editing and viewing with perhaps exif.py, web page gallery generating with curator, a different tool for simple local slideshows, and gphoto for actually getting the images from your camera. Last but not least grep and find to locate the image you want. Whew! Not only do you have to find each one of these applications, but you have to learn each of their different interfaces and quirks. If you tried to incorporate all these features into your file manager you might succeed, but when you try to also integrate all the features that a music and video manager have you end up with a very cluttered and unusable file manager. When you create a Type Manager with a lot of tools users will only want to use your application and no other.

Features of a Type Manager

What about Photoshop? Photoshop isn't a Type Manager, where does it fall? There are two other types of user applications, Content Viewing and Content Creation. Content Creators is any application who let the users create and edit new files such as Microsoft Word, Gimp, and GarageBand. Content Viewers are applications that don't necessarily create files, this includes games, web browsers, image viewers, and chat clients. This leaves Type Managers which are fairly new to the scene. Although not all of the following applications have all of the features: iTunes, iPhoto, Juk, Amarok, and digiKam all can be classified as Type Managers.

So what features make up a Type Manager?
  1. Type Managers need to remove the user from the details of the file system. They need to present the files in a hierarchy that best suits the files. The application should not show the filesystem from within the application's view at all. The applications can even hide the files entirely such as with iTunes where the default view is not browsing the music hierarchy. The application should provide the functionality for automatically managing the location of the files on the filesystem, but should be able to still work if the user doesn't want to move the files.

  2. Type Managers must provide the means for viewing and editing that file meta information.
    • File managers should let you set the permissions.

    • Music managers should let you set the artist, album and track name and other id3 tags.

    • Photo manager should let you view and edit the exif information such as the time that the photo was taken.

  3. Type Managers should include that typical tools that would be used for import and export.
    • Audio managers should have CD rippers of audio disks.

    • Video managers should have DVD burning for your movies.

    • Photo managers should let you import your photos from your camera

    • Game system ROM manager it should include the tools needed to obtain the ROM's off your old game cartridges.

  4. Type Managers can include basic manipulation, but should not be a full blown editor.
    • Music managers should let you equalize music.

    • Photo managers should let you crop photos.

  5. A Type Manager must include full search capability.

    • It must allows the user to search the current context (e.g. group or folder) as well as the global collection (a single line edit is always good enough, even when you think it isn't).

    • Type Managers should supports virtual folders which are really dynamic, real-time searches represented as a group or folder.

    • Additionally, a Type Manager should provide a set of virtual folders which cover the common use cases, for example:
      • A music manager would provide virtual folders for highest rated and most listened to.

      • A photo manager would show recent photos.

      • An eBook manager would list the last N read books.


  6. Type Managers must allow the user to manually group files. While search will often be used by the user, there are times when manually grouping is more appropriate. How the grouping is represented is dependant on the type of content. While it may be a folder in a file manager, it may be a playlist in a music application. It is also common to present new or external files in their own group. For instance:

    • File manager shows a new disk or folder when a CD or USB stick is inserted.

    • iPhoto shows a new group when a user shares their photos over the network (zeroconf).


  7. Type Managers should expose well defined, domain specific interfaces for other applications to use rather then implementing it themselves. In iPhotos when viewing a slideshow I can select a song to play with the slideshow. iPhotos uses iTunes to help me find that perfect song. The average interface should be able to get the list of top level folders and to search.

  8. Type Managers by the design of what they do need to be extensible. Providing a framework for enhancements and third parties to add more utilities will ensure that the application will have a long life. Make sure that enhancements only include features for the manager type.

Type Managers that provide the above features will find themselves suddenly having a rapid fan base which is the best kind. The best part is that there are very few of them currently out there, so it is your market to loose.

Files and Documents

According to the rules of being a Type Manager we can create a specification for what a file manager should be:

  1. While providing a means for the user to view the literal file system hierarchy, the default view would be the user's home folder along with a set of virtual folders that sort their content logically. (or something like that anyways))

  2. Let users change permissions, tell you the size, what application opens the file, etc

  3. Let users burn data CD's. They should also provide means for accessing remote filesystem such as webdav, fish (ssh), ftp etc. And they should let users compress and uncompress files.

  4. Let users rename and delete.

  5. Let users browse media such as CD's, zip drives, floppies, etc.

  6. Search the current directory such as only show all files that match '*.jpg', Search the entire computer 'i.e. all mounted devices' and Show searches such as recently added and modified files.

  7. Utilize other Type Managers and viewers to show previews of files.


Sounds like a pretty good file manager now doesn't it?

What about documents? Can you have a Document Manager? If you can have one, why hasn't anyone created it yet? Searching is typically already provided by the system so that can't be the major drive for adoption, but what about integration of other tools? While discussing this me and a friend tried coming up with features such as word count and revision control but found that we don't maintain enough office documents to do make a proper list. That is until we looked at it from the unix command line perspective. What if the document manager integrated features provided by sed, cat, less, wc, grep, awk, perl etc. Now suddenly the document manager is a very interesting product.

User Interface

On the right is a mockup of a generic Type Manager interface. On the left you have the list of folders including a search folder, a user folder and a mounted media. On the right you have a list of the currently selected folder. This area is typically a view that is best for that type of data be it list, tree, icon or other. You might have multiple panes such as in an e-mail client where there is another area dedicated to showing one full e-mail. On top there is a search bar. Type Managers will of course have other widgets depending upon their type, but you can expect these features to be prevalent in most designs.

Type Managers Everywhere

Anywhere that you deal with a large number of files that contain the same data a Type Manager would make sense. Virus scanning companies probably have an internal tool to deal with all of their virus definitions. Valve has their Steam application which is a game manager. Linux distributions often have some sort of GUI tool for dealing with the thousands of packages. Most Mame front-ends are a Type Manager. IDEs are yet another Type Manager, this time for source files in a project. I use a RSS manager aKregator to read news. You could even make a nice Type Manager for dealing with system processes.

Type Managers are part of the future of the desktop computers. Those that implement all of the features of a Type Manager will be more successful. It is not one specific feature that makes Type Managers so useful, but all of them put together, including search.

Saturday, November 12, 2005

Microsoft, Applications, and $159 Computers

Earlier this year I wrote an article discussing what I think is Microsoft's biggest problem with their Windows Operating system. Why Microsoft's market share wont grow. The gist being the fact that you have to be the system administrator to use Microsoft Windows. At the time I felt that the article wasn't my best and needed more polish and ... I forgot about it. I came across it the other day and so I posted it up on my site in the hope that others might get something out of it.

As many of you know I enjoy playing the original Quake from time to time and a few months ago I was given the source code to the Quake 1 level editor BSP from its author. I spent some time cleaning up the source and now I have posted up the original source and my modifications for anyone else who might want to explore/use it. BSP source project page.

I have done a lot of Qtopia work in the past and about two years ago I created a game similar to Microsoft's InkBall in Qt/KDE called Ballow. The basic selling point of the game is that rather then using a mouse/keyboard/joystick you play the game by drawing on the screen with your stylus. I have no plans to do anything more with this application (got it to demo stage and didn't do anything else) so I have packaged it up and put it on my website for whomever would be interested (there is a screenshot too).

If you can't tell I cleaned up my hard drive this past week :)

And for those developers out there looking for a spare computer to help your compiles via distcc (and something like distccKnoppix) here is a $159 AMD computer that would be perfect for that job.

Saturday, October 22, 2005

Code Complete Review

I read Code Complete by Steve McConnell again this past week. This book is one of the few books I recommend for every programmer on my website. Anyone can read a book on how to code C++ in 21 days, but that doesn't make them a competent programer. After a few years of programing you will learn things from other programmers and from yourself. Not big things, but little things such as:

When working on a problem often times it helps to go to someone else and talk it out. You will probably find that all you need to do it talk out the problem, the other person doesn't even have to say anything.

or

Hard coding that 48 pixel size for every toolbar button isn't a good idea, using a global define is much better.

Your average computer book normally don't concentrate on these types of topics/tips, because they aren't important in teaching you PHP, C++ or how to design user interfaces. But they do make you more productive by making your code more easier to read, easier to maintain, and easier to debug. This book doesn't just teach you tips for writing code, but also dealing with schedules, managers, projects, and everything project related. I do not know of another book that contains the breadth of tips like Code Complete. Here are just a few of the types of tips that are contained in the book:
  • How to use parameters
  • How to name boolean variables
  • Different types of design
  • Enumerated Types, when to use them, and how
  • How to write defines (named constants) and why you should
  • Use variables as short of a time as possible and why
  • When to use a while loop over a for loop
  • When not to use break
  • Tips with boolean expressions
  • Benefits of structured programming
  • How to lay out and format your code (white space etc)
  • Keys to effective comments
  • Estimating schedules
  • Debugging, more then just printf()
  • Project integration strategies
  • Optimization strategies
Those who program in the open source world will find themselves exposed to many similar tips and tricks just by reading other peoples code. In fact this is one of my favorite parts about open source. As I read others code I often learn something new. Then when you submit patches they might be rejected not based upon correctness, but upon how the code is formatted, comments, or other bits that matter more in the long run.

I would recommend Code Complete to any programmer. Beginner programers will of course get more out of it and older programmers will find the book contains many good reminders and perhaps some tips they knew, but had never defined.

KApplication and other KDE4 work

Lots of exciting stuff is going on for KDE 4. Recently I have been hacking on KApplication. Over the years KApplication turned into a storage location for anything that couldn't find a home. A month or so ago I printed out KApplication and QApplication api docs for some weekend reading and planning. Taking it in small, mannagable blocks I have removed quite a lot from KApplication and even more can be done once Qt 4.1 is released. But what makes this really exciting is that as each patch got in, the interdependency in kdelibs was reduced. This will help us in the goal of separating the kde libraries. Yesterday, after a little work I was able to run a KDE application (trusty KTron) using QApplication. Work still has to be done, but we are on our way.

Doing some very unscientific tests you will be happy to hear that your average KDE application seems to drop 3MB in memory size just by porting to Qt4.

Also, for those interested in reading the commits to KDE's svn but don't want to sign up to the mailinglist here are two rss feeds that you can subscribe to.
Topic: Directory of change
Topic: First part of the commit messages

Tuesday, October 18, 2005

Why you want to write api docs

Writing code for the kde libraries is not like writing a class that goes in your KMyBigApp. Once it gets into kde's libraries it will have the following:
  • The structure of the class can't be changed much.

  • A lot of people will (try to) use your class.

  • A lot of people will read your documentation and curse at you if it makes no sense

  • A lot of people will read your code

  • Every stupid bug will be found such as calling foo() crashes the class every time or never returns the correct result.

  • The person hiring you for your next job might look at it. (actually these days it is pretty much guaranteed they will Google for some of your code).


What am I really saying? Writing documentation (and tests) for classes in kdelibs is very much about personal pride. It isn't just a class in your application, you know that people will look for documentation, use every function, and use it in a way that you never thought of. If you have no documentation then you will have people annoyed at you. If you don't write a test application that minimally calls every function the moment someone else does and breaks your class you will feel stupid. If you take the time to write some documentation and test application you are forced to think about your class and how it best fits into a larger application. Once you do this you will discover a few things to tweak in the structure to make it better. Writing documentation and tests for a class in a library isn't busy work that you don't have time for, it is professionalism.

And if you have no professionalism you can always fall back to: Those who submit new classes today to kdecore-devel with docs and tests get a big thank you (from me and others), and those that don't have docs get rejected, it is part of the kde policy.

Thursday, October 06, 2005

How to get laid with a web based office

My my blog I didn't advocate web based editing, but more storage or office docs on a website and the ability to access interact with them on the web. Editing can be done there, but probably much more fruitfull would be a fat client. Re-read my blog entry and notice how most of my feature list you can't do with stand alone clients.

10. privacy: aside from yo' momma, who wants their personal data on someone else's servers?

It would only make sense that some sort of open source web backend office came out.

9. the web browser provides an interface (menus, toolbars) and you want to shove another one, even more complex inside of it's little viewing area? this may work ok for email, but .... a word processor? c'mon!

Agreed, but you could have a fat client for the editing, but everything else is still on the server.

8. jwz hasn't yet figured out how a web office suite will get him (or the average college dorm rat) laid, therefore i must pass on it.

The colaberation part. You like this girl in your class, you offer to help with the paper and make some fixes before heading over to her place. Or more simply: the girl next door needs to print out the paper. Or you upload all your digital photos to the media repository, the girl next door finds some of the photos really good and looks at you in a new light.

7. the prospect of purchasing new servers for the office to run software we already have working just fine on the desktop is inane, thank you very much

100% agree, if web based offices's provide *no* new functionality other then woopie I can edit in my web browser then it will be dead from the get go. It is all about the features that you can provide by having a central repository that is also web accessable.

6. training costs, anyone?

Training costs for Office 12 anyone? Training isn't an issue, if you provide benifites that outweight the cost of training then it will be used.

5. there have been web based (though not AJAX, granted) office apps for years and they haven't caught on

See my #7 point

4. it's bad enough reading email chews up RAM because it's delivered via a web browser, do we really need a word processor that requires 1GB of RAM?

Fat client solves this

3. 100% 24x7 networking in the office is a dream we're still years away from achieving

With a Fat Client it can easily have an offline mode or more easily just a local copy of files you have edited in the last six months (or whatever you specify).

2. even with AJAX, the web browser isn't nearly rich enough to meet the demands of spreadsheet and desktop database users (and no, XUL isn't even close to being wide spread enough to matter). try getting groucho in marketing to let go of his linked-to-million-other-data-sources-realtime-updating-charts-with-a-billion-sheets-and-split-frames-with-funky-data-input-widgets-on-top spreadsheet.

Most people aren't groucho in marketing. That is a TOOL for their job. It is like you telling me that Kate is the only coding editor and me telling you that you can pry vi from my cold dead hands. For a developer the editor is _very_ important, but most others don't have the requirements we do. For many of us a word processor is used to write up quarterly reports or presentations or other simple things once or twice a year. For a student anything with spell check is probably good enough (and don't you dare try to take away itunes from them).

If a word processor is the primary tool for your job then you are going to use Microsoft Office and there is _nothing_ I can do to change your mind. If a word processor is just a tool you use from time to time for spell checking and basic formating then you can change.

1. there's no easily accessible and dependable network on the airplane, most coffee shops, on the highways between major cities on the beach or just about anywhere else that isn't an office or house in a developed country. and if your spreadsheet doesn't let me read and edit my information wherever the hell i happen to be, your app doesn't get used. period.

This is the same as #3... and so is my response.

Monday, October 03, 2005

Web based office suite

Over on slashdot there was an article about how an online office is _coming_ (insert ominous music). Quickly reading through the comments I am amazed at how few people get the value it could provide. I was chatting with some friends of mine about this a year or two ago.

Lets say I made an online editor, now my document editor is simple, damm simple, it only lets you edit the raw html for your document. Having word count and bold text isn't the value of an online editor, there are many other values
  • Backup is garenteed. Assuming the admin hosting the "application" isn't an idiot your documents will never be lost from your mistakes or your bad hardware. Already this is better then most companies today.

  • Revision control. Outside of development you don't code documents under revision control. Most users haven't a clue what it is. With the ability to store every change in a real revion control system on the backend you get all sorts of possibilities including:

  • Access anywhere. I don't know how many times I have been over at someones house and pulled up some vacation photos to clairify something because I have them online. If you have your documents online you will be likely to reference old ones in at random times. Can't do that today with them on home computer.

  • Clean merging when multiple people edit a file. I don't think you can do that in any mainstream text editor today. I am talking about the ability to merge files like we can do today with svn and code.

  • No pesky filesystem or filename to deal with. You simply save the document and search for it when you want to edit it. Users stress out about the name of their files anyway.

  • Instant publishing. When you are done you can mark it as global so that anyone on the outside can view your document. Imagine just browsing around on the internet checking out other peoples documents that they wrote. The key thing being that it
    would take no effort to "publish" the file. And if you have to fix something you just edit the document and it is done.

  • The ability to merge parts of other documents into yours and when those documents are updated so are yours (like a quote or paragraph).

  • Global searching. If your company has all their documents up on this repository then it will be very easy to find any document (say the spec written for a product from five years ago...), compare that with today...

  • If your company changes its name, or on a personal level you change the project name it will be easy to find all of the Documents that use the old name.

  • No more 50MB doc files. You can have a repository of accessory files. Call them clip art, call them vacation photos. You can create multiple documents that use the same 2MB images without having to make a copy of the image. You make a logo for a project and change it, update in one place and be done.

  • The ability to add media to everyones clip art in your family/company

  • Readers can leave comments on your documents. Think slashdot or messageboard style. This could be public or private, either way a valuable way for feedback.

  • LIVE status reports. The chief editor for the paper could just browse to a webpage that tells him the number of words of each of tomarrows articles to see which ones are done. And that is just the tip of the iceburg on reporting.

  • Your printer doesn't work? Just go over to your freinds and print it out on their computers web browser



Online document storing is coming. I could give a rats ass if it doesn't let me add footers or do a word count in version one, but if it starts adding the above colaberation abilities hoochy-mama I am going to put it on my server. Some will argue that we are already there. Wikipedia comes really close. A company could make a fat client with all the nice features for editing the files, but the key is that the files are stored on a remote server that is web accessable to enable all of the above.

Hell I am all excited about this I almost want to go code it myself.

Dan Brown - Digital Fortress Review

I ran out of technical books at the apartment and so I barrowed one of my wife's books by Dan Brown - Digital Fortress. I had read Davinci Code because it was so popular, but I found it overly predictable. The only part that was at all interesting was the reverse handwriting which I now frequently write my personal notes in.

There were hints of what was to come all through the begining of the book. I should have seen it coming when our super code breaker Susan didn't know about One Time Pads. Here are a few more fun things I found when I read it:

-They spent several years building a parallel computer with three million processors. In the real world you build it up block of computers at a time rotating out the oldest with newer computers every year.
-The installed all three million processors and *then* tried it. Again you incrementally add computers.
-A 64 bit key tool 10 minutes to crack and a million bit key took only three hours. In reality every bit you add doubles the number of keys to search
-A normal 6 minute crack cost $800, a 18 hour crack then does not cost $999,999,999
-The algorithm for a new code is here in this encrypted file, now let me just brute force the file to get it with the algorithm ... oh crap another bug in the book.
-Susan has an IQ of 170, but is perfectly "normal". Those who really have IQ's of 170 are not normal, but have a lot of social quirks.
-Susan walks over to get into Hale's computer rather then ssh'ing
-We are suppost to like Susan, but she enjoys the thought of us all using a code she can easily break. I was rooting for the other guys after that.
-I can easily get around anonymous re-mailers by sending a message that will "disintegrate" on the other end.
-When three million processors overheat they explode in a twenty story fireball.... right, now pass me some of that crack
-Lets teach the user all about Caesar box so that we can bring it back at the end of the book AND in the code on the last page of the book.
-"128-10-93-85-10-128-98-112-6-6-25-126-39-1-68-78". - hint there are 128 chapters in the book.
-When a virus is taking down your "iptables" they are either on or off, they don't "fade"
-"X-eleven", puke
-EFF, an annoying group....
-Lets introduce a random Japanese Businessman, Tokugen Numataka, he can't be connected to one of our main characters... or can he
-Didn't you see that movie about the Manhattan project?
Best for last:
-When your iptables are going down and anyone can get into the network in five minutes and we need to gave fifty pages of suspense we will forget about just unplugging the network cable.
-Lets see how long it takes a group of smart people to calculate "three".
-And of course Digital Fortress is a rotating clear text, un-unbreakable code... just well glossed over as some obscure paper written in 1987 that "does some stuff to some other stuff to make it not possible" in the hope that the reader will just accept it. The closest thing I could figure that he meant would be encrypting your data with one key and then encrypting that with another different key. still stupid.

I felt like I just read a bad Neil Stephenson knockoff written in two months with no research. Go read Cryptonomicon, it is way better then this and you learn a cooler simple code.

Saturday, October 01, 2005

Programming On Purpose by P.J. Plauger Book Review

Programming On Purpose by P.J. Plauger was an interesting time travel back to the mid eighties. Object oriented programing was new, assembly was norm and dos was new and unix was starting to be old. The book consisted of selected essays from the authors monthly column in Computer Language Magazine. Starting out, tthis book contains the best example of why not to use a goto. In the forth essay when discussing bottom up design a problem is shown using goto statements. The best part is that there is a bug in it that can cause the program to never exit. Now this essay has been reviewed by editors and other essays had fixes that the readers of the magazine submitted and yet everyone missed it. This books feels like a very early idea/draft of what the book Code Complete became. It presents good ideas, some very basic such as using #define rather then putting 4988 hard coded all over your application. It also discuses some larger issues like modularity and structure. The book very much shows its age in places. For example it talks about the expense of piping data from one unix app to another as being too much. Along those lines you can clearly tell the transition to DOS in the writing as so many developers did in the early nineties. At the end it briefly touches on topics that aren't coding related, but very important to programming such as: office politics, planning, and working in groups. Honestly, unless you are interested in the computer science scene of twenty years ago I would recommend that you go and get Code Complete instead. It has much more and is up to date.

Thursday, September 29, 2005

My mind is confused, an American in Europe

When my Jen (my wife) and I moved to Norway in July she started a blog called: "My mind is confused, an American in Europe" about our experiences. Wasn't entirely sure if it would last or not, but as it seems to be going just fine here is the link for you to enjoy and or subscribe to. It contains a lot of the more of the non-technical side of my life. Fun things like going to Spain for akadamy, moving here ot Norway, and general weirdness we find in Europe like two hole binders.

Sunday, September 25, 2005

Selected Papers on Computer Science by Donald E. Knut book review

Read "Selected Papers on Computer Science" by Donald E. Knuth this afternoon. This book contains a collection of papers from the sixties to early nineties. A lot of them dealt with the connection between mathematics, computer science and how important algorithms are to computer science. There were some topics that were covered more then once, but that typically happens when combining papers from weren't originally meant to be together. In particular I liked the paper on the IBM 650. Everyone that writes about computers from that day always have humorous stories such as doing floating point addition in forty-nine steps when no one thought it was possible. Many of the papers talk about algorithms and showed examples of problems that problems that were only able to be solved once a better algorithm was found. There were interesting bits of computer science history such as discussing Von Neumann's first computer program, George Forsythe's construction of the Stanford Computer Science department, and even computer science in ancient babylon. It was an interesting book to read, but there are others that I would pick before this one.

Wednesday, September 21, 2005

The Inmates Are Running The Asylum book review

Finished reading The Inmates Are running the Asylum, by Alan Cooper last night. I was quite surprised at how new this book was. I have always heard it praised beside other books I own that were written twenty years before it. Simply put this book tells developers that they should step aside and let designers create the user interface. This is repeated over and over all in the book. The book does not tell you how to design, although up until the very last page I kept thinking it was but a chapter away. Alas it was not to be. That is for another book on interface design. The book is an easy read and you could read it in a day if you had the time. I do recommend this book for any developer who wants to improve there applications.

One thing that is very true is how much we do appreciate good design. Yes we will suffer with whatever we have, but the moment a really good design comes around you will never go back. A good example is the ipod. Great design. For playing my music it works. You don't need me to convince you, you already know. I really need to stress this:Yes we will suffer with whatever we have, but the moment a really good design comes around you will never go back.

You maintain a kinda ok application design wise? All it will take is for someone to come out with an application with a much better design and half the features for you to loose users.

Another thing that you need to think about is that users have goals and to reach those goals they do some tasks. A user wants to put a CD they just bought onto their iPod. That is their goal. They don't care to organize their music, tag the files, or any of that other things, those just end up being tasks of the goal. When making your application think of what goals your users will have. If you make the goals hard to accomplish then your application isn't that good no matter how much it can do.

Another side note that is brought up in the book. I HATE how Gaim pop ups dialogs all day long. You have been disconnected, now connected, now signed on again, no away, now automatically logged out,.... AHHHHHH When I come in the morning I don't care to see a single one of these pointless messages. When I use iChat it *never* interrupts me with these pointless messages. I am willing to suffer with Gaim only because it works well enough and hasn't segfaulted on me much. The next time I try KOpete (or anything else for that matter) and it is better I will remove Gaim from my system. (See the above section on users will suffer until good design comes along)

One thing to think about when developing your application is to try to think in numbers other then 0, 1, and infinity. For example in KControl right now we have a Tree widget, that is because there are more then one module. After the cleanup there are less then 50 modules. With more then 10 and less then 50 modules there are better ways to display all the modules then in a tree view. With less then ten modules the icon view like in (most kde app) settings dialogs are another good example. A CD album will typically have less then twenty, when editing you will have a few hundred undo's, most folders will have more then five items and either less then 50 or way more.

The book presents the ideas of user personas. I have heard of this idea before, but only from a 10,000 feet view. It is a very interesting idea that can provide value to developers. They are a set of well defined personas that define a realistic set of skills that the user would have. So here are the three personas that I have created for KDE.

William
-Codes, PHP, Bash, C#
-Works for SciTech Technologies on a Windows project, but maintians a Linux box at work and uses Linux as his primary box at home.
-Has three computer, four if you count the one in pieces
-Involved in two or three sourceforge projects, and submits bug reports to others
-Listens to Korn and Linkin Park, has two mp3 players, and in his spare time hunt for odd cd's in the local CD shop
-Has a personal website (been meaning to update) and a blog
-Drives a Saturn, "moded" it with a new deck and connection for his ipod

Jane
-Married to Bob who codes Linux at work
-Uses a laptop
-Lets Bob fix the computer when it "breaks" and to add (install) applications, but only after trying for twenty minutes to do it herself.
-Loves how in Kicker you can change the icon of Konq to a star with a smily face
-ebay++
-E-mails really only five people outside of work and chats with them on aim too.
-Drives a blue car, Honda maybe

Nick
-Security Guard at the local Zoo
-Uses windows at work when he needs to
-Doesn't user the computer that much, mainly for writing documents, aim, e-mail and for websites people send him.
-Prints more then Jane and William combined times ten.
-Uses a PII 500Mhz computer his son made him.
-Doesn't use any application that isn't already installed or that doesn't have a shortcut on the desktop.
-Baseball++, Football++, Go Jets!
-Walks to work

When designing something in KDE if it is good enough for William then it probably isn't going to be good enough for Jane or Nick, but if you design for Nick you can make everyone else happy too. Jane is willing to explore the Setting and read the Help to find common features and William, well William is going to enable hidden configs just because he can. If you make Nick happy everyone will use your application. When debating implementing a new feature or design try asking yourself: "Could Nick use this?"

Thursday, September 15, 2005

Tweak KDE

One of the things To Do when cleaning up KControl was to remove some stuff that is beyond Advanced dialogs and more like "This will probably break some shit". Things that most users (and developers for that matter) could care less about. There were also some features in KDE that I like, but have to look up every time (such as the developer mode to drkonqi). With that in mind I spent that last hour and coded up Tweak KDE. It lets me easily enable hidden features and it gives a spot to hide away some options that are (but not for much longer) in KControl. This way you tweakers can still have your fun, but most users will never know that they exist. The code is in trunk/playground/utils/tweakkde/. Very simple code and I plan on keeping it that way. I will turn this into an extragear application after I let the code settle a little. Here are some screenshots:



Saturday, September 03, 2005

Back to Norway

Wrapping up my final day here at aKadamy. Tomarrow morning I fly back to norway where I will probably have to wear sweatshirts to keep warm. The week has been fun and interesting. This is some things that just can't be transmitted via e-mail. Seeing someone in person and what projects they are involved with both in KDE and there personal life helps to explain their decisions, belief and direction a lot more. Also when you are in person you can just tell the person to walk over to your desk rather then spending ten minutes on IRC.

The bad:
-The cafeteria closed earlier this week so many of us wasted way to much time (two plus hours?) finding food off campus.
-Spanish keyboards are really hard to use when you are used to American keyboards. Should have brought my own keyboard and mouse.
-Having two rooms separated out the hackers a lot more. One room would have been better.
-We have a lot of work to do
-I Didn't actually get much time to hack before today
-Vending machine ate my money without giving me anything

The good:
-A lot of people talking more about usability.
-KDE base is getting restructured
-KDE4 libs work is underway
-Lots of good System Settings (i.e. kcontrol++) discussions
-Interesting talks
-Lots of talking about how to make KDE better (vs sitting and just coding)
-Met lots of people in person that I have worked with over the years

Malaga was a little disappointing. I was surprised how dirty the city was. The first day we walked from the hotel to the University and there is pretty much trash everywhere. Even on the well maintained university lawns that are mowed there is trash. I was hoping to get together some sort of outdoor game earlier in the week, but decided not to sense I didn't think there would be anywhere to go. I had fun playing tourist, taking lots of photos and seeing some sites. I'll upload them when I get back.

Saturday, August 27, 2005

Malaga, kdelibs, kregexp, and more!

Today is the first fun day here at Malaga and even though we were told to be here at 9 many didn't arrive till 9:30. Oh well, at least we showed up. As allready reported the network is capped. The keyboards are not American so as long as I don't look down I am ok :) Unfortunettly in the main room many of the computers network (i.e. icecream boxes) have been hijacked for the laptop users. Hopefully this will be resolved tomarrow. I have my laptop loaded with OS X Tiger so any KDE developers that want to check it out can stop by. At some point in the next few days (tomarrow evening?) I plan on having a meeting for those who want to work on KControl. So we don't leave anyone out if you are interested please let me know. (Trying to track down everyone manually right now)

Monday, August 22, 2005

Lessons Learned in Software Testing book review

Picked up "Lessons Learned in Software Testing" by Cem Kaner, James Bach, and Bret Pettichord. At Trolltech I have recently written some unit tests for some Qt classes and some code I have worked on so I thought it would be interesting to see what the book would have to say about testing. It is a fairly large book I couldn't quite figure out at first who it was suppose to be sold to. A developer? A manager? Support? Little of everything person? After reading about quarter way through the book I realized that this book is for those who are hired for the testing position, the full time tester. Once I figured that out then the book made a lot more sense.

The book covers covered a lot of interesting topics from a testers perspective.

-What is a tester
-How to write tests (testing techniques)
-How to write up reports
-How to deal with management
-How to deal with developers (and their weird behavior)
-Documenting
-Automation and automating your testing and when not to
-Unit Tests
-Managing testers
-Hiring testers
-Growing your career in Testing

I picked up the book hoping it would cover a lot of strategies for testing my code (being a big book and all). I got a few good ideas that I will use, but most of the book was not directly about code. On the other hand I got an interesting inside into a testers world. A lot of it a testers world deals with interacting with others and how to best do that. From not giving vp's hard numbers because then they will just want more to understanding that when you write a bug report you need to sell it to the developer to get them to want to fix it. Similar to the development world the book had tips about reusing code and techniques such as working in pairs. Overall I think this book was well written and covers all the topics of being a tester. If you are only looking for a book full of tips on how to write some tests for your code then you could probably find a smaller book that covers the same or a larger book that covers more. For a view into a world that in very similar to being a developer, I would recommend this book. If you are interested in spending more of your time (or all of it) testing, you will probably get a good deal out of this.

Thursday, August 18, 2005

KDE Auto Tests is live again

The computer that was running the automated tests for all of trunk and uploading them finally made its slow boat trip over to Norway. I ran it manually this morning, but starting tomarrow it will run nightly so you can watch any issues you fix dissappear. Head over to here and see what you find:

http://kde.icefox.net/tests/

You can also bookmark you application like so:

http://kde.icefox.net/tests/#KDE/arts/soundserver
http://kde.icefox.net/tests/#KDE/kdegames/katomic

For those who will not read the big read box at the top of the web page here it is again:

WARNING: These test scripts are not the most intelligent things and should only be used as guides for code to investigate! They might have false positives. Make sure you understand the problem that each script is looking for to be able to determine if the script is wrong. If any listed description or resolution is incorrect or you don't think has enough information please contact me.

Crossing The Chasm book review

Finished reading "Crossing the Chasm" by Geoffrey A. Moore. It was an interesting book about how to grow a company from its initial cool new product stage to selling to your average corporate middle manager. A good book that builds upon the fundamentals of the adoption life cycle. It concentrates on the change from early adopters to the early majority. This would be the opposite of "The Innovators Dilemma" which concentrated on when your technology reaches the laggard stage. I would have to say that this is a very good book for a lot of people. You could even apply it to many smaller Open source projects (assuming you want it to grow). You only have so many resources to grow your project with and as exciting as it is to try to do everything and port it everywhere it is much better to concentrate on a target audience and grow it from there.

Nothing was better then a little list of desired features in the book that shows just how different the two worlds are:

Early Adopters:
-Fastest
-Easiest
-Elegant architecture
-Price
-Unique functionality

Early Majority:
-Largest install base
-Most third party supporters
-De facto standard
-Cost of ownership
-Quality of support

It was a pretty easy read. So if you have a free evening I would recommend picking up this book.

Sunday, August 07, 2005

How I sold a million copies of my software... book review

Todays book review is: "How I sold a million copies of my software... and how you can, too!" By Herbert R. Kraft. I saw this in the Trolltech library and picked it up for some evening reading. This book presents an amusing look into making software from the pre internet boom. It was published in 1997 and so I can guess that it was written in 1996. Much of the book deals with how to get your software on the shelfs of retailers and all of the details surrounding that. What interested me in the book was the first chapter where there were a list of applications that you shouldn't write along with some reasoning behind each one. Unfortunately I didn't find much more in the book that was interesting once I read it. There was a chapter that talked about some basics that a professional application should have such as documentation and useful error messages. At the end of the chapter I felt let down. One chapter is hardly long enough to cover that topic. Another chapter talks about software management, design etc. Maybe the author felt that he needed to include these topics to be well rounded, but personally I think he would have been off recommending that that reader check out books such as "Code Complete" rather then giving such inadequate advice. There is a chapter about the internet, but due to the horrible timing of this book you can probably guess just how out of date this book is on that advice. Back then software really was mostly bought in stores and so the advice in the rest of the book probably applied, but these days I doubt that the rules still apply. Though-out the book I was trying to figure out the target audience of the book. My only guess can be the amateur programmer who has written a few small applications for their own use and thinks they can make a lot of money selling them at CompUSA. The one topic that should have been touched on more is how most applications wont be successful and how you need have more then one idea. Unfortunately the person who would buy this book is probably the type of person who has one sole application that they think everyone wants and will to try to sell. Because it is their first pro application they will be lucky to break even, wont have another app to sell, and have lost all their free time. This book takes an amusing perspective. It assumes that no matter how bad (or good) your software is you can make money if you play the market and retailers correctly. At the end of the day this book's main purpose really doesn't apply much anymore because of all the changes in the industry so I can't recommend it.

Update:
A few of the applications you shouldn't write:

Games: Most don't make anything
Childrens software: Other then "where in the world is carmen sandiago" very few games for children every are successfull financially
Programming tools: We all give them away, hard to compete
Office Suites: Is this even neccesary?
Screen Savers: Too many free ones
Word Processors: no explination needed

Thursday, August 04, 2005

The Design Of Everyday Things book review

I finished reading "The Design Of Everyday Things" By Donald A. Norman last night. Another short book (two evenings of reading). Throughout the course of the book the author shows product after product (in many cases, doors) that were designed horribly and thus confuse users when they attempted to operate them. This is typical of most user interface books, but unlike others throughout the book the author explains in the most well written manner I have read about why designers think their designs are self explanatory when they are just wrong. Most other books gloss over this fact hoping you will memorize their rules. Another idea which is much more prominently talked about in the book is the idea of blocking, or removing features from the users when the option wont do anything or cause harm. Even though computer GUI's aren't mentioned, many of the ideas presented can be quite easily mapped to computer gui's. Overall the book is well written and has a lot of good ideas and would recommend this book.

Nine things KDE should learn from OS X

Note: This article was written in 2005 and it is commenting on KDE3.

Two years ago I got the opportunity to get a Mac laptop for work. At the time what my job didn't require Linux, but just an Unix environment so I took advantage of the opportunity to learn more about OS X. The more I looked around the more that surprised I became. Yes I had things I don't like, but every day it seemed I was discovering some sort of killer feature that I hadn't seen in any Linux or Windows environment. Rather then loaning out my laptop for a few weeks to every KDE developer I thought I would write out some key things. If you have never truly played with OS X I would invite you see if you can barrow one for a week to expose yourself to it first hand or just visit an Apple store.

1) Users have an address book entry

The first time you log into OS X it asks you to fill in a form with your information. I figured it was for registration and just put in my name, selected and icon and then clicked that I didn't want it to be sent to Apple. I didn't think about it much until later when I started using iChat and noticed that it had used my icon and had my real name. Then when I opened the address book I found an address book entry for me with the information I had entered. The idea of using your addressbook entry everywhere might seem like a simple idea, but it is not one that has caught on in KDE.
  • Games shouldn't prompt you with a blank name dialog when you get a high score.

  • IRC/chat/aim/kopete should know your name, your nick name, and icon.

  • KMail should already know your name (and pgp key!) when setting up an account.

  • KDM shouldn't need to have a separate configure spot for the user icon.

  • If you update your user information it should update the system.

  • Digikam can mark each photo you download as taken by you.

  • KWord and the other office applications can mark that you edited/authored the file rather then a blank field.
You can probably think of more examples where having a users address book information would make for a better user experience in your application. I have suggested to a number of existing applications to try to use the addressbook entry if it exists the past year.

For KDE 4 I think that when a user first logs into KDE it should be prompted to make an adderessbook entry so that applications can take advantage of this information.

2) Single Toolbars

All through out OS X you will find that application typically only have one toolbar and the vast majority of the time there are around seven actions displayed with large icons and text underneath. Don't think it is possible? Lets take a very complicated application, a development IDE. On top is XCode and on the bottom is KDevelop after creating a project named "foo".



I figured there must be a some large set of rules in OS X for what should be in the toolbars. But when I looked it up in Apple's user interface guildlines Window Appearance section
and I found this: "Toolbars are useful for giving users immediate access to the most frequently used commands." So if you are making a media player just because you have the actions cut, copy and paste does not mean they should be in the toolbar, but Play, Pause and Next should be.

This particular issue has already been brought up several times on the kde mailinglists and for KDE 4 it is almost certain that this is going to be changing to follow this rule. You can set large icons with text by default in KControl today to see how your application will look. Right now the easiest thing to do is to remove non essential actions and to shorten the really long names. You might have noticed me doing this from time to time in applications. As a bonus you will find that you have less code, icons, etc to maintain.

3) Applications present simple default views

Compare the difference between OS X's addressbook on the left and KDE's on the right. A very common desire for addressbooks is the ability to create groups of friends, coworkers, etc. If you wanted to make a group of all of your coworkers in your addressbooks what would you do? In OS X's you just click add in the group box and then drag any entries over. In KDE's you have to edit each user, click on select categories and check the category they are in. To add a category from the same dialog click, edit categories, and after typing in the text then click Add. Of course in KDE I can't see any easy way to view all the users in one group. Editing a user is also simpler in OS X, you just click on edit and then the field you want to change, in KDE you have to click edit which brings up a five page dialog and find the field that you want to change. Probably worst of all is that most of the space in KDE's addressbook is taken up by a resource widget which to this day I still don't know what as a user I would do with it. This really should be part of the configure dialog as it is not something you do every day. One final thing: notice how my name in OS X's addressbook is highlighted with the little icon showing that it is "my addressbook", KDE's doesn't have that.





In fact the above OS X addressbook screenshot isn't even the default view! The default addressbook is what you see below:



When I first saw this I laughed at it because I thought this addressbook must not be able to do half of what KDE's can, but it can and in this view it was perfectly usable. You search for someone and their name pops up, click the "+" to add someone. Click the multi-column button for multiple views and you can add groups (and smart groups, aka searches). Adding an LDAP server is in the configure dialog just like in KAddressBook


Lets taking a look at another KDE application. The other day I loaded up Quanta so I could see what has changed sense I last used it. Notice how much of the window is actual productive space where you can work on your document. A quick list of actions presented to the user:
  • 13 different top menus!

  • 34 toolbar buttons in the primary toolbars

  • 5 left sidebar things

  • 2 bottom sidebar things

  • 2 right sidebar things

  • 6 tabs of toolbars on top of the edit window each with around 10 toolbar items

  • Tabs for each open file


Granted this isn't as bad as KDevelop, but still it feels like the developers tried to cram everything on the main screen to the point that I as a user have absolutely no idea where to look for things. I personally hate the idea of the sidebars and find it way to confusing, and to have them on every side of the screen is too much. Application do not need to present this much to the users on the default view and in many cases it is redundant. When I started clicking on buttons the entire screen started changing (as things showed and hid) and after ten minutes I gave up and quit.

This issue is different for each application. Typically the default configuration and view of open source application don't get much attention because the developers never have a clean install :) Hopefully developers will take a minute to look at their appliciation and make some large changes for the better.

4) Drag And Drop


Unlike the promises that Windows had and the lackluster support in Linux OS X really does have drag and drop support.

  • Installing most applications is not harder then dragging the application (folder) to where you want it to be

  • If you are viewing/editing a document it shows up in the caption bar as a little icon, just drag that icon to make a shortcut

  • Can't forget that to eject your CD you drag it to the Eject button (formally the trash)

  • I typically open files, import, and extract from application using drag and drop.


Part of the problem why Linux doesn't take advantage of drag and drop as much is that we developers have a right mouse button. Simple things such as selecting, right clicking and choosing and action you don't do in OS X because you can just drag the objects around. Because we have a right click we don't get around to implementing the drag and drop. The problem comes when there are options in the right click menu that arn't anywhere else. It would be better to think of the right click menu as a toolbar, and use the rules that apply.

For akadamy it might be fun to go out and buy a bunch of single button mice and put them on every computer and see how the developers fair and discover what actions are impossible with a single button mouse.

5) Integration


Closely related to drag and drop is desktop integration. Beyond the fact that every application uses ctrl-q to quit I am talking about:

  • Utilizing the addressbook to get the current users information.

  • Playing a song/playlist from the media player in the photo album application when doing a slideshow.

  • A photos screensaver uses your photo application to select an album.

  • A screensaver that uses album covers.



These are just a few things that I have seen in OS X. When writing your application think about how it can be utilized elsewhere on the desktop. For example digikam could also include a screensaver in its source tree. In Tiger OS X took this to the next level with Automator. A small application that lets you build scripts in a gui environment. A wonderfull example was a script that got all new mail and put them on your ipod. Providing ways for other applications to hook into your is important. Unfortunately querying applications just isn't implemented. For example I can not query kmail for all unread mail or kaddressbook for users in my family group. This might be fantastic project for someone to start for KDE4.

If an application can be converted to a web application (hint: KColorEdit, KTuberling (Potato Guy), KDict) without any loss of functionality then either that application really should be a web application, kpanel applet, or it should be improved to take advantage of KDE better.

6) The Window Manager has planes


Application such as Photoshop or Qt Designer 4 display a number of windows up on the screen at the same time. After launching them in KDE if I brought KMail on top I would have to then manually bring each Designer window up top. In OS X clicking on one window will bring every window in that application to the top. I wrote a small patch for kwin so that KWin will behave this way. Although simple it is quite amazing when used.

I hope to get this in KWin for KDE4 as a configure option. Perhaps the default?

7) Application Folders


Unless you have been living under a rock you already know that applications distributed in OS X can just be folders with a .app extension. I have seen a number of small projects start to enhance the file ioslave to give it this capabilities, but nothing has really come out of it. Someone should take the time to add the support officially to KDE. At the bare minimum written in Python (or javascript, bash/kdialog, ruby, etc) would be able to work and developers could even release KDE applications. That would create a fantastic little sub community that could easy pass around their applications. Users would just love this feature. I have written a small script which will generate app folders of all of the existing KDE applications (those that have .desktop files) for the KDE-darwin project which can be fun to play around with.

8) A Common Viewer


Apple includes an application called "Preview". In essence it does something very similar to Konqueror. It can open any file that I give it. It doesn't let you edit it, but simply view it. It is a small application that can view images, pdfs, but not html, Safari is used for that. For KDE 4.0 Konqueror should be split into three different application. A web browser (Konqueror), a viewer (Viewer) and a File Browser (Browser, ok you can come up with a better name). The backend for these three different applications might be very similar, but their user interfaces should be different so that they can best serve users.


With this viewer then KDE wouldn't need to have all these separate applications:

  • Fax Viewer (KFax)

  • KView

  • KGhostView

  • KPDF

  • KDVI


Update: recently a new project was started to do just this: Okular

Heck you could really remove most of KDE Graphics for this one application. Which brings us to the next section.

9) The number of core applications



When you first use OS X you might be a little annoyed that there isn't a Start Menu (or equivalent) to let you explore the list of all installed applications. Part of the reason is because in Finder when you click on Applications there are around only twenty application installed. Combined with twenty more in the Utilities Folder. This might not blow your mind until you start to count how many there are in KDE and we don't even provide all of the same functionality (no DVD player, Automator, Dictionary and manu of the utilities). Ok yes they only include one game, an opengl chess game, but still the numbers don't look good. There is a lot of duplication in KDE that can be trimmed down.

  • KEdit should have been removed long ago.

  • CD playing and ripping should be in Juk or [insert your favorite music player].

  • Adding the above KViewer will "remove" a lot of applications.

  • Konversation, KOpete, KSirc, only one is needed.

  • KAppfinder really shouldn't exist at all, applications should have a desktop file and if not a bug should be opened against them.

  • kget shouldn't be listed as an application, but just something that shows up from within Konqueror.


On the personal side I am working on improving audiocd so that it can be very easily intigrated into Juk or any other application and when that is done i'll move KAudioCreator either to kdeextragear or to my own person website for archive purposes depending upon demand.

10) Where is number 10?


I didn't want to mention the panel or the file browser to much because there are already efforts underway with Plasma and some thoughts on Konqueror. Because these two are so heated and quickly take over any sane topic those two could easily overwhelm any feedback from this article. When discussing this article please refrain from branching too much into them. There will be many discusions on them at akadamy.

Hopefully you have learned some new things about OS X. I know that most Linux developers come from the Windows world so you know exactly what you are completing against there, but take the time to check out your competition on the OS X side. Not just from Apple. For example I recently downloaded the application "Colloquy" which is a third party IRC client. After using it for a few minutes my impressions were that it was a better application that anything that we had. You might find that in OS X they are doing something you have never seen in Windows or Linux.

Sunday, July 31, 2005

Peopleware book review

Today was a rainy Sunday in Norway. So we stayed in, watched some movies, and I finished reading Peopleware. At 245 pages it isn't the biggest book, but it is famous and it is on a lot of people recommendations lists. In fact I think this book has been cited in more programming books then I have read then any others, so I was familiar with its ideas. It wasn't one long book, but more like dozens of three page essays tied together loosely. Some basics such as:
  • Cubicles are bad for productivity and morale
  • Testing is not an option and must be automated
  • Teams, not groups of people
  • Spending your time hiring the right person
  • Meetings should be random, short and only include those who are required to be there
  • Many more
A few fun ideas that I had not seen so explicitly stated before:
  • Cubes are supposedly so easy to reorganize and yet you [the user] never get to reconfigure them once they are installed and laid out by the managers.
  • The larger the company the more procedures you will run across
  • The higher your CMM the less risky your projects
One idea that is talked about in the book, but never really stressed enough in other books is the fact that users hate change. I have read a few books that talk in detail on the topic, but none detailed in computer science. Overall that is what the book feels like and probably why it is referenced in so many other books. Every other book I have read talks much more in depth on one or two of the topics. But for those who are new to programming this book is a good overview of many different topics and practices. I am pretty sure that is why Trolltech used to give it to every new employee. Considering the age of the book and its popularity I would say that you should be able to acquire a copy from the library, a friend, your companies library or Amazon's used books without any problems. Being so sort it is worth the read if only as a refresher and to give to the next co-worker that gets hired.

Sunday, July 17, 2005

Movies shown on TV in Norway

A very cool aspect of Norway is how when they show a movie on TV they don't chop out parts of the film, edit the language or have twenty minutes of adds right before the end. I used to hate watching films on TV in U.S. because so much was cut and changed that you were always left with a film lacking a lot of the story.

Oh and I found skittles today. :)

Saturday, July 02, 2005

Still alive, Just tired

After visting dozens of people we finally left Boston on Wednesday evening. We took a flight to Amsterdam and then to Norwary arriving 10am Thusday localtime which at that point we had been awake for more then twenty four hours. Due to some last minute scheduling we had to stay in a hotel for a night which was probably better as we were exosted. Unfortunettly because of that we didn't head over to Trolltech that day and missed out on the Qt4 release party that Trolltech had that evening. But we got some much needed sleep and woke up at midnight to find that at this time of the year in Norway the sun doesn't completly set, but just kinda of goes off the horizon for a few hours. In the morning we walked over to Trolltech and I got to meet everyone. On the way back to the apartment we stopped at the local grochers to explore a little and to get some milk. I tried to stay up as much as possible and this morning slept in till 5am so by Monday I should be ok. What an interesting month it has been.

P.S. For those who are moving put your picture frames each inside their own bag, that way if the glass brakes it will be contained.

Saturday, June 25, 2005

Packing/Moving/KDE

For the past month me and my wife have been in full moving mode. Because we are moving to Norway that meant getting rid of everything that we didn't want or need. It was fun going through all of the clothes and ending up tossing out or giving away half of them that didn't fit or were just old and worn out. We decided to try to bring as little as possible to Norway. We tried to limit ourselves to four suitcases and our two backpacks. What we didn't give away, toss out is now in our parents houses as storage. Because we have only been married a few years we didn't have too many pieces of nice long term furniture. The cheap $20 shelves, home made plywood desks, and cracked plastic bins quickly went to the garbage. Several pieces of furniture that we had borrowed were returned, and our couch was sold to a friend. Other then one desktop computer which is being shipped and my wife’s and my laptop I have gotten rid of all my other computer hardware. Suffice it to say that at the end of the day we got rid of a lot so not too much is being stored.

As many of you know I am a bit of a Transformers collector. Before packing them up I set up a little area to photograph the main toys that I collect (1984-1986). My initial estimate of three days was very optimistic, but in my defense I ended up running a lot of errands. Luckily I choose to only take one photograph of each toy per mode (robot/vehicle) rather then ten or fifteen which is the typical number for a toy review. Considering that the 84-86 years have several hundred toys this alone turned into a very large task and took more then a week. The first day was a lot of learning, the next few days were fun, but then it just became tedious and waiting for it to end. Too many toys :) Big props to Digikam which I used all throughout this photographing to retrieve the photos from the camera and for the basic sorting. It did die on me once when I tried to download around 800MB of photos from the camera, the kernel killed the app as the system ran out of memory. I guess it tried to download all of the photos into memory rather then sequentially or something. I like very much how it will automatically rotates the images when you download them, but I don’t like how when names it by the time the photo was taken the filename has a number of odd characters and spaces which simply make it annoying to manipulate the photos on the command line. I was a tad surprised that the slideshow plugin wasn’t included by default. Also anyone else find it odd why it prompts your for the Pictures directory? Seems unnecessary. I was happy to finally take photos of all of them even if it was because I was forced to finally pack them all up. I have been working on and off on a website for them the past few years, just waiting for the photos so at some point in the next six months I should be able to put it up.

With all of the packing, selling, getting things sorted out, moving, and visiting family and friends before flying out my free time has been well, non existent. My subversion HEAD box isn’t even plugged in right now and I only just got my mail server working again the other day. On the plus side once we get to Norway I will have a bit more free time and will be able to work on my KDE projects. I think I will be able to goto the conference this year, but I will know for sure after I start work at TrollTech. I hope to take Audiocd and KAudioCreator to the next level. I plan on finally having KAudioCreator completely use audiocd, not just for the wav files. At the same time I want to try to integrate audiocd into Juk and if that is successful then KAudioCreator will be moved to Extragear (or even removed?). I would rather see KDE have a nicely integrated audio application then a dozen apps that all do the same thing. Also I hope to try to integrate the daap ioslave into Juk. The kdetestscript is run on a computer which is being shipped by boat so it wont be updated for four to six weeks. And of course I will continue to help port KDE onto OSX. I have a lot to do and it is a very exciting time. We will be flying out on Wednesday so starting next week I will begin closing bugs and hacking on KDE again.

Thursday, May 12, 2005

The revison of "tags" in svn

In svn the idea of tags isn't the same as in CVS. To make a tag you in fact (simplified) make a copy of a revision and place it in the tags folder. This is to make it easy to get a tag as all you would have to do is checkout from the tag directory. But you could just checkout from trunk if you give it the correct revision number. If you have that revision number you can do a lot of interesting things such as determining what has changed sense the last release, see who made the most number of commits, or how many bugs were fixed (according to the svn commit logs). Unfortunately obtaining this revision number isn't that easy as you might think.

If you do svn info on the tagged directory you will find that it isn't the revision that was copied from, but a new revision and it doesn't have any properties. But this at least tells us something that we can use, the revision of the copy.  Using that version number we can get the full log for the copy with "svn log -r $rev -v ...". Note the "-v". If you don't pass -v then you won't see:

Changed paths: A /tags/source/phpquickgallery/phpquickgallery-1.7 (from /trunk/phpquickgallery:99)

Now pass --xml and you can easily and safely parse out the revision of the release (in this case 99). So after all that you finally have the trunk revision. :) The reason I originally wanted this piece of information was so that for my personal projects I could generate my ChangeLog file entirely from my svn commit log. My change log typically would have the exact same comment as my cvs commit log, but sometimes I wouldn't remember to add changes to the ChangeLog. So here is a little script which will generate a ChangeLog for a release

#!/bin/sh -x
# Gets the changes between two releases of an application
set -e

APP=$1
VER=$2
LASTVER=$3
HOST="https://foo.com/svn/src"
REP="$HOST/tags/source/$APP/$APP"

# Grep the version number of the move
rev=`svn info $REP-$VER/ | grep "Last Changed Rev" | sed s/Last\ Changed\ Rev:\ //g`
# Grep the log for the copyfrom revision (which is the real revision that this is taged from)
tag=`svn log -r $rev $REP-$VER -v --xml | grep copyfrom-rev | sed s/.*copyfrom-rev=\"//g | sed s/\"//g`

rev=`svn info $REP-$LASTVER/ | grep "Last Changed Rev" | sed s/Last\ Changed\ Rev:\ //g`
lasttag=`svn log -r $rev $REP-$LASTVER -v --xml | grep copyfrom-rev | sed s/.*copyfrom-rev=\"//g | sed s/\"//g`

# Get the log between the two versions
svn log -r $tag:$lasttag $HOST/trunk/source/$APP --xml > $APP-$VER.changelog.xml

# Grap the messages
# Remove empty lines and Internal messages
cat $APP-$VER.changelog.xml | awk '//,/<\/msg>/' | sed -e s/^\//g | \
sed -e s/\<\\/msg\>\$//g | awk ' !/^[ \t]*$/ { print $0 }' | grep -v Internal | \
awk 'BEGIN{print '$VER'} {print "* "$0}' > $APP-$VER.changelog

Thursday, May 05, 2005

A few good programming books

When I get free time I enjoy reading programming books. I frequently pick up new ones that people recommend to see what they have to offer(1). Here is a list of the best books that I think every serious programmer should read, if not already have sitting on their shelf.

Core Programming


These books don't teach the latest fad programming language in twenty for hours and often times they often don't even discuss a specific programming language, but the techniques that are taught are timeless and when taken to heart no programmer will come out unchanged for the better.
Unlike most programming books each time you read these books you discover something new and valuable. I will typical read them every other year, each time gaining something new as I draw upon my recent experiences. For those who aren't new to programming after reading these books you will wish someone had told you about them back when you were first learning to program. These books each contain wisdom that the authors have learned through the years.


Pragmatic Programmer
Pragmatic Programmer: From Journeyman to Master

By Andrew Hunt, David Thomas

Addison-Wesley, Paperback, Published October 1999, 321 pages, ISBN 020161622X

An overview of all the essential tools (editors, version control systems, project managers, etc) that a programmer should be using. It explains why they should each be used and also how to best use them. This book is clear, concise, and filled with examples. It shows good habits which can form the foundation for success in projects and in a programming career.



Code Complete
Code Complete

By Steve McConnell

Microsoft Press, Paperback, Published March 1993, 857 pages, ISBN 1556154844

An invaluable reference that focuses on successful programming techniques. It includes many examples of good and bad code in many different languages. Topics like: how to make your program easier to debug, naming conventions for variables, comments, and where code should belong in a object, make this book valuable by themselves. But it also covers many other topics in depth like refactoring, design, and testing. This book will bring to light some ugly habits that every programmer has and hopefully rid them of it.

Note that there is a Second Edition (ISBN: 0735619670) which although I haven't read yet I have been told it is similar to the first.




Mythical Man-Month
The Mythical Man-Month

By Frederick P. Brooks Jr.

Addison-Wesley, Paperback, 2nd edition, Published August 1995, 322 pages, ISBN 0201835959

A classic book on software engineering which applies just as much today and when it was written in 1975. The book introduced the idea that changing the size of the staff working on a project wont improve a project, but might in fact significantly hinder it. It also accentuates that there is no silver bullet in programming, only a lot of best practices (see above books). This book is referenced in countless other titles and is a worthy read on its own for the fundamental project management ideas presented.



Diffusion Of Innovations
Diffusion Of Innovations

By: Everett M. Rogers

Free Press; 5th edition (August 16, 2003), 322 pages, ISBN: 0743222091

This book is not the easiest book to read, in fact is reads almost like a text book. If it wasn't populated with short stories all throughout this tomb of a book I would have a hard time recommending it. Countless smaller books have been written based upon the information presented in this book. This book takes you step by step through the diffusion of innovation process. It tells you how each step is reached, and more importantly how it isn't reached. The two books on the upper right The Innovator's Dilemma and Crossing the Chasm discuss specific portions of the curve (begining and end respectivly) and are highly recommended reading also. After reading the book you will find yourself recognizing the adoption curve in your every day life. So why does this go with technical books? Unless you are a code grunt you will want to pursuade a group of people of new ideas (abstract ones at that). This book will help you do just that.



GUI Bloopers
GUI Bloopers: Don'ts and Do's for Software Developers and Web Designers

By Jeff Johnson

Morgan Kaufmann, Paperback, Published March 2000, 559 pages, ISBN 1558605827

What is this book doing here you might ask? Well it might not have the deep insight that the above books have, but it does serves an important purpose. Too many user interface books use confusing abstract themes or waste the majority of the book pointing out stupid interfaces in other applications without providing any content of their own. This book does something different, it goes through all of the common GUI objects (buttons, toolbars, checkbox, etc) and discusses what the widget is suppost to convey to the user, how to use it, and how to not use it. Too many programmers may have read the high level user interface books, but can't apply them to the every day programming. This book plainly lays out what and what not to do, which for a lot of developers is more important than theory.



The Design Of Everyday Things
The Design Of Everyday Things

By Donald A. Norman

Basic Books; 1st Basic edition (September, 2002), 272 pages, ISBN 0465067107

Once you have read GUI Bloopers take the time to check out this book. The vast majority of the book does not talk about computers and there interfaces, but rather much simpler items such as doors and how badly many are designed. More importantly throughout the book the author explains in the most well written manner (don't underestimate this feature) I have read about why designers think their designs are self explanatory when they are just wrong. Most other books gloss over this fact hoping you will memorize their rules. Another idea which is much more prominently talked about in the book is the idea of blocking, or removing features from the users when the option wont do anything or cause harm. Unlike Gui Bloopers, The design Of Everyday Things discusses in more abstract form. Hopefully this will help you make good users interface choices for topics not covered in Gui Bloopers.




1. If you feel there is a book that is on your bookshelf that you think every program should read it let me know about it. Although I listed only a very few books here I have quite a collection at home and at work and have read through many programming books good and bad.

Popular Posts