BotFu the Blog - a simple blog with lots of kick!

Time to do a little cleaning...

Jul 5 2008

Today I got a little 'free' time, so I finally did some clean up to my comment board system...I didn't get to do everything I wanted, but I did get some of the more important things done.

1. I added a 'recent' comments bit to the side bar of the blog. (btw, I know a lot of people offer widgets for sidebars and almost all blogs are cluttered with at least a handful of them...I'm wondering does anyone offer a sidebar widget itself? One central location where you can pick and choose from dozens of widgets, configure them, etc. - and then only one bit of widget code to place on your actual site...sort of like feedburner, but for widgets instead of feeds).

2. I tweaked the HTML of the actual comment posting.

3. I added support so that you can request to be emailed about any follow up posts to your own.

4. I turned off the captcha bit and went strictly with my semantic filter approach...although since doing that, I've started getting spammed again. The filter is working, so the spam itself is not getting publicly posted...but it's still annoying (I get an email alert about every post and I then have to either approve or delete them). So most likely I'm going to re-implement the captcha...but I think this time I'll only put it in place for things that don't pass the semantic filter AND have a link in them...

That was about all I got in place today (for my own comment board stuff).

I still have a handful of details I want to implement...many of which I could just do by handing my comment system over to Disqus.com (btw - I'm both a fan and a hater of Disqus right now). My main reason for sticking with my own approach right now is because I prefer to have the comments actually listed as a part of my own content (so I benefit from the limited google juice and such).

However, I really like the idea of being able to unplug comments from the blog and be able to move those around the web to keep the chatter going...I don't have enough of a readership right now for it to really matter, but my plan long term is to build a widget that will allow people to do that with my comment threads as well.

It will sort of be the complete opposite of the Disqus approach (instead of a centrally controlled comment system, it will be a distributed, individually controlled comment system -- each blog owner can simply off a widget to allow their comments to become unplugged...but all the actual content will still always end up on the blog owners site)...if/when I finally get around to building it, I'll share more of the details (honestly I haven't mapped it all out in my head just yet, I've just been building a sort of 'wish' list).

For now though, let's start with the baby step of playing with the upgraded comment system here...so let me know what you think...in the, uh, comment board below

Twitter me this...

Jul 4 2008

So there's a slightly old (in internet times) thread over on NextNY going on about how Twitter can make money (it's in response to an orig. post by Nate Westheimer).

I sort of joined in on the conversation a bit late, but posted a few of my own quick thoughts out there yesterday...and since then I've been thinking a bit more about Twitter and what really should be done with it.

If you've been following this blog for any bit of time, you'll probably remember that I'm not a real big fan of Twitter...but I do have to say that enough other people are fans of Twitter that it's now got large enough adoption that I think some really cool things could be done with it. Here are some of my basic ideas:

Warning many of these could be copies of thoughts others have had but due to my lack of memory I now believe to be my own...

1. Twitterpedia...basically I think Twitter should take all the data gathered each day from all the feeds, apply some intelligent filtering, and present that data as a history of the world for that given day (split up by topics, events, etc.)...it would be very much like building a whole wikipedia for a given day every day of the year. Over a very short period of time, it would be an incredible resource of information. If twitter doesn't do this, I'm sure google will/should.

2. Along the same lines, I really think the power behind Twitter is very much like the power behind google...that is the collective effort of the masses. In google's case it's the collective masses doing searches that help determine the quality of the content (and turn out to be just what advertisers are looking for)...in Twitter's case I think it's about the collective masses reporting about the world they are experiencing...and I think the trick is to figure out what related market could really benefit from this? My opinion/guess is that to start, the various media/news services. If Twitter got to work on some serious data aggregation, they could build some really impressive real-time news reporting services...and then they could turn around and provide those feeds directly to news services (ala the Associated Press business model)...

Anyway those are the two main ideas that have been clouding up my brain the last 24 hours...well that and this whole 4th of July thing (we spent the day at a great birthday party for a 6 year old).

You down with MVC? Yeah you know me!

Jul 3 2008

So on the way into work today for some unknown reason I was thinking about MVC design...

Note: For those readers of you that don't know, MVC in this context stands for Model/View/Controller, and is basically a very popular framework design pattern for software development right now.

The basic idea in one variation or another is:

Model - relates to your data structure; most normally this means your database and your database structure, but sometimes it also refers to things like XML files, flat files, and other data stores. In very general terms you are supposed to store your data related logic and structure in these files.

View - relates to your user interface; most normally this means your graphical user interface (ie. in web applications it's the HTML/Javascript that is eventually presented to the user). In very general terms you are supposed to store just the things that will be rendered to the user in these files (ie. just HTML/Javascript)

Controller - relates to the in-between glue; In very general terms you put all the code here to tie your data to your view.

With that (very) basic structure defined now, you might be thinking "OK sounds good and logical and all, but where does all my business logic code go?".

Good question - lots of people seem to debate this as some favor shoving as much as you can into the models, and some favor shoving as much as you can into the controllers...but here's the thing, they are both wrong!

What nobody who talks about these things seems to tell you is that all your business logic should be in it's own classes (or files if you aren't doing an object based approach).

Your controller should really be the glue that pulls not only your models and your views together, but also your business logic classes. Sure there will be some logic that goes into controller (just like there is inevitably some logic that goes into your models and your views) -- it is after all still programming.

But the basic idea is to move your specific tasks out to their own classes/files...this way your MVC project can use them AND any thing else you ever do can use them (the whole benefit/idea of classes and reusable code)!

For example, if you have a class that handles all the fight action for something like BotFu fight I can easily plug that into my web based MVC application...and I can easily write another program that is scheduled to run as an automated bot who uses the same class to participate in fights...and I can easily write another program that listens for incoming emails and performs appropriate fight commands...

I think you get the point, with proper design and thinking, you can write one class that has your real business logic and then simply use different types of glue to stick that class into various other actions...

MVC is just one of those 'actions'.

Anyway - thinking about all of this got me to think about lots of other things 'they never tell you' about coding and development...and that got me thinking it might make for a pretty good book (or at least some nice rambling blog posts like this one)...what do you think?

Reactive coding...

Jul 2 2008

Today I was notified about some fubnub problems - for some reason del.icio.us feeds weren't publishing, and last.fm feeds were ignoring their schedule and over publishing. This def. needed some investigation.

After a few quick tests, I narrowed the problem down to two things:

1. The Perl script that handles the scheduled posting was crashing on the first del.icio.us feed it was getting to...so it never updated the database to note what had been published. It was just a coincidence that the last.fm feeds were being published first.

Fixing this problem was very simple as I just needed to wrap the publish command with a eval block (Perl's version of a try/catch block).

2. The del.icio.us feed was crashing when attempting to publish to a blog. The cause turned out to be that the del.icio.us feeds often contain no standard ASCII characters (who knows why) and the XMLRPC module I'm using didn't handle that well.

Fixing this issue took a little more effort, but in the end it was really as simple as intelligently implementing CGI::escape. What I mean by intelligently implementing is that I had to pick the right spots in the overall process to escape the data and that itself took a little bit of reflective thinking about the overall steps a feed goes through in the system.

Now you might be wondering why I didn't have these fixes in from the very start. I mean with very little thought you can forsee these type of problems and be proactive about avoiding them.

Well that brings me back to the title of this post...you see by default I'm much more of a reactive than proactive coder. In my defense I do try to think of potential problems when hacking things together (though it's very hard with personal projects because I generally don't design then build...no for my own projects I tend to build then design or at best build and design).

Really it all falls back to my overall development philosophy:

1. Make it work.
2. Make it good.
3. Make it fast.

Right now fubnub is still in phase 1. For the sake of getting things working I often knowingly leave a long list of 'to-do' or 'to-fix' later issues. (and sometimes even I just overlook or miss obvious coding or logic flaws -- but hey I never said I was really all that smart!)

Besides, my follow up philosophy involves being a very active reactive developer...that is, a problem isn't a problem until it's a problem...and once it's a problem, it's a BIG problem that needs to be addressed immediately (or as immediately as my schedule will allow).

I feel like I've stuck to that so far with fubnub...but I still have a LONG LONG way to go (trust me you don't want to see the list of known 'to-do' and 'to-fix' issues I already have for fubnub)!

I'm still alive...I think.

Jul 1 2008

This past weekend I had a good friend in from out of town and a project deadline rapidly approaching...so I had very little free computer time to play with my own interests and projects.

In fact, the deadline for the Bowker project I've been working on was today (but got pushed to tomorrow)...so Sunday night I was working until about 2am, Monday I worked at the office from about 8am till 9:30pm, and today I did about the same schedule...

Normally I wouldn't be doing quite the rush and crush...but last week the project went from a team of 3 internal developers (including myself), and 2 external developers...to just me and the 2 external developers. The external team is not always available...so the past few days it's been mostly my responsibility to make sure we hit this deadline...

And of course this meant bashing my head through a few thousand lines of other people's code (this project is mostly a mix of PHP and Javascript tying to an Oracle database and a handful of web services serving up XML -- the web services are also part of the scope so really I'm helping to build both ends)...all of the front end code is managed through a closed coldfusion based CMS system (called Prism)...and all of the web services are built in a custom PHP framework (that is somewhat like PHPCake without actually being PHPCake)

In the end this all means that I've been spending enormous amounts of time getting to know a number of systems that I probably won't/can't reuse...and there isn't even that much from the experience that I can grep out to share with you all here (well that's not entirely true as I'm sure there are a handful of rants I could really pour out from all of this).

Of course they do pay me pretty well for dealing with this type of thing, so I guess I can't complain too much...and after all I do like a challenge!