Thoughts tag:spencerchristensen.com,2008-01-03:/blog//1 2008-11-28T20:33:57Z Movable Type Publishing Platform 4.01 Light reading over the Holidays tag:spencerchristensen.com,2008:/blog//1.12 2008-11-28T19:44:23Z 2008-11-28T20:33:57Z Spencer
The benefits of vanilla CGI vs FastCGI for Perl apps
   Interesting read from Mark Stosberg.  I'm quite familiar with Mark from his work with CGI::Application,l as I've been a fan of that perl module for many years now.  I think there is a bias here that I need to mention, and that I think Mark and I share.

   What people value in a web development process/toolkit is significantly weighted by the process and tools that web developer a) first learned, and b) is most confortable using.  Meaning that a developer whose first experience programming web applications was with Catalyst and has since found Mojo more comfortable and uses it regularly, will have a different set of "values" (or criteria by which other things are compared) than a developer who started web development with straight CGI.pm and is now a Jifty user.  (this bias should extend itself to any and all programmers, but I find it more appearant in web developers where there is more contention about which toolkit is better than another).

   Whew.  OK, after all that, I have to say that I agree with Mark and feel that "vanilla CGI" is a great way to get things rolling as a developer without having (usually) to change a thing to a web server.  Just write your code and go.  I also feel that if people expect things to run slow in CGI and not in mod_perl or FastCGI because that is their biased environment of choice, then they will program accordingly.  Meaning that they will write code that is slower, heavier, etc.  because "oh, mod_perl will take care of it and it will be fast enough,"  or something similar.

   I've never actualy heard anyone say that, but I hear things close to it from other developers (Java web developers mostly) who feel like everything is perfectly normal when you have to rely on huge complex tools and frameworks and middleware and dedicated containers and separation of tiers and abstracted everything and this and that and the kitchen sink too just to develop web applications.  This "normal bloat" I'll call it, is where that bias I mentioned earlier really comes out.  If people can't even see that their tools and process is overly complex, burdensome, and has a moderate to high degree of dependencies for normal development and opperation, than how can you persuade them that it is perfectly fine to live without that?  How can you make them see that that is not "normal" for many, many other web developers?

   Living without FastCGI???  Shudder.  You're still using perl for web development?!?!?!?  How can you live without Hibernate for data access (or replace with your favorite language specific tool here)?!?!  Running perl CGI without mod_perl??? Are you stupid??

  Yes, stupid like a fox. Err... I mean, doh.

]]>
  • Lightweight code, lightweight framework, lightweight resource consumption- don't add things that I don't need, don't load a bunch of libraries and extras that I didn't ask to be laoded.
  • Allow me as a developer to control everything (or as close to that as possible)- I want to control error messages, logging, database connections, access to templates, what's in those templates, code flow, etc.
  • No dependencies on editors.  EDIs can be nice, but they should not be required to write/edit normal code (whatever normal means to you).  You should be able to chose an editor for your code that has nothing to do with your code.
  • No dependencies on system administration.  This is a tough one for me to admit to because I do so much sys admin work every day, but for a web development standpoint there should be no reason for a coder to manage/deal with configs and restarting system services like a web server.  The web server should be configured once and be able to run a coders code without restarting.


Ok.  I think I've rambled enough, but I hope my view point has been laid out.  I agree that web development using perl and straight CGI is perfectly normal, fast, and reasonable.  Others who scoff otherwise need to check their biases.


]]> Sleep and the art of staying awake tag:spencerchristensen.com,2008:/blog//1.11 2008-11-13T18:28:35Z 2008-11-13T18:35:35Z Spencer
Sleep is an interesting thing.  For some people it is an absolute necessity for basic functioning from day to day.  For others it is just a nice-to-have optional sort of thing.  However, when you go for long periods of little-to-no sleep, anyone will feel the effects.

I'm trying my best to keep my lack of sleep from affecting my day to day behavior and general happiness, but it's hard.  One of the main things that helps is good food and a good shower.
]]> Software design patterns and excess tag:spencerchristensen.com,2008:/blog//1.10 2008-05-04T16:05:59Z 2008-05-04T16:54:43Z Spencer
ORMs (Object Relational Mappers) are a basically a way to have a OO layer between your application code and your RMDBS.  There are some basic "features" of an ORM, but not all ORMs support all of these.  In any case here is a list of common features:

  1. OO interface to tables, rows, functions, etc, in your database.  So you can use native application code and OOP to interact with your data.
  2. A more elegant/simpler API to interact with your database.  Many ORMs use some other database API under the hood, but add routines and interfaces (or simplifies calls) that the normal API lacks.
  3. Object (data object) persistence.  So that you can create an instance of some data you are modeling and then be able to store that object and revive it later with state preserved.
  4. Abstract the interaction between your application code and your database such that in the future if/when you need to move to a different database you application code will require as little change as possible.  Ultimately, changing databases should be a matter of configuration files, or perhaps even less work.  And your app code wouldn't even know the difference between Postgres, MySQL, SQLite, or something else.

]]>
  1. ORMs are slow.  For all their nifty-hood, ORMs add more abstraction, more layers of code, and therefore more overhead with interactions with your data.  For performance critical apps, ORMs are yet another thing to be concerned about.  How many times do application designers have to chose between portability and performance?  This comes up often.
  2. Do they really make your app code better?  Or more portable?  Or easier to maintain?  Or is there a lot of work just to get an ORM configured just for the theoretical chance you app will run on a different database?  If you spent some time making standard SQL that should work across databases, isn't that 95% of the job already?
  3. Is forcing your database into app code objects a good thing in the first place?
  4. Is there an design weakness with too much OOP?  When your code crosses a threshold of complexity due to so much abstraction that no one is really able to know what does what and what the execution code path really looks like, is there a problem with obfuscation by code bloat?  This one doesn't so much speak to ORMs directly, but in the general direction of software design that ORMs can point to.
  5. ORMs are in style at the moment, but in reality many of their features have been in use in some other form for quite some time.  Is there really much benefit in going "all the way" with them?

So, as you can see I have more questions than answers here.  Not really having a lot of experience using any ORM, I may be just simply a noob and not really get it yet.  But there are other factors going on in my life that support concern number 4 above in regard to other aspects of software design.  And so I don't think that my concerns with ORMs are simply noob-ish.

I'll post again with more another time.
]]> Where's your cube again? tag:spencerchristensen.com,2008:/blog//1.9 2008-03-20T18:03:33Z 2008-03-20T18:11:55Z Spencer http://www.walterzorn.com/jsgraphics/jsgraphics_e.htm).

That way, all you would need is to maintain the data through an easy management tool, then your map is updated realtime online.  And anyone can go to the map in their browser and mouse over a cube and get info, or do a search and get a highlighted cube within the map of what they are looking for.

]]> Microsoft Exchange problems tag:spencerchristensen.com,2008:/blog//1.8 2008-03-03T07:05:17Z 2008-03-03T07:23:56Z Spencer Zimbra and go with Microsoft Exchange.  The main points that made them want to switch were: 1) the calendaring/booking conference rooms/scheduling/sharing calendars didn't work very well in Zimbra and is "known to work in Exchange", and 2) email and calendaring for a large organization just needs to work.  Now- I must admit that this is my take on what has been going on, and I may be wrong here.  But, with that- my experience with Exchange has really sucked.  The points for moving to exchange are one-sided.

Exchange doesn't work well with free software.  Exchange is designed to work with Outlook, and no other client is even considered important.  They do claim to have IMAP support for other email clients, but Microsoft's IMAP seems to be unstable.  It continually has problems freezing up.  About 3-5 times per day the IMAP service on the Exchange server hangs and needs to be restarted!  Lame!  And so all Thunderbird users are stuck playing this "is my email working now?" game all the time.

The other thing is calendaring only works with Outlook clients.  Exchange doesn't support iCal/WebDAV or any other open standard.  So for calendaring we pretty much are forced to use the web interface for Exchange.  And the web interface for Exchange has two versions- a full featured one that only works on IE, and then a crippled one that is served to all other browsers.  LAME again!  So all the "features" of switching to Exchange are really only features for Windows users who use Outlook and IE.  If you use anything else, then your email and calendaring just got a whole lot worse!!

Zimbra did have some known bugs in their calendaring, especially in booking conference rooms for meetings.  However, I believe the folks at Zimbra have been working on that for their next release.  Email never was a problem with Zimbra for any user that I could tell- Outlook or Thunderbird or whatever.

But I'm not bitter.... yet.

]]> Cover your bases (musically) tag:spencerchristensen.com,2008:/blog//1.3 2008-01-04T19:12:18Z 2008-01-04T19:54:46Z Spencer
I stumbled across SecondHandSongs.com and found that there is a database of cover songs (it only lists covers that were recorded and put out by a record label, no do-it-yourself or amateur covers allowed).  Fascinating.

Now I come to the idea part.  I think it would be cool to have a plugin for your favorite music player (Banshee, iTunes, WInamp, etc) that looks up the song from your play list and lists covers of that song, with other info perhaps or links to find more info.  It would be really cool to see a list of others that did that song and be able to click on them to hear a sample of their version, or a link to a music service (or store) to buy/download the other version(s).  And perhaps a way to rate them too?  Not sure about that one.

Finally a way to build my own collection of nothing but covers of the song "Moon River"! (this is a joke, I actually hate that song).
]]> Hot Dang. tag:spencerchristensen.com,2008:/blog//1.2 2008-01-03T15:21:52Z 2008-01-03T15:29:34Z Spencer
I like Movable Type a lot.  It seems to be more intuitive than a lot of the other ones I have looked at and tried.  I will be moving my posts from my other blog to this one over the next little bit.
]]> Minimal AJAX toolkit tag:spencerchristensen.com,2007:/blog//1.7 2007-11-15T00:45:21Z 2008-01-07T00:49:21Z Spencer So there is a wide world of tools and methods for "web 2.0", and for developers it is hard to know which one to chose to use and support.  I have tinkered with two AJAX toolkits and found things that I liked and disliked with them.  But overall I found that they were both too big and too feature rich for simple use.

So it occured to me that for some of my simple projects all I needed was bare-bone functionality, meaning the ability to fetch the contents of a given url.  Beyond that I can do what I need in small simple javascript.  I didn't need fancy event handling, or animation, or auto-complete drop downs, or such.  And if I did, then I could probably do that my self later, as long as I had the ability to easily fetch a URL.

 

]]> Thus I started putting together a new AJAX toolkit named oddly enough AJAXMinimal.  This is comprised of a single .js file that provides an object with one method call, fetch_url().  That's it.  Simple, easy to use.  Does the job.

Let's dive into an example of how to use AJAXMinimal, as I think that is a good way to explain the hows and whys and such.

I have an HTML page with three buttons, each of which I want to fetch a given URL and then load the contents of that dynamically into a certain  DIV within my  page.  Thus dynamically changing my page without refreshing the whole thing.  Here is body of the HTML:

<body>
<h1>Test page index</h1>

<form name="main_form" action="" onsubmit="return false">
<input type="button" name="button1" id="button1" value="Button 1" onclick="load_html(this);"/>
<input type="button" name="button2" id="button2" value="Button 2" onclick="load_html(this);"/>
<input type="button" name="button3" id="button3" value="Button 3" onclick="load_html(this);"/>
</form>

<div id="outer_div">
Outer Div
<div id="inner_div">
Inner Div
</div>
</div>

</body>
 

Now to jump back, let's look at the javascript at the top of this file:

<script type="text/javascript" src="/js/ajax-minimal.js"></script>
<script type="text/javascript">
function set_inner_html(am) {
    var inner_obj = document.getElementById('inner_div');
    if (! inner_obj) return;
    inner_obj.innerHTML = am.content;
}

function load_html(button) {
    var am = new AJAXMinimal();
    var button_number = button.id.substr(-1);
    var url = '/cgi-bin/blah';


    var args = new Array();
    args['button_id'] = button_number;
    args['blahblah'] = 4444;
    args['string'] = 'this is a string argument';


    am.fetch_url( 'GET', url, args, set_inner_html );
    return;
}
</script>
 

As you can see, we call load_html() on a click to the buttons which creates an AJAXMinimal object.  The fetch_url() method takes 4 arguments:

am.fetch_url( request_method, url, args_assoc_array, function_to_callback );

  •  request_method is GET, POST, HEAD, or whatever.
  • url is the url to fetch.  This may already have query string args or not.  And can be relative or absolute, but keep in mind the restrictions of using AJAX calls- you can't fetch someting outside of the original domain.
  • args_assoc_array is an associative array of arguments to send with the request.  With the GET method, these are turned into query string args that are then appended to the url.  With POST these are sent as the contents of the POST request.  This arrary should be set up as arr['key'] = value.
  • function_to_callback is a function that will be called when the URL requested has loaded.  This function will be passed one argument only, the AJAXMinimal object itself.  It is within this function that you define and pass in that you do your own thing.

 

In the example above, set_inner_html() is the callback that simply sets the innerHTML of our DIV with the contents of the URL.

That's it!  Simple.  Easy to use.  Easy to understand.

To see this example in action, try it out here:

http://spencerchristensen.com/test_html/index.html

 

 

]]> Celtx will make you a rock star screenwriter tag:spencerchristensen.com,2007:/blog//1.4 2007-09-09T23:15:44Z 2008-01-07T00:19:32Z Spencer If you are going to write a screenplay, then you really should look into Celtx (http://www.celtx.com ).  HandsCeltx down, this is the best tool you can have to begin your creative process.  There are many ways you can write a screenplay, and many tools to help you do so.  But Celtx combines all the best features, and many that others don't have, into one product.  And one of the best things about it- it is Open Source!

It is based on Mozilla's FireFox web browser, and works on WIndows, Linux, and Mac OS X.

]]> I learned a great lesson a few years ago from one of my film instructors which helped me understand a very important princile of filmmaking- technology doesn't make your film great, you make your film great.

This holds true with screenwriting software as much as it does with any other technology for filmmaking.  A great screenplay can be written in just a simple word processor like Word or WordPerfct or Open Office Writer.  Thousands of great screenplays were written even before computers were invented!  So don't think that your screenplay will suck because you don't own a copy of this software or that software.  That is a bunch of crap.

So, why am I seemingly contradicting myself?  I just sadi that Celtx is the best screenwriting software and will make you a rock star, but that you don't need it to be great.  Well, I want to set the stage that if you are looking for something to make you a great filmmaker, that is call film school my friend.  You can't just buy and start using a piece of software and expect your work to be good.  You need to be at a certain level already in your skills, expectations, and creativity such that you could create a good idea for a story on your own.  Only then will the tools you use matter, and even then only to the degree of how you use them to make a difference.  So, bottome line: once you are comfortable with yourself as a story teller, then leverage tools to help you do that better.  The tools wont tell your story for you, you still need to do that.

screen shot of editing a script with CeltxOk. enough lecturing.

Reasons why Celtx is the best screenplay software out there:

1. It is free.

2. It has all the nice features of commercial screenwriting software: auto-formatting and indenting, scene breakdowns, character breakdowns, reports, etc.

3. It has built-in scheduling and calendaring.  This really is cool if you are a writer/director who is going to produce and actaully shoot the film that you write.  You can map things out in a timeline and schedule everything in one place.  Very cool.

4.  It is very easy to learn and use.  It has a very natural layout and functions as you would expect.  User interface is designed well.

5. It has a large and growing community around it.  There are furoms, script sharing servers, FAQs, and lots of online help.  Celtx helps you feel connected with other writers.

6. Try it, and you'll like it.

 

]]> Linux Server Hacks by Rob Flickenger (O'Reilly) tag:spencerchristensen.com,2007:/blog//1.6 2007-09-02T23:41:42Z 2008-01-07T00:43:03Z Spencer book cover imageThis book is awesome.  I learned so much from it that I have placed it second on my list of books every software engineer should read.  There are so many great topics covered in such a easy to read and understand way that you can't help but want to try them out.  And after trying a few out, you start to wonder how on earth did you live without some of these things.  

There are a few books I have read that I really got a lot out of, and this was one of them.  I was familiar with a lot of the things discussed in here, but not at any great detail (at least with some of them).  I even learned a thing or two with perl (imagine that!).

]]> Many of the basics are covered in the book, but not all.  I don't pretend to think that this is meant to be indepth or span all needed sys admin knowledge.  It is a list of some good tips and guides for day-to-day sesrver admin work.  But there are things in here that I didn't know about and have come to really appreciate.

One thing- I have never really been a solid bash scriptor until I read this book.  I felt much more comfortable in perl rather than bash.  But there are a few hacks in here that show some very simple and elegant command line trickery that impressed me.  Like the hack fo finding users on a system who are hogging up all the disk space.  Also, the one about IP address failover from one machine to another was an impressive one.

If you are not using SSH public keys or aren't familiar with public keys, then you need this book.  There is a whole chapter dedicated to SSH and all the lovely things you can do with public keys (automate just about anything, securly).  Also, if you aren't familiar with CVS or other version control systems, there are some great summaries to get you started.

Don't plan on learning from scratch with this book.  It is not for the novice.  You need to be familiar with the command line and with some basic utilities.  But this will help you move from intermediate to a more  advanced systems administrator.

I was a little disappointed that they spent so many hacks talking about MySQL and no mention at all about Postgres.  That is a real shame.  Postgres really should be in more sys admin's set of tools for things.  But I won't rant about that here.  :-)

This book is well written and covers a nice variety of topics.  Not all of it will be new to you, but there will be a nice gem to make your day if you look for it.

]]> new site tag:spencerchristensen.com,2007:/blog//1.5 2007-09-02T23:38:34Z 2008-01-07T00:41:13Z Spencer So I finally was able to get the domain spencerchristensen.com.  It was taken for a while by someone else, but when I check just a couple of weeks ago, it was available.  So I am setting up my personal site.

I have had a personal site for years at  http://www.mecworks.com/~spencer , but this has fallen dormant for a long time.  I hope to get back into maintaining a personal site with this one.  I still don't have a lot of free time to give to this, but hopefully I can at least give more that what I have been doing.

]]> On my old site, which is hosted on my brother's server, I had references to my various projects and interests in independent film and also web development.  I will be carrying a lot of those things over to this site and updating them.  I am also expanding the areas of interest that my personal site covers.  I have several interests beyond those, and many experiences that I haven't written about yet and hope to include a wider range of stuff here.

This is about it for my first post.  I'll be working on several other posts soon, including my resume.

 

]]>