revjim.net

February, 2003:

love and infatuation

Jess’ talk of the replacement of passion and Bonnie’s mention of infatuation being only for younger couples has brought a few thoughts to my mind.

I think we all crave to be craved. We all want someone to want us. We all want to be infatuated. And I don’t think that is something that disappears with age. At some time we’ve all heard someone say — either in regard to ourselves or in regard to someone else — “I just want something different”. I don’t think it is “different” that we seek. It is infatuation. It is excitement. It is our desire to be desired. We don’t want something “different” we just want what brought us to that person in the first place.

Regardless of how long two people have been together, and regardless of what stories or lies they will tell you, it is exciting to be flirted with. It is exciting to know that someone wants you. It is thrilling to know that someone desires something about you. And there is nothing wrong with that feeling. But to think that, with age, our desire to feel this way will fade is to believe a lie.

As couples grow older, many of them find new and interesting ways to be infatuated with their partner. Others are still infatuated with the same things that infatuated them in the first place. These are both good things. However, in some cases, we find ourselves “growing up” and learning to cope without that infatuation. But all we’ve done, in this case, is to suppress one of the very things that make us human beings, and, in the end, we will find ourselves very unhappy or very numb.

Let me be clear about this: I’m not saying that it’s okay to “cheat”. And I’m certainly not saying that every relationship has a pre-determined lifetime and that it should be discarded once it has expired. There are many facets to a happy, engaging, infatuating, desirable relationship and they all play into its success or deterioration.

As a relationship matures, some of those things that made us tingle deep inside will fade. That’s a given. It just isn’t possible to maintain those things and still find ourselves in a growing relationship. But that doesn’t mean that the infatuation disappears. It merely means we find new things to be infatuated with. In the beginning, just the mere thought of speaking to that person on the phone would shoot warm tingles all over our bodies. We’d find ourselves nervous, and stuttering and, when the phone call was over, analyzing every word we said and kicking ourselves for not saying things a little bit differently, or, in some cases, for saying anything at all. But imagine, for a second, if that never faded — if we still got that same, wonderful, magical tingly feeling with every phone call. Would be be able to hold the mature, fulfilling, satisfying, erotic, intelligent, thought provoking, heart warming conversations that we have today? Since we’d spend 90% of the phone call trying to keep the phone from slipping out of our sweaty palms, probably not.

It’s not important to maintain every single thing we’ve ever been infatuated with about a person. Instead, we should remember how amazing those things were, and allow them pass naturally and be replaced by even more amazing and fulfilling things. Just because every kiss doesn’t feel the same as the very first kiss you ever shared doesn’t mean it’s time to call it quits.

Deciding when a relationship is “over” is one of the more difficult things to do. And it isn’t something that you can be taught in a 2 day seminar, or something that you can read in a book, regardless of the author. It’s ultimately up to you (and your partner) to decide when enough is enough. But it should be known that force, ultimatum, lavish offers, imaginary promises and all-out begging generally don’t do much good. We want things to work out. We want this one to be “the one”. And, oftentimes, we’ll do whatever it takes to try to make that happen. And that is a very noble mind-set to hold. However, there comes a time when trying to hold things together is actually making it worse. And it is important that both partners retain enough of themselves and their own sense of security to see when that point has come, to acknowledge it, and to move on.

Love isn’t easy. And there aren’t any rules or a nice neat handbook that we can refer to. A guy might send an email to a girl he was interested in and tell her that he’d like to meet her for a cup of coffee only to be turned down. Then, a few days letter, send an almost identical email to a different girl and find himself sharing a cup of coffee with her that evening and waking up with her the next morning.

Don’t think for one second, however, that, if the person you’ve found is the “right” person, that everything will progress perfectly without a hitch. Love doesn’t work like that either. But, when you find that person that continues to infatuate you, even when he pisses you off, you’ll know that, regardless of how hard some days are, being without him isn’t an option. And he’ll know that too.

Oftentimes, it is easier for us to accuse our partners of being the reason things aren’t working out than it is for us to accept the blame ourselves. It is easier for us to say “You aren’t infatuated with me anymore” instead of saying “I don’t infatuate you any longer”. Sometimes we’re right. Sometimes it is their fault. Sometimes we’re sure we’ve done everything we can and our partner just doesn’t desire us any longer. If you think you’ve come to that point, there’s only one way to be sure: ask.

dreamhost

I’m about to sign up for a DreamHost account with the intent of transferring my blog and all of my domains to it. If there is any reason you believe I shouldn’t, please speak now or forever hold your peace.

Ugh.

Apparently the upgrade to MT 2.61 isn’t the only thing that is causing my “Out of Memory” errors. Because I’m still getting them every now and then when using 2.51. This leads me to believe that the reason behind this is my recent import of over 1500 entries from LiveJournal. This means the MovableType is probably loading some portion of that data into memory and leaving it there while it attempts to rebuild a page. That isn’t really a good idea.

Suggestions? Solutions? Crack cocaine?

easier to use or more flexible?

I’ve run into another stumbling block in my coding of inklog, and I’m not exactly sure how to proceed. I know HOW to code the problem fifty different ways, I just don’t know which way is best. And it is a very important design choice, as the rest of the application will use the same principles. “Let me explain; no, there is too much; let me sum up.”

On each “page”, one has the ability to place multiple components. I’m not sure if each component should have its own template and be parsed separately (making the system easier to use, but less flexible), or if all the datashould be collected and shipped to one template per page. Additionally, I’m not sure if I should place the component reqestors inside the template locking the user into the template system of my choice and providing each piece of a template to be capable of existing on its own (easier to use), or if the components should be requested by the calling page making each piece of the template have knowledge of the request that is parsing it but, therefore, not tie the user to my template system (more flexible).

So I guess, what it boils down to is this: should I make it easier to use, or more flexible?

upgrade, downgrade, write your own

This morning I upgraded MovableType to the NEW version 2.61, then it broke. Some how, while my server is very capable of running MovableType 2.51 and has done so without error for some time, version 2.61 causes my Perl interpreter to issue “Out of memory” errors. Yay!

So, I’ve downgraded back to 2.51. The new features weren’t that great anyway. Really, the only reason I was upgrading was to check out the undocumented feature [via phil ringnalda], but it turns out it isn’t much anyway. I also patched MovableType to fix its new found vulnerability.

The good thing is that this has prompted me to begin coding inklog again. (By the way: I really dislike that, as of today, Phil‘s mention of inklog earns a higher google result number than my own. Hopefully, this entry will fix that.)

LiveJournal to MovableType migration

If you didn’t notice, the revjim.net archives now contain data from April of 2000 through August of 2002 (which is when I started using MovableType). While most of the data converted cleanly, I’m relying on MovableType to do it’s “Convert Breaks” magic on many of the imported entries because they were entered in plain text originally. MovableType fails at this in certain circumstances, so every page might not validate as XHTML 1.0. If you see any that don’t, let me know, and I’ll do my best to get them all cleaned up.

The import process was rather interesting. I initially created a small PHP script that would grab the entries one at a time from their former location (LiveJournal) using XMLRPC, and then insert them into MovableType using XMLRPC. MovableType was way too slow with this method. Most entries were taking about one minute to publish, while others took considerably longer. I even disabled all of my indexes, all of my pings, and TrackBack autodiscovery. But that didn’t seem to make a difference. After about six hours of time, and several instances of MovableType returning XML-RPC faults, I decided to go a different route.

I had my script generate a MovableType import file. Running it took less than two minutes and, when it was complete, I had an importable file ready to go. MovableType gladly took that, however, I still had to rebuild. Since I have over 2000 entries now, rebuilding takes quite some time.

If anyone else is considering migrating LiveJournal data (or any kind of data) into MovableType, I recommend using the Import feature, and not trying to insert them directly.

importing entries

I’m about to do an import of a bunch of archived weblog entries. If the site is slow for a while, that’s why.

breaking Columbia news from SPACE.COM

Apparently, SPACE.COM, a “web site that offers rich and compelling content, included space business news, information, education, and entertainment”, produced by “the premier multimedia company dedicated to space, science and technology”, believes that the Columbia Tragedy was planned by NASA. Furthermore, they state that the Starfire Optical Range is actually a factory that produces shoes by exploiting children. Finally, SPACE.COM states that the Columbia shuttle debris investigation is being conducted primarily by topless women who have a particular liking for yours truly.

Perhaps SPACE.COM should consider the implications of allowing user submitted data to display itself directly on their site.

If you are a web programmer, you should probably take a few notes here. Don’t let this happen to you. Never allow user submitted data to reach the face of your website unless you intend for it to and, even then, never trust that data.

Eocene: Another PHP based MVC framework

I vowed to myself that I wouldn’t get excited the next time I saw a PHP project with some promise. However, I jumped a little when I saw Eocene: a MVC framework for PHP. Just like the others, it seems to be well written and built with good intentions, however, it shares the same three flaws that the rest do.

First of all, it’s method of invocation is not programmable. In the case of Eocene, a member of the $_GET array must be do. The value of this member holds the name of the command to be performed. Instead of having the Framework itself decide what action was called, the name of the action should be passed into the framework. This way, figuring out what action was called is easily modifiable by someone who wishes to use the system in a slightly different manner.

Secondly, there are very few examples to truly demonstrate the functionality of the system. What little information is available is not well documented.

Finally, the developer of the project is claiming that he has little to no time to make changes, fix bugs, write additional documentation and generally support the application in its infancy.

Just like the others, it looks well written and very functional. I just wish it didn’t have the same three drawbacks the the rest of them do.

you know it’ll be a good day when…

You know it’ll be a good day when you get into work and, before you can even sit down at your computer, your boss asks you to hack the password for a user account on a remote system.

It only took me about 15 minutes thanks to WS_FTP’s horrible concept of security. And I did it in PHP.