Tales of the Cowmosher

4 Cent Webhosting

2006-07-13T15:25:10Z

The idea of getting a domain name registered felt overwhelming for me at first, but after doing some research, I quickly felt more comfortable with how the market works. There are probably thousands of companies offering domain name registration, either directly or as resellers, and many provide a wide range of support services. I started by learning about the different services being offered and making a wish list of those I wanted for myself. With that list in mind, I set out across the web in search of the companies offering those services at the best price. Once I had a few to consider, I started investigating those companies more closely.

I could have gone the cheapest rout. There are always the bare bones companies that offer great prices for very little beyond the basic services. I may be cheap, but I’m also a part-time lazy person. The company I wanted was going to make life easy on me, not be another unnecessarily complex responsibility to manage. Besides, most of the cheapest offers were for a limited time only. Renewal costs, which were often hidden in the fine print, could be many times higher than the original registration price. That is a fine point to avoid.

I could have gone the most expensive rout. It’s easy to fine the premium package deals that cost so much they must be good. In fact, some are indeed providing great service for a huge price, but some are just charging the high prices. I found there wasn’t always a one to one correlation between premium price and premium service. I might be lazy, but I’m only a part-time lazy person. All that service is nice, but I didn’t feel I could make use of it.

I chose to go with webhostfreaks.com, and I strongly recommend their services to others. In my opinion, theirs is a middle of the road deal. The domain name registration is costing me less than four cents a day, and the services are certainly making my life easier. Besides the price, there are a few points that really fit my needs.

My account is configured to automatically charge my credit card. That takes all the work out of making sure the domain doesn’t expire. If I hadn’t received an email reminder, I would have forgotten all about the expiration date. If I had lost my registration, either just for it going dead, or due to some domain name clearinghouse snatching it up, I would be mighty angry with myself. Fortunately, I don’t need to remember to do it myself. The automated service keeps me informed about the renewal process. Not every company will bother to remind you when your domain is about to expire.

When my automated renewal failed due to an error, I remembered that I had canceled the credit card associated with my account. That might have given me something to worry about, but my questions to the sales staff at webhostfreaks.com were answered within minutes. I was able to log into my account, update my credit card information, and pay my bills in about a minute. That is some damn fine help staff.

When I started down this road, it seemed like the end was a long way off. There was some work to be done, but it was well worth the effort. Now, one year later, I’m confident I made the best choice. I can go back to forgetting all about this domain name registration process, and get on with my lazy life.

Myspace Makes the Shitlist

2006-07-12T17:19:51Z

One of the latest additions to the Cowmosh website is listings for websites and programs known to have accessibility issues. Hearing of the growing populaerity of myspace.com, I did some investigating. When I tried to register, I ran into another of those sight key validation road blocks. Unlike the google.com account registration which offers an audio key option, myspace is living in the past.
Oddly enough, this older sight key trick is more likely to be hacked by optical character recognition then the audio key is to be hacked by voice recognition software. So, the best way for us blind users turns out to be the best way for programmers. Imagine that; an adaptation that works for everyone.
Its important to note that both methods need to be offered, since deaf users will still prefer the sight key method.

Tracking Missing Files

2006-06-23T12:13:21Z

I have my Apache web server configured so when anyone requests a non-existing file, they are redirected to a customized web page. At first, that was more fun than actually useful, but when I patched in my hit counter, it started racking up hits right away. After the shock wore off, it occurred to me this was an opportunity to automatically track the missing files and who was requesting them.

I move and rename files on my dev site all the time. That's bad practice for a professional web site, but development practically requires it. The idea of missing files or broken links wasn't so much a shock. The fact is I check every page on my dev site and every link was working for me. The number of hits on my missing files script didn't make sense. So, the investigation began.

It could be that someone out there was keeping a broken link to my site. I might have moved or renamed the file on them. I needed a method to log the who, what, and when of the missing file requests. That method came in the form of a simple PHP script patched into my missing files web page.

The script does little more than create and open a log file and note the file requested, the IP address of the user making the request, and the current date and time. With just that, I was able to figure out where to look for the allusive missing files. That PHP script includes these 8 easy lines:

<?php //log missing file request
$missing_file = $_SERVER["REQUEST_URI"];
$ip = $_SERVER["REMOTE_ADDR"];
$now = date("Y/m/d H:i:s");
$fp = "missing_files.log";
$link=fopen("$fp", "aw");
fwrite($link, "$missing_file, $ip, $now\r\n");
fclose($link);
?>

Note: If you are wondering how to configure your web server to use a customized missing file page, see the Apache configuration file for clues.

In my first case, I found that my link to my style sheet was not functioning as expected. Rather than pointing to a static file location, it was more dynamic. The result was many pages were not displaying properly, and the missing file request was silent. I would never see an error message to indicate the problem. In fact, I never saw the error until this investigation directed me to it.

With the combination of my web server redirecting missing file requests, and the resulting triggering of script functions, I can now stay on top of broken links, and missing or misnamed files. I'm not relying on users to report, and I don't have to click all over my site. I just check the log, and if the missing files log is itself still missing, it's a good day.

Running from the command line

2006-06-07T14:11:35Z

I’m Not sure how, but I missed a rather important part of writing code in Python. In several beginner tutorials, the instructions are given as typing simple code in the Python command line. That’s fine for testing extremely simple code. More advanced samples would often instruct to import a small script. Again, that always did the job. What wasn’t being said is how that is all bad practice.

As I have mentioned before, I’m an idiot. I follow the tutorials and do my best to figure out where my scripts go wrong. When I am solidly stuck, and have run out of options, I look for live help in chat channels. Imagine my shock to learn that I had skipped over this essential part of scripting in Python; never develop from within the Python Command Line.

I have written tens of thousands of lines of code that simply do not work as they were intended. Sure, they work from within the Python Command Line, but nowhere else. When I got to the point of converting my Python scripts to Windows executables, they failed in mysterious ways. Even experts had little or no help for me, when I presented my case in various chat channels.

It’s likely that Linux users will never encounter this problem. It’s also perfectly understandable that many developers will see this as pure stupidity. I am that stupid, and I got this way by reading online tutorials written by experts. There exists a problem, and that is that tutorials for beginners are often not stupid enough for me.

The most important instruction to remember is to run your Python scripts from the command line. Don’t use the Python Command Line. That sounds like double talk, I know, but the difference between ‘command line’ and ‘Python Command Line’ is enough to ruin months of my hard work. Please notice that your operating system’s command line is very much not your Python Command Line. While you can write code directly in the PCL to test it, the OSCL is a place far outside that realm.

Yes, I have been reading tutorials that ask several times over to “now run the script” and I was thinking that meant import the script to the Python Command Line. It always seemed to work. Somewhere, way back at the start of my reading tutorials, I must have skipped over the part that explains how to run scripts from the command line. So, just in case anyone else is not sure what I mean, here it is.

Please note that we assume you have Python installed on your Windows computer at ‘c:\python\’ and you also have a file named ‘myscript.py’ at ‘c:\python\’.

First, get to your operating system’s command line. In Windows, we find it in the start menu> programs> accessories>command prompt

Next, change the active directory to your Python main directory with the ‘CD’ command. Type into your command line like this: “CD C:\Python\”

Then, run your script using the python.exe like this:
“python.exe –m myscriptname”

That’s the true and proper way to run a Python script. Of course, you could open your Python Command Line and import that same script. That will usually work, but not always. I still feel safe in testing code from within the PCL, but running the code from the command line is a script’s true test.

Python MUD codebase

2005-12-18T16:03:22Z

Hello my name is James, and I’m an idiot. I just discovered the concept of a MUD codebase. It’s a simple one, but don’t shoot me for being oblivious to it for my whole life. A code base, it turns out, is the core of the MUD server that performs the menial tasks that are required for basic functionality of the server. All the sending and receiving of messages, storing and retrieving of data, and socket management is usually done by such a mysterious code base creature. In essence, it is a mindless zombie awaiting instructions. What is given beyond that, in the way of instructions in code, is another topic altogether.

In the normal world, that one out there somewhere apparently just out of my reach, seems to consider this common practice. Devs (software developers) prefer to build a code base, then modify that to define the game and how it will work. With the fundamentals out of the way, the creative people can take over. They would have another level of functionality overlay the code base and make the difference between each specific MUD game. The coders get to define how combat works, how economics and weather work, and all those intricacies that give a game its personality. That seems all well and good, but they all reach the same huge obstruction.

As one might imagine, allowing a collective group to write code to run on the code base has some safety concerns. Being that Python is powerful, and potentially destructive, those coders had better be trust worthy individuals indeed. From my recent reading, it has been brought to my very limited attention that Python lacks the ability to limit its realm of operation to a specific location. That is to say, it knows no bounds. Once installed and functioning, there is no way to make it stay in some sort of safe zone. Therefore, any code Python acts on has the potential to effect any portion of the local machine. Of course, there are safety measures attempting to thwart such malicious attacks, but not everyone is of the caliber required to deal with attacks from within.

I understand there are some devs trying to build a cage strong enough to keep Python from rampaging all over a hard drive, but as of this post, I have not found it. I’m no genius, but there does seem to be another solution. Maybe I’m just convinced of my own correctness, but does a MUD server need to be defined through the use of so much hard code?

I believe it to be possible, if difficult, to build a fully functional Python MUD server with options or perhaps modules that offer flexibility while still being safe. A code base could be designed to include the basic operational functions while interchangeable packages overlay the code base to become the game. Furthermore, each package could be designed to allow for options to be chosen instead of being coded. It is my hope that such a system would open the process of creating MUD worlds to a much larger audience. It would be great if all that was required was the interest, the creativity and the time to take part in the creative side of MUD games. Requiring even a limited understanding of a programming language seems a factor that might be unnecessarily prohibitive.

Making a Windows executable file

2005-12-07T17:15:48Z

After a bit of trial and error, I finally made one. I've wanted to have the option to distribute my Python applications as executable Windows files for
a while now, and it seems like my first impressions were correct. I should explain that I'm not one of those absolutist Linux users who refuses to even
accommodate the needs of Windows users. I’m about making life easier for everyone and anyone who is interested in using my software. After all, it’s the end user who determines how and when or even if an application will be used. And, knowing that a large portion of the potential user population demands that programs be not only reliable but also easy to use, it falls to me to make every effort to satisfy those demands. This sort of file type is a great step toward meeting that goal.

Because an executable file is fully self contained, it can stand alone as a single file download. It runs without the need for Python to be installed on the local machine, and it can even run entirely independent of other Python programs already running on the same machine. But, the end user is probably only concerned with the basics. An executable is just that, it can be run like any other program with which a Windows user would be familiar. Not even needing to be installed, these files are about as user friendly as can be imagined.

I expect that Linux users don’t give a monkey’s nut about Windows executable files. They know they have it good and I’m not looking to tell them Windows is better. I’m simply trying to reach a larger audience for my projects. Even the most devout Unix user must realize that there is an enormous and still growing number of Windows users. Treating them like undesirable intruders into the computing world seems, to me, to only limit the potential of the software I produce. Having been in the position of being unable to make use of an application because it was not distributed for Windows, I’m devoted to making all my Python programs available for everyone to use and enjoy.

I have further plans to distribute either MS installer or WinZip self extracting files for Windows users. These would be a single file, easy for download, and unpack the executable into a uniform and well placed directory. They may also install desktop and/or start menu links. I’m not yet certain how, but especially in the case of my MUD server, I plan to distribute the executable as a Windows service which would run ‘silently’ in the background. I have a great deal more to do on this topic of development, but I’m excited about the possibilities.

Expectations of a wall

2005-12-06T14:28:15Z

I don’t surf around much, but I do read lots of forums and postings involving programming. I find it more than a little bit odd how often I find students of computer sciences and novices like myself professing their interest in writing a MUD code base in the Python programming language. At first, I found it encouraging how many others shared my own opinion. Recently though, it’s beginning to worry me how few have put their words into action.

For the number of people proclaiming their interest in writing a Python code base, there seems to be an alarmingly small number of the creatures roaming the web.
In all my searching, I have found only 1 viable MUD code base written in Python. It’s available at source forge , and anyone interested in it can find it themselves. I have a few reasons for not being satisfied with it, but I may get into that another time. First, I want to explain why this worries me.

The question, it seems, is why so many people set out with intentions of writing a Python code base for a MUD and never reach their goal. It could be that they don’t share my twisted sense of devotion to the idea. That doesn’t worry me. It could be that they don’t have the good fortune of having little else to do with their time. That seems to get a lot of coders, from what I read in forums. However, if the problem lies in some shortcomings on the part of Python, that’s a serious obstacle.

So, I’m left with this lurking sense of doom, because I’m not even certain Python is well suited for the task. I’m afraid I’ll hit the same wall that has stopped all those who have gone before me. Even though I’ve made great progress and I’m learning more about Python and how a MUD must function, I’m going into this blind. That’s no pun either. I didn’t know jack about Python when I started, but I just jumped in with both feet. It may be too late for me to stop now, being that I already have a working framework for my code base. I’ll just have to put my doubts aside and focus on my task at hand.

In the beginning...

2005-12-05T14:08:33Z

Having read over some of the content of this live-journal site, I signed up for a free account. I'm hoping to exchange ideas about MUDs, MUD coding, and the use of Python in every-day life. Today I have taken a step into the unknown, but who can know what tomorrow may bring?