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.

Popular Posts