Droplets of Yes and No

I don’t want a copy of Photoshop. Its not that I’m cheap (that’s a whole other story!), its just that I don’t like using sledgehammers to kill mosquitoes. I’m trying to do some simple bitmap editing and it has turned into a big headache because it is hard to find a simple graphics editing program.

I was using Pixen which is highly regarded and does just what I need it too. Buuuuuut… I can’t get the program to run more than a few minutes without a crash. And that just really bums me out because it seems like the perfect program. Sadly, I’m not the only one having this problem, posting around the net seem to indicate that this is a common issue.

And unlike Windows, the Mac doesn’t seem to come with any simple programs a-la Paintbrush. What’s up with that? I realize Apple is all about minimal cruft and what-not, but this really takes it to an extreme.

For the moment I’m trying out tileeditor which is a pretty minimal editor, but at the same time seems to work pretty well. (Although as a side note I would like to point out that you need to start the editor in the same directory as your artwork, otherwise it seems to try and save to the wrong directory. Every time I did this is put _tmp and the front of the path, which of course doesn’t exist. I’m not sure if this is a Mac specific thing, but just starting the program in the art directory seemed to get around this issue.)

I’ve been thinking about business logic lately. Specifically about how to make nice flexible rules without hard coding them in the code itself. This has led me to look more at Lisp-y languages like Scheme and Erlang. (I’ve got some more to say about Erlang, but that’s a topic for a later post.)

At any rate, today on Reddit there were a few really good postings on this topic and one of those postings led me to more really good articles on the topic. (As a side note, I’m really glad this happened today, lately reddit has been a dumping ground for picture links and other uninteresting things.)

While none of these links shows exact methods for implementing business rules, they are a great starting spot.

• Stevey’s Home Page - The Emacs Problem

• The Fishbowl: Dear XML Programmers…

• SISC - Second Interpreter of Scheme Code

These links also mention a lot about XML and the associated headaches that come with working with it. As one of them pointed out when you (modern programmers) think about storing data, XML usually springs to mind first. Past experiences with XML and XSLT have left a weird taste in my mouth: They seem like they are on to a good idea, but the execution and use of it just feels so contrived. These articles enlightened me to think about the data with more of a functional “lisp” frame of mind.

Lots of food for thought. Lately I’ve been thinking a lot about the MVC pattern and how it is trumpeted all over the place, yet sometimes it doesn’t seem to solve the core problem of getting the application out the door to the user in a timely and maintainable manner. (And when I say that, I am thinking mostly of web apps.) Perhaps this is a better way…

On Friday, the wife and I decided to stop by Blockbuster and pick up a movie. I had enough cash on me to cover the cost, but I decided to use my check card instead. After the 3rd time they had me swipe my card I thought that I should have just used the cash. The 5th time they asked me to swipe it I told them to swipe it. The guy behind the counter swore up and down that if the receipt didn’t print I wouldn’t get charged….

I should have known better.

They charged me 3 times. *sigh* I thought in the future things were supposed to be getting easier. That will teach me to try and be all slick with my payment options. Now I get to play the fun game of “how many people do I need to convince that this is a mistake”.

Its almost spring time and I’ve been doing some spring cleaning both at work and at home. Yes, its refactoring time.

For the most part I like refactoring. It’s a chance to go back and tighten up the code, correct earlier guesses, and just make things nicer looking. One thing that has really been hammered home to me is the type of refactoring you are trying to do depends greatly on the underlying design and what you are trying to change about it.

Example: One of my home projects is an RPG game written in python. I started out with one code base, and began changing it to meet my ideas/needs. Over time it has change two more times. Yesterday I noticed that a major class (the display that draws the tiles to the screen) had not really been migrated and could use some attention. As I began trying to work in the new changes I saw why I put the project down a few months ago: there’s got to be some major changes because the class is so different than the new architecture. As a result, most of the refactoring tools/techniques I’m used to using (at work)
just can’t be used right now.

At work, I’ve got a pretty well laid out architecture (coded in Java) and most of my refactoring work revolves around streamlining and consolidating methods and classes. The refactoring tools in Eclipse make this a breeze because everything is pretty straightforward. (Also, the strong typing of Java is really helpful in this area, its much easier for Eclipse to figure out what a member variable is in Java than it is in Python.)

The moral of the story? I think it’s best to make sure you build in some flexibility to your designs. This will allow you more choices down the road, especially as you discover new techniques for your particular language. As always, the tools are helpful, but they can only do so much to help you.

No matter what you do, no matter what you are best at, you can always learn something new. This is an awesome article about being a better developer. Anyone of the tips in the article is a starting point for a project to learn something new. Revisiting them will make you a true master of your craft.

Programming is all about moving forward. Being a better developer and making better software is the only way to achieve this.

Once you fight your way through all of the junk (photo’s, xkcd comics, etc.) on reddit, you’ll occasionally find some pretty interesting and enlightening things. A few days ago I saw this link to a Scheme interpreter in Python. I’ve always been interested in the Lisp family of languages, and this is one of them implemented in python. What a cool learning experience.

After looking at that for a while I tried googling for some other examples and found this really awesome Lisp in Python implementation.

Every so often I’ll think to myself “Wow, how hard can it be to make a language?” Then I’ll remember that it can be pretty damn hard (actually I remember my Programming Languages Concepts class, then I get the shakes thinking about all of the edge cases and other complications that you have to keep track of). Seeing something like these links is really educational for me, I get to see how two similar languages have been implemented (and thanks to the comments on programming.reddit.com) and how they could have been done differently.

Sometimes, no matter how much you whine about something, it just won’t go away until you roll up your sleeves and work on it.

I’ve been feeling like whining about how all of these cool programs and games are getting released by everybody these days, and I haven’t been able to get squat done. But every time I started to think about it, I kept remembering that I have a small pile of unfinished projects that could use some attention. Some need a little bit, others need a lot.

I’m a big fan of the “pick something small, get it working, and use that as inspiration to move onto something bigger” philosophy. I use that technique all the time at work to try and get around logjams (be they mental, or load based). For the most part its pretty effective, the feeling of accomplishment builds quickly as small tasks disappear off the old to-do list.

So I decided to apply this to a python project I’ve been twiddling with for over a year. I ran one of the tests for it, and saw an error. I spent about a half hour or so playing around fixing the error and in the process managed to improve the code flow, pretty print my output messages, and uncover a potential problem before it had a chance to bite me. And you know what? It feels good to have gotten that done. A few more sessions like this one and I might actually finish this project up before the end of the year…

As a side thought on this topic: It is really important to use tools that allow you to have a maximum amount of productivity. In a situation where you are time constrained (i.e. a deadline is looming, you only have an hour to play, etc.) every second counts. If you are fighting you IDE, you are not solving your core problems. I thought about using TextMate to try and work with my python code last night, but I kept running into situations where using Eclipse was easier. So despite the “niceness” of TextMate, I had to abandon it for this project and keep on using Eclipse (and the wonderful PyDev plugin). Less twidiling, more working.

I’ve been messing around with Cocoa for a few weeks now, mostly trying to make an OpenGL program. I’ve been making good progress, but man, it does get tedious. I’m not an OpenGL expert, so I’m constantly needing to look things up to make sure I’m on the right track.

Last week at an Apple ADC Tech Talk I saw an example of Quartz Composer.  I had only vaguely heard of Quartz Composer before and hadn’t really looked into it. It turns out that it is a very useful tool for building a neat GUI quickly, and is available as part of the Xcode tools. After getting home from the talk I played around with it and was able to build lots of cool demo-type apps very quickly.

And then… I discovered that it can be integrated into Cocoa apps very easily. I mean, I found this great tutorial on the Apple Dev site, and within 5 minutes I had a Quartz Composer (QC) window running in my test app along side my OpenGL test window. And not a line of code was written. The absolute bets news is that you can expose the internals of the QC window to the Cocoa framework and then manipulate the QC object from your program!

That just rocks so hard. Now I can focus on the mechanics of my program instead of worrying about the mechanics of OpenGL. Of course, the QC isn’t 100% efficient as hand tuned code, but for most of what I want to do with it, its perfect! Thank you Apple!

As a side note, if you are interested in doing Mac development and you aren’t a member of the ADC (Apple Developer Connection), you really owe it to yourself to go sign up for one of their free accounts and check it out. Its a great resource for all things Mac and OS X.

There’s a bit of controversy going on about Mark’s post about full screen writing apps. Mark doesn’t quite see the point of the application (it basically is a word processor that takes up the whole screen) and makes some comments about how he doesn’t like this. His comments were a bit over-the-top, and of course, people took exception to this.

But this is nothing new. Emacs vs. vi, Whopper vs. The big Mac, Windows vs. Mac vs. Linux, Kirk vs. Picard. There have been many holy wars before, and there will be many more. And like most of them, this is one is over something seemingly small and insignificant.

For some people these apps are the best thing since sliced bread. Myself, I don’t really get the appeal of the application. If I want “full screen” editing, I usually just maximize the window, but I’m simple like that. To each his own I suppose, no one is forcing you to use the app.

But one thing I do get is the cool free publicity that these apps are getting! WriteRoom is the leading full screen editor for the Mac, and with Mark’s blog post making the front page of Reddit, I imagine that it is getting a lot new traffic which translates into new sales. At $24.95 a pop, even a dozen extra sales will mean a few extra hundred dollars for the developer.

That’s not too shabby. Hopefully this little flare up will result in the developer (Hog Bay Software) winning a few new customers. Mac Developers can use all the free attention they can get…

My MacBook had a boo-boo. The battery wouldn’t charge, all it would do is show a battery icon with and X in it on the status bar at the top of the screen. I tried all of the tips on the Apple support pages, but nothing worked. So I decided to try my luck at the Genius bar at the local Apple store.

I don’t really know what I was expecting, probably a hard time as that’s what I usually get at stores when I try to get something fixed, but this visit was as smooth as silk. I had to wait a little bit past my appointment time, there was a ton of people in there and a couple of the problems looked bad, but once I was called up I was done in less than 10 minutes!

I explained to the “genius” (sorry, I didn’t catch his name) what was going on, and what I had tried to fix it. He booted up the Mac, confirmed the problem and then brought out a new battery. He plugged it in, booted the Mac and then it showed there was a battery and it was charging. I was so happy (I was afraid it was the logic board) and when I asked what was the problem with the battery, I was told that the chip in the battery was probably dead.

The best part about the whole experience was that the battery was covered under the warranty, so there was no money out of my pocket! Woo-Hoo!

As a side note, after the iPhone announcement the other day I heard that Apple would be providing the customer support for the phone, not Cingular. Customer support is a major undertaking, and I was really wondering how Apple would handle this. Granted, phone support is different from one-on-one support, but everyone I saw at the Apple store today was really nice. Granted most of the customers were nice also, but a few seemed on edge (since their equipment was going to have to go into the shop to get fixed). But no one was steamed or looking unhappy with how they were being treated. Contrast that with most cell phone stores, and you’ll see a big difference. Hopefully Apple will be able to maintain that level of customer satisfaction and service when the iPhone rolls out…