You’ve read Refactoring. You’ve seen Prefactoring on the bookstore’s shelf. Well, after you’ve fact’d it all up, it’s time for Defactoring.
My new book, which introduces such techniques as overriding your framework’s core eventloop and running dynamic_cast<> on each widget that passes through to see if it’s the widget you’re looking for.
Matt Ball writes about the tendency of “delicious generation” apps to become abandonware.
That’s fine by me. My biggest problem with them is that they seem to be composed almost entirely of lightweight to-do list applications and other such “my first real program” homework assignments.
http://www.anxietyapp.com/
http://hogbaysoftware.com/products/taskpaper
http://www.culturedcode.com/things/
http://www.objectivesatisfaction.com/what_todo/
http://www.jimmcgowan.net/Site/DoIt.html
http://www.nomicro.com/Products/ToDo/
http://www.magnetismstudios.com/MonkeyBusinessLabs/Checkmarker
http://www.bluehenley.com/products/dobedo/
http://www.mygnu.com/julius/proj_todo.html
http://www.myownapp.com/istk_app.html
http://www.intuiware.com/Products/MacOSX/HotPlan/
http://www.myownapp.com/meinkopp_app.html
http://www.desertsandsoftware.com/?todo_home
http://www.orionbelt.com/productMac.php
http://a-sharp.com/opal/opal
Nice icons and websites though. Makes me wonder where the developers’ real strengths lay.
Sometimes, late at night when the moon is full and no one is around, I’ll download the Emacs source. Then, I’ll make a single change. Maybe rename a variable or a function, or comment something out. Then, I’ll recompile it and put the binary on my website for people to download. But I won’t provide the source of my changes! Muahahahaha.
In Vacuous Virtuoso’s CTGradient code bloat article, he showed how easy it was to trim a 1300 line 3rd party piece of code down to 30 lines by trimming the unneeded code.
Super. We should all look at what code we use and whether it is inefficient or not.
The problem is he didn’t include any numbers beyond the LOCs. It would have been nice to have had some before and after numbers on execution speed, binary size, and memory usage.
No big deal though. It’s still a decent article.
It’s turned into a bit of a flame war though, or as close to a flame war as the usually polite Mac developer community gets.
I started it with what I like to think of was an innocuous comment.
It went back and forth a little bit with Daniel Jalkut joining in too.
Then this guy, Rick, joined in and immediately went personal.
Rick also posted a fun little timecube style rant on his blog where he referred to developers as the Landed Gentry of Mac Development and as snakes. He also put the word “people” in scare quotes.
It’s also amazing how far these ‘people’ will go to defend what essentially is a defenceless position.
Not quite sure what he thinks we are instead.
Sean was totally unnecessary with his
Do us a favor, think of this as being a thanksgiving dinner. The adults are busy discussing things at the dinner table. Take your slice of turkey, and go back to the childr- Oops, I mean, “indy” developer table.
style comments.
I just think that the personal attacks are pretty lame in a discussion by a bunch of developers about the relative merits of a code cleanup.
I came across an interesting post about SmallTalk’s Seaside versus Ruby’s Rails.
The meat is in the comments which are very polite and informative. I’ve only played with Squeak once back in college so I didn’t really grasp the whole editing-live-objects-which-don’t-live-in-files thing.
It sounds pretty neat and pretty powerful.
I always knew that binary searching was fast, O(log2) and all that. But when you have to run it by hand over 3000 subversion revisions, looking for the place where you introduced a memory leak, and after four steps you’ve eliminated 93% of the search space, you get a new appreciation for it.
There are some tools out there for automating these searches through subversion. They didn’t fit our problem though because determining whether we were showing a memory leak was fuzzy.
Turned out to be 4 memory leaks. Two very minor ones, and two major ones in third party libraries, one of which only showed up on the Mac platform.
Thanks to binary searching, we could quickly identify the exact spots where these leaks were introduced.
I saw Bjorne Stroustrup give a lecture as part of the New York City Google TechTalks. Pretty interesting stuff. More updates to the language that I was expecting. Some much desired features too.
Two downsides:
If you are trying to register a callback on getting a URL passed to your program through AppleEvents, don’t use the documented kAEInternetSuite and kAEISGetURL enums. They are defined as ‘gurl’, but the actual value passed to your program is ‘GURL’. From what I can tell, everyone defines their own enums because this is well known.
Apple can’t fix it though, because it would break everyone’s software. So they keep documenting it as ‘gurl’, and we keep redefining it to the actual value.
Awesome.
Guido van Rossum’s Python 3000 Status Update. Nothing new if you’ve watched his tech talk, but still an interesting read.
At my job, we have one of those new espresso pod machines in the kitchen. Usually after lunch, I’ll start to get a little drowsy and need a caffine kick.
Today, I chose the heavy duty espresso forte pod and made myself a double espresso.
After finishing it, I immediately found the puzzling bug that the lead dev and I had been staring at. Super. I then misread the spec and dove deep into Qt4’s QTableView MVC architecture before coming up for air.
There are twothreefour1 things wrong with caffine.
I try to not have it every day, so I can preserve the wonderful, creative effect it has.2